+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: Ereignis-gesteuerter Ablauf (wenn > dann > wenn > dann …) (/Thread-Ereignis-gesteuerter-Ablauf-wenn-dann-wenn-dann-%E2%80%A6)
Seiten: 1 2
Ereignis-gesteuerter Ablauf (wenn > dann > wenn > dann …) - quarks - 01.07.2010 18:44
Hallo Forum,
ich habe in den letzten Tagen so einiges versucht und auch hier gelesen, allerdings stehe ich immer noch total auf dem Schlauch und finde keinen Einstieg für mein erstes richtiges LV7.1 Projekt.
Das Projekt:
Ein Ofen fährt in einer Endlosschleife eine programmierte Temperaturkurve 10°C – 95°C und wieder auf 10°C, das macht er selbstständig.
In LabVIEW habe ich 2 analoge Eingänge, ein Temperatureingang und einen digitalen Ausgang.
Nun soll der Ablauf folgendermaßen aussehen:
>>>>>
Step1 - Ist Temperatur über 90°C gehe zu Step2
Step2 - Starte Timer 15Min. > Sind 15Min vorbei gehe zu Step3
Step3 – Zähle Zähler1 +1, setze Digitalen Ausgang, gehe zu Datenaufzeichnung
Step4 – Ist Temperatur unter 13°C gehe zu Step5
Step5 - Starte Timer 20Min. > Sind 20Min vorbei gehe zu Step6
Step6 – Zähle Zähler1 +1, lösche Digitalen Ausgang, gehe zu Datenaufzeichnung
Step7 – gehe zu Step1
Datenaufzeichnung - für 12 sec. Der Analogeingänge, Temperatur und Zählerstand dann Rücksprung
<<<<<<<<
Ein Highlight wäre noch wenn jede Minute die Datenaufzeichnung 1x angetriggert wird um den Temperatur-verlauf mitzubekommen.
Ich habe es schon mit case-strukturen, viele aneinander gehängte und und oder und oder nicht dies aber das nicht Verknüpfungen und Timer versucht :-) verwirre mich aber immer mehr in Unlogik. Ich habe keinen Ansatzpunkt wie ich den sturen Ablauf hinbekomme.
Ich bin schon für einen Gedankenanstoß froh und ganz toll wäre natürlich ein Muster zum spionieren.
Vielen Dank im voraus an alle von Euch
Mit freundlichen Grüßen Quarks
Ereignis-gesteuerter Ablauf (wenn > dann > wenn > dann …) - Y-P - 01.07.2010 18:47
Hier ist eine "State Machine" schon fast unumgänglich. Bsp. dazu gibt's einige im Forum.
Gruß Markus
Ereignis-gesteuerter Ablauf (wenn > dann > wenn > dann …) - quarks - 01.07.2010 20:38
Hallo Markus,
danke für die schnelle Antwort.
Da ich gerade mein LV nicht zur Verfügung habe kann ich nicht schauen ob dies in meiner base Version vorhanden ist. Habe heute schon ein paar mal über diesen Ansatz gelesen und Beispiele (nur die Grafiken da ich zu Hause kein LV habe) versucht nachzuvollziehen, allerdings die Funktion des Weiterschalten innerhalb der Struktur nicht wirklich verstanden.
Gruß quarks
Ereignis-gesteuerter Ablauf (wenn > dann > wenn > dann …) - eg - 01.07.2010 20:42
Eine "normale" Programmierung reicht hier völlig aus. State Machine muss nicht unbedingt sein, einfach die Steps nach und nach abarbeiten, der Datenfluß macht den Rest für dich.
Gruß. eg
Ereignis-gesteuerter Ablauf (wenn > dann > wenn > dann …) - quarks - 01.07.2010 21:44
OK,
die State Machine werde ich morgen mal in LV versuchen zu verstehen. Und die normale Programmierung werde ich auch testen wenn ich noch ein paar Schlagwörter für den Ansatz zum rumknobeln bekomme. Wie gesagt ich versuchte es mit der flachen case Struktur idas hat nicht geklappt. Allerdings glaube ich das dies der richtige Ansatz war aber die "verknüpfelung" (sorry) von mir Müll war.
Tja, die abnormale Programmierung beherrsche ich ja (helfe da auch gerne jedem, jederzeit darin weiter) allerdings führt diese leider nicht zum Ziel.
(Selbstironie)Für Heute vielen Dank an Euch und schlaft gut
quarks
Ereignis-gesteuerter Ablauf (wenn > dann > wenn > dann …) - Y-P - 02.07.2010 05:45
:ironie:Ja, man kann auch 6 Bildschirme nach rechts programmieren in einer Flat-Sequence.
In dem Fall würde ich jedenfalls zu 100 % eine State-Machine verwenden.
Gruß Markus
' schrieb:Eine "normale" Programmierung reicht hier völlig aus. State Machine muss nicht unbedingt sein, einfach die Steps nach und nach abarbeiten, der Datenfluß macht den Rest für dich.
Gruß. eg
Ereignis-gesteuerter Ablauf (wenn > dann > wenn > dann …) - Lucki - 02.07.2010 07:56
Bei einer textorientierten Programmiersprache würde man über den Fall, daß Programmierschritte linear hintereinander ausgeführt werden sollen, überhaupt nicht nachdenken müssen, und am allerwenigsten an eine Statemachine denken: Programmanweisungen hintereinander schreiben - fertig.
Bie LabVIEW hat man die Besonderhait, daß alles was datenmäßig nicht voneiander abhängig ist, virtuell gleichzeitig ausgeführt wird, es gibt kein Garantie auf ein bestimmte Reihenfolgé. Man muß diese gegebenenfalls erzwingen.
Die Möglichkeiten dazu sind:[list]
[*]Datenabhängigkeiten herstellen (bevozugte Methode)
Falls sich das nicht auf natürliche Weise sowieso ergibt, kann man den Fehlercluster Ein/Ausgang, den die meísten VIs haben, dazu benutzen, diese Abhängigkeiten herzustellen.<>
[*]Sequenzrahmen, hintereiander<>
[*]Sequenzrahmen, gestapelt<>
[*]State-Machine.<>
[st]Bei einer richtigen State-Machine werden typischerweise in den einzelnen Staten logische Entscheidungen gefällt, welcher Status als nächstes angesprungen werden soll. Wenn es einfach linear weiter geht, dann muß man keine State-Machine verwenden (und wenn man sie verwendet, dann würde ich sie nicht als solche bezeichnen, sondern allenfalls als ein Gebilde, welches den optischen Eindruck eine State-Machine macht).
Wenn man sie aber hier verwendet, dann nur deshalb, weil die alternative Verwendung von Sequenzrahmen auch ihre Nachteile hat:
Sequenzrahmen, hintereinander: Das BD wird kann meterlang werden und passt nicht mehr auf den Monitor.
Sequenzrahmen, gestapelt: Die Überführung von lokalen Sequenzvariablen in die nachfolgenden Rahmen verursacht oftmals häßlichen Drahtwirrwar.
Ereignis-gesteuerter Ablauf (wenn > dann > wenn > dann …) - Matze - 02.07.2010 08:09
Hallo zusammen!
' schrieb:Wenn man sie aber hier verwendet, dann nur deshalb, weil die alternative Verwendung von Sequenzrahmen auch ihre Nachteile hat:Weitere Nachteile, weshalb ich eine Sequenzstruktur generell nicht verwende (auch wenn der Ablauf zunächst fest vorgegeben ist):[list]
Sequenzrahmen, hintereinader: Das BD wird kann meterlang werden und passt nicht mehr auf den Monitor.
Sequenzrahmen, gestapelt: Die Überführung von lokalen Sequenzvariablen in die nachfolgenden Rahmen verursacht oftmals häßlichen Drahtwirrwar.
[*]ein nachträgliches Einfügen von Zuständen ist nur schwer möglich<>
[*]Zustände können nicht mehrfach pro Ablauf ausgeführt werden
Hier müsste ein kompletter Abschnitt kopiert werden, was die Wartbarkeit erschwert und fehleranfällig ist bei Änderungen. Es passiert schnell, dass man vergisst, bei Änderungen alle identischen Abschnitte anzupassen und selbst dann können sich Fehler einschleichen<>
[*]die Reihenfolge ist fest vorgegeben und kann ohne weiteres nicht verändert werden (speziell bei Prüfabläufen ist das teils nötig, wenn man sieht, dass ein Prüfschritt o.ä. fehlt)<>
[st]Auch wenn ich wenige Millisekunden warten muss (Ventiltrennzeit o.ä.), verwende ich das folgende SubVI. Das wirkt zwar primitiv, doch ich zweckentfremde den überflüssig erscheinenden Fehleranschluss, um die Ablaufreihenfolge nach dem Datenflussprinzip vorzugeben.
[attachment=27542]
Fazit: Die Sequenzstrukur hat meiner Meinung nach fast nur Nachteile und sollte nicht verwendet werden.
Ereignis-gesteuerter Ablauf (wenn > dann > wenn > dann …) - IchSelbst - 02.07.2010 08:38
Gerade die von quarks beschriebene Abfolge schreit ja förmlich nach einer Statemachine.
Statemachine haben einen weiteren Vorteil: Nach jedem einzelnen Step kann man nämlich, und zwar außerhalb der Statemachine-Struktur, einen für alle Schritte identischen Code ausführen lassen. Abbruch der Statemachine zu einem beliebigen Zeitpunkt wäre so ein Fall.
Eine Statemachine muss auch nicht zwangsläufig linear sein. Wenn ein Step S1 z.B. 20 Minuten warten soll, muss das nicht der Step S1 selbst machen. Er ruft einen Step SW mit Parameter WAIT auf. Der Step SW selbst ruft sich im Raster von z.B. 20ms selbst auf. Jetzt hat man die Möglichkeit im Raster von 20ms irgendwas zu machen - z.B. Abbrechen. Nach den 20 Minuten gibt der Step SW die Kontrolle wieder an den aufrufendes Step zurück.
Ereignis-gesteuerter Ablauf (wenn > dann > wenn > dann …) - eg - 02.07.2010 10:50
Also ich bleibe bei meiner Meinung. Die Steps kann man in SubVIs packen, Loops und Case-Strukturen machen die mehrmalige Ausführung und Entscheidungen. Falls man ein Step mehrmals ausführen muss, dann das entsprechende SubVI einsetzen. Den Datenflüß über Error-Cluster ist die beste Möglichket, sogar Fehlerbehandlung ist inklusive. Falls parallele Abläufe gewünscht sind, Producer/Consumer verwenden.
Was fehlt noch?
Gruß, eg