From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
09-01-2020 12:19 PM
There are various articles showing that a while loop's i counter will not rollover after it reaches max value. See below:
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000001DcZJSA0&l=en-US
I understand that historically this hasn't been an issue for most developers as many programs will not have loops that cycle so many times. However, I feel like this is unexpected behavior as everywhere else in LabVIEW adding 1 to a maxed I32 would result in 0. Is there a reason why the loop counter should not follow the same rule?
Solved! Go to Solution.
09-01-2020 01:14 PM
Adding 1 to a maxed out I32 returns -2147483648, not 0. Which makes sense if you think about how the sign is stored when you convert it to its base2 representation.
Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.
09-01-2020 01:24 PM - edited 09-01-2020 01:28 PM
@FireFist-Redhawk wrote:
Adding 1 to a maxed out I32 returns -2147483648, not 0. Which makes sense if you think about how the sign is stored when you convert it to its base2 representation.
Correct, I apparently forgot how I32's work for a moment.
My question should ask "Why does it not roll over to min(I32) (-2147483648) as would be expected by other I32 values."
09-01-2020 01:45 PM
Hi J,
@JScherer wrote:
My question should ask "Why does it not roll over to min(I32) (-2147483648) as would be expected by other I32 values."
I guess this was a design decision with the very first LabVIEW version. The iterator of a loop is most probably used to index array elements: it doesn't make sense to index elements with large negative indices!
(At that time LabVIEW on FPGA was no topic at all and this problems mostly is notable on FPGA while loops - as written in the linked KB article.)
09-01-2020 01:46 PM
Rollover would be quite unexpected. Would not like that. There are also other limit, for example the max array size is I32, so autoindexing on a loop with more than ~2^31 iterations is not possible anyway.
Of course you can maintain your own [i] of any datatype by just incrementing a shift register. Dirt cheap!
Ideally, we should be able to define the datatype of loops, see also my old post from 2006! Of course that's not an easy change because it needs very dramatic changes in so many areas (64 bit array sizes, etc.)
QUOTE:
"We need to be able to set the data type for the FOR loop ([N] and [i]): If I wire a U64 to [N], I want [i] to be U64 so it can exceed the range of I32."
09-01-2020 01:58 PM
09-02-2020 02:30 AM
You could also use a 48-bit counter and let a DSP do the work for you. Should keep you going for more than 80 years. Pretty sure it won't be your problem any more by the time it rolls over. Just leave a note in the source code.... 😉
Should be on the palettes, it also has a programmable "reset" which allows for a +1 counter for any arbitrary rollover value.
09-02-2020 10:51 PM
@JScherer wrote:
My question should ask "Why does it not roll over to min(I32) (-2147483648) as would be expected by other I32 values.
https://zone.ni.com/reference/en-XX/help/371361R-01/glang/while_loop/
This won't answer the why. But it will tell you the behavior is expected/designed.
Would rolling over have provided you with better behavior? I'm curious what you're using it for that wouldn't have been in an awkward state with the rollover.
10-12-2020 01:32 PM
@natasftw wrote:
@JScherer wrote:My question should ask "Why does it not roll over to min(I32) (-2147483648) as would be expected by other I32 values.
https://zone.ni.com/reference/en-XX/help/371361R-01/glang/while_loop/
This won't answer the why. But it will tell you the behavior is expected/designed.
Would rolling over have provided you with better behavior? I'm curious what you're using it for that wouldn't have been in an awkward state with the rollover.
For me, I was using the quotient and remainder function with inputs of [counter value] and [constant n] to send data to the host every n loops. As such, rolling over would have been the expected/preferred behavior.
10-13-2020 03:27 AM - edited 10-13-2020 03:29 AM
@JScherer wrote:
For me, I was using the quotient and remainder function with inputs of [counter value] and [constant n] to send data to the host every n loops. As such, rolling over would have been the expected/preferred behavior.
Except of a disruption at the roll over moment if your divider was not a power of 2! I usually use unsigned integers and subtraction/addition for such things. That has a well defined roll over semantic for all intervals you can use and is usually what you want in that case.
Also under FPGA the increment and decrement node let you configure if it should saturate or roll over. I use both regularly.