LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Timed loop on PC suddenly runs 10 times faster?

Solved!
Go to solution

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?

 

2019-10-29 09_26_54-Start.png

 

[Compiled in Labview 2015, uses shared variables to connect to cRIO

Run on windows 7, no updates last week]

0 Kudos
Message 1 of 9
(3,802 Views)

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.

0 Kudos
Message 2 of 9
(3,751 Views)

The code is too big and messy for anybody to dig into, Smiley Wink

0 Kudos
Message 3 of 9
(3,745 Views)
Solution
Accepted by topic author Ola_A

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

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 4 of 9
(3,723 Views)

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"?

0 Kudos
Message 5 of 9
(3,653 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 6 of 9
(3,642 Views)

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 (whitepaperexample 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).


GCentral
Message 7 of 9
(3,621 Views)

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?

 

0 Kudos
Message 8 of 9
(3,583 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 9 of 9
(3,573 Views)