Ereignis-gesteuerter Ablauf (wenn > dann > wenn > dann …)

' schrieb:Was fehlt noch?

Vielicht nur noch die Festellung, daß mit LabVIEW unterschiedliche, von der Effektivität her gleichwertige Programmierstile möglich sind, die man gegenseitig tolerieren sollte.
Aber gleichwertig ist natürlich nicht alles was läuft. Das Markenzeichen fast jeden Anfängers hier im Forum ist z.B. die exzessive Verwendung von Sequenzrahmen (vor denen auch NI warnt), womöglich zusätzlich zum durchgezogenen Fehlerstrang.
Aber ebenso geht mir auch die mit einem gewissen Stolz im Unterton verkündete Feststellung, grundsätzlich keine Sequenzrahmen zu verwenden "da die Nachteile überwiegen", am A.. vorbei. (Ja, die Nachteile sind da - aber wenn die alle in der gegebenen Aufgabenstellung nicht relevant sind, was dann? Die Sequenz nur wegen wegen eines hochgehaltenen moralischen Prinzips trotzdem nicht verwenden? Lach..)

' schrieb:Also ich bleibe bei meiner Meinung. Die Steps kann man in SubVIs packen, Loops und Case-Strukturen machen die mehrmalige Ausführung und Entscheidungen. ...

... schon hast du eine State-Machine

' schrieb:... schon hast du eine State-Machine

Ja, richtig, aber das Umgekehrte gilt genau so: Wenn eine While-Schleife mit Casestruktur drin (- einem Ding also, das aussieht wie die State-Machine-Vorlage von LabVIEW -) keinen entscheidungsabhängigen Ablauf hat, sondern auschließlich dazu dient, eine starre Abfolge herzustellen - dann ist da noch längst keine State- Machine. (Bei einem Textprogramm aus 5 Zeilen ohne Verzweigungen würde kein Mensch auch nur von ganz fern auf die Idee kommen, das als "State-Machine" zu bezeichen. Wenn aber dasselbe in LabVIEW mit dieser For-Schleife/Casestruktur gemacht wird, dann wird das hier oft schon für die Programmierung einer State-Machine gehalten. Ja, es sieht so ähnlich aus, aber mehr ist es nicht.)

Ist das etwa nicht entscheidungsabhängig?

' schrieb:>>>>>
Step1 - Ist Temperatur über 90°C gehe zu Step2

Step4 – Ist Temperatur unter 13°C gehe zu Step5

Datenaufzeichnung - für 12 sec. Der Analogeingänge, Temperatur und Zählerstand dann Rücksprung
<<<<<<<<

Oder vor allem das hier:

Zitat:(wenn > dann > wenn > dann …)

Je nach Wert wird in einen anderen Case gesprungen (bzw. im gleichen Case gewartet).

Aber mir wird die Diskussion langsam zu blöd. Ich würde definitiv eine State-Machine verwenden und was ihr macht und wie ihr eine State-Machine nennt, ist mir egal.

Gruß Markus

EDIT: Und wenn ich schon mal dabei bin:

Zitat:Aber ebenso geht mir auch die mit einem gewissen Stolz im Unterton verkündete Feststellung, grundsätzlich keine Sequenzrahmen zu verwenden "da die Nachteile überwiegen", am A.. vorbei.

Ich habe noch nie einen Fall gehabt, wo Sequenzrahmen gereicht hätten. Und wenn, hätte ich sie definitiv nicht verwendet.
Auf jedem NI-Lehrgang lernt man, dass man so programmieren soll, dass das Programm jederzeit erweiterbar ist. Und das geht bei einer State-Machine einfacher (und vor allem übersichtlicher) als bei Sequenzrahmen.

' schrieb:Ist das etwa nicht entscheidungsabhängig?

Step1 - Ist Temperatur über 90°C gehe zu Step2
Step4 – Ist Temperatur unter 13°C gehe zu Step5

Das hast im Prinzip Recht, und sogar zu 100%, wenn man ein reales profesionelles Programm aus dieser Grundidee mit diesen 5 Steps machen will - und das sollte doch immer das Ziel sein. Dann würde es bei Step 1 beispielsweise vollständig heißen:

Step1
Ist Temperatur über 90% gehe zu Step 2
Wenn Stoptaste gedrückt gehe zu Exit.
Wenn Temperatur 90* nach 30min noch nicht erreicht gehe zu Heizt_nicht.
Wenn Temperatursenor defekt gehe zu Temperatursensor_defekt.
(Oder so ähnlich)

Die reine Grundidee ließe sich zwar genau so gut mit einer Sequenzabfolge oder mit Datenabhängigkeiten herstellen. Man ist dann aber in der Sackgasse, wenn man das Programm in Richtung professioneller Ansprüche erweitern möchte. Um später nicht in diese Situation zu kommen, ist es nie verkehrt, das Statemachine-Gerüst auch im ersten Entwurf schon zu verwenden.
Ich wollte keineswegs Einwände gegen dieses Konzept geltend machen, ich habe nur etwas dagegen, wenn jemend eine Sequenz einfachster Art, verpackt in das Statemachine-Gerüst, schon für eine State-Machine hält.

' schrieb:Aber ebenso geht mir auch die mit einem gewissen Stolz im Unterton verkündete Feststellung, grundsätzlich keine Sequenzrahmen zu verwenden "da die Nachteile überwiegen", am A.. vorbei.

Das Problem sind die Pauschalisierungen: Keine Sequenzen! Keine Lokalen Variablen! Keine Express VIs!

Das stimmt so natürlich nicht, denn solange man weiß was man tut bzw. was die Zukunft noch bringt, gibt es auch Indikationen/Rechtfertigungen für alles oben genannte. Aber einem Anfänger zu erklären was z.B. RaceConditions sind, ist immer mehr Aufwand als einfach zu sagen: "Mach das nicht!" "Mach das!" "Vermeide das grundsätzlich!"

Deswegen rät man einfach pauschal: Keine Sequenz! Nimm 'ne State-Machine! Anstatt ellenlang zu erklären warum Squenzen nachteilig sein können.

Anzeige

Statemachine ist zuerst einmal ein abstrakter Begriff, hinter dem ein "formales Verhalten" steht, das eher ein allgemein gültiges Prinzip ist als ein Programmierkonzept. Da sich CPU's aber so schwer tun mit Prinzipien, muss ein programmiersprache-abhängiges Konstrukt her zur Umsetzung der Theorie in die Praxis. Das ist in LV eine Sequenzrahmenstruktur mit Loops und Verzweigungen - oder eine Case-Anweisung in Whileschleife. Wie die vielen anderen notwendigen Elemente - Eingangsdaten, Ausgangsdaten, Verknüpfungen etc. etc. - in Praxis umgesetzt werden, lass ich jetzt mal weg. Ob die Sequenzrahmen-Anweisung oder die Case-Anweisung verwendet wird, hat per se nichts mit der abstrakten Statemachine zu tun. Warum man sich für das eine oder das andere entscheidet, liegt alleine daran: "Des Menschen Wille ist sein Himmelreich", Erweiterbarkeit, Übersichtlichkeit, etc. Besonders die beiden letztgenannten hängen vom ersten ab - auch wenn eigentlich eine Normierung (Styleguide) wichtiger sein solle ...

Ich geh jetzt erst mal in den Garten 2m³ Häckselspäne wegschaffen - bei der Hitze.