Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
20.12.2021, 23:20 (Dieser Beitrag wurde zuletzt bearbeitet: 20.12.2021 23:24 von ar7ur8.)
Ich bin noch immer recht neu in LabVIEW und versuche gerade eine Anwendung zur Automatisierung von Dauermessungen zu erstellen. Dabei geht es vor allem um Messungen die aus 2-5 Schritten bestehen und in bestimmten Zeitabständen (stündlich, täglich usw.) wiederholt werden müssen.
Um dies zu realisieren wählte ich zunächst den Ansatz einen Queued Message Handlers, indem ich die Queue mit Array Inhalten (bestehend aus einem Cluster mit einem Enum zur Schrittauswahl, einem Integer zur Auswahl Anzahl und einem Integer zur Auswahl der Wartezeit) fütterte. Dieser Ansatz funktioniert auch ziemlich gut, bis auf einige Funktionen, die dadurch nur bedingt möglich sind. Und zwar: mein größtes Problem ist, dass die einzelnen Messungen (Lagerstrom/Spannungsmessung, Impedanzmessung) und die anderen Vorgänge während der laufenden Dauermessung nicht einzeln ausgeführt werden können, auch wenn sie nicht verwendet werden. Mir ist natürlich klar, dass das aufgrund der Casestruktur so ist, also habe ich zunächst versucht bei den Einzel-Events die Schritte mittels "Element vorne einfügen" in die Queue zu füttern. Das funktioniert zwar, jedoch wird der Vorgang erst ausgeführt, wenn der aktuelle Vorgang fertig ist (falls eine längere Wartezeit geplant ist - unbrauchbar). Ich habe alles nach Antworten durchgesucht und auch die LabVIEW Core 1-3 Learnpaths durchgemacht, ohne eine bessere Idee zu finden als die, die ich heute aufgebaut habe.
Bei diesem Ansatz befinden sich die einzelnen Messungen (und andere Vorgänge) in separaten While-Schleifen mit Case-Strukturen. Diese werden dann mit Hilfe von Meldern ausgeführt. Die Meldungen für einzelne Ausführungen werden dabei aus der Event-Struktur gesendet. Die Meldungen bei einer Dauermessung werden mit Hilfe eines QMH (fast nach dem alten Entwurf) in Form von User-Events (für die zuvor genannte Event-Struktur) generiert. Insgesamt habe ich also drei Haupt-While-Loops, die für die Ausführung zuständig sind und sieben weitere While-Loops mit den Messungen/Vorgängen.
Mir ist bewusst, dass ich mit diesem Ansatz gegen viele Richtlinien von LabVIEW verstoße und ich bin deshalb auch selbst unzufrieden mit meiner "Lösung", auch wenn sie (zumindest für mich) zu funktionieren scheint. Nach nun knapp zwei Wochen muss ich allerdings zugeben, dass mir keine bessere Lösung einfällt und suche deshalb hier nach Hilfe.
Beim Aufruf der "notifier_main - Kopie.vi" führt der Start-Button eine Dauermessung mit der im Array ausgewählten Reihenfolge aus. Die LEDs sollen dabei die Ausführung der einzelnen Messungen/Vorgänge andeuten. Rechts neben den LEDs kann die Einzelausführung vorgenommen werden.
Ich hoffe, dass ich mein Problem, sowie die Ansätze verständlich rüberbringen konnte und bin für jede Anregung/Kritik offen und dankbar.
Artur
PS: das angehängte VI ist bei weitem nicht fertig und soll lediglich Architektur testen. Ich bitte fehlende Stopp-Buttons, sowie die nur einmal vorhandene Occurance zu entschuldigen.
Zitat:Das funktioniert zwar, jedoch wird der Vorgang erst ausgeführt, wenn der aktuelle Vorgang fertig ist (falls eine längere Wartezeit geplant ist - unbrauchbar).
Ich habe jetzt nicht in deine VIs geschaut, aber mal eine allgemeine Anregung:
Wenn man 1000s warten will, kann man das so machen:
1. man wartet 1× 1000s
2. man wartet 20× 50s
3. man wartet 50× 20s
4. man wartet 1000× 1s
Such dir eine (für deine Anforderungen) passende Option aus…
erstmal vielen Dank für deine Antwort, ich denke das könnte der richtige Ansatz sein. Allerdings ist mein Dauermessung-Aufbau mmn derzeit nicht dafür geeignet. Beim letzten Ansatz des QMH habe ich die Vorgänge direkt in der Event-Struktur in die Queue eingefügt. Wenn ich nun aber den Vorgang mehrmals ausführen möchte, verändere ich die Anzahl der Schleifenausführungen und passe die Wartezeit an (Stunden, Minuten, Sekunden). Somit läuft diese Schleife eine bestimmte Zeit (was ja auch alles andere als optimal ist in der Event-Struktur). Selbst wenn ich jetzt eine Reihe von "Warten (1s)" Vorgängen habe - die am Anfang eingefügten Vorgänge werden erst bei der nächsten Ausführung erfasst und ausgeführt.
Ich nehme an, dass ich den Aufbau der Dauermessung überarbeiten müsste, habe aber noch keine andere Lösung.
Edit GerdW: Anhänge immer direkt im Forum anhängen!
21.12.2021, 10:41 (Dieser Beitrag wurde zuletzt bearbeitet: 21.12.2021 11:01 von GerdW.)
Zitat:Somit läuft diese Schleife eine bestimmte Zeit (was ja auch alles andere als optimal ist in der Event-Struktur).
Hier liegt dein Grundproblem!
Ein Event sollte immer so schnell wie möglich abgearbeitet werden! Wenn du dagegen eine stundenlange Wartezeit einfügst, wird dein Programm nie vernünftig funktionieren…
- Das Aufrufen einer "Ablauf Dauermessung" sollte ein anderes Event sein als das Warten auf den nächsten Step. Keine geschachtelten Schleifen im Event!
- Ein "Wait ms" mit einer Wartezeit im Stundenbereich sollte NIE verwendet werden, egal ob in einem Event oder nicht…
(21.12.2021 10:41 )GerdW schrieb: - Das Aufrufen einer "Ablauf Dauermessung" sollte ein anderes Event sein als das Warten auf den nächsten Step. Keine geschachtelten Schleifen im Event!
okay, dann werde ich das wohl überarbeiten müssen.. passt der allgemeine QMH Aufbau dafür, oder muss ich da eine andere Lösung suchen? Momentan weiß ich leider nicht wirklich wie ich das umsetzen soll..
Zitat:- Ein "Wait ms" mit einer Wartezeit im Stundenbereich sollte NIE verwendet werden, egal ob in einem Event oder nicht…
Das war mir leider bis jetzt nicht ganz klar. Was ist denn die "best practice" für solche Fälle?
Eine andere Frage die mich außerdem beschäftigt ist die Eingabe des Programmablaufs. Momentan wird diese ja durch ein Array Bedienelement gemacht. Nach längerer Verwendung merke ich allerdings, dass es nicht die beste Lösung ist weil:
- die Reproduzierbarkeit fehlt
- zu wenig Eingabeparameter (und alle gleich für jeden Schritt)
ideal wäre es mmn, wenn ich so etwas wie ein Skript (CSV oder INI Datei) erstellen könnte, bei dem ich die Schritte sowie die jeweils dafür notwendigen Parameter festlege. Dieses Skript wird dann quasi "abgearbeitet".
Gibt es dafür eine Möglichkeit oder werde ich da nicht weit kommen?
Zitat:Das war mir leider bis jetzt nicht ganz klar. Was ist denn die "best practice" für solche Fälle?
Das hatte ich doch oben schon geschrieben: statt einmal 1000s zu warten kann man auch 1000× 1s warten. Oder man wartet bis zu einem bestimmten Timestamp, natürlich auch mit 1s-Intervallen…
Zitat:ideal wäre es mmn, wenn ich so etwas wie ein Skript (CSV oder INI Datei) erstellen könnte, bei dem ich die Schritte, sowie die jeweils dafür notwendigen Parameter festlege. Dieses Skript wird dann quasi "abgearbeitet".
Gibt es dafür eine Möglichkeit oder werde ich da nicht weit kommen?
Nimm eine CSV-Datei und lese sie ein.
Dann "einfach" die Daten aus der CSV-Datei entsprechend deiner Requirements parsen und in eine sinnvolle (programm-interne) Datenstruktur packen…
wenn ich richtig verstehe, muss dann nach jeder Sekunde ein neues Event mit dem Vorgang "Warten 1s" kommen? Müsste dafür nicht auch eine For-Schleife mit einer bestimmten Iterationsanzahl verwendet werden?
In diesem Fall wäre während dieser Ausführung ja auch die Case Struktur "geblockt".
Ich bitte mich zu entschuldigen, falls ich etwas nicht richtig verstehe. Stehe nur mittlerweile ein wenig auf dem Schlauch bei diesem Thema..
(21.12.2021 11:41 )GerdW schrieb: Nimm eine CSV-Datei und lese sie ein.
Dann "einfach" die Daten aus der CSV-Datei entsprechend deiner Requirements parsen und in eine sinnvolle (programm-interne) Datenstruktur packen…
Okay, das hört sich schon mal gut an. Gibt es auch die Möglichkeit die csv-Datei in LabVIEW zu erstellen, bzw. zu bearbeiten (nur bestimmte Werte in bestimmte Felder)? Auf diese Weise könnte ich sicherstellen, dass auch andere Benutzer das Programm bedienen und eigene Abläufe generieren können.
Wäre in diesem Fall vielleicht so etwas wie ein "Schritt hinzufügen" Fenster sinnvoll, bei dem man den zunächst die Messung auswählt und abhängig davon dann die möglichen Parameter gewählt werden können?
Diese Daten könnten ja dann der bereits vorhandenen oder neuen csv-Datei angehängt werden oder?
Zitat:wenn ich richtig verstehe, muss dann nach jeder Sekunde ein neues Event mit dem Vorgang "Warten 1s" kommen? Müsste dafür nicht auch eine For-Schleife mit einer bestimmten Iterationsanzahl verwendet werden?
In diesem Fall wäre während dieser Ausführung ja auch die Case Struktur "geblockt".
Verwendest du einen QMH oder eine "event-based statemachine"?
Wenn du, wie geschrieben einen QMH verwendest, dann schickst du einmal einen Befehl "Wait until t+1000s". Der entsprechende State im QMH wartet eine Sekunde und sendet sich selbst "wait until t+999s", usw.…
Zitat:Okay, das hört sich schon mal gut an.
Das kan man alles programmieren!
Man muss es "nur" programmieren…
ich habe auch mal (als eher Unerfahrener) ein Blick draufgeworfen und ein Snippet für die anderen erstellt (zumindest als grobe Überischt als Bild, haben ja nicht all zu viele lv21).
Ich habe bisher gute Erfahrungen mit dem QMH von Delacor gemacht (DQMH aus dem VIPM) und so wie ich das hier verstanden habe, passt der sehr gut für deine Aufgabe.
Hier die Frage, muss Temperatur+ und Temperatur- separat sein (passieren die gleichzeitig?) sonst liese sich das zusammenfassen (auch ohne DQMH).
Musst du warten bis die anderen fertig sind? Oder wozu dient die Occurence? Hier solltest du aber nicht die Schleife blockieren, nur damit du auf das Ergebnis wartest.
Soweit was mir auf- und eingefallen ist.
MfG Timo
Justieren ist dem Gerät sagen was es anzeigen soll, kalibrieren ist die Kontrolle dieser Anzeige. Eichen ist ein längerer Prüfprozess und darf nur das Eichamt!
21.12.2021, 19:37 (Dieser Beitrag wurde zuletzt bearbeitet: 21.12.2021 19:40 von GerdW.)
jetzt habe ich mal deine VIs angeschaut - und habe Fragen über Fragen…
- In deinem Beispiel gibt es einige Loops, wo du Referenzen nicht durchverdrahtest: das solltest du dringend nachbessern…
- Warum überall diese ganzen Wartezeiten? Wenn du einen Ausgang an- und ausschalten willst, kannst du auch eine Loop verwenden und brauchst keine zusätzliche lokale Variable mehr…
- Warum Wartezeiten in Schleifen, die sowieso (endlos) auf einen Notifier warten?
- Ich hoffe, in deinem "richtigen" Programm gibt es eine Möglichkeit, das Programm auch (sinnvoll) zu beenden?
- Du hast von einem QMH geschrieben, dein VI basiert aber auf Notifiern, UserEvents und dann auch noch irgendwelche Occurances!? Wieso dieser Mix aus gleich drei verschiedenen Elementen?
Zitat:Momentan wird diese ja durch ein Array Bedienelement gemacht.
Ich bevorzuge (Multicolumn)Listboxen, um dem User eine Tabelle in einem ansprechenden UI anzuzeigen. Der User kann darin einfach eine Zeile auswählen und dein Programm kann dazu passende Controls anzeigen…
