Labornetzteile mit Arduino programmieren

[DerDieter]

Hallo zusammen
Ich baue mir gerade ein Labornetzteile das digital über einen Arduino Mega CC CV CP verwalten kann.
Im Netz habe ich bisher kein annähernd passendes Beispiel gefunden.
Hardware mäßig läuft alles auch in den analog Teil super, hier werde ich nur noch Kleinigkeiten ändern.
Das Netzteil kann 30V und 10 Ampere. Wobei jedoch bei 10 Ampere Trafo bedingt dann bei 23 Volt die Grenze ist, aber das ist ok.
Vom Trafo werden 24V Wechselstrom bereitgestellt. Ich denke später darüber nach, bei geringer Spannung die Spannung im Eingansbereich zu verringern. Momentan Regel ich alles schon über deren Arduino.
Die Temperatur wird getrennt durch einen Uno gesteuert.
Da mein Code immer wieder erweitert, umgeschrieben, was neues dazwischen geschoben ist. Ist alles sehr sehr unstrukturiert, aber das ist beim testen normal. Irgendwann sind aber soviel Variablen, Funktionen teilweise unefektiv oder auch überflüssig. Dann fängt man am besten ganz neu an, alles von Grund auf neu zu programmieren.
So und da stellt sich vorab die berechtigte Frage? Hat vielleicht jemand schon einen guten Funktionsplan, der vielleicht besser ist, als mein Gedankengang, wo man Anregungen, und vieles mehr berùcksichtigen kann. Wenn jemand so etwas besitzt, teilt er ja vielleicht seine Ideen.
Im Netzteil steuern OPV den Strom und die Spannung, diese werden von 16 Bit über einen Mega angesprochen, ein INA Modul gibt mir im 16 Bit Bereich Rückantwort.
Ein Encoder steuert die Feineinstellung, eine kleine Tastatur kann direkt Strom und Spannungswerte vorgeben.
Zur Ausgabe hängen momentan 3 kleine OLED dran.
Es soll jedoch alles später auf ein 5 Zoll Nextion Display ausgegeben werden, auch hier ist dann eine Strom und Spannungsvorgabe möglich.
Das ist jetzt schon ein wenig aufwendiger und dafür würde ein Flussdiagramm eine gute Hilfe sein.
Da ich im Programmieren nicht so die Erfahrung habe, wäre ich hier für Tipps und Hinweise dankbar.
Mfg Dieter

[Holomino]

Hmm, meine letzten Displayanwendungen für Controller liefen immer nach dem gleichen Schema:

Eingänge (Peripheriewerte, Tastaturereignisse, Schnittstellentelegramme, Maskenwechsel und zeitgesteuerte Trigger für z.B. Animationen oder das Cursorblinken) festlegen und damit eine gemeinsame Schnittstelle für alle Bildschirmmasken definieren. Beispiel: Die Routine zur Abfrage der Tastatur ruft bei erkanntem Tastendruck die Funktion ActiveMask.KeyIn(int keyNum) auf.

Ausgänge (Displayinhalt, Peripherie-/EEPROM-Werte, LEDs, Buzzer, ...) in einzelnen Modulen abstrahieren und entsprechende Funktionen zur Verfügung stellen. Z.B. Display.WriteText(string s, int x, int y, bool reverse)

Zwischen Ein- und Ausgänge quetscht man nun die Bildschirmmasken. Objektorientiert würde man wohl zuerst eine Basisklasse mit abstrakten oder virtuellen Methoden für die Eingänge programmieren und anschließend die eigentlichen Bildschirmmasken jeweils davon ableiten. Mit Standard-C geht es über das Anmelden von Callbacks, also Funktionszeigern.
Letztlich aber leitet man so bei beiden Methoden über das Setzen der "ActiveMask" alle Eingänge auf die aktive Bildschirmmaske. Die Maske kann dann im Code selbst entscheiden, ob sie z.B. ein PeripherieValueChanged(pvData* data) überhaupt in der Ansicht hat und entsprechend reagieren muss.

Vom Programmablauf gesehen kannst Du Dir das dann so vorstellen:
Die Abfrage Deiner Eingänge per Loop oder Interrupt bilden das zeitliche Rückgrat Deiner Applikation (den Zyklus). Das Ergebnis der Abfrage eines Eingangs wird per entsprechender Funktion an die aktive Bildschirmmaske weitergeleitet, die ihrerseits Ausgänge manipuliert. Die Bildschirmmaske selber hat aber keine Loop und wartet auch nicht. Sie bremst also die Eingangsabfragen nicht aus. Einen Eingabewert aus mehreren Tastendrücken z.B. muss sie über eine Statemachine (max. Anzahl Eingabestellen + Eingabeüberprüfung) aus den einzelnen Aufrufen von KeyIn(int keyNum) zusammensetzen. Das ist zwar kompliziert, hat aber den Vorteil, dass man auf dem Display einen Sollwert editieren kann, während zusätzlich dargestellte Istwerte sich laufend aktualisieren.
Das gleiche gilt für die Ausgänge: Das Schalten einer LED verursacht sicherlich keine zeitlichen Verzögerungen. Beim Aktualisieren des gesamten Bildschirmes kann es Optimierungsbedarf geben (nur aktualisierte Bildschirminhalte ausgeben, ggf. das "Übersetzen" von Text in Pixel in die Loop der Eingänge übernehmen). Also auch diese Aufrufe kurz halten und nichts einbauen, was die Eingangsabfragen bremsen könnte.

[DerDieter]

Hallo Holomino, ich danke dir für deine Ausfühung.
Momentan ist das ganze bei mir so aufgebaut:
Das der Haupt-Sub den Ablauf ohne irgend ein Delaiy beständig durchläuft.
Der Encoder wird aber zusätzlich über Interrupt gesteuert und dient zur Feineinstellung von Strom und Spannung.
Dann wird die Tastatur abgefragt, falls Änderungen vorhanden sind wird ein Unterprogramm abgearbeitet.
Danach wird mit 16bit jeweils für Strom und Spannung der Wert ùber I2C der DAG (danach OP) eingestellt.
Dann ermittelt ùber I2C ein INA-Modul Strom und Spannung.
Die Aufrufe finden immer in Unterprogrammen statt.
Dann folgt das Unterprogramm für die OLED Ausgabe.
Was jetzt noch kommen muss wäre eine genaue Anpassung von der Spannung der sich ja bei verschiedenen Ampergrõßen ändert. Also ein Abgleich von Istvolt zu Sollvolt.
Der Kurzschluss und die Amperabweichungen werden analog vom Netzteil ùber OP und Shunt geregelt.
Auch habe ich CV CP und constant Wiederstand noch nicht berücksichtigt.
Was auf jeden Fall auch noch eingebunden werden soll ist ein 5" Nextion Display wo auch Vorgaben gemacht und die Ausgabe erfolgt.
Die OLED fallen dann weg die sind nur zum Testen