+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Bug Liste (/Forum-LabVIEW-Bug-Liste)
+---- Forum: LabVIEW 2010 (/Forum-LabVIEW-2010)
+---- Thema: Fehler beim Typecast: u32->sgl, sgl->u32 (/Thread-Fehler-beim-Typecast-u32-sgl-sgl-u32)
Fehler beim Typecast: u32->sgl, sgl->u32 - rdugg - 06.04.2011 14:46
Hallo,
in einem komplexeren Prüfsystem wird auf einer RT-Hardware ein SGL-Array erzeugt, das unter anderen auch Daten von einem Bool-Array enthält, das ganze wird zum PC geschickt (TCP-IP) dann wird SGL-Array wieder zerlegt und das Bool-Array extrahiert.
Dabei tritt bei Bit 22 in einem 32iger Bool-Array ein Fehler auf.
Ich konnte das ganze ohne RT-Hardware auf dem PC reproduzieren.
In dem Beispiel (Anhang) sind zwei Varianten per Disable-Structure möglich.
[attachment=33138]
Einmal funktioniert der Typcast fehlerfrei, beim anderen Mal nicht.
Kann mir da bitte jemand weiterhelfen?
Vorab vielen Dank!!!
RE: Fehler beim Typecast: u32->sgl, sgl->u32 - GerdW - 06.04.2011 15:37
Hallo rdugg,
abgesehen davon, dass es grenzwertig ist aus einem Array mit 32 Elementen irgendwas bei Index 32 und 64 auszuschneiden, scheint beim BuildArray eine Prüfung der SGL-Werte stattzufinden. Aus einem "beliebigen" NaN wird dann ein korrektes NaN und der dahinterliegende 32bit-Wert ändert sich... Ohne BuildArray passiert auch nichts mit dem Bitmuster!
Mögliche Lösung:
Caste doch in ein U32-Array...
RE: Fehler beim Typecast: u32->sgl, sgl->u32 - rolfk - 09.04.2011 00:08
(06.04.2011 14:46 )rdugg schrieb: Einmal funktioniert der Typcast fehlerfrei, beim anderen Mal nicht.
Kann mir da bitte jemand weiterhelfen?
Hast Du Dir schon mal den Wert der Fliesskommazahl angeschaut? Das ergibt NaN (Not a number). Und gemäss Standard ist ein ganzer Range von Bit Patterns equivalent zu NaN, und ist NaN == NaN immer falsch.
Im einen Fall funktioniert es weil LabVIEW alles inplace tut und der binäre Wert der 4 Bytes im Speicher dadurch nie ändert. Im anderen Fall ist es wegen dem Array alles ausser Inplace. Und da immer: NaN != NaN, macht es auch nichts aus, wenn LabVIEW beim kopieren einer NaN Zahl ein anderes Bitpattern nimmt das ebenfalls NaN angibt, und das ist dann die kanonische NaN mit allen Bits gesetzt.