Unbekannter LabVIEW Knoten

' schrieb:Coercion Dot (kleines rotes Dreieckchen oder "Punkt").

Ahhh, kenne ich doch. Hatte ich schon öfters. Wußte nur nie warum sie da sind, was sie bedeuten, geschweige denn wie sie heißen.
Aber man lernt nie aus...

' schrieb:Coercion Dots gibt's wenn Du z.B. eine U32-Konstante an einen I16-Indicator anschließt, genauso ist es wenn Du z.B. an eine "Geteilt"-Funktion eine Integerzahl anschließt. Da werden immer Double verlangt. Wenn Du eine Integerzahl anschließt, wird es intern umgerechnet. Der Hinweis dafür ist eben ein Coercion Dot (kleines rotes Dreieckchen oder "Punkt").

Gruß Markus

Ja, aber ich meine sowas:
   

Und ja, ich stelle meine Frage anders:
wie kann ich ein universelles SubVI erstellen, das beliebigen Enum (als Typ) am Eingang hat und diesen Enum dann ausgibt?

' schrieb:Ja, aber ich meine sowas:

Du willst also wissen, warum beim Vergleich eines U16-Enums mit einem U16-Int bei U16-Enum ein Konvertierungspunkt erscheint?
Ganz einfach: U16-Enum und U16-Int sind zwei verschiedene Typen. Auch wenn die Bitbreite gleich ist, so ist ein Enum, sogar jeder verscheidene Enum, ein eigener Typ. Und das ist auch gut so. Es muss hier also ein Konvertierungspunkt erscheinen.
Enum-Typen wie auch Int-Typen haben eine Grenze: An dieser Grenze funktioniert - eigentlich - der Befehl succ(Value) bzw. pred(Value) nicht. Und da Enums eine unterschiedliche Länge (Anzahl Elemente) haben können, liegt auch diese Grenze bei jedem Typ anders. Daher sind die Typen nicht gleich. Es gibt z.B. Kompileroptionen, die auf Bereich testen (und bei Überschreiten eine AV werfen) - auch deshalb darf man Enums nicht mischen => Konvertierungspunkt.

Jetzt wolltest du aber wissen, warum bei diesem ULK-Element () kein Dot erscheint: Wer weiß, was die da reingebaut haben, die Softwarler von LV.

Zitat:wie kann ich ein universelles SubVI erstellen, das beliebigen Enum (als Typ) am Eingang hat und diesen Enum dann ausgibt?

So ganz verstehe ich das jetzt nicht. Einfach Eingang auf Ausgang geben?
Oder meinst du ohne Dot?
Ohne Dot würde theoretisch wie folgt gehen: Der Typ des Eingangs ist ein Typ, der für alle Enums identsich ist. Also sozusagen, wenn alle Enums von diesem einen Basistyp abgeleitet sind. Ob das irgendwie mit LVOOP gehen würde?

VielenDank für die Antworten!
Gruß
Bruno

' schrieb:Ja, aber ich meine sowas:
[attachment=44054:CDot.png]

Ist das vielleicht die Lösung?
   

' schrieb:Ist das vielleicht die Lösung?
[attachment=44073:enum.png]

Ja, das ist klar, aber probiere das mal in ein SubVI zu packen.

Anzeige

Hier....


  Untitled_7.vi (Größe: 5,94 KB / Downloads: 137)



  Untitled_8__SubVI_.vi (Größe: 6,89 KB / Downloads: 142)



Gruß Markus

' schrieb:Hier....

[attachment=44076:Untitled_7.vi]

[attachment=44077:Untitled_8__SubVI_.vi]


Gruß Markus

Und jetzt trage in Enum etwas ein.
   

Ich meine wie kriegt man im SubVI den Datentypen (Liste mit Elementen) des angeschlossenen Enums raus?

' schrieb:Ich meine wie kriegt man im SubVI den Datentypen (Liste mit Elementen) des angeschlossenen Enums raus?

Gute frage ich ahb diese Problem in meinen Progs mit Typ.Def. gelöst, wäre aber über ne andere und universelle Lösung auch sehr dankbar...

' schrieb:Und jetzt trage in Enum etwas ein.
[attachment=44078:Hi.png]

Ich meine wie kriegt man im SubVI den Datentypen (Liste mit Elementen) des angeschlossenen Enums raus?

Da must Du schon den Ring statt den Enum verwenden, da geh es nämlich nicht so pingelig zu wie bei Enum.

Und wenn du an das Sub-Vi statt den Wert die Referenz übergibst, dann geht Dir auch der Ringtext dort nicht verloren.