Numerisch Double vs. Double

Hallo liebe LV Gemeinde,

habe mal eine Nachfrage / Info. Wer ins ab und an mal ins LVOOP Forum schaut hats ja vielleicht schon gesehen, dass ich mir mal eine "Number" Klasse gebaut hatte die unter anderem nen Variant einliest und anschließend in ne Unterklasse des entsprechenden Typs umwandelt. Habe dabei jetzt gerade eine "interessante" (=ärgerliche) Sache entdeckt:

Offenbar kennt Labview aus irgendeinem Grund 2 Arten von Doubles. Die eine gibt beim Drüberhovern in der Kontexthilfe aus sie sei: "Numerisch(Double[...])", die andere "(Double[...])" *ohne das Numerisch*

Das erste kriegt man aus Numerischen Controls raus (kann man aber offenbar auch aus Rechenoperationen rauskriegen - warum, wieso und vor allem wann - keine Ahnung), das zweite aus Konstanten die man aufs BD droppt.

Warum ist das ein Problem? Nun, meine Klasse untersucht auf "Number" Ebene den Typstring und erstellt dann eine Adäquate Kindklasse. Dummerweise ist der Typ String von Double: [4, 10]
Während der von Numerisch(Double) zum Beispiel: [14, 16394, 2382, 30061, 25970, 26995, 25448] ist... (ja ich habe grade gesehen, dass der nicht immer der gleiche ist...)
Entsprechend führt das zu Fehlern. In der LV Hilfe ist auch nur angegeben, dass für Zahlen der Typ String [4, Zahl] ist wobei Zahl den typ definiert (DBL, I32 etc. pp.). Diese komische Zweite Art von Zahl wird da garnicht erwähnt.

Weder habe ich ne Ahnung wie dieser zweite Typstring überhaupt zu entschlüsseln ist, noch verstehe ich warum das verschieden gehandhabt wird. Vor allem da nirgends ein Cast auf was anderes angezeigt wird (wenn ich Numerisch(Double) zu (Double) addiere, dann kommt double raus, ohne dass der am Eingang irgendwas rot markiert)... Wann Rechenoperationen diesen Numerisch(Double) Typ erhalten und wann nicht ist mir auch etwas unklar. Scheinbar ist Array Addition zum Beispiel typerhaltend.

*edit* Aus irgendwelchen Gründen schleift Labview den Bedienfeldnamen oder Untertitel (im Datentyp) mit und erhält den bei Addition (benutzung des Addition primitive VI) mit sich selbst nicht, bei Addition mit was anderem schon - *verwirrt*
Warum man den das dann aber noch dazu in den typstring reinsteckt ist mir unverständlich, da der Bedienfeldname eigentlich nur zur Programmierzeit eine Bedeutung hat, entsprechend ist der für den Typstring grundsätzlich völlig ohne Belang (da der Typstring ja eigentlich den Datentyp angeben soll und nicht woher der kommt).

Ich bin jedenfalls nachhaltig verwirrt. Und frage mich ob man das Problem lösen kann (im Sinne von: den Zusatz verändern oder trotz Zusatz den Typ richtig auslesen).

gruß Kiesch

Es gibt halt unterschiedliche type descriptors für Konstanten und FP-Elemente. Du kannst das hier:

   

benutzen (Get TDEnum from Data__ogtk.vi). Bitte dazu OpenG Toolkit installieren.

VDB

@VDB

warum krieg ich aber dann trotzdem so einen "merkwürdigen" Typ bei einem Wire, dass ein Ausgang von Arrayelemente aufsummieren ist (der Ausgangspunkt der mich drauf gestoßen hat waren zwei Ausgänge von jeweils nem SubVI, die multipliziert und anschließend aufsummiert wurden und trotzdem hab ich hinterher nen "Frontpaneldatentyp" oder was auch immer das sein soll - obwohl dem an sich keine Frontpanelreferenz irgendeiner Form zugeordnet werden kann (Array aufsummieren liefert nen Skalar, die Arrays selbst hingegen sind eben nunmal arrays, noch dazu geht der Bezug zum Frontpanel eigentlich schon an dem Punkt verloren wo sie multipliziert werden (da an der Stelle schon keines der FP Elemente hinter dem Steckt was da rauskommt.

Ansonsten: Geht das auch irgendwie vernünftig ohne OpenG Toolkit? Wollte das eigentlich bisher immer vermeiden irgendein Toolkit zu installieren wenns nicht Notwendig ist... Falls nicht anders geht würd ich das natürlich noch machen...

Frage dann noch dazu: Das gezeigte VI gibt dann den tatsächlichen Typ aus? (also in meinem Fall immer Double)

Vielleicht
Ich hätte hier exemplarisch noch ein paar weitere Doubles:
   
Passt auch mit der "Klassenhierachie" von LabVIEW-Controls zusammen:
   
Datentyp von Numeric-Controls lässt sich bei aktiviertem LabVIEW-Scripting auch hierüber feststellen:
   
Gruß, Jens

Verstehe trotzdem nicht wieso das weitergeschleift wird. Eine Referenz auf den Knopf mit der man etwas mit den Daten anfangen könnte kann man doch daraus eh nichtmehr konstruieren (?).

Gibts da denn von NI ne Aussage zu? Oder ist das ein Bug / Feature?

*seufz* ich schau mir dann mal schonmal das OpenG Toolkit an *grummel*

(19.02.2013 16:05 )Kiesch schrieb:  Offenbar kennt Labview aus irgendeinem Grund 2 Arten von Doubles. Die eine gibt beim Drüberhovern in der Kontexthilfe aus sie sei: "Numerisch(Double[...])", die andere "(Double[...])" *ohne das Numerisch*

Das 'Numerisch' vor dem '(Double[...])' ist doch einfach der (default) Label-Name des Controls - oder bin ich da jetzt ganz auf dem Holzweg?

Anzeige

So hab mir das mal angeschaut und das funktioniert. Muss wohl doch auch mal näher ins OpenG Toolkit reinschauen, sind ja doch ein paar ganz hilfreiche Funktionen auch dabei.

Ansonsten, für diejenigen die nicht das OpenG Toolkit verwenden wollen:

Der eigentliche Typ ist im lo Teil des 2ten Integers codiert (und immer gleich). Entsprechend muss man wenn man an den ran will das einmal mit Zahl Teilen bearbeiten.

Als Veranschaulichung die Implementierung im OpenG Toolkit:

   

Zu beachten ist, dass Enums und Integer intern unterschiedliche Typen haben (was ja durchaus sinnvoll ist).

Gruß Kiesch

P.S: Ich erlaube mir mal das auch als Lösung zu markieren, da es denke zumindest zum Verständnis beiträgt.
Thema hat sich dann damit erledigt.

Alternativ gäbe es auch das <vi.lib>\Utility\VariantDataType\GetTypeInfo.vi. Damit und mit den anderen VIs aus den Ordner, kann man auch recht viel über Datentypen raus bekommen, ohne OpenG und ohne den VIPM.