10-29-2019 03:51 AM
Really strange bug occured today, a PC program that has worked for years suddenly run 10 times faster. It was a Timed Loop (see picture) that suddenly when amok. Restarting the pc solved the problem. Once in a million, or have anybody else seen it?
[Compiled in Labview 2015, uses shared variables to connect to cRIO
Run on windows 7, no updates last week]
Solved! Go to Solution.
10-29-2019 06:23 AM
Well, since you did not include any code (and the picture that you attached is useless) my best guess is that the code in some extremely rare instance changes the timing of the timed loop.
10-29-2019 06:26 AM
The code is too big and messy for anybody to dig into,
10-29-2019 07:37 AM
The constant "process missed periods, ignore original phase" could make the loop run much faster than normal (temporarily) to try to make up for previously missed iterations...
-Kevin P
10-30-2019 09:44 AM
Kevin, do you have a suggestion on the best setting in my case?
I guess the reason we have "Process missed periods, ignore original phase" is to catch up if the loop for some reason takes sligtly longer than the stipulated 1.0s. I think the logic in the program depends on the number of iterations. So "Skip missed periods..." might not be perfect.
Is there a way to "discard missed periods, and start counting from now"?
10-30-2019 10:28 AM
@Ola_A wrote:
[Compiled in Labview 2015, uses shared variables to connect to cRIO
Run on windows 7, no updates last week]
Sounds like a bad architecture to me. I see 2 major red flags:
1. a Timed Loop on a Windows PC
2. Network Published Shared Variables
Timed Loops reduce everything inside of it into a single thread and greatly reduces the amount of optimizations the compiler can do. And Windows is not deterministic, which will cause issues like what you are seeing.
I'm guessing you are trying to get data from the cRIO and you want to process all of the data points from it. If that is the case, then NPSVs are NOT the way to go. You should be using a Network Stream or raw TCP/IP to send data from your cRIO to your PC. This ensures you are getting all of the data and processing it as soon as possible.
10-30-2019
11:26 AM
- last edited on
05-23-2025
08:56 AM
by
Content Cleaner
Hi Ola,
This knowledge base article (Configuring Timed Loops and Timed Loops with Frames) discusses the possible "modes" in the section titled "Setting the Mode of a Timed Loop".
That being said, Timed Loops are rarely the droids you're looking for on Windows.
As crossrulz already said, if the goal is to measure something with a specific sampling rate, you'd likely have a better time controlling the timing on the cRIO system, and then streaming them (using the mentioned Network Streams (whitepaper, example program)) to Windows where you can gather them at any rate you like (i.e. it doesn't require strict determinism/very reliable timing)
You can pass (almost?) any type over a Network Stream (much like a Queue), so you can cluster a time value together with your measurements if you're not happy with just a fixed t0, dt, then array of points (i.e. waveform, but you'd only send the array probably).
10-31-2019 04:20 AM
Thanks, and yes I have heard many times that shared variables have their limitations. Like that you have to handle en error or lost data on each such read...
Changing from shared variables to something else is a big refactoring in our code, I don't think we hade the time to do it. Or maybe not so big if you really look into it, once we have a big cluster with all data read from network stream available it should be easy to read from that cluster instead of read from shared variables. The reads are scattered all around the code I might add.
But for the timed loops it might be easy to change it for something else, what do you suggest? A while loop with wait unt next ms multiple?
10-31-2019 06:32 AM
@Ola_A wrote:
But for the timed loops it might be easy to change it for something else, what do you suggest? A while loop with wait until next ms multiple?
That is the simple replacement.