 DBL to I16 bug |
|
|
|
|
Bug reporting guidelines:
See here for the proper LabVIEW bug reporting procedure.
Tags |
(This content has not been tagged yet)
|
 ·
 ·
 ·
 ·
 ·
 ·
 ·
 ·
 ·
 ·
 ·
 ·
 |
 Aug 9 2006, 09:57 PM
Post
#1
|
|||
 Active  Member Posts: 18 Joined: 25-October 05 From: Kitchener Member No.: 3342 Using LabVIEW Since:2003 LV:8.0.1 ,7.1.1 ,7.0 
 |
I'm running LabVIEW 8.01
LabVIEW 8.01 handles data type conversions differently. When converting a Double (36611.0) to an I16, the value of the I16 is maxed out Binary (111111111111111) When converting a U16 (36611) to an I16, the value of the I16 is the same value as the U16 in Binary (1000111100000011) This post has been edited by Kevin Boronka: Aug 9 2006, 10:00 PM
Attached File(s)
|
||
 |
 
|
||
| Ad |
Aug 9 2006, 09:57 PM
Post
#
|
||
|
|
|
||
|
|
|
||
|
Aug 10 2006, 05:11 AM
Post
#2
|
|||
 CCT It Premium Member  Posts: 1337 Joined: 13-June 05 From: Woerden, Netherlands Member No.: 2399 Using LabVIEW Since:2001 LV:8.5.1 ,6.1 ,8.2.1 
My Blog
My Gallery
|
QUOTE (Kevin Boronka @ Aug 9 2006, 11:57 PM)  I'm running LabVIEW 8.01 LabVIEW 8.01 handles data type conversions differently. When converting a Double (36611.0) to an I16, the value of the I16 is maxed out Binary (111111111111111) When converting a U16 (36611) to an I16, the value of the I16 is the same value as the U16 in Binary (1000111100000011) It is strange indeed, in LabVIEW 8.2 and 7.1 the same occurs. But looking at the help states that: QUOTE This function rounds all floating-point numer values to the nearest integer But still it should not do a typecast of U16 to I16 but a conversion.. seems like some work for NI Ton PS there is no difference when connecting the U16 directly to the indicator --------------------
|
||
|
|
|
||
|
Jan 17 2007, 11:31 AM
Post
#3
|
|||
 <customize this text> Premium Member Posts: 1012 Joined: 9-April 04 From: Rotterdam Member No.: 349 Using LabVIEW Since:1992 LV:8.5.1 ,8.2.1 ,7.1.1
|
QUOTE (tcplomp @ Aug 10 2006, 12:11 AM) It is strange indeed, in LabVIEW 8.2 and 7.1 the same occurs. But looking at the help states that: But still it should not do a typecast of U16 to I16 but a conversion.. seems like some work for NI Ton PS there is no difference when connecting the U16 directly to the indicator Actually not necessarily. This is a behaviour that also occurres in C, at least the compilers I know of and it has its uses when you read in data from a stream in a certain format but later want to reinterpret some of the data. I know for sure a few cases where I have relied on this fact and changing that now would certainly break lots of peoples VIs. Rolf Kalbermatter
|
||
|
|
|
||
|
Jan 17 2007, 02:46 PM
Post
#4
|
|||
 Very Active Member Posts: 165 Joined: 9-February 05 From: region Eindhoven, the Netherlands Member No.: 1555 Using LabVIEW Since:2008 LV:7.1.1 ,8.5.1 ,8.2.1
|
QUOTE (rolfk @ Jan 17 2007, 12:31 PM) Actually not necessarily. This is a behaviour that also occurres in C, at least the compilers I know of and it has its uses when you read in data from a stream in a certain format but later want to reinterpret some of the data. I know for sure a few cases where I have relied on this fact and changing that now would certainly break lots of peoples VIs. Indeed, I've also relied on that many times. If the behaviour is to be changed (which would not be a bad thing on itself IYAM), the automatic version upgrade process should replace the U32 or I32 nodes by Typecasts nodes. Because from the Typecast function that behaviour is expectable. I find it strange that the typecast node sometimes modifies data. It should never do that. Joris
|
||
|
|
|
||
|
| Time is now: 2nd December 2008 - 03:39 AM |