Timed Loop Incorrect Behavior

[GerdW]

Hi Alex,

I see this:

---

@alexderjuengere wrote:
in labview praxis, I run into a limit at 9.007.199.227.927.314 < 2^53, delta: 26.813.678

---

And this:

(Both in LV2016 32bit)

[JB]

Thank you very much for your tests. The behavior you are observing is the expected one.

As mentioned, without any modifications to the executables (the most recent ones being built with LabVIEW 2021), the issue appeared on the same day across several of our production lines as well as on our development machines.

This leads us to suspect a potential link with a probable operating system (W10 Entreprise) update.

[alexderjuengere]

---

Thank you very much for your tests. The behavior you are observing is the expected one.

As mentioned, without any modifications to the executables (the most recent ones being built with LabVIEW 2021), the issue appeared on the same day across several of our production lines as well as on our development machines.

This leads us to suspect a potential link with a recent operating system update.

---

for curiosity, I tested  on a surface pro 8 with windows 11 professional (25H2 build 26200.8246 via winver32.exe)

licence	perpetual	1-year subscription
IDE	labview 2020 64 bit	labview 2026 q1
JB demo.vi

good luck with re-solving this nasty issue!

[RTSLVU]

---

@raphschru wrote:

Timed Loops might not be the best choice for non-RT targets.

---

From what I understand back when they were first released everyone said that Timed Loops were only appropriate to use on FPGA targets. Something to do with the timing jitter inherent in Windows 

[Andrey_Dmitriev]

---

@RTSLVU wrote:

---

@raphschru wrote:

Timed Loops might not be the best choice for non-RT targets.

---

From what I understand back when they were first released everyone said that Timed Loops were only appropriate to use on FPGA targets. Something to do with the timing jitter inherent in Windows 

---

There is nothing fundamentally wrong with using Timed Loops on Windows, as long as we clearly understand that the loop body itself is single‑threaded (means its content executes on only one thread at a time). As far as I can guess, LabVIEW will generate a single chunk of LLVM code for the loop body, so it still executes on one thread. We can also assign a dedicated CPU core to that loop, which I do time to time, and it works and can be really useful when I need to set affinity to the piece of code.

I only ran into problems once, many years ago with LabVIEW 2010, when occasionally RS‑232 communication happened to be inside such a loop. In that case the execution was sporadically frozen, but that was clearly a LabVIEW Run‑Time issue, not a problem with Timed Loops themselves.

It should also be understood that there is no “magic” involved: using a Timed Loop does not increase the underlying Windows timers resolution. The loop cannot achieve timing precision beyond what the OS (and Windows is not Real-Time by default) and hardware actually provide.

[alexderjuengere]

---

@Andrey_Dmitriev wrote:

---

@RTSLVU wrote:

---

@raphschru wrote:

Timed Loops might not be the best choice for non-RT targets.

---

From what I understand back when they were first released everyone said that Timed Loops were only appropriate to use on FPGA targets. Something to do with the timing jitter inherent in Windows 

---

There is nothing fundamentally wrong with using Timed Loops on Windows, as long as we clearly understand that the loop body itself is single‑threaded (means its content executes on only one thread at a time). As far as I can guess, LabVIEW will generate a single chunk of LLVM code for the loop body, so it still executes on one thread. We can also assign a dedicated CPU core to that loop, which I do time to time, and it works and can be really useful when I need to set affinity to the piece of code.

I only ran into problems once, many years ago with LabVIEW 2010, when occasionally RS‑232 communication happened to be inside such a loop. In that case the execution was sporadically frozen, but that was clearly a LabVIEW Run‑Time issue, not a problem with Timed Loops themselves.

It should also be understood that there is no “magic” involved: using a Timed Loop does not increase the underlying Windows timers resolution. The loop cannot achieve timing precision beyond what the OS (and Windows is not Real-Time by default) and hardware actually provide.

---

yes! besides changing the OS or making changes to OS (eg. disable real time protection) - busy waiting is making your timers more robust, to a certain extend

https://forums.ni.com/t5/LabVIEW/Which-is-better-between-Wait-ms-and-wait-until-next-ms-multiple/m-p...

[Intaris]

---

@RTSLVU wrote:

---

@raphschru wrote:

Timed Loops might not be the best choice for non-RT targets.

---

From what I understand back when they were first released everyone said that Timed Loops were only appropriate to use on FPGA targets. Something to do with the timing jitter inherent in Windows 

---

Real-Time works with TImed loops also.

Two days late for a Star Wars quote, but: "There is another"

[Yamaeda]

---

@Intaris wrote:

---

---

Two days late for a Star Wars quote, but: "There is another"

---

Well it is "Revenge of the Sixth"! 😉