Anlagensteuerung oder anders: Wie sehr sollte man in sub-VIs aufsplitten?

Heyho!

Nachdem ich mit Jens' Hilfe (danke nochmal) mein Netzteil endlich zur Kooperation bewegen konnte, hat sich beim weiteren Programmieren promt die folgende Frage aufgetan:

Wie weit bzw. was überhaupt sollte ich in sub-VIs aufdröseln???

Mal als Beispiel das Netzteil, wie es nun als Einzel-VI mittels flacher Sequenz soweit funktioniert:
- RS232 konfigurieren
- Stellwert-String berechnen
- RS232 schreiben
- 250 ms warten
- RS232 lesen
- RS232 schließen

...der Tipp von Jens lautete aber, ich solle doch alles in handliche sub-VIs packen. Also gesagt, getan: alles (bis auf die Wartezeit natürlich) wurde in Einzel-VIs gepackt und die wieder in einer flachen Sequenz zu einem Ablauf vereint. Dann kam die Erkenntnis, daß man den RS232 ja nur einmal öffnen/schließen muß, also wurde diese wieder um ein "do/while" erweitert usw.. Aber sub-VIs erstellen, um sie dann in einem weiteren VI wieder zusammen zu fassen? Beißt sich die Katze da nicht in den Schwanz? Oder ich denke mal wieder viel zu kompliziert...

Gegen das "große" Netzteil-VI wäre eigentlich auch nichts einzuwenden, wenn nicht zwischendurch noch je ein Befehl für "ein" und einer für "aus" mit entsprechender Abfrage käme. Die hatte ich zuletzt noch versucht, mit Hilfe einer state machine den ist-Zustand mit einem evtl. Schaltbefehl (ein/aus) abzugleichen. Dann sollte alles zusammen im einzelnen VI zusammengefasst werden, das wurde aber schnell sehr unübersichtlich. Also hab' ich mich irgendwann doch für Feierabend entschieden und dachte, ich frag' - natürlich nach vorheriger Suche - lieber nochmal die Profis um Rat

Zum besseren Verständnis hier noch ein grober Überblick, was die Anlage können/machen soll:

- Die Laufzeit aufzeichnen
- Permanent eine A/D-Karte auslesen und die Werte anhand einer Kalibriergeraden umrechnen, sowie aufzeichnen
- Über RS232 einen Kryostaten steuern
- Über RS232 ein Netzteil steuern
- ...Und das ganze auch noch in unterschiedlichen Programmphasen...

Du brauchst nicht für jede VISA open, VISA write, VISA Read und VISA Close ein eigenes SubVI.
Wenn Du was zusammenpackst, dann so dass es Sinn macht.

Richtlinie: Alles was größer ist als eine Bildschirmgröße, ist zu groß und sollte durch SubVIs verhindert werden.
Ansonsten würde ich einfach größere Blöcke mit Funktionen die "zusammengehören" in ein SubVI packen.

Gruß Markus

' schrieb:Gegen das "große" Netzteil-VI wäre eigentlich auch nichts einzuwenden, wenn nicht zwischendurch noch je ein Befehl für "ein" und einer für "aus" mit entsprechender Abfrage käme. Die hatte ich zuletzt noch versucht, mit Hilfe einer state machine den ist-Zustand mit einem evtl. Schaltbefehl (ein/aus) abzugleichen. Dann sollte alles zusammen im einzelnen VI zusammengefasst werden, das wurde aber schnell sehr unübersichtlich.

Finde ich eine sehr gute Lösung. Im Prinzip sollte ein Sub VI nur eine Funktion (besser gesagt Aufgabe) enthalten. Das heißt ich würde genau wie du die Kommunikation (RS232) in ein Sub VI packen und die Stellwert-String Berechnung wieder in ein Sub VI. Jedes Sub VI würde ich als State-Machine entwickeln. Das hat einige Vorteile, bspw. werden die VI's "kleiner" als mit Sequenzen (aber du machst im Prinzip nichts anderes als eine Sequenz auch), die VI's sind viel leichter zu erweitern (Modularer) und das Toplevel VI, aus dem deine Sub VI's aufgerufen werden, wird auch besser "lesbar"(da du ein Kommando an das Sub VI anlegst. Dieses sollte im Prinzip selbst erklärend sein wie z.B. "Get X-Values". Jeder der dann über deinen Code schaut wird direkt wissen das du dir hier irgendwelche Werte aus dem Sub VI ziehst, ohne auch nur einmal in dein Sub VI reinzuschauen). Deshalb würde ich für Sub VI's meistens zu der State-Machine Architektur greifen.

Oberstes Ziel einer Programmierung - ob LV, Delphi und naja auch C++, muss sein, alles in SubVI's zu machen. Je weniger in einem Unterprogramm steht, desto besser: Bei fast nix, kann auch nix falsch sein. Und fast nix lässt sich auch besser überblicken und damit debuggen.

Übertreiben darf man es natürlich nicht.

' schrieb:Oberstes Ziel einer Programmierung - ob LV, Delphi und naja auch C++, muss sein, alles in SubVI's zu machen. Je weniger in einem Unterprogramm steht, desto besser: Bei fast nix, kann auch nix falsch sein. Und fast nix lässt sich auch besser überblicken und damit debuggen.

Übertreiben darf man es natürlich nicht.

Bei meinen Projekten achte ich darauf, SubVIs so zu erstellen, dass sie sinnvolle Aufgaben erledigen und dadurch auch in späteren bzw. anderen Projekten wieder einsetzbar sind. Man muss ja nicht jedes mal das Rad neu erfinden nur weil man grade eine Kutsche bauen möchte.

LG
Torsten

' schrieb:Mal als Beispiel das Netzteil, wie es nun als Einzel-VI mittels flacher Sequenz soweit funktioniert:
- RS232 konfigurieren
- Stellwert-String berechnen
- RS232 schreiben
- 250 ms warten
- RS232 lesen
- RS232 schließen

Hier mal ganz offen meine Meinung:
Den typischen Anfängerstil in einem LV-Programm erkennt man regelmäßig an der exzessiven Verwendung von Sequenzen. (Man will das, was man von einem textorientierten Programm her als Programmablauf gewohnt war, hinüber retten in LV, und hat sich nicht genügend mit den Vorteilen der Datenflusssteuerung vertraut gemacht). NI empfiehlt ausdrücklich die Anwendnung der Datenflusssteuerung statt Sequenzen. Schon bei der beschriebenen Abfolge wäre die Sequenzstruktur vermeidbar. Die seriellen Funktionen haben alle Error- und Task- In/Outputs, die sich miteinander verbinden lassen, wodurch die die Abfolge festgelegt würde.
Wenn Du aber das, was in den einzelnen Sequenzen steht, schön in SUB-VI packst, und dann aber, wie Du schreibst, die Sequenzstruktur immer noch beibehälst - also da fällt mir nur noch die Bezeichnung "pervers" für ein solches Programm ein.

' schrieb:Hier mal ganz offen meine Meinung:
Den typischen Anfängerstil in einem LV-Programm erkennt man regelmäßig an der exzessiven Verwendung von Sequenzen. (Man will das, was man von einem textorientierten Programm her als Programmablauf gewohnt war, hinüber retten in LV, und hat sich nicht genügend mit den Vorteilen der Datenflusssteuerung vertraut gemacht). NI empfiehlt ausdrücklich die Anwendnung der Datenflusssteuerung statt Sequenzen. Schon bei der beschriebenen Abfolge wäre die Sequenzstruktur vermeidbar. Die seriellen Funktionen haben alle Error- und Task- In/Outputs, die sich miteinander verbinden lassen, wodurch die die Abfolge festgelegt würde.
Wenn Du aber das, was in den einzelnen Sequenzen steht, schön in SUB-VI packst, und dann aber, wie Du schreibst, die Sequenzstruktur immer noch beibehälst - also da fällt mir nur noch die Bezeichnung "pervers" für ein solches Programm ein.

Dem stimme ich grundsätzlich zu, hat ja allerdings nix mit dem Problem zu tun. Sequenzrahmen kann man mit vielen kleinen Funktionen oder eben mit einem SubVI füllen.

Sinnvoller ist es meiner Meinung nach, jedem SubVI einen ErrorIn und einen ErrorOut zu geben und durch die ErrorLine den Datenfluss zu steuern.

Meine Main-VIs sehen grundsätzlich ziemlich leer aus. Man soll auf einen Blick die Struktur erkennen können und sich nicht mit unwichtigen Einzelheiten auseinandersetzen müssen. Dann bekommen alle SubVIs noch aussagekräftige Symbole und ne gute Inline-Dokumentation und alles ist perfekt.

' schrieb:Sinnvoller ist es meiner Meinung nach, jedem SubVI einen ErrorIn und einen ErrorOut zu geben und durch die ErrorLine den Datenfluss zu steuern.

Meine Main-VIs sehen grundsätzlich ziemlich leer aus. Man soll auf einen Blick die Struktur erkennen können und sich nicht mit unwichtigen Einzelheiten auseinandersetzen müssen. Dann bekommen alle SubVIs noch aussagekräftige Symbole und ne gute Inline-Dokumentation und alles ist perfekt.

' schrieb:Dem stimme ich grundsätzlich zu, hat ja allerdings nix mit dem Problem zu tun.

Ja, das hätte ich vielleicht noch dazu schreiben sollen, daß ich mich damit in Richtung außerhalb der eigentlichen Frage bewege.

Der ursprüngliche Sinn eines Unterprogramms war ja, nicht an verschiednen Stellen eines Programms den gleichen Code schreiben zu müssen. Später galt dann die Verwendung eines Unterprogramms auch dann als guter Programmierstil, wenn es nur ein einziges Mal verwendet wird - wegen der besseren Strukturiertheit eines solchen Programms.
Dem stimme ich zu - aber nur nicht für jedes noch so kleine Programmschnipsel, und wo hier die Grenze liegt, wird wohl jeder etwas anders entscheiden.

Ich packe auch gern mehrere Funktionen in ein einziges Sub-VI. Z.B diese Programmfolge

- RS232 konfigurieren
- Stellwert-String berechnen
- RS232 schreiben
- 250 ms warten
- RS232 lesen
- RS232 schließen

könnte man so in ein SUB-VI packen:

Das Sub-VI hat zwei boolsche Eingange "Initialisieren" und "Schließen"
Das Sub-Vi wird defaultmäßig ohne Inititalisieren und Schließen ausgeführt. Mit angeschlossenem trues werden dann die anderen Funktionen ausgeführt. (Das ist dann so eine Art Anlehnung an die objektorientierter Programmierung - das Sub-Vi macht alles, was das Objekt "RS232" betrifft.)

' schrieb:(Das ist dann so eine Art Anlehnung an die objektorientierter Programmierung - das Sub-Vi macht alles, was das Objekt "RS232" betrifft.)

Auch hier gilt wieder: Ein Bild sagt mehr als tausend Worte:

Wobei hier "objektorientierte Programmierung" nicht als Programmiersprache im Sinne von Delphi/C++ zu verstehen ist, sondern als "Programmiergrundsatz": Der Grundsatz heißt (weiß ich seit neuestem ) "enge, interne Bindung" und besagt genau das: Alles was ein "Objekt" betrifft, ist zusammengefasst. Und auch nur das, was das Objekt betrifft.