04-30-2026 10:26 AM
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
04-30-2026 11:43 AM - edited 04-30-2026 11:48 AM
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.
04-30-2026 05:27 PM
@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.