Problems with RT timing

[Lee_Jay]

I have two VIs, a time-critical and a normal-priority.  The time-critical routine has a while loop with a wait-until-next RT timer at 2500uS.  The normal-priority vi has two while loops.  One has a wait-until-next RT timer at 100mS and the other has a wait-until-next RT timer at 1250uS.

The idea is for the time critical loop to execute and let the normal-priority VI to execute while the VI is sleeping.  An execution trace shows the actual time-critical portion executes in 450uS leaving plenty of time to call the normal priority VI.

The normal priority VI's high-speed loop needs to execute once per iteration, but it can go many iterations without executing at all, as long as it can catch up later (100 element FIFO).  That's why its timer is set so it can execute twice during each iteration if necessary.  Testing shows it can execute up to 36 times per iteration if not clocked.  The slower loop in the normal-priority VI is for host communications and it can execute more-or-less whenever it can.

The problem is, this isn't working reliably.  The fast loop in the normal-priority VI stops executing entirely about 80% of the time.  The other 20%, it works perfectly.  When it stops executing, the slower loop in the same VI does keep executing at its slower rate.  I've removed everything from that fast loop so it does nothing but wait and it still stops executing.

Am I doing something wrong regarding clocking these three loops?  Is there a better way to do this?

LV PDS 8.01, by the way, on an PXI8176 running RT, and a 3GHz P4 running XP as host.

Thanks,

Lee Jay

[JulieC]

Sounds like a dangerous (dead-lock prone) way to go about things.  I don't have the RT package, but the theory should be similar to the regular Wait Until Next function.  Take a peek at this tutorial: http://zone.ni.com/devzone/conceptd.nsf/webmain/E83351E12CD2D50886256B66006E4D15#2

[Kevin_Price]

If your normal-priority fast loop "stops executing", then it's either starved for CPU or your termination condition is being met, right?  From your description, it shouldn't be starved so what's the loop's termination condition?

I'm not sure what the BEST way is, but here's something I might try:

Time-critical loop: runs in a Timed Loop structure.  The Timed Loops give you better control and awareness of actual timing.  Any data needed by normal priority fast loop should be written to a queue.

Normal priority fast loop: Dequeue data with a long (infinite?) timeout inside a standard While loop.  This type of call will allow the thread to sleep while waiting for data to.show up in the queue.  You shouldn't need additional "Wait" timing -- the queue helps you stay in sync.

Normal priority slow loop: standard While loop.  If you use "Wait" timing, try to avoid waking up at the same time as the TC loop.

Another thought:  when I did RT a few versions back, I used occurrences to synchronize various threads.  At the end of the TC loop, an occurrence was set to wake up a data acq thread.  After grabbing new data, an occurrence was set to wake the data processing thread.  After that, another was set to wake the thread for generating new output signals.  You get the idea.  Each thread owned the CPU during the time slice when it was active.  They weren't ever competing for it.  This scheme was reliable at 1 kHz.

-Kevin P

[Lee_Jay]

Sounds like a dangerous (dead-lock prone) way to go about things. 

Yes.  I'm aware of this and I use a flat sequence structure in the time-critical loop to prevent this condition.

Lee Jay

[Lee_Jay]

I don't know what's causing the halt.  The termination condition is not met for sure (actually, I can't even get that to stop because the loop stops executing - even abort doesn't stop it) but it doesn't run either.  It doesn't look starved for CPU time since there's over 2000uS in each loop in which the time-critical loop is waiting (shown in the execution trace).  The VI in which the while loop that stops responding exists continues to show that it's executing in the execution trace, but that's because it hasn't ended or been called again.

I don't think I can use any of the timed-event or related structures because the wait-until-next in the time critical loop is in a case structure that, in the other case, causes the system to be hardware clocked via a wait-on-IRQ from an FPGA.  The same thing happens in that case (only one of my two normal-priority while loops keeps executing).

Lee Jay

[JulieC]

An idea from my general development experience (not LV specific) ... is there some shared resource that your time-critical thread is grabbing and not releasing?

[Lee_Jay]

That's possible.  I've had trouble with memory-subsystem saturation in the controller due to RT's horrible memory management.  Even when the loop is waiting, the memory controller must be horribly busy doing who-knows-what based on the testing I've done.

Lee Jay