LabVIEW
Timed Loop Incorrect Behavior
Hi,
From the help :
This property of the timed loop returns now a constant and impossible value of -4294967298. If the Loop Timing Source is configured for absolute time, this incoherent timestamp is returned :
The Expected Start [i] property of the timed loop, which according to the documentation uses the same time base and units as Actual Start [i], returns coherent values.
Please let me know if anyone has already encountered this issue. The problem is systematic and can be reproduced very easily.
Many thanks in advance for any help
Hi JB,
Here's a thread discussing the same issue:
https://lavag.org/topic/18757-timed-loop-actual-start-timestamp-gives-erroneous-value/
Timed Loops might not be the best choice for non-RT targets.
Questions for further investigation:
- Does "Error" from the data node give an actual error when that happens?
- Have you tried other timing source types? (pre-configured ones, custom ones (hardware/software))?
Regards,
Raphaël.
@JB wrote:
Hi,
For several applications (LV15, 18 and 21 executables), some of which have been running reliably for years, unexpected Timed Loop behavior appeared on the same day. A Windows 10 update deployed by our IT department could be the cause, although this remains unconfirmed.
From the help :
This property of the timed loop returns now a constant and impossible value of -4294967298. If the Loop Timing Source is configured for absolute time, this incoherent timestamp is returned :The Expected Start [i] property of the timed loop, which according to the documentation uses the same time base and units as Actual Start [i], returns coherent values.
Please let me know if anyone has already encountered this issue. The problem is systematic and can be reproduced very easily.
Many thanks in advance for any help
Feels like something to do with Epoch time.
I once had something related to 'using the i of a timed while loop', which also affects standard while loops:
the i of a loop can overflow - which leeds to nasty little bugs appearing occasionally
with nasty little bugs I mean halting your system or process until you restart the whole "system" via power cycling.
you would expect the loop i to start over at 0 (or -2147483646) again - but no, this is happening, after passing 2147483647:
- the loop i is halted after 2147483647 (which is (2^32) /2)
- the i32 x+1 starts over as excpected
- the double x+1 is unaffected after passing 2147483647, which is also expected, as a float64 maximum is around 1+E308
but wait! after a little while, when hitting the maximum of the double x+1, you will realize, this will halt to.
only the i32 x+1 counter is marching on, as you would expect
that was the behavior the last time I checked it
Hi Alex,
@alexderjuengere wrote:
the loop i is halted after 2147483647 (which is (2^32) /2)
It's 2^31-1 exactly…
(off by one error 🙂 )
@alexderjuengere wrote:
the double x+1 is unaffected after passing 2147483647, which is also expected, as a float64 maximum is around 1+E308
but wait! after a little while, when hitting the maximum of the double x+1, you will realize, this will halt to.
only the i32 x+1 counter is marching on, as you would expect
Even though a DBL float can handle values upto ~1E308 it doesn't provide equally good precision!
A DBL float uses a mantissa of 53 bits (52 bits with implicite leading one), so it can exactly represent integers from -2^53 to +2^53 - this should be your expectation…
Thank you for your feedback and shared experience.
If anyone would like to run a quick test, here is a basic VI in LV18.
This screenshot illustrates the unexpected behavior that has recently appeared.
Unlike the “Expected Start” values, the “Actual Start” value remains constant and inconsistent.
Even when wiring the error cluster inside the loop, no error is returned.
In our real VI (dating back to 2012 and working reliably until now), the elapsed time between iterations is used to calculate a physical quantity. Unless you can shed some light on this, I do not see any alternative but to replace the "Timed Loop", whose use in this case is questionable anyway.
@JB wrote:
Thank you for your feedback and shared experience.
If anyone would like to run a quick test, here is a basic VI in LV18.
On the recent version mentioned above everything looks just fine
The same in LV2010 (32-bit), LV2014 (both 32 and 64) and LV2018 (32-bit). Have no other legacy version installed.
@GerdW wrote:
Even though a DBL float can handle values upto ~1E308 it doesn't provide equally good precision!
A DBL float uses a mantissa of 53 bits (52 bits with implicite leading one), so it can exactly represent integers from -2^53 to +2^53 - this should be your expectation…
hi! when using a double as an positive finite integer counter "double x+1", I assumed:
- Sign: 0 (positive)
- Exponent: 11 bits (maximum value \(2046\) for normalized numbers, as \(2047\) is reserved for Infinity/NaN)
- Mantissa: 52 bits (all set to 1)
in labview:
in theory, this offers 9.007.199.254.740.992 = 2^53 possibilities
in labview praxis, I run into a limit at 9.007.199.227.927.314 < 2^53, delta: 26.813.678
but when using 9.007.199.227.927.314 as a starting point, we run into the expected limit at 9.007.199.254.740.992
