Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
08.05.2014, 21:58 (Dieser Beitrag wurde zuletzt bearbeitet: 08.05.2014 22:09 von jg.)
Habe ein kleines Programm zu Testzwecken mit zwei Qeues und einem Eventhandler gebastelt,
das auch soweit funktioniert. Um das Blockdiagramm etwas übersichtlicher zu gestalten, habe ich die
Qeue-Operationen in je einem Sub-Vi als FGV ausgelagert. Das kann ich dann über ein Enum
mit Init, Set und Get aufrufen, was nichts anderes als obtain, en- und deqeue macht und die Qeue-Ref
in eine FGV speichert. Läuft auch.
Die Qeues sind jeweils Type-Def-Structs mit je einem Type-Def-Enum (als Message-Header) und einem
Variant (als Message-Data), pro Qeue jeweils anders, da die beiden Qeues ja was unterschiedliches machen sollen.
So weit, so gut.
Als nächstes wollte ich, falls zukünftig weitere Qeues kommen sollten, das ganze noch dynamischer machen
und habe die beiden Sub-Vis in ein Polymorphes gepackt. Diese werden dann mit dem entsprechenden Type-Def
eindeutig zugeordnet beim Aufrufen des Polymorphen.
Hier funktioniert das ganze nicht mehr, was mich überrascht hat. Das Poly-Vi wählt doch "auch nur" zwischen
den beiden Vis, die ich vorher einzeln hatte, - und die liefen -, oder? Oder haut die Speicheradressierung nicht mehr
hin für die Verwendung einer FGV?
Ich hoffe, das Problem ist klar geworden, ansonsten gerne nachfragen.
Für Ideen, Erklärungen und weiteres wäre ich sehr dankbar.
Haben Sie ja nicht.
Sind zwar beide Enums, jede aber als eigene Typedef., wenn man die jeweils verkehrt anschließt kommt auch eine
Fehlermeldung, dass die Typen nicht passen. Das Poly-Vi unterscheidet richtig.
Wie gesagt, es funktioniert bei beiden VIs seperat genommen gleichzeitig in einer Main.
Sie sind identisch aufgebaut, jedoch unterschiedliche Typedefs vorrausgesetzt.
Es haut erst nicht mehr hin, wenn sie in ein Poly gepackt werden.
Ich poste morgen mal einen Ausschnitt daraus, der das ganze auf das Problem reduziert.
Gruß,
Andre
11.05.2014, 08:50 (Dieser Beitrag wurde zuletzt bearbeitet: 11.05.2014 08:53 von cb.)
mit Polymorphen VIs geht das nicht, ausserdem müsstest du für jede neue "Instanz" (=neues Enum-Typedef) das entsprechende VI neu programmieren und in das polymorphe VI einbinden. Das bringt dann zwar etwas vorteil beim Programmieren, vorallem wenn man viel mit Copy&Paste arbeitet, hilft aber nicht wirklich viel ...
Das Mittel der Wahl wäre eigentlich LVOOP. Ich hab mich mit der genau der gleichen Problemstellung schon seit LV 8.0 rumgeschlagen, weil ich auch sehr viel mit den von dir beschriebenen Strukturen mache. Ein Problem ist dann aber selbst bei LVOOP, dass die Elemente des Klassen-Clusters "protected" sind, d.h. du kannst den Cluster ausserhalb der Klasse nicht aufdröseln, was im Endeffekt dazu führt dass du dann doch wieder für jedes typedefed Enum ein eigenes VI erzeugen musst, weil ja das Control (-Terminal) im VI an das Typedef gebunden ist und nicht durch einen dynamic dispatch Mechanismus in das "richtige" Typedef umgewandelt wird.
Im Endeffekt läuft es darauf hinaus, dass man mit LVOOP zwar eine Standard-Queued-Statemachine-Queue-Klasse (watt ein Wort ...) entwickeln kann, aufgrund der internen Beschränkungen von LVOOP kann man sie dann aber wiederum nicht nutzen (Stand LabVIEW 2011 SP 1 ...). Und genau das ist der Grund warum ich immer sage: LVOOP ist eigentlich nur ein Marketing-Gag, wirklich viel bringen tut es nicht - zumindest nicht so lang man solche Sachen wie oben beschrieben nicht damit lösen kann und sich Basis-Klassen schreiben kann, die man dann auch wirklich über jahre hinweg in jedem Projekt nutzen kann ...
Leider häng ich gerade noch auf LV2011SP1 fest (aus diversen Gründen) und da schafft man es nicht mit LVOOP eine Basis-Statemachine-Queue-Klasse aufzubauen, die dann auf eine abgeleitete Klasse reagiert bei dem im Prinzip nur das typedefed enum ausgetauscht wird mit dem man die States für die Klasse festlegt. Aber vielleicht geht das ja mit 2013SP1? Obwohl ich es mir ehrlichgesagt nicht vorstellen kann - aus den og. Gründen ...
Das Test-Projekt, das ich angehangen habe hilft in Richtung deiner Fragestellung schon mal ein bischen, allerdings muss man immer noch für die Queue-Insert und Dequeue-Operationen ein extra VI erstellen, im besonderen dann, wenn man das getypedef'te Enum als einzelnes Control (-Terminal) haben will, damit man es einzeln anschließen kann, was man fast muss, da man ja im Klassen-Cluster keinen Zugriff auf irgendwelche Elemente hat ...
Ich schaue mir das mal an, wenn ich es schaffe mit LV2013 dann eine
benutzbare "Standard-Queued-Statemachine-Queue-Klasse" zu bauen,
werde ich das Ergebnis posten.
(11.05.2014 11:04 )Andre_A schrieb: super Antwort, danke.
... auch wenn's selbst in den Ohren des Autors wie "super-nerdy-Bullshit" klingt
lass es mich unbedingt wissen wenn es geklappt hat - ich hab grad selber keine Zeit mich drum zu kümmern. Wenn das wirklich funktioniert, dann werd ich ab sofort freudiger LVOOP-Hardcore-User und strick mein gesamtes Project-Design-Pattern um
Was mich an der ganze Geschichte irgendwie nervt ist, dass LV alle Möglichkeiten um das umzusetzen eigentlich schon mitbringt (Stichwort: X-Nodes), das ganze aber für die "normalen" Anwender nicht freigegeben wird. Ich hab keine Ahnung ob in Deutschland überhaupt jemand eine X-Node-Entwicklungs-Lizenz hat!? Ich hab mal nach einer Lizenz gefragt, aber mein Ansinnen wurde wohl von NI als so abwegig eingestuft, dass ich noch nicht mal eine Antwort bekommen habe. Und dann steh ich da mit dem halbgaren LVOOP, fluch leise vor mich hin, und benutz weiter mein VIScripting-based-Queuded-Statemachine-Queue-Management-VIs-Template-Instance-Create&Copy-Tool (noch ein viel schöneres Nerd-Wort ) und denk mir jedes mal: "sch**** die Wand an, eigentlich müsste das doch schon längst anders gehen!"
(11.05.2014 11:04 )Andre_A schrieb: super Antwort, danke.
... auch wenn's selbst in den Ohren des Autors wie "super-nerdy-Bullshit" klingt
lass es mich unbedingt wissen wenn es geklappt hat - ich hab grad selber keine Zeit mich drum zu kümmern. Wenn das wirklich funktioniert, dann werd ich ab sofort freudiger LVOOP-Hardcore-User und strick mein gesamtes Project-Design-Pattern um
Was mich an der ganze Geschichte irgendwie nervt ist, dass LV alle Möglichkeiten um das umzusetzen eigentlich schon mitbringt (Stichwort: X-Nodes), das ganze aber für die "normalen" Anwender nicht freigegeben wird. Ich hab keine Ahnung ob in Deutschland überhaupt jemand eine X-Node-Entwicklungs-Lizenz hat!? Ich hab mal nach einer Lizenz gefragt, aber mein Ansinnen wurde wohl von NI als so abwegig eingestuft, dass ich noch nicht mal eine Antwort bekommen habe. Und dann steh ich da mit dem halbgaren LVOOP, fluch leise vor mich hin, und benutz weiter mein VIScripting-based-Queuded-Statemachine-Queue-Management-VIs-Template-Instance-Create&Copy-Tool (noch ein viel schöneres Nerd-Wort ) und denk mir jedes mal: "sch**** die Wand an, eigentlich müsste das doch schon längst anders gehen!"
viele Grüße
cb
Ausser wenn Du nie rot anläufst wenn LabVIEW sich einfach ganz unscheinbar ins Nirvana abmeldet oder etwas netter einen Crashdialog sehen lässt sind X-Nodes wahrscheinlich nichts für Dich.
Und vom Ton deiner Postings in diesem Thread bezweifle ich ein wenig dass das bei dir der Fall wäre.
(15.05.2014 10:58 )rolfk schrieb: Ausser wenn Du nie rot anläufst wenn LabVIEW sich einfach ganz unscheinbar ins Nirvana abmeldet oder etwas netter einen Crashdialog sehen lässt sind X-Nodes wahrscheinlich nichts für Dich.
Und vom Ton deiner Postings in diesem Thread bezweifle ich ein wenig dass das bei dir der Fall wäre.
ach, die Crashes hab ich auch ohne X-Nodes. Manchmal ein paar mal am Tag. Ich hab keine Ahnung ob es bei LV2013SP1 besser is, aber ich glaub's nicht, denn das gibt's seit ich LV benutze (2001). Und rot anlaufen, den Computer anbrüllen, LabVIEW verfluchen und NI zur Hölle wünschen gehört bei mir zum daily business
Ok, wieder ernst: klar, ist das ein "heisses" Feature und man kann viel Sch**ss mit machen, aber das kann man mit Pointern auch und keiner käme auf die Idee Pointer zu verbieten weil man damit Memory leaks programmieren kann. Und ich geb die Hoffnung nicht auf, dass das irgendwann auch mal als offizielles Features released wird, das würde nämlich wirklich viel bringen! (mir zumindest - glaube ich)
/
Queues mit FGVs in Polymorphen VI
...) entwickeln kann, aufgrund der internen Beschränkungen von LVOOP kann man sie dann aber wiederum nicht nutzen (Stand LabVIEW 2011 SP 1 ...). Und genau das ist der Grund warum ich immer sage: LVOOP ist eigentlich nur ein Marketing-Gag, wirklich viel bringen tut es nicht - zumindest nicht so lang man solche Sachen wie oben beschrieben nicht damit lösen kann und sich Basis-Klassen schreiben kann, die man dann auch wirklich über jahre hinweg in jedem Projekt nutzen kann ...
