Using cDAQ timers to repeat a hardware-timed finite-sample pulse train clock

Question

Hi all,
As part of a complex project, I must implement an acquisition hardware interface for a linear motion sensor using the Synchronous Serial Interface (SSI) output common in industrial motion control. (I have a fair bit of experience in digital electronics, but I'm new to hardware timer-synchronized digital I/O in LabVIEW.)
To do this, I need to create a hardware-timed bursted pulse train TTL clock signal. Each burst consists of 25 high-low transitions with a full-cycle period of 2.67 microseconds (375kHz). The output must then be held high until the next burst, which occur at 1ms intervals.
Using cDAQ timers and a NI 9401 (based on the example at http://www.ni.com/example/30256/en/), I've been able to create the pulse train burst as described (see attached VI image). Next I need to configure another timer to trigger this burst to repeat at 1ms intervals.
Does anyone have any pointers about the best way to accomplish the hardware timing for repetition of the pulse train?
Any suggestions of alternative strategies or observations as to the ways my noobish code is stupid or inefficient are welcome as well!
Thanks!
Solved!
Go to Solution.
Attachments:
Hardware Timed Pulse Train Clock.jpg ‏102 KB

Answer 1

Hey Ryan, 
A picture of the behavior you are seeing would be helpful. The NI 9411 should only be reading 50 bits every 1 ms.  
It may not be possible to read 25 bits (do you mean 50 bits? 25 high 25 low) and push it to a queue without encountering an overflow error. If you take a look at the above code the digital input will receive 50 sample clocks every 1 ms. This is equivalent to acquiring 50 points every 1 ms which is an acquisition speed of 50 samples/1 ms=50 kHz. The read loop must keep up with the 50 kHz rate otherwise the buffer will overflow. In the above example I’ve set the read to pull 5000 samples (x) with the assumption that the loop will take less than or equal to .1 seconds (y). This yields a software acquisition speed of 50 kHz (5000 samples/100 ms). If the loop speed is faster than 100ms then the 10 seconds timeout on the DAQmx read will allow for the read to block so the FIFO may be filled.
The options available for question 2 are below. They may be used separately or in conjunction.
Move the DAQmx Read for the NI 9411 to its own independent while loop, set the DAQmx Read to acquire 50 samples, do not graph the data, and pass the data to a Queue for processing in a consumer loop. This will increase the loop speed which may allow you to keep up with the 50 kHz acquisition speed. This may not work because the loop speed will need to be 1 ms or less.
Increase the value of the Samples per Channel control that goes into the DAQmx Timing VI. This will increase the DAQmx Software Buffer size. This buys time until you receive an overflow error because the DAQmx Software Buffer is being filled faster than samples are removed.
Read in 5000 sample chunks (producer loop), push this to the queue, and perform the analysis in 50 bit chunks (consumer loop). The additional queue created should allow for the acquisition loop to keep up.
Regards,
Izzy O.
Product Support Engineer
ni.com/support