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

[RyanBiggs]

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 https://forums.ni.com/t5/Example-Code/NI-DAQmx-Correlated-Digital-I-O-with-NI-CompactDAQ-and-LabVIEW... 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!

[Izzzzz · Accepted solution]

Hello RyanBiggs,

You will need to do the following based on the code you attached.

1. Set up a second Continuous Counter Output task that will output a pulse at 1000Hz. 
2. Configure your first Counter Output Task to start based on the configuration in step one using the DAQmx Trigger vi.
3. Configure the first Counter Output task to be retriggerable via the property node so the Counter Output will output pulses whenever it sees a rising edge of the second Counter Output Task.

The implementation is shown below.

Regards, 

Izzy O. 

Product Support Engineer

ni.com/support

[RyanBiggs]

Fantastic, thanks Izzy, that makes it all clear. Very much appreciated! This saves me much time getting the details straight, and it's great to have it here in the forums as a resource to the community.

My next task is using the same timing to read in the data clocked out by this signal, using a NI 9411. I think this gives me a good start, but any pointers for that part are most welcome as well.

Thanks again,

Ryan

[Izzzzz]

Hey Ryan, 

Could you provide more details on what you are trying to accomplish in case my interpretation is incorrect? 

You will need to add a Digital Input task for the NI 9411 and set the Digital Input’s Sample Clock Source as the Internal Output of Counter 0.

The implementation should look similar to this. 

 

Best Regards, 

Izzy O.

Product Support Engineer

ni.com/support

[RyanBiggs]

Superb, I can't overstate how grateful I am for your assistance Izzy! We are setting up this code in the midst of a lot of immediate business pressure and other demands, so I haven't had as much time as I'd like to do the "homework" on these topics. I apologize for that, but I am continuing to learn a ton about hardware timing from your examples.

Your latest code is working, and appears to be reading the sensor data successfully and stablily. A couple of observations/questions:

1. Except for the first and last bit, we seem to be getting each bit from the sensor twice in the input waveform, as if sampling is occuring on both the falling and rising edges of each clock cycle. This is probably not a surprise given the way the ctr0 and output waveform are configured. Can you suggest a more elegant way to handle this rather than simply discarding every other bit?

2. I need to study further the buffering for the digital read and how this is handled between while loop cycles. With many configurations I get buffer underflow errors, although things work without fault if I set the "samples per loop" control for the digital read also to 5000 as with the sample clock samples per channel. Ideally, I'd like to read each 25-bit sample individually, then immediately push the data to a queue before reading the next. I'm not sure if this is possible in a non-real-time system, although I am populating other queues at a similar rate from high-speed RS-485 data. Is it possible to do this with proper settings? If not, do you have any suggestions for obtaining the smallest batch of samples possible per loop before pushing the data to a queue?

Many thanks once again,
Ryan

[Izzzzz]

Hey Ryan, 

1. A picture of the behavior you are seeing would be helpful. The NI 9411 should only be reading 50 bits every 1 ms.  
2. 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