LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Loops end values is this true? under false condition

0 Kudos
Message 1 of 11
(1,284 Views)

YES!

 

Spoiler
The "i" is an I32 value and you reached the MaxInt32 (=2^31-1) after a while…
Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 11
(1,281 Views)

Really? Why would it exit a loop when it's just a counter? Logic tells me - though I know that LabVIEW isn't logically programmed - that it would restart at 0. 

 

According to what I learned about data flow, I'd rather expect the outer loop to exit immediately without having entered the inner loop at least once. 

0 Kudos
Message 3 of 11
(1,223 Views)

@MaSta wrote:

Really? Why would it exit a loop when it's just a counter? Logic tells me - though I know that LabVIEW isn't logically programmed - that it would restart at 0. 

Just because your logic seems to be different than what LabVIEW does, does not mean that LabVIEW is unlogical. In fact LabVIEW is very logical and while some things may seem not intuitive at first sight, it is pretty much always because the alternatives would be in one way or other either horribly wrong or not how numeric analysis has decided to do things, usually by people that may have lived more than a century ago and were smarter than you and me together.

 

Our intuition is usually the first thing that is getting wrong when prompted with such problems.

 

The specific reason for the iteration terminal to actually max out at the maximum integer value rather than wrapping around is pretty simple. Many times in loops the iteration terminal is used to detect the first iteration by comparing this value to 0. When it would wrap around, this "initialization" criteria would be triggered over and over again, which is almost never what the programmer who used this i==0 "trick" intended.

 

Besides, the iteration terminal is a signed integer and wrapping around a signed integer definitely would give you some very "unintuitive" sequences!

 

If you really need a wrap around counter, you can easily do it by adding a shift register to your loop and do a simple increment on the value. In this case you can also choose the right datatype, most likely an unsigned integer of some size to avoid unintuitive number sequences on wrap around.

 

According to what I learned about data flow, I'd rather expect the outer loop to exit immediately without having entered the inner loop at least once. 


That is not how a while loop works in LabVIEW. in C and many other languages you have a

 

while (condition) {}

 

and a

 

do {} while (condition)

 

LabVIEW always does the second and if you think about it, it would be very difficult to come up with a variant that does the first for a data flow language.

 

If you do not want to execute anything in a while loop such as yours with a constant condition, why even have it there at all?

 

If you have a dynamic condition that you want to terminate the loop on but also do not want to execute anything inside the loop body right from start, you have to add a case structure. The alternative of making the termination terminal overloaded with yet another right click selection option to select early abort and trying to indicate that with yet another glyph or something on that terminal is definitely less obvious.

 

image.png

Rolf Kalbermatter
My Blog
Message 4 of 11
(1,212 Views)

Hi MaSta,

 


@MaSta wrote:

Logic tells me - though I know that LabVIEW isn't logically programmed - that it would restart at 0. 


Why do you think an I32 should restart at 0 when it overruns at 0x7FFFFFFF?

My logic tells me it should "restart" with -2147483648=0x80000000 instead!

 

But NI decided to have the loop iterator stop at MaxINT32, which IMHO was a good decision.

When you really REALLY want to rely on a loop iterator in loops running so fast they will hit that limit then you should (atleast) use an U64 in a shift register…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 5 of 11
(1,203 Views)

@MaSta wrote:

Really? Why would it exit a loop when it's just a counter? Logic tells me - though I know that LabVIEW isn't logically programmed - that it would restart at 0. 


To be clear, the loop don't exit. It keeps running, but the i terminal keeps outputting the MAXINT value. In the image the code isn't running, but that's presumably because it was stopped manually.

 


@MaSta wrote:

 

According to what I learned about data flow, I'd rather expect the outer loop to exit immediately without having entered the inner loop at least once. 


Then you misunderstood. The loop condition terminal only tells the loop whether the current iteration is the last one. It's not like the break command in C. This isn't specifically about dataflow (the dataflow in this case only says that the inner loop and the code for the condition can execute independently), but it makes much more sense for LV to complete the loop rather than break when the condition is fulfilled for any number of reasons (the behavior is consistent, behavior of loop outputs is well defined, etc.).


___________________
Try to take over the world!
Message 6 of 11
(1,201 Views)

We must see in two perspective 

 

perspective 1 : in FPGA on host there will be no limit to i - iterations

 

perspective 2 : in FPGA on target there will be a limit to i - iterations = 2,147,483,647

 

(Not only for Labview FPGA it suits other FPGA 's too)

0 Kudos
Message 7 of 11
(1,180 Views)

@Harishkanmani wrote:

We must see in two perspective 

 

perspective 1 : in FPGA on host there will be no limit to i - iterations

 

perspective 2 : in FPGA on target there will be a limit to i - iterations = 2,147,483,647

 

(Not only for Labview FPGA it suits other FPGA 's too)


There always is a limit. Also on FPGA. You can not have infinite bits in an integer! The question is if you want to have a wrapping or a maxing.

 

In the case of the LabVIEW loop iteration terminal that decision has been done more than 30 years ago and it is not going to change now.

 

The same is true about the datatype of the iteration terminal. It was decided that this was an int32 back then and changing it now to either unsigned or 64-bit or both would have a whole slew of undesired consequences in many other places and also be a liability for upgrading existing programs to this new LabVIEW version.

Rolf Kalbermatter
My Blog
0 Kudos
Message 8 of 11
(1,175 Views)

@Harishkanmani wrote:

We must see in two perspective 

 

perspective 1 : in FPGA on host there will be no limit to i - iterations

 

perspective 2 : in FPGA on target there will be a limit to i - iterations = 2,147,483,647

 

(Not only for Labview FPGA it suits other FPGA 's too)


For FPGA code, I always rely on my own counter (in a shift register) for the loop iteration.  I often get away with using a U8 or U16 instead of the I32, saving some resources.  I also use a comparison (ex: >= 100) and a Select to reset the counter.  In Windows, I will often use a Quotient & Remainder to do the reset in a single function, but that is very expensive in FPGA.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 9 of 11
(1,152 Views)

@rolfk wrote:

The same is true about the datatype of the iteration terminal. It was decided that this was an int32 back then and changing it now to either unsigned or 64-bit or both would have a whole slew of undesired consequences in many other places and also be a liability for upgrading existing programs to this new LabVIEW version.


As NI starts pushing 64-bit LabVIEW more (and deprecating 32-bit), I think it would make sense for NI to start moving things like this to using the I64 instead of the I32, including array and string functions.  I'm actually struggling to quickly find other examples of things that use I32.  VISA Read uses a U32 for the byte count; Set File Position is a U64.  But I'm sure there are a ton of VIs NI would have to update to do this, so it might be more effort than it's worth.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 10 of 11
(1,150 Views)