DAQmxBaseWriteDigitalU32 gives error -200284 with numSamples >= 2048

[pstys]

This is a followup to my plea for some guidance on how to generate a digital output pulse synchronously with an analog in acquisition. My (partial) solution was to fill a DO buffer with the correct series of uint32's, start a pulse train @ ctr0 as the master clock for the DO and AI series (manually tying ctr0 out to PFI0 and using the latter as the clock source for both), configure an AI series to do the A/D, then start the clock.

This sort of works except that anytime I try to output a series of uInt32's at the digital output port with a buffer longer than 2047 samples, DAQmxBaseWriteDigitalU32 returns an error -200284:

"Some or all of the samples requested have not yet been acquired. To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger, make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock."

This occurs regardless of the timeout parameter in the DAQmxBaseWriteDigitalU32 call.

NI-DAQmx base v2.1 on Mac OSX, M6251 card.

Can anyone tell me what I'm doing wrong (please tell me this card/driver is able to output more than 2 kSamples at a time!!!)

As background, the reason I have to do this is because DAQmxBaseCfgSampClkTiming does not accept DAQmx_Val_FiniteSamps as a param, so that by the time I stop ctr0 in code by calling DAQmxBaseStopTask, several cycles of the (circular) DO buffer are output generating multiple pulses. So I thought of zero-padding the DO buffer, but I can't pad past 2047 samples.

Any tips greatly welcome.

Peter.

[Neal M]

Hello pstys,

The discription you provide of what is going on is confusing to me.  It appears that there is one of two things going on:

1)   The error text you are getting is for an input.  What it is telling us that your samples to read input for your read function might be too high and the function is waiting (until it times out and throws an error) until that number of samples has been acquired.  For example, if we specify a samples to read of 1000 and only take 500 points, then the function will timeout waiting for the last 500 points and throw the error you show.  The way to get around this is to put the read into a loop and put the samples to read as -1 (which means "read whatever is there").  That will prevent a timeout error and allow you to control the read more accurately.

2)   The fact you are getting an error when you write more than 2047 says to me that you are trying to write more to your cards FIFO than it can hold (its size is 2047 samples, page 7 - waveform characteristics).  I am not sure if you can do full double buffered DO with DAQmx Base (you can with DAQmx), which appears what you are trying to do.  I would recommend trying to write multiple times with smaller amounts (e.g. write x points of your waveform every so often so that there are less than 2047 samples on the FIFO at any one time).

The discrepancy between the error and the function it says it happened in usually occurs when people do not handle their errors correctly.  You should be sure that you are passing errors correctly (see our example programs, they all do).

I hope this gives you some place to start.  Please post back with your findings.

[pstys]

Hi Neal:

See my replies to your previous comments (prefixed with >>>):

>>> 1) The error text you are getting is for an input...

You'd think, but this is the code that generates the error:

DAQmxErrChk (DAQmxBaseCreateTask("",&taskHandleDO));
DAQmxErrChk (DAQmxBaseCreateDOChan(taskHandleDO, "Dev1/port0/line0", "", DAQmx_Val_ChanForAllLines));
#define dummySampleRate 1000
uInt32 numSamples = 2048;
DAQmxErrChk (DAQmxBaseCfgSampClkTiming(taskHandleDO, "/Dev1/PFI0", dummySampleRate, DAQmx_Val_Rising, DAQmx_Val_ContSamps, numSamples));
// write samples to DO buffer; limited to <2048
DAQmxErrChk (DAQmxBaseWriteDigitalU32(taskHandleDO, numSamples, noAutoStart, kTimeOut, DAQmx_Val_GroupByChannel, dataDO_32bit, NULL, NULL));

The last stmnt generates error -200284 for numSamples > 2047.


>>> 2) The fact you are getting an error when you write more than 2047 says to me that you are trying to write more to your cards FIFO than it can hold (its size is 2047 samples, page 7 - waveform characteristics).

I think this is the issue, even tho the error seems to refer to a read timeout (it's actually a write timeout because the FIFO is filled).


>>> I am not sure if you can do full double buffered DO with DAQmx Base (you can with DAQmx), which appears what you are trying to do.

So how do I find out if I can do full double buffered DO (I assume this means reading the uInt32's from the host computer's RAM?)



>>> I would recommend trying to write multiple times with smaller amounts (e.g. write x points of your waveform every so often so that there are less than 2047 samples on the FIFO at any one time).

Interesting thought: how do I do this and not screw up the timing of the output pulse pattern? Are you saying that I can call DAQmxBaseWriteDigitalU32 several times on the fly while the DO data are being clocked out, and the subsequent calls to DAQmxBaseWriteDigitalU32 (with 2047 samples each) will wait until the FIFO is flushed, then fill the FIFO with new uInt32's without skipping a beat in the output pulse pattern?



>>> The discrepancy between the error and the function it says it happened in usually occurs when people do not handle their errors correctly.

I did not handle the error, I just looked up the error text from your docs. It's definitely DAQmxBaseWriteDigitalU32 that returned -200284 so DAQmxBaseWriteDigitalU32 is returning a misleading error number.

Peter.

[Neal M]

Hello peter,

Sorry it took so long for me to get back to your post, I've been talking to the developers of DAQmx Base about this issue so I would know the correct answers to your questions.

You cannot do double buffered DIO with DAQmx Base because it does not configure a RAM buffer.  DAQmx Base just uses the onboard FIFO and nothing else.  It also only uses Interupts (instead of a DMA channel) to do the data transfer.  What this means for us is that we need to write to the FIFO multiple times to keep the FIFO filled with data to output. 

The DAQmxBaseWriteDigitalU32 function writes to the FIFO, it does not actually control the generation (that is done in hardware).  So if we call DAQmxBaseWriteDigitalU32 before starting with 2047 samples, wait until 1000 or so samples have been generated, then call DAQmxBaseWriteDigitalU32 again with 1000 samples.  This way, there is always new data in the FIFO to be written without overflowing the memory.

We cannot write 2047 samples each time because one of two things would happen.  First, we would get an error (the same error you are currently seeing, I believe) because we are trying to write too many points to our FIFO.  Or, we would wait until the FIFO is empty and write then.  This would force us to stop generation (or output old data) between writes.

So the logic flow we want is this:

1. Configure the task
2. Write 2000+ points to the FIFO with DAQmxBaseWriteDigitalU32
3. Start generation
4. Wait until at least x points have been generated
5. Write x points to FIFO using DAQmxBaseWriteDigitalU32
6. Repeat 4 & 5 until all data has been generated
7. Close everything

The error text you are seeing is incorrect for the error generated, I will report that problem to R&D.

[pstys]

Dear Neal:

Thx for your detailed reply, this is potentially helpful. I understand the point of your logic flow, but I am unclear how I would do #4 above: "Wait until at least x points have been generated". I can't see any calls in the mxbase C API that tell me how many samples have with been clocked out to the DO port since the last call to DAQmxBaseWriteDigitalU32.

If you could tell me how to test for this, then I can try your logic:
1) underfill the FIFO
2) start clocking out
3) keep refilling the FIFO with small chunks ONCE I KNOW WHEN THE PREVIOUS CHUNK OF SAMPLES WAS CLOCKED OUT
4) repeat until all DO data have been written out

Looking fwd to your reply re above,
Peter.

[Neal M]

Hello Peter,

There is no way to directly poll how many points have been output in DAQmx Base.  There is also no way to tell how much unwritten data is in the FIFO.  Both of these are properties available in DAQmx, but not DAQmx Base.  However, I believe that the DAQmx Base Write function will block the program until there is enough room in the FIFO and then write the data to it.  What I mean by this is if we write 2000 points initially to the memory, start our task, then immediately call another write of 1000 points, what will happen is the second write will wait until there is 1000 points free in the FIFO and then write the points.  If, however, we timeout (it took too long to clear enough points for the write), then it throws the error we have been seeing.

I wrote a LabVIEW program that does this and I believe this will work.  At the very least, it is waiting a proportional amount of time to the number of points I am trying to write (more points=more time holding in the write).  So the thought pattern is a bit different than the steps you outline in your post.  Instead of refilling the FIFO once you know the chunk has room, you write a chunk and the function will write it when there is room.

I have attached my VI so any LabVIEW users trying to do this can see as well.  Please give this a try and let me know if it works for you as well.

[pstys]

Hi Neal:

I figured there was not a way to poll remaining FIFO samples.  But you're right, calling the write fn will wait until there is room in the FIFO, but there are 2 serious problems with this:

1) my measurements on a digital scope show that the 2nd fill of the FIFO (ie. 2nd write call) completely screws up the timing ie. there appears to be the same 1-2 ms delay before that 2nd call completes.  So even while you can refill the FIFO, the timing is screwed up so don't bother trying to generate anything longer than what fits in the 2047 sample FIFO.

2) the 2nd problem is even more curious, and more serious.  See my recent post:

http://forums.ni.com/ni/board/message?board.id=250&thread.id=36335

Finally, I can't study/try your vi because i don't have LabVIEW.

Peter

[Neal M]

Hello Peter,

I have looked for this timing issue on my PC with my hardware, but I cannot replicate it.  My next step is to try and look at my program on a Mac and see if I can reproduce it there.

I have talked with my colleagues that have been working with you on other forums (as well as your support email and R&D).  And I think that we need to take a look at the big picture of what your application is and the best way to make it successful.  In order to do this, it would be best (and fastest) to take this issue offline and work through your direct contacts at NI instead of on the forums.  I will continue to look at this specific issue and work with my colleges to help you reach your goals as fast as possible.  We can then post what we come up with on the forums.  Please let me know if you do not want to proceed in this manor.

[pstys]

Hi Neal:

I'm happy to proceed in whatever manner will find a solution. I have been in touch with other NI folks off-list so perhaps I'll pursue that for now. If/when a solution is found, i'll post to the list so that others may benefit in the future.

thanks for your help,
Cheers,
Peter.