(13.12.2018 13:03 )Achim schrieb: Ich hab immer noch nicht so richtig kapiert, wie dein Schleifenkonzept zu deinen verschiedenen Aufgaben passt.
Warum müssen Schleifen pausiert werden? Soll nach einer "Pause" ein schnelles Loslaufen möglich sein?
Dazu könntest du in jeder dieser Schleifen eine "Queue driven state machine" packen. Und diese wartet dann am "Dequeue" solange, bis ein neues Kommando kommt. Das Kommando schickst du dann "von außen", wenn es weitergehen soll. Ansonsten könnte sich diese SM auch selber antreiben, je nach dem was in einem State "entschieden" wird.
Diese einzelnen SM würde ich in je ein "Prozess-VI" (SeriellProzess.vi, DAQProzess.vi, RegelungProzess.vi) packen, dann kannst du in jedem VI auch ne Eventstruktur verwenden und dort ggf. auch User Events konfigurieren (z.B. Input direkt von einer HW-Komponente). Alle Prozesse laufen parallel und erst mal asynchron. Die Synchronisierung (wo notwendig!) könntest du ergänzend mit Notifiern ("neuer Sollwert", "neuer Istwert") oder Occurences oder...hinkriegen.
Der Stopp aller parallel laufenden Prozesse kommt per Queue Message aus einer Zentralen SM, die auch das GUI verwaltet bzw. von dort manuelle Events empfängt.
Genauso tauschen die ProzessVIs untereinander Daten aus, d.h. auch durch Queues, oder durch FGVs
Die Sache mit dem Pausieren liegt daran, dass die Gerätesteuerung nicht vollkommen in einer Statemachine bearbeitet wird. Die Initialisierung findet zunächst in der Hauptloop statt und der eigentliche zeitkritische Part geschieht in den parallelen Schleifen (Das ist eine Systementscheidung die bereits etwas länger zurückliegt und nicht geändert werden kann ohne das Programm defakto neu aufzubauen). Daher würde die Schleife Nachlaufen, käme es zu Fehlern in meinem Programm. Warum ich mich mit meinem Halbwissen nicht für einfache Caseabfragen entschieden hab die über local variables gesteuert werden, hab ich in einem vorigen Post erklärt.
Soviel erst mal zu meinen Ausreden
Die Queue driven state machine kannte ich noch nicht, aber das Verhalten entspricht dem was ich ursprünglich gesucht habe um Schleifen zu steuern.
Damit kann ich mir die "Masterloop" sparen.
(13.12.2018 13:03 )Achim schrieb: Festzuhalten: Es ist hier definitv kein LabVIEW (2011)-Bug zu beobachten!
Auch wenn ich mich damit nicht beliebt machen sollte: Aber wenn die Runtime und die Entwicklungsumgebung durch ein Programm in einen Zustand laufen, aus dem der einzige Ausweg ein terminieren der Labview.exe ist. Dann ist das ein Bug in LabVIEW, da dieser Zustand nicht korrekt behandelt wird. Ich weis nicht ob ich das korrekt rüber gebracht habe. Das Fenster "Resetting VI" geht nicht mehr weg und LabVIEW ist bis zu seinem Neustart nicht bedienbar.
Aber allem zum trotz natürlich herzlichen Dank Achim für die Anregung bezüglich der Queue driven state machine. Das hat mir sehr weitergeholfen.
(12.12.2018 14:28 )jg schrieb: Also 9 parallele Timed-Loops, das wäre wahrscheinlich sogar unter einem RT-System der Tod des Programms. Das Windows nicht mehr mit kommt, wundert mich da nicht.
Timed Loops bedeuten einen tiefen Eingriff in den Task-Scheduler. Da werden gnadenlos andere Tasks rausgehauen oder pausiert, wenn die entsprechende Timed-Loop daran ist, was abzuarbeiten. Sachen, bei denen du das Zeitverhalten nicht vorhersagen kannst, wie serielle Kommunikation u.ä., haben in einer Timed-Loop auch nichts verloren.
Gruß, Jens
Ich habe die Timed-Loops durch normale While-Loops ersetzt. Die ersten Langzeittests sehen vielversprechend aus. Ich denke Ich kann dieses Problem als gelöst taggen. Für die Probleme mit den spontanen resets in meinem Regler habe ich Workarounds eingebaut, die diese spezifischen Fälle erkennen und Redundanzen aktivieren. (Ich habe schon lange gesucht, aber ich will nicht abstreiten, dass ich vielleicht doch mal in bestimmten Fällen irgendwo durch null teile (bzw. auch 0/0))
Vielen Dank an alle die mir hier geholfen haben.
MfG: Sepp
