LabVIEW
Loops end values is this true? under false condition
@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.
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…
@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.
@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.
@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.
