Hobbybrauer.de

So habe ich mir das gewünscht

lg Herbert

Ja genau, alls nur für Herbert

du bist soooo nett zu mir

Aber ich kann nur sagen -es funktioniert jetzt auch bei großen Kolben extrem gut auf hohe Boost-Drehzahlen zu fahren und wie du schön im Video gezeigt hast viel Sauerstoff einzubringen.
Ein ganz kleiner "Wunsch" ist ja noch da aber nur für Leute mit extrem schlechter Netzversorgung, dauernden Stromausfällen ......

lg Herbert

glassart hat geschrieben: ↑Mittwoch 6. März 2019, 09:39 Ein ganz kleiner "Wunsch" ist ja noch da aber nur für Leute mit extrem schlechter Netzversorgung, dauernden Stromausfällen ......

Du hast ja sicher schon bemerkt das ich das bisher erfolgreich ignoriert habe

ja sicher, ist ja wirklich nicht so wichtig

lg Herbert

Für die die jetzt nur Bahnhof verstehen: Herbert hatte sich gewünscht das nach einem Stromausfall die Boost-Funktion wieder eingeschaltet wird falls sie das vorher war

ich wollte ja nur die Hefe mit sauerstoffreicher Würze verwöhnen

lg Herbert

aber wie schon gesagt, ist dies wirklich nicht so wichtig wenn der Aufwand zu groß dafür ist

Im Endeffekt musst du alles im EEPROM speichern. Damit du bei nem Neustart, wenn die Spannung wieder da ist alles noch passt. Brownout muss auch aktiv sein damit das EEPROM nich kaputt geht wenn geschrieben wird und die Spannung ausfällt.

Die Daten alle in nen Struct und den dann zum uint8_t Pointer casten und bytweise ins EEPROM.

Du brauchst dann noch ne Option das an und auszuschalten. Das bläht den Code schon auf.

Gruß Jackfrost

Jack, es wird bereits alles mögliche gespeichert. Nur nach einem Stromausfall wird nicht wieder der Boost-Modus gestartet sondern der Normal-Modus

Ok dann ist mein Post hinfällig.

Gruß JackFrost

Update: https://github.com/micworg/stir/releases/tag/v1.5.0

Neu:
- es gibt jetzt eine API und man kann den Rührer über USB/Seriell steueren
- Quelltext gründlich aufgeräumt

Und noch eins: https://github.com/micworg/stir/releases/tag/v1.5.1

- Kleine Fehler behoben
- Beispielscript für die API hinzugefügt

Noch ein Update: https://github.com/micworg/stir/releases/tag/v1.5.2

habe noch einen Ausschalttimer hinzugefügt.

Das wird ja langsam inflationär :) Meinen "Prototypen" habe ich am Wochenende zusammengestöpselt. Dass er sporadisch Anlaufprobleme hat und eine 4stellige IST-Drehzahl anzeitg schiebe ich mal auf die fliegende Verdrahtung.

Michael, was hast du mit dem Timer vor bzgl. der Laufzeit - in welchen Zeiteinheiten ist der programmiert ? Stunden, Minuten ?

Aber läuft alles sehr gut und du hast am Sketch ziemlich aufgeräumt während wir und auf der HBCON "vergnügt" haben ( soweit das ein Laie beurteilen kann)
Ganz toll funktioniert jetzt der langsame Hochlauf bei großen Gefäßen

lg Herbert

so wie es aussieht sollten es Stunden sein da sich bei mir nach 2 min noch nichts an der Anzeige geändert hat

Der Ausschalttimer ist in Stunden, wird sofort aktiv. Wenn er auf 0 steht (das ist default) ist er nicht aktiv. Ich habe das als Option gedacht für die die gerne Dekantieren z.B.

Super Michael -das ist eine tolle Zusatzoption

flensdorfer hat geschrieben: ↑Montag 11. März 2019, 14:09 Das wird ja langsam inflationär :)

Ich verspreche das hört jetzt auf werde jetzt erstmal nur noch Fehler beheben.

flensdorfer hat geschrieben: ↑Montag 11. März 2019, 14:09Dass er sporadisch Anlaufprobleme hat und eine 4stellige IST-Drehzahl anzeitg schiebe ich mal auf die fliegende Verdrahtung.

Ich würde zuerst mal schauen ob alles an der richtigen Stelle angeschlossen ist. Hast Du die Pullup und -down Widerstände eingebaut?

So war das nicht gemeint :) Flashen geht ja schnell!
Widerstände sind eingebaut, statt 1x10k jeweils 2x 4k7. Richtig angeschlossen ist alles, im weiteren Ablauf pendeln sich beide Lüfter sauber aus den SOLL-Drehzahlen ein. wie gesagt, das scheint zu wackelig zu sein. Ganz ohne Widerstände hatte ich das auch schon so beobachtet.

kleines Update: https://github.com/micworg/stir/releases/tag/v1.5.3

kleines Update: https://github.com/micworg/stir/releases/tag/v1.5.4

Sehr gut!
Besten Dank für deinen Einsatz.
Wir sind gerade auch da dran.
Ist noch eine Heizung geplant?

Der Rührer kann die Temperatur nicht im Medium messen. Das erfolgt normalerweise über einen Tauchfühler, der über eine Art Galgen in das Medium geführt wird. Jedoch ist diese Lösung für uns nichts, weil so ein Tauchfühler durch die Koblenabdeckung geführt werden müsste >> Infektionsgefahr. Ohne Messen kann die Firmware die Temperatur nicht regeln.

Hier ein Kompromiss:
Als Heizplatte kannst du dir 2x 12V/10W Heizmatten unter jede Rührstelle kleben. Dann pro Rührstelle einen 3 Stufen Schalter einbauen, mit der du die Heizmatten aus, eine an oder zwei an schalten kannst. Damit kannst du die Temperatur vom Boden unter dem Kolben recht gut manuell kontrollieren. Funktioniert bei mir recht stabil und erfordert keinen Eingriff in die Firmware.

mwx hat geschrieben: ↑Mittwoch 13. März 2019, 09:37 kleines Update: https://github.com/micworg/stir/releases/tag/v1.5.4

Hi,
welche Version der LiquidCrystal_I2C Library verwendest du genau?
Ich würde die Tage anfangen den OLED Support einzubauen. Wäre es OK für dich, wenn wir die nötigen Libs einfach mit ins Projekt werfen? Dann muss niemand lange suchen.

Im Augenblick hab ich nicht vor eine Heizung in die Steuerung einzubauen, aber je nach Nachfrage kann sich das auch wieder ändern.

@Jens, so ähnlich hatte ich das auch vor, ich hatte eher an eine Heizpatrone gedacht (ähnlich wie im Grainfather Conical), geschaltet per Relais kann man eine sehr einfache Regelung auch hinbekommen.

Ich verwende diese hier: https://github.com/marcoschwartz/LiquidCrystal_I2C

Gute Idee die Libraries reinzupacken.

Du musst dann mal gucken wie Du mit dem Speicher hinkommst, der ist nämlich jetzt schon 83% voll ..

DerDerDasBierBraut hat geschrieben: ↑Mittwoch 13. März 2019, 18:23 Hi,
welche Version der LiquidCrystal_I2C Library verwendest du genau?
Ich würde die Tage anfangen den OLED Support einzubauen. Wäre es OK für dich, wenn wir die nötigen Libs einfach mit ins Projekt werfen? Dann muss niemand lange suchen.

DerDerDasBierBraut hat geschrieben: ↑Mittwoch 13. März 2019, 17:34 Der Rührer kann die Temperatur nicht im Medium messen. Das erfolgt normalerweise über einen Tauchfühler, der über eine Art Galgen in das Medium geführt wird. Jedoch ist diese Lösung für uns nichts, weil so ein Tauchfühler durch die Koblenabdeckung geführt werden müsste >> Infektionsgefahr. Ohne Messen kann die Firmware die Temperatur nicht regeln.

Hier ein Kompromiss:
Als Heizplatte kannst du dir 2x 12V/10W Heizmatten unter jede Rührstelle kleben. Dann pro Rührstelle einen 3 Stufen Schalter einbauen, mit der du die Heizmatten aus, eine an oder zwei an schalten kannst. Damit kannst du die Temperatur vom Boden unter dem Kolben recht gut manuell kontrollieren. Funktioniert bei mir recht stabil und erfordert keinen Eingriff in die Firmware.

Danke, hört sich super an!

WOW, ich bekomme Basteltrieb!

ist einfach nur genial das Teil

Danke nochmals Michael für deine Arbeit, mir fällt absolut nichts mehr ein was da noch hinzukommen sollte ( natürlich möchte ich Jens mit einem ganz tollen OLED-Design nicht bremsen, die Displays liegen gerade geliefert neben mir und die Einbaublende für OLED + Encoder ist auch schon gedruckt mit Encoder rechts )

lg Herbert

Jetzt hab ich Trottel mir mit meiner fliegenden wackeligen Freiluftverdrahtung mindestens die Ansteuerelektronik des LCD und auch noch nen UNO geschrottet
Lernen durch Schmerz, obwohl ich es ja besser können sollte. Naja, also Nachschub beim großen Fluss und auch gleich ein paar Lochraster mitbestellen.

Was haste denn am Uno gekillt ? Ggf kann man es ja tauschen , dann haste nen auf Reserve ?

Gruß JackFrost

Da hast Du bestimmt die 12V irgendwo angelegt ..

@ JackFrost: son kleiner fizzeliger SMD, das lohnt nicht, was eh ein Nachbau.
@ Michael: entweder das oder ich habe sense und control für nen Sekundenbruchteil gebrückt.

So, Uno und anderes LCD aus dem Fundus aktiviert und der Testaufbau läuft wieder. Ich beobachte allerdings ein komischen "Einschwingverhalten" von FAN2: egal woher eine Änderung der SOLL-Drehzahl kommt (manuell, Boost), die IST-Drehzahl sackt erst deutlich ab, dann greift die Regelung stark ein und die IST-Drehzahl schießt über das Ziel hinaus, sinkt dann aber auf SOLL ab. FAN1 ist derweil davon unbeeindruckt. Auch zeigt FAN2 oft 4stellige IST-Drehzahlen, die die Regelung dann massiv stören und bis zum Stillstand führen. Da bleibt der Lüfter ein paar Sekunden, bis die Regelung das bemerkt und die Drehzahl langsam hochfährt.

Auch wollen die Lüfter nach Anlegen der Spannung direkt hochdrehen, obwohl ich sie auf OFF gestellt hatte, bevor ich die Spannung abnahm.

Keine Ahnung, ob das am Testaufbau auf dem Breadboard liegt oder am UNO-Nachbau. Ich kann gerne mal ein paar Videos davon in eine Cloud schieben, falls das etwas hilft.

Hallo Arne,

Du könntest mal versuchen die Lüfter zu tauschen. Vielleicht hat Fan 2 eine Macke.

Überprüf bitte auch nochmal ob die Pull Widerstände richtig sind, also von Pin 2 und 3 jeweils 10k auf 5V und von Pin 9 und 10 jeweils 10k auf Masse.

Ich vermute Du hast kein Oszilloskop?

Am Breadboard-Aufbau kann es eigentlich nicht liegen, die Schaltung ist so primitiv das da keine Störungen zu erwarten sind (ausser vielleicht ein Wackelkontakt)

Du kannst ja auch mal Foto posten, manchmal sehen 1000 Augen mehr als 2

So, ich habe noch Wagoklemmen gefunden, damit hat sich das mit den merkwürdigen IST-Drehzahlen erledigt. Das Klemmbrett ist wohl nicht so dolle für solche Signale und/oder zu wackelig.
Was ich aber weiterhin beobachten kann ist, dass bei SPEED-Änderungen für FAN1 die IST-Drehzahl von FAN2 deutlich ansteigt um danach wieder auf den Sollwert einzuschwingen. Umgekehrt bleibt FAN1 bei SPEED-Änderungen für FAN2 völlig unbeeindruckt.

Ich nutze Version 1.5.4.

[edit] Aktivieren der BOOST-Funktion für FAN1 hat keine Auswirkung auf die IST-Drehzahl von FAN2.

Toll, meiner kann das auch Mir ist völlig unklar wieso das bisher nicht aufgefallen ist (nichtmal Supertester Herbert) .. ich habe den Fehler bereits gefunden, das Update kommt noch heute.

flensdorfer hat geschrieben: ↑Montag 18. März 2019, 08:35 Was ich aber weiterhin beobachten kann ist, dass bei SPEED-Änderungen für FAN1 die IST-Drehzahl von FAN2 deutlich ansteigt um danach wieder auf den Sollwert einzuschwingen. Umgekehrt bleibt FAN1 bei SPEED-Änderungen für FAN2 völlig unbeeindruckt.

So, hier das Update: https://github.com/micworg/stir/releases/tag/v1.5.5

Perfekt, Michael - Danke! Kann den Fix bestätigen.
Hatte mein Rumgefrickel ja doch etwas Gutes.

Michael, klar habe ich das gesehen aber ich kann doch nicht nur lästig sein
Aber recht viele Fehler sind sicher nicht mehr versteckt

lg Herbert

flensdorfer hat geschrieben: ↑Montag 18. März 2019, 12:07 Perfekt, Michael - Danke! Kann den Fix bestätigen.
Hatte mein Rumgefrickel ja doch etwas Gutes.

Absolut. Und schön das Dein Rührer nun auch läuft

glassart hat geschrieben: ↑Montag 18. März 2019, 12:26 Michael, klar habe ich das gesehen aber ich kann doch nicht nur lästig sein
Aber recht viele Fehler sind sicher nicht mehr versteckt

Der Arduino hat so wenig Speicher .. da ist gar kein Platz für viele Fehler

Zumindest meiner merkt sich nicht zuverlässig den ON/OFF-Zustand von FAN1/FAN2. Ich schalte immer beides auf OFF, bevor ich das Netzteil abziehe. Mal sind nach dem Einstecken des Netzteils nach einer beliebigen Zeitspanne beide wie erwartet auf OFF, mal nur einer und der andere dreht hoch auf Solldrehzahl (die korrekt gespeichert wurde) und mal sind beide ON und drehen hoch.

Das liegt daran das nicht immer sofort gespeichert wird, sondern nur alle 60 sec wenn sich was geändert hat. Das schont das EEPROM. Du kannst das Verhalten mit dem Parameter SAVEDELAY (Zeile 43) ändern. Gespeichert wird auch wenn Du die Sperrfunktion aktivierst.

hatten wir auch schon, Michael. Aber ich werde zum Schutz des EEPROM´s die Zeit so belassen denn im Normalbetrieb kommt es ja nicht vor dass man in kleiner 1 Minute was ändert und dann ausschaltet. Nur wissen muss man es um nicht verwirrt zu werden

lg Herbert

nochmals, einer der besten Zusatzoptionen ist die einstellbare Hochlaufzeit !!!

Ich bin noch nicht zum Löten gekommen. Bis ich mal wieder richtig Zeit habe ist der Betatest durch.
Danke Jungs

Alles klar, den Parameter hatte ich nicht auf dem Schirm. Also im Prinzip die Anzahl Sekunden aus SAVEDELAY warten, bevor man das Netzteil abklemmt.
RTIME habe ich auf 60 (s) stehen - bedeutet, dass die neue SOLL-Drehzahl innerhalb von 60s, also schon sanft, angefahren wird? Umgekehrt könnte man mit RTIME=0 oder <=20 ein sehr zügiges Hochdrehen bewirken?

Genau so ist es. Das wird allerdings nur dann aktiv wenn Du den Rührer von OFF auf ON stellst. Wenn Du einfach nur die Drehzahl änderst während er schon läuft funktioniert das nicht.

SAVEDELAY ist in Millisekunden, das kann Du auch problemlos auf 5000 stellen. Es ging nur darum das nicht bei jedem Drehimpuls gespeichert wird.

@ flensdorfer - genau, ich habe für den 5 L-Kolben die RTIME auf 180 s gestellt da es doch dauert bis die Masse in Bewegung kommt und man dann aber auch sehr hohe Boost-rpm fahren kann ohne dass das Fischchen einen vom Rand her "anlacht"

lg Herbert

bei mir ist ein Rührer "der Große, Langsame " und der zweite für 1 L und kleiner -auch bzgl. den Magnetabstände.

Alle 60 Sekunden zu speichern ist für den EEPROM auch nicht so gut. Das EEPROM kann mindestens 100.000 mal beschrieben werden bei 24h betrieb, sind das 69x 24h. Also ca. 35 Sude. Ich würde da auch ein 5V FRAM nehmen. Das kann 10^12 mal beschrieb/gelesen werden. Wenn es so was beim Ali nicht gibt, kann ich auf Wunsch auch was designen.

Gruß JackFrost

Ich schrieb ja 'alle 60 sec wenn sich was geändert hat' .. wenn kein Parameter geändert wird (also wenn keiner am Knopf dreht) wird auch nichts gespeichert. Also wenn Du 10 mal am Tag am Knopf drehst müßte es so ca. für 27 Jahre reichen :)