Hallo LVF!
Meine Frage ist, wie kann ich solche typunabhängige SubVIs erstellen?
' schrieb:Hallo LVF!
Meine Frage ist, wie kann ich solche typunabhängige SubVIs erstellen?
Polymorphe VIs (Voraussetzung: mind. Pro-Paket). Wobei die dann immer nur für die Datentypen funktionieren, für die du was definierst.
Gruß, Jens
' schrieb:Polymorphe VIs (Voraussetzung: mind. Pro-Paket). Wobei die dann immer nur für die Datentypen funktionieren, für die du was definierst.
Gruß, Jens
Diese Lösung passt mir leider nicht.
Ich weiss, dass ich es so machen kann:
[
attachment=16414]
Aber ich will Queues mit einem Array verwalten und da kommt es zu folgendem Problem:
[
attachment=16415]
' schrieb:Diese Lösung passt mir leider nicht.
Ich weiss, dass ich es so machen kann:
[attachment=44063:QueueTyp.png]
Aber ich will Queues mit einem Array verwalten und da kommt es zu folgendem Problem:
[attachment=44064:QueueArray.png]
Dann sind aber die Cluster in deinem 2. Bsp nicht identisch. Denn zu einem Array kannst du natürlich nur Elemente gleichen Typs zusammenfassen.
Ich habe nur mal kurz nachgezeichnet, und bei mir hat es z.B. so kein Problem gegeben:
[
attachment=16419]
Gruß, Jens
' schrieb:Dann sind aber die Cluster in deinem 2. Bsp nicht identisch. Denn zu einem Array kannst du natürlich nur Elemente gleichen Typs zusammenfassen.
Ich habe nur mal kurz nachgezeichnet, und bei mir hat es z.B. so kein Problem gegeben:
[attachment=44068:Image01.png]
Gruß, Jens
Ja, aber so bekommt man das Kommando (in der Case-Struktur) nicht raus, man muss dann noch mal kasten. Siehe hier:
' schrieb:Meine Frage ist, wie kann ich solche typunabhängige SubVIs erstellen?
RTTI - Runtime-Typinfo. So heißt das in Delphi. Verwende ich aber nicht. Ob es sowas in LV gibt, weiß ich nicht. Möglicherweise in der Pro-Version.
Das Problem ist die strikte Typbindung des Kompilers - was auch richtig so ist.
' schrieb:RTTI - Runtime-Typinfo. So heißt das in Delphi. Verwende ich aber nicht. Ob es sowas in LV gibt, weiß ich nicht. Möglicherweise in der Pro-Version.
Das Problem ist die strikte Typbindung des Kompilers - was auch richtig so ist.
Dann bleibt wahrscheinlich nichts anderes übrig als Strings statt Enums zu verwenden (was ich ja auch mache) oder Typecast ausserhalb des Lese- und Schreibe- SubVIs zu verwenden. Das Problem bei der ersten Lösung ist, dass Strings im Vergleich zu Enums CPU-fressender sind und es können Tippfehler beim Schreiben auftreten. Das Problem bei der zweiten Lösung ist, dass es nicht mehr so kompakt (kann man nicht als Libraray verwenden) aussieht, wie es gewünscht ist.
Die dritte Möglichkeit wäre die Queuereferenzen nicht mit Arrays, sondern in einem Cluster zu verwalten, was dann aber dazu führt, dass man die Erstellung von Queues nicht in ein universelles SubVI packen kann, da der Cluster mit Queuereferenzen dann projektabhängig ist. Und ausserdem kann man dann keine neuen Queues zur Laufzeit erzeugen, was die ganze Dynamik des Projektes ausschliesst.
' schrieb:Dann bleibt wahrscheinlich nichts anderes übrig als Strings statt Enums zu verwenden (was ich ja auch mache)
Genau. Aufgrund der Struktur eines Strings geht das nämlich.
Zitat:Das Problem bei der ersten Lösung ist, dass Strings im Vergleich zu Enums CPU-fressender sind und es können Tippfehler beim Schreiben auftreten.
Genau. Und deshalb, besonders letzteres wegen, ziehe ich die Methode mit Enum und Konvertierung vor.
Mehr zum Thema:
http://www.LabVIEWforum.de/index.php?showt...ost&p=63332
So wie es aussieht werde ich keine gute und passende Lösung dazu finden. Aber ich bin jetzt davon überzeugt Numeric(für Kommando) und String(für Daten) zu nehmen und Type Cast aufs Kommando ausserhalb des Lese- und Schreibe- VIs zu verwenden. Ich glaube in anderen Programmiersprachen wird es auch so gemacht. Es kommst also demnächst eine neue Version der Tasking-Library (wo ich leider immer dem Benutzer der Library erklären muss, dass er beim Lesen und Schreiben zuerst das Kommando auf/von Enum type-kastet
).