6602 / 6723 Syncronization over RTSI

[scottalmond]

I would like to provide a syncronized reset pulse (once every 1.5 seconds) using a 6602 card and generate a continuously repeating analog waveform using a 6723 card.  I require these signals to remain synconized (to better than 0.2 ms) for one month in a lab environment.

I generate a 5,000 Hz base clock on the 6602 card.  I down-convert this clock using a counter for 10 samples HIGH and 7,490 samples LOW (one tick every 1.5 seconds).

I pipe the 5 kHz signal into the 6723 card over an RTSI cable.  I use this clock as an analog sample clock to iterate through a table of 7,500 samples (a continuous non-regenetive waveform) to create an analog signal output.  I set a trigger for the table to begin continuous output on the rising edge of the 1.5 second reset pulse.

How can I be assured that after one month of continuous cycling every 1.5 seconds that the analog waveform and reset pulse will still be syncronized?  I am relying on the counter on the 6602 card to downconvert the 5 kHz base clock, and the 6723 FIFO buffer outputting at the same 5 kHz base clock, to both output samples perfectly over the span of a month without any form of feedback syncronization (I receive an error that re-triggering is not suported by these cards, so that is not an option).  Is there documentation stating that the counters on these cards are infalable at this operating speed?

Thank you for your time.

[Kevin_Price]

Documented infallibility's gonna be a pretty tough thing to find.  But I will say that when running continuously for a month, the reliability of the 5 kHz clock would be one of the *least* of my concerns.  Others:

1. Careful programming of the non-regenerating AO task at 5 kHz.  You need your software structured to feed it reliably with an average of 5000 samples per second for a month.  And you need to be a little careful with your memory management so you don't slowly choke the computer down with overuse.  It isn't really *hard*, but there are a few pitfalls to avoid.  (Be careful of nodes like Build Array or Insert Into Array)

2. Windows (friggin') updates. Enough said

3. Antivirus s/w launching a scheduled scan

4. Other s/w doing automatic things for your, <cough, spit>, convenience"

Sync across RTSI should be fine, managing to keep a stable PC OS and S/W environment is the more significant risk.

-Kevin P

[scottalmond]

Point 1 was one of my major concerns going into the project too.  However, it seems the LabVIEW API automatically handles all the low level communication for me.  I hand off the full analog waveform table (which is larger than the 6723 card's FIFO buffer) for all my channels when I initialize the program and the API continuously refills the buffer without any further input from my program.

Down time isn't an issue so long as it's rare and we're aware of it (we check the computer daily).  Knowing that the two cards are out of synconization (due to anti virus or otherwise) would be a sufficient solution to this problem (we can notify the user to reset the software).

Right now I'm weighing the option of using one of the analog channels on the 6723 card to output the reset pulse (an analog channel that only outputs 0 or 5 V).  I'm just surprised there isn't any way to query the status of the cards through the API or any other way to ensure the cards are syncronized.

[Kevin_Price]

If you only write data to the buffer once and then the driver and hardware make sure the same waveform keeps repeating indefinitely, then you're actually doing *regenerative* AO.   And most of the concerns go away.

Item 1 no longer applies. Items 2-4 are very unlikely to interfere with the DAQmx driver, other than a possible Windows Update auto-reboot.

The sync is in the hardware, a bogged-down CPU or unresponsive OS won't change it short of a buffer underrun that errors out the AO task and stops generation entirely.  Once you've configured the tasks as described, as long as there's no task error you'll maintain sync indefinitely.  Other than a Windows update auto-reboot.

-Kevin P