TypeCast U16-Array auf FXP-Array - zu wenige Elemente

Hallo zusammen,

gestern ist mir wieder mal sauer aufgestoßen, dass ich keine Arrays aus U16 in Arrays aus FXP "typecasten" kann. Soweit ich das herausfindenkonnte funktionieren die anderen DatenTypen wunderbar: es werden immer sauber alle Bits "uminterpretiert". Bspw. stecken im Ausgangs-Array 2Elemente U16 und ich typecaste das nach U8, dann sind es 4xU8 Elemente. Aber mit dem FXP Datentype habe ich Probleme!

Hier mein konkretes Problembeispiel:
   

Gruß

Hallo nochmal,

ich habe ein weiteres Test-VI gebaut, was mein "Problem" noch einfacher veranschaulicht. Es enthält 3 Tests, wobei die ersten beiden funktionieren der dritte aber fehlschlägt. Aber bitte seht selbst:
   
   

Wo steckt mein Denkfehler, oder ist es tatsächlich ein Bug?

Gruß

Hallo Erik,

frag doch mal bei NI nach, warum ein FXP-Array intern nach U64 gecastet wird, ein skalares FXP degegen nach U8. Würde mich auch interessieren...

Der Typecast-Block an sich nimmt meiner Meinung nach keine Arrays an, sozusagen, versuchst du ein Element vom Typ ArrayFXP in ein Element vom Typ ArrayU8 umzuwandeln. Arrays werden in LabVIEW scheinbar anders gespeichert als reine Variablen. Also ist ein Array U8 genauso groß wie ein Array U64? Das müsste man genauer untersuchen.
Jedenfalls, geht das so nicht wirklich. Das jeder 8. Wert stimmt liegt dann (wenn meine erste Ausssage stimmt) daran, dass der Typecast bei Elementen mit weniger Bits als der geforderte Typ, die Bits in den Upper-Bit bereich schiebt. (siehe dazu die LV-Hilfe) Größter unsigned Datentyp ist U64, also 8x8 Bits, also 8x U8.
Hab das natürlich jetzt nicht kontrolliert, bin aber der Meinung, dass das der Grund sein sollte. Sollte dem nicht so sein, bitte korrigiert mich. Bin ja schließlich lernwillg.

PS: Für FXP Typecasts nutze ich in der Regel gleich die vorgefertigten Blöcke für den FXP-Typ.

(13.03.2012 11:49 )GerdW schrieb:  Hallo Erik,

frag doch mal bei NI nach, warum ein FXP-Array intern nach U64 gecastet wird, ein skalares FXP degegen nach U8. Würde mich auch interessieren...

Wer sagt denn dass ein FXP intern ein U8 ist? Wenn Du einen String von 2Millionen Bytes in einen U8 Typecasted nimmt LabVIEW auch einfach den ersten Character und tut nichts mit dem Rest. Das ist was die ersten zwei Beispiele tun. Typecaste einen Skalar FXP in ein Byte Array und Du erhälst genau 8 Bytes. Das ist das interne Format für ein FXP da er maximal 64 Bits haben kann. Das dynamisch im Speicher anders machen zu wollen wäre ziemlich sinnlos, da die Ersparnisse an Speicher minimal sind, aber die Performanceauswirkungen gewaltig zu Buche schlagen können. Der FPGA Compiler wird wahrscheinlich schon ein Optimierungsschritt haben um bei der Umsetzung nach FPGA diese unbenützten Bits wegzuoptimieren, was aber wohl einige Zeit beim Compilieren hinzugefügt hat.

Aber FPGA Compilieren macht man typischerweise nur ab und zu, das Diagram checken und für Compilierung bereithalten wird andauernd bei jeder Editoperation im Hintergrund getan.

Hallo und danke für das rege Interesse,

Ich habe nun beim Support von NI nachgefragt:
Es ist bestätigt, dass für RT und Host-Systeme (nicht FPGA) der FXP-Datentyp intern immer mit 64bit gerechnet wird. Das ist die maximale Breite des Datentyps. Es gibt (noch) keine Ermittlung des Mindestbreite, selbst wenn man explitzit bspw. den FXP-Datentyp auf 8bit-Breite eingestellt hat.

kurzum: Its a feature, not a bug.

Da ich den FXP-Datentyp zunächst nur auf der FPGA-Ebene verwendete (und es da wie vorhergesehen funktioniert), glaubte ich zunächst einen Bug entdeckt zu haben, als ich es auf Host-Seite ausprobierte. Es ist für mich schlicht nicht "intuitiv" wenn ein explizit auf 8bit gestellter Datentyp intern weiterhin 64bit hat. Wenn ich explizit U8 wähle, dann ist der intern ja auch nicht U64, oder?

Alles jammern hilft nichts. Jetzt habe ich die Funktionsweise verstanden und werde meinen Code entsprechend anpassen.


Danke und Gruß
Erik

Anzeige

(13.03.2012 13:26 )erik.brenncke schrieb:  Hallo und danke für das rege Interesse,

Ich habe nun beim Support von NI nachgefragt:
Es ist bestätigt, dass für RT und Host-Systeme (nicht FPGA) der FXP-Datentyp intern immer mit 64bit gerechnet wird. Das ist die maximale Breite des Datentyps. Es gibt (noch) keine Ermittlung des Mindestbreite, selbst wenn man explitzit bspw. den FXP-Datentyp auf 8bit-Breite eingestellt hat.

kurzum: Its a feature, not a bug.

Da ich den FXP-Datentyp zunächst nur auf der FPGA-Ebene verwendete (und es da wie vorhergesehen funktioniert), glaubte ich zunächst einen Bug entdeckt zu haben, als ich es auf Host-Seite ausprobierte. Es ist für mich schlicht nicht "intuitiv" wenn ein explizit auf 8bit gestellter Datentyp intern weiterhin 64bit hat. Wenn ich explizit U8 wähle, dann ist der intern ja auch nicht U64, oder?

Alles jammern hilft nichts. Jetzt habe ich die Funktionsweise verstanden und werde meinen Code entsprechend anpassen.


Danke und Gruß
Erik

Du vregisst den Unterschied. Ein U8 oder U64 ist ein explizit gewählter Datentyp der ja auch ein eigenes Icon, und im Falle der polymorphen Funktionen auch eigene Methoden hat, aber der FXP ist ein nachträglich konfigurierbarer Datentyp. Das eine wird vom Syntaxchecker einmal bei der Auswahl des Datentyps festgelegt, das andere ist mehr eine Laufzeiteinstellung, ausser wenn es im FPGA Compile in den Bytecode umgesetzt wird.

Wäre auch nicht praktisch um aus 64 verschiedenen FXP Icons wählen zu müssen.

Danke,

das hab ich soweit jetzt verstanden, trotzdem beißt sich das in meinem bescheidenen LV-Verständnis (noch) etwas mit der "intuitiven" Polymorphie beim TypeCast.

Gruß


offtopic: Es wären sogar mehr als 64icons, da man ja auch zw. signed/unsigned unterscheiden kann.