Deterministic Timed loop

[MogaRaghu]

I am right now using the PCI-6229 for some critical machine functions and data logging inside of a 50ms timed loop in LV8.0. The source of clock is the 1kHz time base from O/S.

However the timing accuracy is inadequate as it varies whenever there is a mouse movement or some such activity. ( even though I make sure that there is no other concurrent program running on the WIN_XP system ) Normally for most other projects this is not an issue but in this particular machine I need to switch on/off a solenoid at 0.25 Second intervals and the resulting pressure curves are plotted. Even a small drag in timing flattens the curve

Is it possible to have a hardware timing source ( from the PCI 6229 card ) for the Timed loop so that it is more deterministic on a relative term ? I know that WIN_XP is not real time but for the time being I am looking at getting closer to it without major hardware change.

Thanks

Raghunathan

[craigc]

Hi,

I remeber doing something similar about 7 years ago with a serial link.  What i done was i updated the DIO Buffer every few milliseconds to create a clock.  I then wrote the buffer continuosly out of the DIO.  It was a bit of a hash and i cant remember exactly how i did it (and i have moved jobs so dont have the code), but may be the sort of thing you can think about with this problem.  By doing this i effectively had a clock OP in the region of 1MHz or something, which you may be able to utilize more effectively.  The advantage was that it didnt matter too much when the OS updated the buffer as long as it never went empty!  utilise a bit of oversampling too and you could generate a more deterministic clock.

Sorry it not more precise but mayby something to think about.

Craig

[PhillipBrooks]

After reading the specs for the 6229, I didn't see anything that indicates that it has any source of clock source on-board. Since this board is "optimized for cost-sensitive applications", I imagine that a clock source would have added cost.

I can tell you that I've used DAQmx, timed loops and a NI 6509 DIO board to transmit TCP messages at a rate of 2400 Hz (see thread here). I used the pulse output of a waveform generator as an input to a DIO line. That DIO line was configured for rising edge Change Detection with DAQmx. The DIO lines of the 6229 should be able to do the same.

Good luck!

[TCPlomp]

I think you can use the sample clock from the 6229 for your loop.
Otherwise output a timed digital stream on port 0 (I have don a read with a 6221 no issues)

Ton

[Jarrod_S.]

You are correct that Windows is not deterministic. While there are some things you could do to make it more deterministic, the timing errors will still effectively be unbounded. Also note although you don't see any other programs running, WinXP is always running tasks in the background that can steal CPU cycles from LabVIEW, however high LabVIEW requests its own relative priority to be.

Your best solution will involve separating the HW timing in your DAQ board from the SW timing in your application (the timed loop). Yes, you can use your sample clock on your DAQ board as a timing source for your loop, but this is still going to be dependent on software timing and won't remove the jitter you are seeing.

You will want your timing to be solely dependent on a continuous or finite DAQmx task that uses a sample clock. For instance, if you are using DIO lines to switch your solenoids on or off, you will want to use one of the 32 clocked DIO lines on your 6229 to do so. I believe your card has at least a 1MHz sample clock for digital stream generation, though you should doublecheck me there. You could then design your digital pattern such that you send the data out at a clocked speed. For instance, set your sample rate to be 0.25 seconds, then have your digital pattern be a finite sequence of F-T-F. The digital lines will be updated according to a HW clock on your DAQ board that is independent of Windows.

Check the Example Finder for examples of doing clocked Digital Output.

[MogaRaghu]

Dear Phillip,

You hit the nail on the head - yes what you posted was exactly the solution that i wanted. Thanks.

In fact I read the 6229 all over and upside down but still could not locate an on board clock that could be used the way i wanted. Going by the other posts, I seem to be correct.

This forum is a great place - I sincerely believe that  it is one of the reasons  to have taken LV to where it is today.

Thanks to all others who took the time to help.

Regards

Raghunathan

[Stuart_G]

To answer your original question...YES...the 6229 can be used as a timing source for the timed loop.  Look at the example ..\NI\LabVIEW\Examples\DAQmx\Analog In\Measure Voltage.llb\cont Acq and Graph voltage-int clok-timed loop.  Also, if you uses the example finder and search for timed loop you will find other ways to use DAQ with the timed loop.  I am not sure if it will get you the determinism you want (that is what RT is for), but it might be a little better.

StuartG

[MogaRaghu]

I have another query on this method of using an external event like the Change state of a DIO line or the Counter as a clock source  for  triggering  the Timed loop.

In this method you are sure of creating the trigger with minimum latency ( the time delay between the event and the time of generating the trigger ) But then what about the response of the Timed loop to this trigger ? I think it still has to wait for the O/S to accord permission to start the loop ? Or does the Timed loop start  as-soon-as the external event  occurs ??

As  I understand,  in a normal Timed Loop configured to run off the O/S based 1kHZ clock,  the following are involved :

1. The variance in the interval between triggers depending on the CPU load.
2. The latency in the response of the timed loop to the trigger.

So when we feed the trigger from an external source we are only elimnating item 1. We still have the uncertainity because of Item 2 . Correct ?

Raghunathan

[Jarrod_S.]

Timed Loops can't break the rules of the operating system environment in which they run. Nothing can, really. In Windows, for instance, you can request that your application code have the highest possible priority, but it's still up to Windows to set your relative priority. And even at the highest application-level priority, Windows can preempt you with whatever it deems more important. While this is annoying for us developers who want that complete control and don't feel like we'd abuse that power, that type of complete control reaked havoc on previous OSes like Windows 95 where one faulty program could bring down the whole system.

If you really want to get closer to the hardware and be able to set priorities that an OS respects, you will need a Real-Time system. Those systems don't have keyboards or mouses or antivirus programs that would steal CPU cycles from you. This dedication allows you to create systems with a high level of determinism. Windows won't allow that.

You do have good options, however. Either let your DAQ board do all the real-time processing, such as creating the digital stream using its onboard clock. Or you could look into turning your existing computer into a Desktop ETS Real-Time computer. You could then dual-boot either into Windows, or your RT OS.