Optimum parameter selections for data acquisition and generation tasks in parallel loops.

[Amartansh13]

Hi everyone, 

I have made this vi which performs following operations: 

1) Data Acquisition using DAQmx read at 500k S/s (Producer loop)

2) Data logging in a parallel loop (Consumer loop) in multiple files in TDMS format. 

3) Data generation at analog output using DAQmx write at 500k S/s. I have used the DAQmx write in non-regeneration mode. So, in the first second, I am sending 1msec burst of sine wave with 5k Hz frequency followed by zero voltage for remaining 1sec-1msec= 0.999sec. In the 2nd second, I am sending 1msec burst of sine wave with 5+1=6k Hz frequency followed by zero voltage for remaining 1sec-1msec= 0.999sec.................and in this way, I am increasing the frequency of burst by 1K Hz to reach 50k Hz. It is a kind of frequency sweep. After which I want to stop generation and acquisition simultaneously. 

4) The acquisition and generation is completely synchronized by sharing the 'ao' sample clock with the analog input and by triggering reading operation using 'ao' start trigger.

I have few doubts related to this vi:

1) Is it good to keep DAQmx read and DAQmx write in two parallel loops? In most of the online examples, I have seen that people have kept daqmx read and daqmx write in the same loop. In my case, the generated data needs to be updated every second and hence complex function generator sub vi has to be connected to the daqmx write inside the loop. When I am keeping both daqmx read and daqmx write in the same loop, may be due to the complexity and delay caused by this function generator sub vi, this error is occurring ("The application is not able to keep up with the hardware acquisition"). I think the DAQmx read is not called fast enough (due to the slow writing operation) in the loop. That is why, I put daqmx read and daqmx write in two parallel loops. It is working fine but I don't know whether it is good and efficient way of doing things or not because I have not seen any online example of that kind. 

2) What should be values of these parameters: 1) Number of Samples per channel in 'DAQmx Timing''  2) Number of Samples per channel in 'DAQmx Read'. The sampling frequency is 500K S/s. 

Till now in all my previous data acquisition projects, I have always left these two parameters unconnected and error never occurred. But in this project, if I am not assigning any value to these parameters, weird errors are occurring. 

Please have a look at my vi (attached) and suggest me the solutions. I am using USB 6356 board. 

[Duffy2007]

Hello Amartansh13,

if read and write are synchroniced and the same rate is in use the two functions can be placed into one loop. My recommendation is samples/sample rate = 1/10 example 50 Ks / 500KHz for reading the the values with this setting the loop run with 100ms, which represent in the most cases a stable loop rate. The number of samples are normal the same value on the DAQmx Timing and DAQmx read input.

In your case you can also design the function generator to make smaler parts of the waveform, then the loop can run faster.

The next when using a start trigger the slave must be started before the master.

You can also use the default timeout, -1 should not be necessary.

[Amartansh13]

Thank you so much replying!

In future applications, I might use different sampling rate for read and write. Keeping that in mind, can you see my vi and tell me if it is okay to use parallel loops for reading and writing?

Also, I have made function generator vi as small as possible. I couldn't understand what you want me to do when you say " In your case you can also design the function generator to make smaler parts of the waveform, then the loop can run faster."

Once again thanks for the reply.

[Duffy2007]

Hello Amartansh13,

yes it is ok to use two independent loops. With different sample rates you can only use the start trigger for synchronisation. When the generator loop should run faster, it is needed to design a generator, which deliver the setpoints more frequently, then the loop can run faster.

[Kevin_Price]

A few quick hit-and-run comments, no particular order:

1. I'd leave the AO and AI in separate loops.  As long as you get the tasks hardware-synced, it's more flexible to let the task servicing (writing burst data to AO task, reading response data from AI task and writing to file) proceed more independently.

2. Since you seem to have a plan for the AO waveform progression prior to starting the program, you may help yourself by creating a larger buffer.  For example, suppose you wrote the first 3 seconds worth of AO data to the buffer before starting your main loop.  Then you can loop once a second and feed the task with the next second of future data, starting from the 4th second, 5th, 6th, etc.

   It may not be strictly needed, but it gives you some breathing room between the generation buffer and the software servicing rate.

3. I agree that reading about 1/10 sec of data from the AI task each iteration is a good place to start.

4. You can probably speed up your file writing by switching to file primitives that let you open the file once outside the loop, keep writing to an open file ref inside the loop, then closing it once outside the loop.  I don't know for sure, but I'm suspicious that the Express vi will open & close the file every iteration.

   However, I agree with your approach of separating the file writing into a separate loop from AI.

-Kevin P

[Amartansh13]

Thank you for your reply!

So, according to you, most of the part of my vi is correct. 

But still I wonder that how leaving the samples per channel unconnected was working fine in my previous projects but now it is not working. The only difference in my previous project and this project was regeneration mode. Earlier I was using daqmx write in regeneration mode and hence no loop was required for updating daqmx write. But now I am using daqmx write in non regeneration mode. All other parameters are same. Now if I am leaving samples/channel unconnected then it is giving error which I mentioned in my previous post. Though using samples=  1/10th of sampling rate is working correctly but I would like to know what is the reason behind this. 

Can you please explain why it was working earlier but not now? 

I have attached my previous vi (where I left samples/channel unconnected). You can compare it with my new vi attached in the above post. 

[Kevin_Price]

Your code would take a lot of work to fully decipher and I don't have the time.  Friendly advice: put in a little work to neaten your code and wiring.  It'll be for your own good as well when troubleshooting or modifying programs in the future.

I don't think you'll find that the problems arise from whether or not you specify # samples to read inside the AI task loop.  When you don't specify, it defaults to read "all available".  With nothing else to pace the loop, that loop probably iterates very rapidly and picks up very few samples per iteration.  When you *do* specify, the task waits until that # are available, then returns them all at once.  It's almost always preferable to read data in these kinds of decent-sized chunks.

You *may* have an issue from not specifying # samples per channel in your AO task call to DAQmx Timing.  When unwired and in continuous sampling mode, DAQmx automatically picks a buffer size for you.  When wired, DAQmx *may* treat it as a suggestion rather than a demand.  That used to be true in some circumstances, can't recall exactly what they are and don't know if they still apply.  What I would do to get a specific size is to follow up the DAQmx Timing call with call to a DAQmx Buffer property node where I (again) set the buffer size.  DAQmx would use this size and not override it because it thought it knew better.

I'm out of time now, but I think you'll find your time best spent on the AO task (and on some general neatening of your diagram  ), special focus on buffer size and how you keep feeding the non-regenerating task.

-Kevin P

[Amartansh13]

In your answer, what does this means: "With different sample rates you can only use the start trigger for synchronisation" .

I want to be sure that my generation and acquisition is synchronized. I have used these two steps for synchronizing my ai0 channel with ao channel:

1) I have shared the "a0 sample clock" with the analog input "daqmx timing" block and also,

2) I have triggered my analog input task by the "a0 start trigger".

Normally these two steps are sufficient for synchronizing analog output and input tasks. But in my case, I am using parallel loops ie one loop for daqmx read and one loop for daqmx write. I am concerned that whether my two steps synchronizing technique will work here or not. 

Please let me whether it will work or not. 

As I told you earlier, I am using separate loops for read and write because I am updating daqmx write every second (in non-regeneration mode). The update mechanism is little bit complex and hence putting daqmx read, write and signal generation/updating vi causes errors in analog reading operation. So, I have no option but to use two parallel loops. 

[Amartansh13]

I want to be sure that my generation and acquisition is synchronized. I have used these two steps for synchronizing my ai0 channel with ao channel:

1) I have shared the "a0 sample clock" with the analog input "daqmx timing" block and also,

2) I have triggered my analog input task by the "a0 start trigger".

Normally these two steps are sufficient for synchronizing analog output and input tasks. But in my case, I am using parallel loops ie one loop for daqmx read and one loop for daqmx write. I am concerned that whether my two steps synchronizing technique will work here or not. 

Please let me whether it will work or not. 

As I told you earlier, I am using separate loops for read and write because I am updating daqmx write every second (in non-regeneration mode). The update mechanism is little bit complex and hence putting daqmx read, write and signal generation/updating vi causes errors in analog reading operation. So, I have no option but to use two parallel loops. 

[Duffy2007 · Accepted solution]

Hello Amartansh13,

yes, both tasks run synchronous You have done the right, sharing the sample clock and use a start trigger. only the itteration of the two loops are differen, but with the shared sample clock, they are synchroniced.