Netzteil Programmierung

Guten Tag,

ich bräuchte Hilfe zu paar allgemeinen Fragen.
Ich möchte ein Netzteil über TCP/IP ansteuern und mittels SCPI programmieren, um einen Prüfstand darüber zu betreiben.

Der User wird u.a. erstmal aufgefordert Spannung, Strom und Laufzeit einzugeben. Und es soll möglich sein mehrere Messungen hintereinander automatisch ablaufen zu lassen. Bedeutet er kann mehr Datensätze auf einmal eingeben und diese werden dann nacheinander bearbeitet.

Meine Idee war es, dass der User anfangs erstmal wählt wieviele Messungen er durchführen möchte. Dies sollte die Array-Zeilen-Anzahl bestimmen. Danach gibt er für jede Messung die Daten zeilenweise in das Array ein und am Ende drückt er auf Start und die Messungen werden nacheinander abgearbeitet.
Sprich das Array wird je Schleifendurchgang zeilenweise ausgelesen. Die ausgelesenen Werte als SCPI-Befehl an das Netzgerät geschickt. Dann das Go gegeben, anschließend z. B. eine Minute gewartet, bis der nächste Befehlssatz übermittelt wird. Und das in einer Schleife solange, bis alle Array-Zeilen abgearbeitet wurden.

Meine Frage, ist dies möglich?
Ist es schlau dafür Arrays zu benutzen?
Wie setze ich die Laufzeit, welche der User für jede Einzelmessung individuell bestimmen kann, am besten um? Ich denke ein normales "Wait" oder "Time Delay" wird nicht funktionieren.

Ich danke schon mal für eure Hilfe.

Anzeige

(01.02.2024 14:02 )SirTom schrieb:  Meine Frage, ist dies möglich?

Klar, LabVIEW ist eine vollständige Programmiersprache.

(01.02.2024 14:02 )SirTom schrieb:  Wie setze ich die Laufzeit, welche der User für jede Einzelmessung individuell bestimmen kann, am besten um? Ich denke ein normales "Wait" oder "Time Delay" wird nicht funktionieren.

Nimm eine StateMachine mit zB folgenden Zuständen:
(1) UserInput: der Nutzer bekommt einen Dialog, indem er seine Messpunkte eingeben kann
(2) InitDevice: Öffnen der TCP-Verbindung zum Netzteil und evtl. Startbefehel schicken, zB *CLS, *RST
(3) StartMeasurement: setze via SCPI Spannung und Strom
(4) WaitMeasurementTime: warte die Messzeit ab
(5) NextPoint: wenn weitere Messungen -> (3) sonst -> (6)
(6) End: Schließen der TCP-Verbindung

zu (1): Erstell ein SubVI, indem der Nutzer in einem 2D-Array seine Messpunkte eintragen kann.

Edit: @Mods: ich denke das sollte verschoben werden, da hier wahrscheinlich kein CodeBeispiel entsteht.

Vielen Dank, für die ausführliche Antwort.

Macht es aufgrund der StateMachine Sinn, beim zeilenweisen Auslesens des Arrays, die Werte erst in ein Daten-Cluster zu packen, dieses als Data-Shift-Register durch alles States zu schicken, um besseren Zugriff in den Zuständen "(3) StartMeasurement" und
"(4) WaitMeasurementTime" zu haben?

Machen wir auch so, außerdem hast du ja noch andere Daten die du ins Cluster packen kannst, z.B. die TCP-Verbindung zum Netzteil oder den Index des aktuellen Messpunktes. Dadurch brauchst du keine lokalen Variablen und das Blockdiagramm sieht aufgeräunter aus.

Die Messwerte würde ich komplett als 2D-Array ins Cluster packen, wenn der Nutzer sie in (1) eingegeben hat. In (3) und (4) greifts du mit der IndexArray-Funktion und dem Index auf die Werte der aktuellen Messung zu und in (5) kannst du prüfen, ob der Index > Anzahl Zeilen im Array ist, um zu entscheiden, ob du fertig bist.

Nochmals vielen Dank.

Verstehe ich das richtig, dass während der Wartefrist, im Zustand (4) WaitMeasurementTime, keine Änderungen der Einstellungen möglich sind?

Auf Spannung und Strom hätte ich gern durchgehend Zugriff ohne unbedingt die Messung zu unterbrechen.
Brauche ich dafür einen parallelen Thread?

Hallo Tom,

Zitat:Verstehe ich das richtig, dass während der Wartefrist, im Zustand (4) WaitMeasurementTime, keine Änderungen der Einstellungen möglich sind?

Die Einstellungen gehören in den Cluster mit den StateMachine-Daten, du hast also in jedem State darauf Zugriff und Änderungsmöglichkeit…
(Warum will man während einer Wartezeit Einstellungen ändern?)

Zitat:Auf Spannung und Strom hätte ich gern durchgehend Zugriff ohne unbedingt die Messung zu unterbrechen.
Brauche ich dafür einen parallelen Thread?

Sind das Messwerte oder Einstellungen?

Es geht mir rein um die Einstellung von U und I auch während der Messung, ich möchte diese auch während der Messung umstellen können.
Auf Einstellungen wie Output-Modus, obere/untere Grenzen brauche ich keinen Einfluss und die werden auch während der Messung ausgegraut/nicht bedienbar gemacht.

---

(05.02.2024 07:44 )GerdW schrieb:  Die Einstellungen gehören in den Cluster mit den StateMachine-Daten, du hast also in jedem State darauf Zugriff und Änderungsmöglichkeit…
(Warum will man während einer Wartezeit Einstellungen ändern?)

Ich dachte man hat über den Cluster nur Zugriff auf die aktuell eingestellten Werte, nicht jedoch auf die Funktion, um diese zu ändern. Ich müsste also erst aus dem Warte-Zustand in den Init-Zustand wechseln, vllt über eine Event-Struktur. Aber unterbricht dieses Vorgehen nicht die Messung, bzw. beeinflusst die Wartezeit?
Würde es funktionieren die Funktion zum Einstellen von U und I als SubVI einfach auch in den Warte-Zustand zu packen?

Hallo Tom,

Zitat:Ich dachte man hat über den Cluster nur Zugriff auf die aktuell eingestellten Werte, nicht jedoch auf die Funktion, um diese zu ändern. Ich müsste also erst aus dem Warte-Zustand in den Init-Zustand wechseln, vllt über eine Event-Struktur. Aber unterbricht dieses Vorgehen nicht die Messung, bzw. beeinflusst die Wartezeit?
Würde es funktionieren die Funktion zum Einstellen von U und I als SubVI einfach auch in den Warte-Zustand zu packen?

Vielleicht brauchst du ja "nur" einen weiteren State zum Anpassen von U/I anstatt das Netzteil komplett neu zu initialisieren?
Ob deine Messung dadurch unterbrochen wird, musst du anhand des Treibers für dein Netzteil/DMM selbst überlegen.
Ob deine Wartezeit beeinflusst wird, hängt von der Art&Weise ab, wie du sie implementierst. (Und natürlich auch von deinen Genauigkeitsanforderungen an die Wartezeit: wenn du auf 1ms genau warten willst, aber gleichzeitig Gerätekommunikation im Bereich von 100ms einbaust, dann könnte es Unstimmigkeiten geben...)

Ok, danke. Welche Art von State Machine wird verwendet, wenn man erst ganz normal die Einstellungen des Netzteils über LabVIEW bedienen möchte und zusätzlich den oben erwähnten "Messreihen-Modus"?

Ich hab was von "Queued state machine" gelesen bzw. "Event Driven State Machine". Könnt ihr mir dazu bitte Ratschläge geben?

Auch habe ich noch Probleme bei absoluten Grundlagen.
Die einzelnen Funktionen stehen soweit, z. B. auch das Setzen von Einstellungen mittels .csv-Datei. Aber ich habe keine Ahnung wie ich die einzelnen Funktionen in eine State Machine einbinde.

Ich möchte halt keine Sequenz-Struktur, bei der jede einzelne Einstellung nacheinander immer komplett abgefahren wird, sondern nur diese eine Einstellung, die wirklich vom User eingegeben wurde, ausgeführt wird.

Wie setze ich das um? Packe ich die einzelnen Funktionen in eine Event-Struktur die sich wiederum im Zustand "Einstellungen"befindet? Ich habe gelesen, dass Event-Strukturen innerhalb einer State Machine schlechter Programmierstil sein soll. Statt dessen sollte die State Machine in einer Event-Struktur eingebettet werden und jegliche User-Eingaben im "Timeout" erfolgen.

Hast du dir den Link zu dem Artikel über StatesMaschine aus meinem erstem Post angesehen?

Ich würde mit einer einfachen StateMaschine anfangen, bei der die Zustände über Enums definiert werden. Andere Varianten wie Queue- oder Event-driven braucht man erst, wenn man den Zustand von außerhalb ändern möchte, zB aus einem parallel laufenendem Programmteil.

Deine bereits funktionieren Funktionen rufst du in den entspechenden States auf. Eine Sequenzstruktur brauchst du nicht.