simple analog input and analog output loop gets buffer overflow- WHY??

[WildCherry]

Dear All,

I have a USB-6211 DAQ and Labview 8.5, and NIDAQmx version 8.71 (the latest one?), running on windows XP

The attached VI exits after about 4 seconds of execution with the overflow error: Error -200279 occurred at DAQmx Read (Analog 1D Wfm NChan NSamp).vi:1

The example is very simple, involving a single loop containing a single channel AI (continuous sampling at 40 samples at rate of 4000 samples/sec), in parallel with a single channel AO, writing a DC value at 10 samples at 1000 samples/sec.

Thus, both read and write should take about 100 mSec per iteration- still the AI buffer gets overflow after just 4 seconds. It is the same phenomenon even if I lower the AO write samples (from 10 to 5 for example)

Could the problem arise from the use of the DAQ assistants instead of the more primitive read/write functions? Shouldn't this also work with the DAQ assistants?

Any help would be greatly appreciated!

PS the problem persists when I changed the AO write rate to 4000 to equal the AI rate

PPS the problem disappears if I disconnect the wire between the simulate signal and the AO daq assistant - meaning the problem resides in the daq assistant or its workings

PPPS moving the read and write to different loops would probably work, but why doesn't this work with my single loop??

Thanks dearly,

WildCherry

[JoeFriedchicken]

Hi WildCherry,

The DAQ Assistant is not always the best approach for looped measurements. Each time the loop executes, the DAQ Assistant asks the driver to create the task, configure it, read/write to/from it, and clear it. This is a lot of overhead and often results in these kinds of buffer errors. The DAQ Assistant is better suited for finite or one-off operations.

The DAQmx driver installs several example VIs that demonstrate how to use the full API, and one even addresses simultaneous analog input and analog output. Please take a look at it, modify it for your needs, and let me know if you'd like further clarification.

Multi-Function-Synch AI-AO.vi
Help » Find Examples... then Hardware Input and Output » DAQmx » Synchronization » Multi-Function

[WildCherry]

Dear Joe,

I took your advice and am started using the DAQmx more low-level functions. I must be doing something wrong in the DAQmx Write function tho, because the attached VI takes about 3 seconds to complete, when the total time of the samples is supposed to be around 40 milliseconds.

Can you please see if you can find any problem here? I would like very much for it to finish when the samples are done, i.e. 40 seconds.

Thanks dearly,

WildCherry

[JoeFriedchicken]

Hi WildCherry,

From what I see on my machine [1], your code works correctly: the output pulse runs for 0.040 seconds, or 40ms.

The way that you're measuring the time of execution isn't very accurate because you place the 'time at start' Tick Count VI in the same frame as the analog output. All of the code in the first frame will try to execute in parallel, but there is no guarantee that the Tick Count VI will be executed first. In addition, the 'Simulate Arbitrary Signal' ExpressVI takes time to execute and isn't part of the analog output process.

Measuring the time of generated outputs using software generally isn't very accurate, but if you want to improve your measurements, I would make two more frames before the first frame. Put the ExpressVI and property node in the new first frame, put the Tick Count VI in the second frame, put the DAQmx Write VI in the third frame, and leave the last frame as it is.

[1] see my attachment of your front panel

[WildCherry]

Dear Joe,

As you can see, the primitive timing scheme I have shows 1050 mSecs, instead of the planned 40 mSecs (taking into account the time for the function generator and machine timing, which shouldn't be more than a few mSecs?)

If you measured the acutal pulse generated, I believe it would be spread over that whole 1000 mSecs- that's what I got when doing a parallel AI loop to measure the AO.

Something is bad with the timing of the AO waveform- can you see something wrong or missing in the VI? Perhaps the waveform generated from the "Simulate Arbitrary Signal" is somehow not compatible with the DAQmx Write function? Anything?

Thanks dearly and have a great weekend,

WildCherry

[Steven_C]

Hi WildCherry,

I was taking a look at some of the code posted above and it appears the best thing to do would be to start with a shipping example example and build it into your end application. Based on the original code you provided, I would suggest that you try to run the example that Joe suggested, in other words:

Go to Help » Find Examples... then Hardware Input and Output » DAQmx » Synchronization » Multi-Function >> Multi-Function-Synch AI-AO.vi.

If this example does not work, I would suggest going to a simpler example for basic analog output. A basic example in LabVIEW may be found at:

Go to Help » Find Examples... then Hardware Input and Output » DAQmx >> Analog Generation >> Voltage >> Cont Gen Voltage Wfm-Int Clk.vi

If this does not work, you may drop down a DAQ assistant, follow the walk through steps, right-click on it and select the option to "Generate DAQmx Code".

Once we have a basic VI up and running we will be able to help in tweaking it by using appropriate property nodes and such. Please let me know if trying any of these example still results in unwanted delays or if they do, in fact show significant performance increases. Thanks and have a great day!

Best regards,

Steven

[WildCherry]

Dear Steven,

Thanks for the refrence to the Examples; I actually went over these, but when I tried executing an AO myself, using these same functions and Simulate Arbitrary Signal VI, I ran into some unexpected problems. The VI I attached two posts above (test_writing_onech.vi) shows this problem:

A waveform which is supposed to be of 40 mSec length is made with the Simulate Arbitrary Signal VI, but when I try to wire this to the DAQmx Write, two problems occur (which arrise from the same source I am sure)

1. The actual time spent on in the Write VI is around 3 seconds on my machine (it was around 1 sec on Joe's) [see "time mSec" indicator on the Front Panel]

2. The actual pulse generated lasted these whole 3 seconds! instead of the intended 40 mSec [as measured by a multimeter attached to the AO ports on the DAQ]

What could be causing this? I didn't use the DAQmx Timing VI, therefore Write should work using on-demand timing - but still, why doesn't this work?

Another note: when I try changing the number of Samples in the WFM, by changing the dX in the Timing window in the Define Signal part of Simulate Arbitrary Signal VI, then the total time changes about proportionally to the number of samples- i.e. there seems to be a more or less (not precise at all) constant rate of generation of around 1000 samples/sec, regardless of the actual time the WFM should have taken.

Could there be a problem using Simulate Arbitrary Signal VI with these DAQmx functions? (Write etc.)

Thanks dearly for your help,

WildCherry

[JoeFriedchicken]

Hi WildCherry,

First, I'd like to revisit how you're measuring the time it takes to execute the DAQmx Write VI in LabVIEW. I've revised your VI to more exactly measure this in software, and in my screenshots, you can see that the write step takes only 5 ms. I also added cursors to the plot and the waveform itself has a 40 ms duration. The reason that DAQmx Write doesn't use the same amount of time as the waveform is because that driver call isn't blocking: it sends the command to the driver and then to the board and returns control to LabVIEW while the board runs its command.

Without specifying a sample clock rate, the task will default to 1000 S/sec. You can see this by adding a timing property node and reading the sample rate. The sample clock rate will remain fixed at 1000 for any dX set in the Simulate Arbitrary Signal VI.

I believe the reason that you're observing prolonged output is the order in which you're calling DAQmx Write and the regeneration property node. The error cluster between the two causes the DAQmx Read call to execute before the regeneration property node. I reversed the order in my revision of your VI and noticed only one 40 ms pulse in the test panels for my board.

Please let me know what you try and what happens. I think we're very close to getting things running 🙂

[WildCherry]

Dear Joe,

Thanks dearly for your reply. I finally changed my VI and utilized DAQmx Timing, using the "Use Waveform" configuration, and added DAQmx Start, and DAQmx Wait Until Done VIs, and it seems to work as expected finally 🙂 So the example I sent you is no longer relevant- although I DID try to implement the changes you suggested and it still takes 3 seconds on my machine and not the 5 milliSecs you encountered (The timing measurement sequence doesn't matter- I changed that also just to make sure- it also makes sense that it won't, as the clock VI (and all other no-input vis) in the same frame are supposed to start executing in parallel (at least up to the timing of the OS..), and so the time measurement should be the same even if it's in the same frame.

So it is still a mystery what happened in this example, but we shouldn't be concerned about it now.

Thanks again and have a great week,

WildCherry

[JoeFriedchicken]

Hi WildCherry,

Excellent 🙂 I'm glad you've got a working VI -- that's the important thing.