Design Pattern for Acquisition and Generation, problems with delay on generation

[Arturiux]

What is the best design pattern to acquire and generate data. I need to synchronize a camera using a square pulse. It is desired that the camera is only activated during the acquisition state. 

Right now I'm using a producer/consumer pattern (See attached image). In the producer I have the DAQmx read and DAQmx write. I'm also using DAQmx TDMS logging. In the consumer I'm only displaying the results in a chart using a queue.

The problem I have is that the DAQmx write is delaying the producer loop on the deployed PC and creates the error -200279 on the acquisition task (Increase buffer size, reading more frequently, etc).  I increase the buffer to the total number of samples for the entire acquisition but the error is still there. Do you have a suggestion for a better design pattern for this implementation? or Am I generating the signal correctly?

Software:

LabVIEW 2014

Acquisition Parameters:

Total Time= 100s

Fs=10kHZ

# samples to read=10k

Generator Parameters:

Square Signal created with Square waveform from the waveform generation palette.

Signal Freq=100Hz

Fs=1kHz

#Samples=1k

DAQmx timing= Use waveform

Hardware:

cDAQ9184

mod1: 9220

mod2: 9269 (analog output)

mod3: 9203

mod4: 9237

Thanks in advance

[Tim_McClung]

couple things worth verifying

1. Make sure all of your tasks are sharing the same sample clock.  This is important because starting and stopping the main task will make sure all tasks get stopped (because the halting of the sample clock) I didn't see anything in your code that shows you are configuring your output task to share the sample clock of your input task.  

2. Verify that you are disabling both tasks during execution.  DAQmx requires that each architype (AI, AO, DI, DO) have a unique task associated with it, so you should have two tasks to budget.  Item 1 will probably take care of this, but you may be seeing overflow because you are stopping your AO task and your AI task is still rolling on.  When you restart your AO task and attempt to aquire you've already generated an overflow.  If you are increasing your buffer size and the problem is not being solved it doesn't sound like a runaway issue; it sounds like implementation issue.

Cheers,

Tim

[Arturiux]

Thanks Tim,

I think the sampling clock is the missing part. This is a new topic for me but it makes sense. I'll deploy the modification and let you know if I still have the same problem. What about the sampling frequency and number of samples?, I configured the number of samples in each task to acquire 1 second, but should I also share the same sampling frequency for the two tasks?. and finally which sampling clock should I use?, the ao or the ai sampling clock?

With respect to the second point I'm clearing both tasks at the end of the while loop, first the AO later the AI (Not sure if that is what you are referring to). The user reports that the error is not consistent and before I increased the buffer it crashed around the 6 seconds, after I increased the buffer it crashes around 80 seconds. The error sometimes disappear after they restart labview.

Regards

[Tim_McClung]

use the ai sample clock as this will limit your AO to only when Ai is operational.  The other way around will limit AI to only when AO is operational....

 This may not matter but I find controlling with the AI to be easier to keep track of. (I'm a test and measurement guy so it's my preference).

things worth trying on the overflow problem....

Put a control up that will show the amount of bytes in the buffer.  This will let you view if you are actually having runaway issues with your acquisition rate.  it's possible.  If you are then I would recommend changing the rate or samples you are pulling... or if you don't care about lossiness you can make sure to clear the buffer if it gets over a certain size.  This will cause aliasing but will make sure you are not getting behind.  A good indicator of runaway is that your display seems to be lagging your process (you are looking at old data because most of it is still sitting in the buffer)

I think the attached image is the correct property for reading the current available samples.  If you watch this value while aquiring you'll be able to see what exactly is happening with your buffer during operation.

Let me know if that helps or you have any other questions,

Cheers,

Tim

[Arturiux]

Thanks again Tim,

I implemented the suggested changes and also add the stop task at the end of the loop. I'll let you know if it works as soon as I deploy the changes.

Regards

Arturo

[Arturiux · Accepted solution]

Hi again Tim,

I found that the error was created due the DAQmx write block inside the producer loop, it seems it takes some time to write the data even if synchronized with the ai/samplingclock. I decided to generate the entire waveform for the full length of the acquisition at the configuration stage and start the task using the trigger of the acquisition task. During the loop I just monitor the status of the generator task to catch any error. I based my design pattern on this example:

https://forums.ni.com/t5/NI-DAQmx-Examples/Multi-function-Synchronization-for-AI-and-AO/gpm-p/349060...

I appreciate that you explained me the synchronization topic since it was the key to solve this kind of implementations.

I'm not sure if I really need the start trigger since I already have the SampleClock of the AI as clock source.

Regards

Arturo

[niarena]

Have you taken a look at this below?

Timing and Synchronization Features of NI-DAQmx

http://www.ni.com/product-documentation/4322/en/

[Arturiux]

---

@niarena wrote:

Have you taken a look at this below?

Timing and Synchronization Features of NI-DAQmx

http://www.ni.com/product-documentation/4322/en/

---

Hi niarena,

Thanks for the info, It seems is a good practice to share both trigger and sample clock for a good synchronization. After reading more about DAQmx, it seems the original problem with the DAQmx delaying the loop was that the autostart node was on default (True), causing the write task to stop and start in each loop. I won't test this since my current program is working really good with 0 samples available on the buffer during the entire acquisition but I think that could have been an easy fix. Although, I'm glad I didn't know since I learned a lot about synchronization in the process :).

[Tim_McClung]

Good to know you picked up some useful information in the process, best wishes on your project.

Tim