02.07.2010, 13:43
(Dieser Beitrag wurde zuletzt bearbeitet: 02.07.2010 13:47 von Lucki.)
|
Lucki
Tech.Exp.2.Klasse
Beiträge: 7.699
Registriert seit: Mar 2006
LV 2016-18 prof.
1995
DE
01108
Deutschland
|
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..)
|
|
|
02.07.2010, 18:56
(Dieser Beitrag wurde zuletzt bearbeitet: 02.07.2010 19:01 von Lucki.)
|
Lucki
Tech.Exp.2.Klasse
Beiträge: 7.699
Registriert seit: Mar 2006
LV 2016-18 prof.
1995
DE
01108
Deutschland
|
Ereignis-gesteuerter Ablauf (wenn > dann > wenn > dann …)
' 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.)
|
|
|
03.07.2010, 08:25
(Dieser Beitrag wurde zuletzt bearbeitet: 03.07.2010 08:29 von Y-P.)
|
Y-P
☻ᴥᴥᴥ☻ᴥᴥᴥ☻
Beiträge: 12.612
Registriert seit: Feb 2006
Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN
71083
Deutschland
|
Ereignis-gesteuerter Ablauf (wenn > dann > wenn > dann …)
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.
--------------------------------------------------------------------------
Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------
|
|
|
03.07.2010, 09:21
(Dieser Beitrag wurde zuletzt bearbeitet: 03.07.2010 10:05 von Lucki.)
|
Lucki
Tech.Exp.2.Klasse
Beiträge: 7.699
Registriert seit: Mar 2006
LV 2016-18 prof.
1995
DE
01108
Deutschland
|
Ereignis-gesteuerter Ablauf (wenn > dann > wenn > dann …)
' 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.
|
|
|
03.07.2010, 10:14
|
IchSelbst
LVF-Guru
Beiträge: 3.700
Registriert seit: Feb 2005
11, 14, 15, 17, 18
-
DE
97437
Deutschland
|
Ereignis-gesteuerter Ablauf (wenn > dann > wenn > dann …)
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.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
|
|
|
| |