Umsteigerfrage zu generischem Entwicklungsansatz

Ich bin neu hier und auch neu unter LabView, als steinigt mich bitte nicht gleich wenn ich ein paar Fragen extra stellen muss.

Ich soll hier ein kleines Messprogramm entwickeln, allerdings in LabView. Ich bin ein Umsteiger aus dem klassischen Informatikbereich, daher steh ich gänzlich aufm Schlauch und die Suche in Foren bzw. Tutorials hat mir leider nicht wirklich geholfen, bzw. hat LabView meistens andere Ansichten als ich, weswegen ich mit LabView immer wieder im Streit liege

Zum Problem: Ich habe die Messaufgaben und Datenflüsse für mich selber so halbwegs skizziert ... eine Herausforderung ist jedoch, dass sich das Messgerät ändern kann (ausgetauscht / geupdatet) und damit die Messroutinen (VIs) umgeschrieben werden müssen, bzw. komplett neue VIs geschrieben werden müssen bei einem Austausch!

Mein Ansatz war es den Programmablauf generisch zu halten, also alle Vorgänge mit Prototypen ohne funktion zu schreiben und dann dynamisch zur Laufzeit aus einer llb oder lvlib die "Treiber" zu laden, welche in erster Linie aus Ableitungen dieser Prototypen bestehen und weiteren SubVI die für die Steruerung des Gerätes notwendig sind.

Leider hab ich beim Testen der Tutorials immer das Problem gehabt dass es irgendwo an etwas Speziellem scheiterte.

z.B. call by reference: das Pattern verändert sich nicht wenn ich das entsprechende Vorlagen-VI ändere -> ich muss jedesmal quer durchs Programm und die Pattern neu setzen (für den Fall dass ich mal ein Messwert mehr brauche in zukunft), alternativ wollte ich die Referenz durch die VIs schleifen, die verliert aber ihre Integrität und ist nicht mehr strikt wenn ich im SubVI damit arbeite (oder ich hab was übersehn)

dll-lib: der faule Ansatz in dem ich die Treiber als DLLs schreibe ... scheitert an den ziemlich mageren Schnittstellen zwischen LV und C

.NET: war sehr verlockend, ist aber leider nicht dynamisch (oder ich hab was übersehn). Eventuell könnte man auch die Pattern über die .NET-dll realisieren, ich hab keine Ahnung, bitte sagt es mir?

LVOOP ... ich tu mich seeehr schwer selbst mit den Tutorials zu begreifen wie ich einen vernünftigen Dummy erstelle den ich dann für neue Geräte einfach nur (mit weniger als 20 klicks) überschreiben kann und dann dynamisch laden kann. LabView ist da seeehr umständlich mit den LVOOP funktionen, die sind gut versteckt in Untermenüs und Eigenschaftsfenstern hinter kryptsichen Bezeichnungen (im deutschen Layout) soll "muss überschreiben" kopiert werden ... oder so ähnlich ... aber wie setz ich denn dieses "muss überschrieben werden" flag ? und warum erstellt er mir bei der Funktion für ableitende Klasse erstellen nur den Klassencontainer aber keine Funktionen(VIs), bzw. meckert mich nicht an dass ich diese nicht überschriebne habe?

AUSSERDEM: wenn ich die Anwendung generisch schreibe und zur Laufzeit mit einer abgeleiteten referenz die generische Methode aufrufe, wird auch der Code hinter der generischen Methode ausgeführt, obwohl ich davon ausgehen würde dass er der abgeleiteten Referenz wegen auch die abgeleitete Methode ausführt ... oder versteh ich da was total falsch und es geht so garnicht?

PS: tschuldigung für die ganzen Schreibfehler, ich war ein wenig verzweifelt und mehr am grübeln als am schreiben ... und hab mir nen ganz schlechten Schreibstil ohne groß und klein angewöhnt, gelobe Besserung

Anzeige

Hi

Zum Thema generisches Programmieren mit LVOOP gibt es in der Tat nur wenig Zusammenhängendes zu lesen.

Versuch es doch einmal mit folgender Diplomarbeit zum Thema Mobile Agenten mit LabVIEW. Die zugrunde liegenden HGF-Klassenbibliotheken, Veröffentlichungen und Vorträge findest Du hier.

Gruß Holger

also die Diplomarbeit zeigt zwar eine art generisches programmieren, jedoch seh ich immer wieder statische Verweise auf die entsprechenden abgeleiteten Klassen, welche zur Erstellzeit nicht zwingend bekannt sein müssen/können! ... und die Methodenaufrufe funktionieren hier scheinbar auch nicht so, dass die Methode der ableitenden Klasse statt der Eltern-Methode aufgerufen werden! ... es kann sein dass ich jetzt im schnellen durchlesen den entscheidenden Teil übersehen habe, aber kann es sein dass ich bis auf die privaten Daten nichts generalisieren kann ... also die überschriebenen Methoden nur dann verwenden kann, wenn die entsprechende Klasse zur Entwurfszeit bekannt ist.

revidiere meine Aussage (teilweise), im Anhang befindet sich noch sehr nützlicher Text!

ohje ... wenn ich das so lese verschwimmt mir alles vor den Augen ... kennt evetnuell jemand ein vereinfachtest Beispiel dafür oder ein passendes Tutorial ? Oder kann mir eventuell ein Mini-Beispiel zeigen, damit ich etwas zum verstehen habe? So ala i = ParentClass.increment(i); -> i = i+1; bzw. i = ((ParentClass)SubClass).increment(i); -> i = i+2;

Hi

Im Anhang findest Du ein Beispiel für die einfache Vererbung eines Dialogs.

Du musst aber noch HGF_BaseClasses herunterladen. Mindestens die Fehlerbehandlungs-VI werden daraus benötigt.

Gruß Holger

danke für die Downloadlinks!

das ist mal seeehr schön, so versteht es sich gleich viel besser

verstehe, ich muss das VI als dynamisches dispatch VI erstellen, damit es in den ableitenden Klassen auch erstellt wird

---------------------ab hier kann man überspringen -----------------------

aber ich muss den Aufruf des dynamischen "showDialog" noch in ein statisches "displayDialog" einbetten und indirekt aufrufen, oder könnte ich das "showDialog" auch so mit einer Referenz einer abgeleiteten Klasse im Main-VI(!!!) füttern?

oder ist das jetzt eher nur OOP-Kosmetik? (in dem Falle weil die dispatch VIs protected sind.. oder sind die generell protected ?)

Das einzige Problem ist nur wie ich dem Programm zur Laufzeit die Referenzen auf die entsprechenden Nachfolgerklassen vermittle (in dem Beispiel sind sie ja schon zur Entwicklungszeit bekannt) ... aber das Problem hab ich auch bei call by reference, nur bleibt durch die Elternklasse die Integrität der Referenz erhalten!

vielleicht seh ich den Wald vor lauter Bäumen nicht ...

mir schwebt da so eine Art Auswahldialog vor, der beim Aufruf das Verzeichnis scannt und die LVLibs anbietet, daraus hol ich mir die Referenzen und pack sie in ein Array oder Cluster... kann cih DAS eventuell mit call by reference lösen ? quasi einen "selbstentpacker"/"loader" VI starten? so müsste ich nur ein einziges connection pattern editieren wenn ich mal den "loader" ändern will

---------- hier gehts weiter --------------


Nachtrag: Ich habe jetzt mal einfach ne neue Klasse genommen, den Klassenpfad ermittelt (als dateidialog-ersatz) und dann den Pfad zum erstellen eines neues Objektes mit Hilfe von Objekteigentschaften ermitteln -> Laufzeitklasse ermitteln mit der Basisklasse als Zielobjekt dann als 3tes in das Array eingehangen, die showDialog.vi überschrieben und an die "Nachricht" noch etwas angehängt

http://twitpic.com/4pref4/full

VIELEN DANK an dieser Stelle ^^ das hat mich jetzt wochen des stöberns im Internet gekostet an genau so ein wunderschönes Beispiel zu kommen ... vielen vielen dank!!!!

(26.04.2011 14:15 )ceos schrieb:  danke für die Downloadlinks!

das ist mal seeehr schön, so versteht es sich gleich viel besser

Danke.

(26.04.2011 14:15 )ceos schrieb:  verstehe, ich muss das VI als dynamisches dispatch VI erstellen, damit es in den ableitenden Klassen auch erstellt wird, aber ich muss den Aufruf des dynamischen "showDialog" noch in ein statisches "displayDialog" einbetten und indirekt aufrufen, oder könnte ich das "showDialog" auch so mit einer Referenz einer abgeleiteten Klasse im Main-VI(!!!) füttern?

oder ist das jetzt eher nur OOP-Kosmetik? (in dem Falle weil die dispatch VIs protected sind.. oder sind die generell protected ?)

Dynamic Dispatch VIs können auch öffentlich sein und direkt aufgerufen werden. Der Vorteil meines Konstrukts, ein öffenliches statisches VI dem Benutzen anzubieten, liegt darin, dass ich ein pre-/post-processing von bzw. nach dem Aufruf des dynamic dispatch VIs erzwingen kann. Wenn das nicht nötig ist, kann man das dynamic dispatch VI auch direkt öffentlich machen. Meine Erfahrung zeigt aber, dass man selten beim ersten Versuch alles richtig bedacht hat. Bei meinem Konstruckt hat man noch die Möglichkeit nachzubessern, ohne das öffentliche Interface zu ändern bzw. an allen aufrufenden VIs zu ändern.

(26.04.2011 14:15 )ceos schrieb:  Das einzige Problem ist nur wie ich dem Programm zur Laufzeit die Referenzen auf die entsprechenden Nachfolgerklassen vermittle (in dem Beispiel sind sie ja schon zur Entwicklungszeit bekannt) ... aber das Problem hab ich auch bei call by reference, nur bleibt durch die Elternklasse die Integrität der Referenz erhalten!

Die Auswahl des richtigen Overwrite-VI bleibt LV überlassen. Es ruft immer das Overwrite-VI der konkreten Klass des eingehenden Objektes auf. (Dabei ist die Performance kein wirkliches Problem. Das haben die LV-Entwickler gut gelöst.) Um zur Laufzeit ein Objekt einer bestimmten Klasse generisch zu erzeugen, gibt es ein entsprechendes VI (getDefaultObject o.ä.). Besser ist es die HGF_Factory zu benutzen, die gleich die Attribute als Variant-Attrribute an das Objekt übergibt und es sich selbst richtig initialisieren kann, siehe Diplomarbeit.

(26.04.2011 14:15 )ceos schrieb:  vielleicht seh ich den Wald vor lauter Bäumen nicht ...

mir schwebt da so eine Art Auswahldialog vor, der beim Aufruf das Verzeichnis scannt und die LVLibs anbietet, daraus hol ich mir die Referenzen und pack sie in ein Array oder Cluster... kann cih DAS eventuell mit call by reference lösen ? quasi einen "selbstentpacker"/"loader" VI starten? so müsste ich nur ein einziges connection pattern editieren wenn ich mal den "loader" ändern will

Das Auswählen der verfügbaren Bibliotheken muss die/der Applikation/Entwickler schon selbst bereitstellen. Aber das dynaische Laden der Bibliothek kann zur Laufzeit erfolgen. Der Host des Agentensystems erledigt diesen Teil. (Es würde den Rahmen dieses Beitrags sprengen, dies hier im Detail zu erläutern.)

Ganz wichtig ist es noch, das Entwurfsmuster Besucher (Visitor) zu verstehen. Das ist ziemlich mächtig, und absolut notwendig, wenn man generisch mit LV-Objekten als Entities arbeiten möchte.

Gruß Holger

in dem Post eins höher hab ich schon meine Kommentare ergänzt ... ich wollte halt nicht Doppelposten

ich denke ich hab jetzt soweit die Übersicht wie ich meine Idee in LabView hochziehe

das dynamische Laden war einfacher als erwartet (siehe Bild und letzten Satz ein Post weiter oben) , die Factory schau ich mir an wenn ich den Frust der letzten Wochen abgeschüttelt habe ... nichts für ungut, aber ich hab schon fast abgeschlossen mit LabView weil ich so verzweifelt war ... der Umstieg iss schon ziemlich herb ^^

@ceos: Der 2. Beitrag heute, bei dem du alles klein schreibst!
Machst du das bei deinen Dokumenten für deinen Chef (wenn du einen hast) auch so?

Gruß, Jens

Ja ich habe einen Chef.

Nein ich gebe ihm nur doppelt korrekturgelesene Berichte!

weiter oben habe ich was dazu geschrieben:

PS: tschuldigung für die ganzen Schreibfehler,[...] hab mir nen ganz schlechten Schreibstil ohne groß und klein angewöhnt, gelobe Besserung

und ich habe die letzten Posts auch immer schön korrigiert wenn mir noch was aufgefallen ist .... der 2te Post im Bug Forum tut mir leid, den hab ich vergessen zu editieren, soll ich jetzt alle noch editieren oder reicht es wenn ich mich zukünftig mehr zusammenreisse ?

Schade dass man hier so superernst ist und gleich angeraunzt wird, ein einfaches "Bitte halte dich an die Regeln und schreib ordentlich" wäre freundlicher gewesen in meinen Augen.

(ausgehend davon dass es nicht so agressiv gemeint war wie er wirkte) klang der Post eben schon extrem böse und reizt schon fast zum flamen! (und das sage ich jetzt nur aus reiner Ehrlichkeit und nicht weil ICH provozieren möchte!)

Ansonsten wird einem hier sehr gut geholfen.

Ich habe dir heute vormittag schon eine PN geschrieben. Da du darauf nicht reagiert hast, greife ich jetzt öffentlich ein.

Gruß, Jens

P.S.: Solche Hinweise bekommt hier so ziemlich jeder, der sich nicht an die LVF-Regeln halten will. Nimm das also bitte nicht zu persönlich, es ist zu 50% auch immer ein Hinweis an alle.
Ich werde dir bestimmt nicht jeden Schreibfehler vorhalten, aber bei durchgehender Kleinschreiberei greife ich ein.