Case-Auswahl im SubVI abhängig vom Aufrufer - Druckversion +- LabVIEWForum.de (https://www.labviewforum.de) +-- Forum: LabVIEW (/Forum-LabVIEW) +--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein) +--- Thema: Case-Auswahl im SubVI abhängig vom Aufrufer (/Thread-Case-Auswahl-im-SubVI-abhaengig-vom-Aufrufer) |
Case-Auswahl im SubVI abhängig vom Aufrufer - aw - 10.02.2016 15:47 Hallo, ich habe ein SubVI mit einer Casestruktur, dass von verschiedenen übergeordneten VIs aufgerufen werden kann. Der Großteil des Programmcodes wird von allen aufrufenden VIs benötigt, nur die Berechnung von einigen Parametern und damit die Cases unterscheiden sich je nachdem welches Vi aufruft. Bisher steuere ich die Auswahl des Cases über eine Typdefinition mit Enums und übergebe an der jeweiligen Stelle im Programm eine Enum-Konstante an das SubVI bzw. den dortigen Caseselektor. Gibt es eine elegantere Lösung den jeweiligen Case abhängig vom Aufrufer abzuarbeiten? Danke für Eure Hilfe! RE: Case-Auswahl im SubVI abhängig vom Aufrufer - GerdW - 10.02.2016 15:50 Hallo aw, Zitat:Gibt es eine elegantere Lösung den jeweiligen Case abhängig vom Aufrufer abzuarbeiten?Du könntest abfragen, wer der Aufrufer ist (CallChain) - und anhand dessen VI-Namen den Case aufrufen. Ob das jetzt eleganter als ein typdefiniertes Enum ist, glaube ich nicht… RE: Case-Auswahl im SubVI abhängig vom Aufrufer - aw - 10.02.2016 17:43 Danke GerdW. Ich gebe Dir recht, es ist nicht wirklich eleganter. Aber ich spare mir am SubVI zumindest den Anschluss für die Enum und natürlich die Enum selbst. Bei einem recht umfangreichen Projekt bedeutet das ein klitzekleines bisschen mehr Übersicht. Und der Programmieraufwand für die Aufrufkette hält sich durchaus auch in Grenzen. RE: Case-Auswahl im SubVI abhängig vom Aufrufer - IchSelbst - 10.02.2016 18:23 (10.02.2016 17:43 )aw schrieb: Aber ich spare mir am SubVI zumindest den Anschluss für die Enum und natürlich die Enum selbst.Das halte ich für einen ganz schlechten Programmierstil. Zitat:Bei einem recht umfangreichen Projekt bedeutet das ein klitzekleines bisschen mehr Übersicht.Unübersichtlichkeit und Umfang stehen in keinem kausalen Zusammenhang ... Ich rate von solchen Algorithmen ab. Dieser Algorithmus ist vom Namen des aufrufenden Programmes abhängig. Somit ist das VI wohl nicht wiederverwendbar. Ich würde bei strikten Enums bleiben. RE: Case-Auswahl im SubVI abhängig vom Aufrufer - GerdW - 10.02.2016 19:06 Und ich würde den Enum-Input zusätzlich auf "Erforderlich" setzen, um darüber eine vernünftige Code-Dokumentation zu erzwingen… RE: Case-Auswahl im SubVI abhängig vom Aufrufer - aw - 10.02.2016 21:37 Erst einmal danke für Euer Feedback. Ich bin immer für Anregungen bezüglich guten Programmierstils dankbar. Trotzallem sei mir eine Nachfrage erlaubt. Zitat:Ich rate von solchen Algorithmen ab. Dieser Algorithmus ist vom Namen des aufrufenden Programmes abhängig. Somit ist das VI wohl nicht wiederverwendbar. Ich würde bei strikten Enums bleiben.Kannst Du das bitte kurz näher erläutern. Für mich sieht das so aus: Unabhängig davon für welche Variante ich mich entscheide, muss ich bei Änderungen nachbessern. Bei der Variante mit der Aufrufkette muss ich ggf. geänderte VI-Namen ändern oder einen neuen Case für einen neuen Aufrufer hinzufügen. Im zweiten Fall muss ich die Typdefinition erweitern und ebenfalls einen neuen Case hinzufügen. So oder so ist die Wiederverwendbarkeit bei beiden nicht ohne weiteres gegeben!?! Ich kann den Vor- oder Nachteil der einen bzw. anderen Variante dabei nicht wirklich erkennen. RE: Case-Auswahl im SubVI abhängig vom Aufrufer - IchSelbst - 10.02.2016 22:31 (10.02.2016 21:37 )aw schrieb: So oder so ist die Wiederverwendbarkeit bei beiden nicht ohne weiteres gegeben!?! Bei der Verwendung der Aufrufkette tritt folgendes Problem auf - ein sehr gefährliches Problem: Wenn du das SubVI (im Allgemeinen: ein Modul) in eine neues Projekt integrierst, also in ein neues VI platzierst - wird zur Entwicklungszeit kein Fehler (<= das ist das Problem) auftreten. Warum auch sollte ein Fehler auftreten: Im SubVI machst du einen String-Vergleich, der erst zur Laufzeit relevant ist. Um das Problem zu umgehen, musst du also von vorne herein einen Case im SubVI haben, der eine Meldung macht, wenn das aufrufende VI unbekannt ist. Würde hier jetzt zur Entwicklungszeit ein Fehler auftreten, wäres du nämlich daran erinnert, dass du Strings im SubVI ändern musst. Mag sein, dass dieses Problem in deinem Falle nicht so gravieren ist - aber es besteht. Wenn du einen Enumerator nimmst, kann überhaupt nichts passieren - da gibt es per se keine Probleme (nur Arbeiten). Zum Modul "SubVI" gehört nämlich auch der Enumerator. Wenn du also das SubVI in ein neues Projekt integrierst ("wiederverwendest"), musst du auch den Enumerator kopieren. Ohne den Enumerator wird zur Entwicklungszeit angezeigt, dass er fehlt! Spätestes dann wirst du ihn kopieren. Zur Integration eines Modules gehört auch immer der Aufruf des Moduls in einem aufrufenden Objekt. Und bei der Platzierung des Modules auf dem BD wirst du bereits zur Entwicklungszeit durch die IDE daran erinnert, dass du einen Eingangsparameter entsprechend belegen musst. Wenn jetzt im Gegensatz zu oben das Programm als ablauffähig angezeigt wird, wird es auch funktionieren (es sei denn du hast dich bei der Auswahl des Enumerators vertippt etc.). Es gibt auch noch einen programmier-theoretischen Grund, es ohne Aufrufkette und mit Enumerator zu machen: Ein Modul, das wiederverwendet werden soll, muss ein "gekapseltes Objekt" sein. Als solches hat es interne Daten und Funktionen, die nach außen hin nicht sichtbar und nicht zugreifbar sind. Diese internen Daten und Funktionen sind naturgegeben projektunabhängig (das ist zwar sehr schwierig - wenn dem aber nicht so währe, würde man es nicht wiederverwenden wollen). Interes in einem SubVI ist das komplette BD (enthält Daten!) und das FP. Nach außen hin hat ein Objekt eine Schnittstelle - im Falle eines VIs sind das die Ein- und Ausgänge. Und was meinst du wohl ist mit der Aufrufkette: Der Inhalt der Aufrufkette ist projektabhängig! Es befinden sich innerhalb des Objektes also Daten, die nicht unabhängig sind, aber auch nicht zugreifbar! Aufrufkette widerspricht also dem Paradigma "gekapselt". Mit dem Enumerator ist das ganz einfach: der gehört zur Schnittstelle. RE: Case-Auswahl im SubVI abhängig vom Aufrufer - GerdW - 11.02.2016 09:07 Hallo aw, Zitat:Im zweiten Fall muss ich die Typdefinition erweitern und ebenfalls einen neuen Case hinzufügen. So oder so ist die Wiederverwendbarkeit bei beiden nicht ohne weiteres gegeben!?!Warum nicht? Wenn du das Enum nur durch Hintenanfügen von neuen Items erweiterst, bleibt die Wiederverwendbarkeit gegeben! Du musst die älteren Projekte nur beim nächsten Öffnen neu kompilieren, da sich das Enum selbst geändert hat, ansonsten ändert sich aber nichts… RE: Case-Auswahl im SubVI abhängig vom Aufrufer - IchSelbst - 11.02.2016 09:34 Ich wollte noch folgendes schreiben: Ein Algorithmus kann mittels eines Namens identifiziert werden. Spricht: Wenn du eine Case-Sequenz hast, die abhängige Sachen macht, so hat jeder einzelne Programmteil in den Cases einen Namen - offensichtlich den Namen, den auch der Case hat. Nun sollte aber dieser Name nach dem gewählt werden, was der Programmteil tut (Enumerator) - und nicht nach dem, der diesen Programmteil aufruft (Aufrufkette). Mag sein, dass bei dir diese Namen bisher identisch sind - das ist aber im Normalfall nicht der Fall. Wenn du das SubVI in eine neues Projekt einbindest, heißt der selbe Algorithmus plötzlich anders. RE: Case-Auswahl im SubVI abhängig vom Aufrufer - aw - 11.02.2016 10:03 Hallo IchSelbst und GerdW, danke für Eure Ausführungen und Muße einem Grünschnabel diese Programmierparadigmen etwas näher zu bringen, ich habe durchaus etwas dazugelernt und sehe jetzt klarer. Ich werde das neue Wissen beim weiteren Programmieren berücksichtigen. Beste Grüße |