Without reading all the posts above, i just want to state a thing or two regarding stuff i picked up from previous posts (not much as i haven't read them thouroughly):
a) Windows is NO DETERMINISTIC system. So on this system, there is no determinsm. Never ever. That being said, "getting out of sync" is expected.
b) There is a heavy misconception about timed loops. So the following information tries to solve some of the "i think i know" and "i heared" stuff.....
A timed loop is special structure which affects both compiler and runtime engine. Underlying of timed structures is a timer thread which is used to track time for all structures (OK, there are some additional ones, but for sake of simplicity...).
Facts about timed structures:
1. Content of a timed structure is compiled into a single clump which will run in a dedicated thread. Read: Each timed structure will spawn its own thread where the content of the structure is serialized for execution. This is of course in addition to the timer thread for the timed structures.
2. Timed structure priority ranges from 1-65535. Having the same priority for different timed structures is a stupid idea on Windows and a no-go for Real Time. This priority range is scheduled between High Priority and Time Critical Priority. All time critical priority VIs will hence pre-empt any timed loop messing all time settings! Afaik, this is true for RT and Windows alike.
3. Never call time critical VIs within timed structures (See point 2)
4. Avoid using shared resources, esp. subVIs, in multiple timed structures. If you do, set those VIs to "subroutine" priority and configure the call to "Skip if busy". (Note: only set simple VIs to "subroutine". Refer to LV help for further info)
5.You can use timed structures on any target. On Windows, it is best used for "more timing information and configuration" compared to 'normal loops' (e.g.discarded missed periods and keep phase) but adds significant overhead. Having the content serialized and running in its dedicated thread could be both advantage and disadvantage. On RT, you have the "full power of timing control" so it is best used there. FPGA targets use the timed loop for Single Cycle Timed Loop to enforce code to the FPGA specific timing. Special constraints do occur though.
6. Keep special care when using timed structures in reentrant VIs (See point 2)
7. The timing thread cannot enforce determinism. If the content of the structure or any system functionality (e.g. Windows by itself) breaks that timing, it happens. The timed structures leave you a configuration on how to react on that situation though.
8. The first iteration of a timed loop is usually off (finished late) because of things like memory allocation. This depends very much on the desired timing (e.g. 10kHz) compared to the content of the loop and the time the system requires for the "preparation". Therefore, this is called "Warm Up Iteration".
9. Timed structures depend on system timing. If the system time drifts compared to a second, external timing source, you might want to synchronize the timed structure to that timing source (e.g. DAQmx task). Timestamps are not valid in that situation if they are read from the system directly (e.g. by using "Tick Count(ms)")
10. Timed structures don't execute faster than "normal code".
11. Avoid using non-deterministic code in timed structures like file IO, network access and similar.
I think these are the most important facts. Note that "normal loops" can break up into several clumps using different threads during execution at any time (clumps are "synchronized" in case by the scheduler/dispatcher). There is, except timed structures (and some other weirdo's like UI thread with appropriate settings), no "This Thread <=> That Code" relationship during execution of LV code.
Norbert
Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
