Kann ein VI erkennen, ob an den Ports ein Draht angeschlossen ist?

Hi
Die Frage, wissen zu wollen, ob im Caller-VI ein Draht an ein SubVI angeschlossen ist oder nicht, zeugt meiner Meinung nach von schlechtem Design.

Ein VI kann selbstständig ausgeführt werden, und übernimmt die Daten für die Datenquellen auf dem Blockdiagramm aus den Frontpanel-Controls. Wird es als subVI aufgerufen, übernimmt es die Daten für die Datenquellen auf dem Blockdiagramm vom Caller. Datenfluss! In beiden Fällen sollte das VI sinnvoll und vorhersagbar arbeiten und richtige Ergebnisse liefern.

Die Frage, wissen zu wollen, ob im Caller-VI ein Draht an ein SubVI angeschlossen ist oder nicht, kann man vermeiden, in dem man die notwendigen Eingänge der Connector-Pane auf required setzt. Dann ist der Caller gezwungen eine sinnvolle Wahl zu treffen. Ob Rückgabewerte vom Caller verarbeitet werden, sollte völlig irrelevant sein.

Zusätzlich sollte in jedem SubVI der Wertebereich der Eingänge überprüft werden. Das gilt natürlich auch für die Ausgänge. Auch die Ausgänge sollten immer in einem definierten Wertebereich liegen, auf den sich der Caller verlassen kann. Fehlverhalten sollte im Error Cluster berichtet werden. Für die Fehlerbehandlung ist dann wieder der Caller zuständig.

Dieses Vorgehen hilft, robuste Software zu entwicklen. Übrigens: Der VI-Analyzer kann überprüfen, ob alle Error-Ausgänge verdrahtet sind.

Gruß Holger

Anzeige

@BNT

Eigentlich wäre solches Verhalten sogar ein Designevorteil. Es geht ja nicht darum wie Fehlende Drähte allgemein zu behandeln sind und das das trotzdem funktionieren (oder gerade nicht - setzen auf "erforderlich") soll, sondern darum eine Funktionsumschaltung durch die Anordnung der Verdrahtung zu erreichen.

Im Prinzip ist ja gewünscht, dass man eine FGV nicht über ein explizites Kommando steuert, sondern über Ein- / Ausgangsbelegung. Da diese redundant ist zum Kommando (leer - lösch / Eingang - Schreiben / Ausgang - lesen) wäre das sogar dahingehend sinnvoll, dass man sich Fehler bei falschem Kommando spart (was weis ich, unachtsam das falsche Kommando reingegeben im Code).

Andererseits kann man so natürlich bei vergessener Verkabelung neue Fehler produzieren. Denke trotzdem dass das SO (mit "intuitiver" Kommandoerkennung) die bessere Variante wäre. Aber na ja, ist ja mindestens beim Ausgang nicht ganz einfach möglich.

Wäre es dann nicht immer besser die FGV in subVIs zu kapseln, die jeweils nur schreiben oder lesen, also nur einen Eingang und keinen Ausgang und umgekeht haben?

Das sind zwar zwei VIs mehr, aber ein solches Design wäre Datenfluss-konform und beim Aufruf im Caller unproblematisch.

Gruß Holger

Hallo,

@Kiesch /Lucki: Wieso sollte man denn bei einer FGV den Fall Release, also löschen der Daten, überhaupt benötigen? Ist für mich etwas seltsam, dass man einen Wert löschen und nicht ersetzen will.

Prinzipiell ist es doch aber von Voretil, wenn man einem SubVI einen "Befehl" mitgibt, da dies durchaus auch die Wartbarkeit des übergeordneten VIs stark erhöht und die Lesbarkeit des Codes verbessert.

MfG Carsten

Nunja, die Info kann man auch in die Kontexthilfe stecken, wobei die man das sowieso nur in Fällen verwenden sollte in denen aus der Anschlussbelegung auch sofort der Verwendungskontext für den Bearbeiter klar wird

Davon ab: Man kann mit einem Release ja intern auch einen Schalter setzen, der darauf hinweist das die Variable nicht initialisiert ist. Das könnte man zum Beispiel brauchen wenn man eine Motorsteuerung hat die kalibriert wird und die Kalibration da drin speichert weil die in verschiedenen Programmteilen gebraucht wird und irgendwann diese Kalibration löscht um anzuzeigen, dass die nichtmehr gültig ist (was weis ich - Kalibration basiert auf nem Abstand zu nem Werkstück und man wechselt das Werkstück und muss die deswegen neu machen o.ä.). Dann kann man schon mit dem Wechsel des Werkstücks die Kalibration löschen und so sicherstellen, dass die neu gemacht werden muss.

Wie gesagt das nur mal als mögliches Beispiel. Bin da auch aktuell am basteln einer sinnvollen Architektur meiner LV Objekte, damit die selbst Rückmeldung geben ob die Vollständig initialisiert sind oder nicht. In meinem Fall würde ich dabei durch das Resetten vor allem einen Buffer löschen (Array das Werte aus einem File einliest) und natürlich sicherstellen, mein Programm weis ob es schon in dem File gelesen hat und die Daten aus dem RAM nehmen darf oder aber das File neu einlesen muss. etc. pp. Gibt eigentlich zahllose Anwendungen für einen kontrollierten Reset.

Gruß Kiesch

P.S: @BNT

Es geht hier um eine Erleichterung der Arbeit. Wenn es eine einfache Möglichkeit gäbe auf sowas zu prüfen wäre das schon schick. Ist letztlich nichts anderes als eine Art von Funktionen überladen. Die Möglichkeit vermisse ich in Labview tatsächlich schmerzlich (auch wenn es halt eine Designentscheidung von NI ist - auch wenn ich das Inkonsequent finde, wo man doch ohne OO auch polymorphe VIs unterstützt)...
Wie auch immer, letztlich muss man selbst entscheiden wie der Code für einen selbst am leichtesten durchschaubar und Verständlich ist. Nach aktueller funktionalität ist dabei vermutlich tatsächlich die Kapselung der FGV die sinnvollste Variante.

(06.03.2012 13:15 )BNT schrieb:  Wäre es dann nicht immer besser die FGV in subVIs zu kapseln, die jeweils nur schreiben oder lesen, also nur einen Eingang und keinen Ausgang und umgekeht haben?

Das sind zwar zwei VIs mehr, aber ein solches Design wäre Datenfluss-konform und beim Aufruf im Caller unproblematisch.

Gruß Holger

Die Idee gefällt mir. Lässt sich auch super mit Polymorphen VI kombinieren, in dem das fehlende Schieberegister durch eine FGV in den polymorphen VI instanzen ersetzt wird.

Hallo,

ich verfolge eure Gedankengänge durchaus interessiert, aber werde immer skeptischer...

Sofern die Anwendung nicht hochkomplex ist, und der Nutzen solch "unüblicher Struktur-Konstruktionen" den Aufwand und die Gehirnknoten (bei euch und anderen) rechtfertigt, bin ich weiterhin der Ansicht:
Keep it simple! Das ist oft die nachhaltigste Designentscheidung, die auch der Wartbarkeit und Pflegbarkeit sehr zu Gute kommt.
Wenn also eine "Standard-FGV" ihren Job tut, warum dann "Unter-FGVs" und "SubFGV-Queue-Init/Read/Write-Verschachtelungen" mit 3 VIs statt einem VI, usw. ?

Ich finde den Ansatz, den der TE gepostet hat, ganz gut: selbstinitialisierende FGV mit typdef Enum. Für komplexere Sachen dann "ActionEngines" wo nötig.
Gruß

Ich habe mal versucht das TE beispiel als polymorphes VI umzusetzen:
Das VI soll sich je nach angeschlossenem Datentyp automatisch ändern. Das Queue-shiftregister befindet sich in einem FGV-subvi.

Nichts ist angeschlossen: Release
Double am eingang: Send
Double am ausgang: Read

Leider scheiterts am READ fall. Das VI passt sich nämlich nur auf Eingangsdatentypen an.