Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

How to flush output buffer, optionally resize it, and write to it again, before starting output task

Solved!
Go to solution

I'm using PyDAQmx with a USB-6363, but I think the question is generic to DAQmx.

 

I have an output buffer which I want to be able to (re)write to without starting the output task.

 

Specifically, I have a GUI and a few sliders the user can move around.  Each time the slider changes, a new set of values is loaded into the output buffer via DAQmxWriteAnalogF64.  After setting the value the user can click a button and the output task starts.

 

In some cases the slider change doesn't require a change of buffer size, only a change of the data.  In this case I get the following compalint from DAQmx while attempting the write:

The generation is not yet started, and not enough space is available in the buffer.

Configure a larger buffer, or start the generation before writing more data than will fit in the buffer.
Property: DAQmx_Write_RelativeTo
Corresponding Value: DAQmx_Val_CurrWritePos
Property: DAQmx_Write_Offset
Corresponding Value: 0
Property: DAQmx_Buf_Output_BufSize
Corresponding Value: 92

 

In other cases the slider change requires both change in buffer size and change of data.  In this case I get the following, but only after doing it a few times each time increasing the size of the write.

DAQmx Write failed, because a previous DAQmx Write automatically configured the output buffer size. The buffer size is equal to the original number of samples written per channel, so no more data can be written prior to starting the task.

Start the generation before the second DAQmx Write, or set Auto Start to true in all occurences of DAQmx Write. To incrementally write into the buffer prior to starting the task, call DAQmx Configure Output Buffer before the first DAQmx Write.
Task Name: _unnamedTask<0>

Status Code: -200547
in function DAQmxWriteAnalogF64

 

 

I've tried configuring the output buffer via DAQmxCfgOutputBuffer (in some cases configuring it down to zero or one samples, then back up again, in an attempt to clear it out) but that doesn't seem to do the trick.

 

Of course I can work around the problem by loading the data only when the user clicks the final button, but that's not what I'm asking here.

Is there any way to "redo" the output write before starting the task?

 

thanks

Michael

 

0 Kudos
Message 1 of 6
(7,789 Views)
Solution
Accepted by topic author RedmondUser

I don't have hardware handy today to validate this, but try unreserving the task before writing the new buffer:

 

DAQmxTaskControl(taskHandle,DAQmx_Val_Task_Unreserve);

 

 

With a simulated device it makes the error go away in the case where the buffer is the same size.  You'll have to validate if the data is actually correct but I think it should be (unreserving as far as I can tell resets the write pointer so the old buffer will be overwritten by the new data).

 

I still get errors when trying to change the buffer size though (on my simulated 6351).  I reported a couple of similar errors regarding reconfiguring tasks here, I suppose it's possible that this issue was also fixed in 9.8 (I'm still using 9.7.5 on this computer).  If the behavior is still present in the newer driver and also shows up on real hardware (not just simulated), then it seems that this is a DAQmx bug that someone at NI should look into.

 

I wrote a simple LabVIEW VI that captures the error to help the folks at NI reproduce it:

UpdateAOBufferSize.png

 

The best workaround for now would likely be to recreate the task if you need to change the buffer size (or avoid writing the data until you are sure about what the buffer size will be).

 

 

Best Regards,

John Passiak
0 Kudos
Message 2 of 6
(7,750 Views)

Great, thanks very much for the answer 🙂  I'll try it on the hardware and see what happens.

 


@John_P1 wrote:

I don't have hardware handy today to validate this, but try unreserving the task before writing the new buffer:

 

DAQmxTaskControl(taskHandle,DAQmx_Val_Task_Unreserve);

 

 

With a simulated device it makes the error go away in the case where the buffer is the same size.  You'll have to validate if the data is actually correct but I think it should be (unreserving as far as I can tell resets the write pointer so the old buffer will be overwritten by the new data).

 

I still get errors when trying to change the buffer size though (on my simulated 6351).  I reported a couple of similar errors regarding reconfiguring tasks here, I suppose it's possible that this issue was also fixed in 9.8 (I'm still using 9.7.5 on this computer).  If the behavior is still present in the newer driver and also shows up on real hardware (not just simulated), then it seems that this is a DAQmx bug that someone at NI should look into.

 

I wrote a simple LabVIEW VI that captures the error to help the folks at NI reproduce it:

UpdateAOBufferSize.png

 

The best workaround for now would likely be to recreate the task if you need to change the buffer size (or avoid writing the data until you are sure about what the buffer size will be).

 

 

Best Regards,


 

0 Kudos
Message 3 of 6
(7,744 Views)

I finally tried this and it seems to work.  Here is a piece my python code, from class DAQCtrl, where I'm configuring both input and output simultaneously.

 

def arm(self, data):
""" Sets up DAQ output, input, and clocks to send/receive
the correct number of points. Expects data to be N x 3 array."""
airate = self.aorate * self.inputOutputRatio
ldo = len(data)
inputN = int(ldo * self.inputOutputRatio)

if self.armed:
print('Clearing')
self.armed = False
self.stop()
self.aotask.TaskControl(pd.DAQmx_Val_Task_Unreserve)
self.aitask.TaskControl(pd.DAQmx_Val_Task_Unreserve)

if not self.armed:
try:
print('Arming')
self.aotask.update(data, self.aorate)
self.aitask.update(inputN, airate)
self.armed = True
except pd.DAQError as e:
print("DAQ exception caught:\n%s" % str(e))

 

0 Kudos
Message 4 of 6
(7,514 Views)

Hi,

 

I was able to recreate the behavior you were seeing and submitted a Corrective Action Request (CAR). The CAR ID for this issue is 528991. Keep an eye out for a fix in future versions of DAQmx. A list of bug fixes for each version can be found in the corresponding readme.

 

Thanks for bringing this to our attention!

https://www.linkedin.com/in/trentweaver
0 Kudos
Message 5 of 6
(7,495 Views)

Hi,

 

I just opened an issue on github for a similar problem, I'm not sure I understand how to implement the workaround.

All the details, including minimal code producing the problem, are on the gh issue,

 

Any tip welcome!

 

Guillaume

 

0 Kudos
Message 6 of 6
(2,625 Views)