Initial Racing in Timed Loops

[GuruDoo]

I am using 2 timed loop and a while loop in the same case statement.  When I call the case the first time it runs as expected.  However,when I call the case subsequent times, the timed loops races at the start and indicated that there is a late loop error.  I have both Timed loops set (and they need to stay set at) process missed cases, ignore phase.  Also, I have both timed loop set to a offset from the start of the case.

If I change it to discard missed cases the racing goes away, but I need to process missed cases.

Any suggestions on how to get rid of the initial racing.

I'm using labview 8.6.1.

[RavensFan]

It is difficult to understand what you are doing with out seeing your code.  Please attach a VI that shows what you are doing.

[GuruDoo]

Hey Ravens Fan,

Not sure if this will run for you or not as I am controlling motors and DAQ though non-NI products.  It looks a little messy as I just cut the desired code out of my main code, and put it into it's own VI.

Basically there are 3 loops

1).  The while loop Controls the DAQ.  It just reads a point from the DAQ and writes it to a local variable.

2).  The DAQ Timed loop.  It runs on a set time (100ms) and reads the local variables and does a few comparisons, writes data to the graphs, and writes data to arrays

3).  The Motor Timed loop.  It runs on a set time (100ms) and reads the local variables and generates data for the motor control, does a few comparisons and writes data to arrays.

Both of the timed loops (2 and 3) are set to process missed periods and ignore phase.  They are synchronized and have an offset.

Like I said during the first run, everything runs fine.  The while loop starts, after the offset both of the time loops start.  All 3 of the loops run the expected number of times.  If I run it again, all of the loops seem to start right away, the 2 timed loops, loop many times at the beginning and the Late Loop error is active.  Loop 2 will run hundreds of extra times, before any useful data is passed to it.  Once the data is there, it appears to behave normally. 

Hope that gives you an idea of what I am getting at.

Thanks,

[RavensFan]

Waaaaayyyy too many local variables.

The only thing I can see right now is there is no guarantee of when your timed loop synchronization VI runs relative to the start of the any of the while loops.

You might also want to run that node again after your timed loops have stopped with a True boolean wired to clear.  I would suspect that the second time around, you are trying to add the same loops again and that is causing problems with the history it maintained from the first time you added the loops.

Why not have the upper while loop be a timed loop as well?

Do you absolutely need timed loops?  There are other structures such as rendezvous's, queues, and notifiers in the synchronization palette that would help for passing data between loops and also keep the loops in synch.  With your abuse of local variables, I really do suspect that you have a race condition between the loops.  I can't tell what is the source of data and what are the sinks of data.  It is very likely that you are operating on stale data in the loops, or completely missing a set of data, even when though you are trying to synchronize the loops.  That just synchronizes the start of the loops, it doesn't control when individual nodes run within the loops.

[GuruDoo]

Hey Ravens Fan,

Thanks for the suggestions.  I will look into resynching with T on the clear to see if that helps. 

I know that I have a lot of local variables, and I need a better way to clear everything up without weighing down my execution.  I'll look into the queing functions to see if they make sense to me.  I've been reluctant to try the synchronization functions as I have never used them and don't quite understand them fully.

I was talking to a coworker who suggested doing the while loop with the timed loops.  This way the while loop containing the DAQ runs at its desired time, and the timed loops can pluck data from it at the intervals they need it at.  This is dependant upon the fact that the DAQ loop must run at least 2 times as fast as the timed loops (which it is).  Any thoughts on the subject?

The DAQ (while) loop is the only one writing to variables the other 2 timed loop are reading from the same variables and writing to different variables, so there shouldn't be any race conditions.  Unless, they can occur differently than what I am thinking (having two or more items write to the same variable at the same time).

I'm not to concerned about the loops staying synchronized throughout execution (hence the ignore phase).  I would like them to start at the same time, pull current data into them, and use the current data to make their decisions.  I would like the while loop to start first, I'll try switching it to a quicker timed loop to see if that helps.

Thanks for the insight, and I appreicate the look at my code snipette.

-GuruDoo

[GuruDoo · Accepted solution]

I solved the problem.  It should have been obvious.  I had 2 timed loops, and previously I using their independant timing sources.  To fix it, I wired the same timing source into both of them, and cleared the timing source after the data collection was over.  Now when I activate the timed loops multiple times, I do not start with a block of timed loop errors.

[Snamprogetti]

It's not because they're two, it happens with 1 timed loop too, whenever you execute a timed loop with "Process missed periods" multiple times. Unless you clear its timing source, at every subsequent execution it will immediately reprocess all iterations since start of program!

That's the solution anyway