time stamps not linear

[Kevin_Price]

Considering the fact that you've managed to implement a producer / consumer pattern using a queue, might I humbly suggest that you also abandon the use of the DAQ Assistant?  My personal and heavily biased opinion is that the DAQ Assistant is of very limited use, aimed primarily at those who are (or should be!) reluctant to do their own programming.  If you're comfortable slinging data around through queues, you should easily be up to the task of explicit DAQ programming.

The examples you find from the LV Help menu are often a very good starting point to illustrate the proper sequence of DAQ calls.  Probably the single most important lesson for your large-ish acquisition is to configure and start the DAQ task *before* entering your main loop, perfom Read's inside the loop, then Stop and Clear the task after the loop completes.  It may be the case that there are ways to accomplish similar things with the DAQ Assistant, but I myself don't know them and would suggest that in the long run, you're much better off learning how to control the tasks more explicitly anyway.

The choice of input and output in same or different loops depends on what you need to accomplish.  Not much help, huh?  Can you describe your app more?  Can you post code?  One thought, just in case I'm guessing right: are you writing data to your output generation task every loop iteration?  If your output is meant to generate some kind of repeating pattern, it wouldn't be necessary to keep writing to it over and over.  An output task can be setup so that you write data to its buffer 1 time ever and the board will keep regenerating that data in a circular fashion.  I guess I still can't twist my head around enough to see how that should have any effect on the timestamps of the input task though.

If you can post code, could you post a screenshot of it too?  For some of us, network PC's and LabVIEW PC's can't be accessed at the same time...

-Kevin P.

[Erik_J]

Hi Jamie,

"I think you are saying though the DAQmx has the potential to create a buffer of size 4095 samples, but my choice limits this to 1024 samples.  Whats more, data is transferred between the DAQ and labview I guess in smallish, arbitrary chunks at intermittent times whenever possible and not in 1024 sample chunks.  However Labview then assembles the colleted data into 1024 sample blocks.

Is my understanding correct?"

You are correct.


I am trying to understand why if I have a DAQ assistant programmed to continuously acquire data do I 1) need to put it in a while loop and 2) need to specify a value called "number of samples".

1) While continuously acquiring the data, you need to intermittently get the data off of the DAQ card's buffer and into the PC buffer.  That is what happens on each iteration of the LabVIEW while loop.  If you did not have the DAQ Assistant in a loop, the DAQ card's buffer would overflow if doing continuous acquisition.

2) When continuously acquiring data, the "number of samples" input specifies the buffer size for the acquisition.


I understand one may start before the other, but if the sample rate is the same will they both work in synch with each other?

Yes, even though the tasks will not start at the same time, they will synch up with each other.


"Is it better to keep both the DAQ assistant input and output blocks in the same while loop or place them in their own separate while loops?"

It is good programming practice to reduce the number of while loops in your program.  For this reason, it is better to keep your DAQ inputs and outputs in the same while loop.


From Kevin's post:
"Considering the fact that you've managed to implement a producer / consumer pattern using a queue, might I humbly suggest that you also abandon the use of the DAQ Assistant?  My personal and heavily biased opinion is that the DAQ Assistant is of very limited use, aimed primarily at those who are (or should be!) reluctant to do their own programming.  If you're comfortable slinging data around through queues, you should easily be up to the task of explicit DAQ programming."

I couldn't agree more with Kevin.  If you are comfortable programming in LabVIEW, you should consider using the explicit DAQmx VIs.  I have attached an example that both generates and acquires data in the same while loop using the explicit DAQmx VIs.  Please take a look at it and let me know if you have any other questions.


Best Regards,
Erik

Message Edited by Erik J on 11-15-2006 11:09 AM

Message Edited by Erik J on 11-15-2006 11:14 AM

[Erik_J]

Try this attachment instead, the other one looks for the a VI in a bogus location.

[Jamieg]

Hi All,
Sorry it has been a while replying, I was sorting out some other hardware issues and other programming.

I have abandoned the daq assistants and am using your example Erik J as a basis.

Attached is a slight modification I made in an effort to force the timing of the output and input to be more synchronized I set the ai SampleClock source to the ao SampleClock instead of the default which uses the ai SampleClock.  This caused a problem where by the analog input now follows the sample rate of the analog output instead of the analog input.  This can be shown by looking at the timing in the file the VI generates.  Why does this happen?  Can I not use the ao SampleClock with independent output and input sample rates?

Regards,
Jamie

[Jamieg]

Hi All,

The file I uploaded previously does not make my point as clearly as this one.

When writing to file, the time stamps written match the designated input sample rate but the analysis shows the data is really analysed at the output sample rate when the ao SampleClock is used as the input.  Also, if you compare the file sizes for the same recording times, you'll see the file size is dependent in this case on the output sample rate rather than the input sample rate.

Jamie

[Erik_J]

Hi Jamie,

If you specify a source in your DAQmx Timing VI, then all the input sample rate will do is specify the buffer size for the acquisition.  So even though you are specifying a rate, the acquisition will still use the rate provided by the AO sample clock.  You cannot achieve two different rates when using the same sample clock.

Both the AI and AO sample clocks are based off of the same timebase, so even if the generation is using the AO sample clock and the acquisition is using the AI sample clock, we can still get them to synchronize by using a start trigger.  We can export the start trigger from the AI task to the AO task and to make sure the AO task starts before the AI task.  Please see the attached VI for an example of this, or you can find this example in the Example Finder under Hardware Input and Output » DAQmx » Synchronization » Multi-Function » Multi-Function-Synch AI-AO.vi.

And to correct myself before: when doing continuous acquisition, the DAQ Assistant or DAQmx read must be inside a while loop to move the data from the PCs buffer to LabVIEW memory.  The samples are actually transferred from the DAQ card to the PC buffer using DMA (direct memory access) almost immediately after they are acquired.

Please take a look at this example on synchronizing AI and AO, they can use their own sample clocks.

I hope this helps, I will be back in the office on Wednesday, December 27th to assist you further.  Happy Holidays!!!

Best Regards,
Erik J.
National Instruments

[Jamieg]

Erik,

After some modifications I have turned the data generation/acquisition VI into a sub-VI called from a larger VI.  This subVI puts the acquired data on a queue.

This leads to the problem of the big VI not having access to the stop and pause buttons in the subVI, nor the chart.
I can get the sub-VI window to open when called, and then press the stop button on it, but I would like the main VI to have the stop and pause button on it.

I have another subVI which removes data from the queue, analyses and can decide when to stop the acquisition.
This setup is similar to the producer/consumer template, however the producer and consumers are now subVIs.

What is the best way to get the subVIs and the main VI to exchange data whilst running?  Eg I would like both the analysis subVI and main VI to have stop buttons which would propagate to the acquisition subVI.  Also, selected charts from either subVI I would like displayed in the main VI with up to date information.

In other programming languages I am familiar with I would simply pass variables to a sub-function and they would be passed back at the end, and global variables are avoided.  However, as this is real-time rather than sequential programming, I suspect the task is more complicated.

Attached is the code so far which does this task.  Other comments about programming style or efficiency are most welcome.

Regards,
Jamie

[Erik_J]

Hi Jamie,

The best way to communicate between VIs is to use Global Variables.  To use Global Variables, create a Project and place all of your VIs in it.  Then in the Project Explorer, right-click on My Computer and select New » Variable.  Then you can select the data type and name of the variable.  To read to or write from your variable in any of your VIs, simply drag the variable from the Project Explorer to the Block Diagram of the desired VI.

If you want to use the Main VI to write values for the Sub VI to read and then have the Sub VI to return a graph to the Main VI, Global Variables would be your best bet.  Click here for more information on Global Variables.

Regards,
Erik

[kazinoz]

I know this thread is old but I would like to look at your code. Whenever I try to look at any of the code, I can't find the "Waveform Buffer Generation.vi". I am using LabVIEW 8.6, was this something residual to 8.0?

Would love to look at the whole code, thanks.

[A_Person]

I can't speak for anything about the original code, but Waveform Buffer Generation was not found when I did a search in 8.0.  Looks like a custom VI.