LabView-Programm-Struktur mit Annäherung zu den squenziellen Abläufen in TestStand

Hallo LabView-Gemeinde,

allg. Frage:
Kann mit LabView und einem Zustandsautomaten (State Machine) die Zustände von außen (z.B. über eine .csv-Datei und einem Zustandsautomaten) verändert/variiert werden -
also Reihenfolge und Anzahl? Benennung der Zustände (z.B. über TypDef) soll gleich bleiben.
Falls ja, welche Möglichkeit gibt es dazu?

Hintergrund ist:
Ich stelle mir die Frage, inwiefern kann mit LabView, die sequenziellen Abläufe von TestStand übernommen werden.

Ziel sollte sein:
Auf TestStand zu verzichten und in LabView eine angenäherte Struktur zu TestStand zu erhalten.

Ich weiß, dass die sequenzillen Abläufe mit TestStand z.T. einfacher und vorallem flexibler realisiert werden können.
Zum einen brauche ich diese "hoch"flexible Struktur nicht umbedingt und zum anderen ist die Software-Lizenz von TestStand auch nicht gerade günstig.

Ferner war meine Idee eine Queue-State-Maschine Struktur zu modifzieren/erweitern.
vgl. http://www.mezintel.com/blog/labview-que...e-machine/

Vielen Dank im voraus.

Thomas

Anzeige

Hallo t.,

Zitat:Kann mit LabView und einem Zustandsautomaten (State Machine) die Zustände von außen (z.B. über eine .csv-Datei und einem Zustandsautomaten) verändert/variiert werden -
also Reihenfolge und Anzahl? Benennung der Zustände (z.B. über TypDef) soll gleich bleiben.

Ja.

Zitat:Falls ja, welche Möglichkeit gibt es dazu?

Als ersten State deiner Statemachine ("init") lädst du eine externe Datei (wie dein CSV). In dieser Datei steht dann drin, welche weiteren States ausgeführt werden…

Im Grunde erstellst du dir so einen einfachen Interpreter für deine persönliche Programmiersprache. Ich habe das mal für einen kleineren Prüfstand (Druck-/Temperatur-Tests an Sensoren) gemacht und alle wichtigen Vorgänge darüber automatisiert. Mit etwas Programmieren kann man auch Schleifen (wie "Drücke von 1.0 bis 10.0 bar in 1.0bar-Schritten") erlauben… Dann dem User noch einen Konfigurator programmieren, mit dem er die meisten Testabläufe selbst erstellen kann und das Ergebnis dieser Konfigurationen dann in die später verwendeten CSV-Dateien (oder Text, oder "Batch") speichern!

Super! Echt sehr interessanter und durchdachter Ansatz. :-)

Ich stell mir gerade die Frage, wie hast du die Schnittstelle zwischen der csv.-Datei und den States realisiert.
Hast du da eventuell ein Beispiel? Arbeitest du da auch über TypDef?

Muss mich in die Thematik die nächsten Wochen erstmal weiter reinarbeiten, aber das wäre genau der Lösungsansatz. :-)

Echt stark! Das Speichern würde dann bei mir erst in den nächsten Schritten kommen...

Hallo t.,

Zitat:Ich stell mir gerade die Frage, wie hast du die Schnittstelle zwischen der csv.-Datei und den States realisiert. Hast du da eventuell ein Beispiel? Arbeitest du da auch über TypDef?

Du musst die CSV-Datei natürlich parsen, d.h. die Befehle wieder einlesen und auf Gültigkeit prüfen.
Beim genannten Beispiel hatte ich mit einem Array von Befehlen gearbeitet, man könnte auch mit einer Queue arbeiten. Die Statemachine holt sich immer einen Eintrag aus dem Array und kann bei Bedarf (Schleifen…) auch neue Befehle ins Array schreiben - gerne auch an beiden "Enden"…
Ob man die States jetzt über ein Typdef oder Strings aufruft, ist relativ egal: du musst sowieso die Befehle schon vorher auf Gültigkeit prüfen!