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

Diese Frage stelle ich mir schon seit Jahren, und wahrscheinlich gibt es darauf keine Antwort - aber die Hoffnung stirbt zuetzt, und so will ich wenigstens mal gefragt haben.
Beispiel siehe das angehänge VI. Es hat einen Eingang, einen Ausgang, und einen Modus-Schalter mit den Werten Write, Read, Release.
Ich möchte dass das VI den Modus von selbst erkennt,
und zwar so:
Wenn am Eingang etwas angeschlossen ist und am Ausgang nichts, dann Modus = Write.
Im umgekehrte Falle: Modus = Read
Wenn überhaupt nichts angeschlossen ist, dann Modus = Release.
Wenn beides angeschlossen ist, dann ist egal was passiert, es sollte nicht vorkommen.

  Test.vi (Größe: 19,6 KB / Downloads: 267)

Anzeige

Du meinst mit "angeschlossen" "am Anschlussfeld des SubVIs angeschlossen", oder? Und im SubVI soll dann erkannt werden, ob etwas angeschlossen ist?

Das einzige was mir dazu einfällt: Wenn man "abstruse" Standardwerte für dein Eingang festlegt (die nicht in der Praxis auftreten), dann kann man den unangeschlossenen Fall sicher abfangen. Beim Ausgang so nicht, da fällt mir nichts zu ein auf Anhieb...

den anderen?
Gruß

Das habe ich mir auch schon überlegt, nur beim Ausgang fällt mir nichts ein.
Komisch ist: Beim Fehlerstrang merkt ein VI, ob am Ausgang etwas angeschlossen ist oder nicht. Ist nichts angeschlossen und man hat einen Fehler, stoppt das Programm an dieser Stelle und blendet ein Pop-up mit der Meldung ein. Ist ein Fehlerstrang angeschlossen, dann passiert das nicht. So eine Erkennung müsste doch auch allgemein mit jedem Ausgang irgendwie möglich sein.

Hab ich mir auch schon gewünscht und hatte das selbe gefunden wie erik.brennecke: Standardwerte abfragen.
http://digital.ni.com/public.nsf/allkb/1...24006FA6DF

Oder dieses ominöse VI-scripting machen.
https://decibel.ni.com/content/docs/DOC-10021

Ich benutze momentan stattdessen polymorphe VI, wobei ich das polymorphe VI + Selector-VIs in eine llb packe.

Das mit dem Fehler-Dialog stimmt aber auch nur, solange du das automatische Fehler-Handling von LabVIEW nicht deaktivierst.

Für den Ausgang ist mir auch kein Automatismus bekannt. Wobei ich sagen muss, irgendwann geht es auch mit dem Automatismus zu weit, sonst weiß man im BD gar nicht mehr, welcher Fall des SubVIs aufgerufen wird.

Ein anderer Vorschlag zu deiner Frage: Kapsel die 3 Funktionalitäten deines SubVIs in 3 weiteren VIs, die dann nur die benötigten Anschlüsse haben. Damit gewinnst du wieder viel Übersicht!

Gruß, Jens

Danke für die sehr hilfreichen Antworten. Es geht also, aber vom Aufwand/Nutzen-Verhältnis bzw. von der Verlangsamung des VIs her wird man sich überlegen müssen, ob es sich wirklich lohnt. Das VI "Terminal Checker" werde ich auf jeden Fall mal probieren - ob ich es dann jemals noch verwende, sei dahingestellt.

Anzeige

(05.03.2012 20:18 )phylin schrieb:  Ich benutze momentan stattdessen polymorphe VI, wobei ich das polymorphe VI + Selector-VIs in eine llb packe.

Wenn es verschiedene Instanzen des VIs sind, haben die dann auch alle einen eigenen Speicherbereich - dadurch geht doch Funktionalität verloren.

Ich würde nie auf Selektor Enums an VIs verzichten - diese zwingen einen immer ein Mindestmaß an BD Doku mitzuschleifen. Durch Einheitliche Bezeichnungen hat man direkt eine gehaltvolle Zusatzinfo zum VI.


Gruß

Ja, so habe ich es davor gemacht (Stichwort Action engine). Man hat alles praktischerweise in einem VI drin.
Nur, dann sollte man auch zwingend eine typ-def vom selector enum machen. Ich hab das nicht gemacht und hab mich nachher schwarz geärgert, als ich ständig alle selector-enums neu erstellen musste, jedesmal, wenn ich die enum geändert/erweitert habe.

Der Nachteil an diesen Enum-selectoren ist allerdings, das sie immer noch freibeweglich rumschwirren. Ich hab damit schon viel Kabelsalat verursacht. Beim Polymorphen VI hab ich den Vorteil, dass der Selector direkt unter dem VI klebt. Für mini-dokumentation ist also gesorgt. Weitere Vorteile von Polymorphen VI sind, dass man zusätzlich das VI-Icon je nach gewählten Selector anpassen kann, und man nur die Anschlüsse sieht, die für den jeweiligen Selector wichtig sind.

Was meinst du mit der folgenden Aussage? Speicherplatz auf der Festplatte?

Zitat:Wenn es verschiedene Instanzen des VIs sind, haben die dann auch alle einen eigenen Speicherbereich - dadurch geht doch Funktionalität verloren.

edit: okay, mit nem polymorphen VI lässt sich natürlich nur schwer eine funktionale globale Variable realisieren. Passt also nicht sonderlich gut zum Read/Write beispiel.

Um noch mal auf mein Beispiel zu kommen: ich werde alles so lassen wie ich es vorher schon hatte. Nämlich zur Erstellung und Speicherung der Queue-Referenz dieses FGV-ähnliche Sub-VI verwenden:

  EventQueue-1.vi (Größe: 23,48 KB / Downloads: 236)

und für Queue schreiben, lesen, freigeben kein besonderes Sub-VIs erstellen. Einfach direkt ausführen: