Odd fixed point saturation

[nanocyte]

I ran into an issue where when I saturate to a particular fixed point type, it doesn't saturate to use the full number of bits, it saturates to some other odd number. Does anyone have a script to search for these weird fixed point types?

[Intaris]

What's the datatype of the FXP constant you're coercing to?

[Kyle97330]

The properties of the second one are messed up.  Right click properties on it, then go to Data Type:

If you then change the word length to a different amount of bits, then back to 25, the minimum and maximum values change:

Once you have done that, then the data types match and give the same result:

[Intaris]

Hmm, interesting.

I do know that LabVIEW kind of keeps track of arithmetic done on FXP on FPGA.

If you wire a FXP +8 to a "+1" node and look at the context help of the output, it will list it as FXP 9, but with a range of 0...256. Adding another "+1" will leave tha data type at FXP9, but will increase the range to "0..257".

This way LabVIEW can prevent an explosion of the bit width of math operations on FPGA. MAybe you created a constant from one such terminal and it messes with the "Boolean to Number" function. That's my guess. Don't have LabVIEW open right now, can't check.

[nanocyte]

Yes, that's probably what happened. I guess I'd prefer it was my job to prevent "bit width explosion" rather than the IDE though I could also imagine the compiler optimizing some bit widths behind the scenes. Seems something like that is dangerous enough that it deserves a special color or something. In the meanwhile, I was hoping someone had a script (maybe for VI analyzer) to find these "bugs waiting to happen". I guessing many of you might have some of these buried in your code too.