LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why No Rollover for While Loop i I32

Solved!
Go to solution
Highlighted

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?

0 Kudos
Message 1 of 10
(424 Views)
Highlighted

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.

Redhawk
Test Engineer at Moog Inc.

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.

0 Kudos
Message 2 of 10
(400 Views)
Highlighted

@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."

0 Kudos
Message 3 of 10
(387 Views)
Highlighted
Solution
Accepted by topic author JScherer

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.)

Best regards,
GerdW

using LV2011SP1 + LV2017 (+LV2020 sometimes) on Win10+cRIO
Message 4 of 10
(371 Views)
Highlighted
Solution
Accepted by topic author JScherer

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."


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
Message 5 of 10
(367 Views)
Highlighted

Understood, I hadn't thought about that being a problem for auto indexing

 

As you all guessed, I found this out for myself the hard way on an FPGA on a loop that executed every 10us for 5.7hr of runtime. I'm now using a U64 so If I have the problem in 5.7M years, I'll let y'all know.

0 Kudos
Message 6 of 10
(350 Views)
Highlighted

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.... 😉

 

https://www.xilinx.com/support/documentation/ip_documentation/counter_binary/v12_0/pg121-c-counter-b...

 

Should be on the palettes, it also has a programmable "reset" which allows for a +1 counter for any arbitrary rollover value.

 

 

Message 7 of 10
(274 Views)
Highlighted

@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.

0 Kudos
Message 8 of 10
(215 Views)
Highlighted

@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. 

0 Kudos
Message 9 of 10
(107 Views)
Highlighted

@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.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 10 of 10
(79 Views)