Problem with continuous generation with NI 9269

[Taki1999]

I am attempting to generate an excitation signal for a resolver coil using an NI-9269. The resolver excitation signal is 3 kHz with and amplitude of 10V. This excitation signal is driving 4 resolvers so I'm using an independent channel for each resolver.

I'm prepopulating the sine waveform to write at 96000 Hz with 128 samples (1 full cycle) and initializing an array of waveforms to send to a DAQmx Write for NChan NSamp Analog 1D Wfm.

Everything seems to work fine for a while and then the analog outputs just crap out and stop generating voltage. When I stop the task, I get a -200018 error. 

I've tried dropping my output rate to 48000 Hz with 64 samples but it doesn't seem to make much difference. 

I've tried monitoring the Overcurrent property and it doesn't trip before the AO generation stops.

My working theory is that the additional noise on the coil is causing the AO to decide that it hasn't settled and then it overruns the update time. Are there any properties that I can monitor to let me know that the AO has quit? Are there any properties I can adjust to make the AO more tolerant of whatever condition is causing it to quit?

I'll try and put together a snippet that shows my configuration.

[Kevin_Price · Accepted solution]

My cDAQ knowledge is pretty modest and the spec sheet didn't answer some of my own questions.  I was looking for the size of the on-board FIFO for AO.  Perhaps that's a chassis spec rather than a module spec?   Meanwhile, I'll take a shot anyhow.

• a forum search reveals that this error isn't always simple to diagnose and solve.  The stated problem is that fresh data wasn't available at the board at the time of the sample clock edge.  Among the possible causes:

- failure of the bus to deliver data from PC memory to the board in time.  USB devices (such as a cDAQ chassis) are much more prone to this problem than PCIe or PXIe devices.

- noisy sample clock signal, especially when using an external clock source.

- starting the task too soon after initially writing samples to PC memory.  There might not have been enough time for the driver to deliver data from PC memory down to the board.

- an undesirable setting of the DAQmx Channel property known as "Data Transfer Request Condition", or possibly neighboring properties specific to USB

• if possible (can't tell if it is), see if you can configure this task to "Use Only Onboard Memory".  Then it can regenerate the sine wave(s) without having to rely on being constantly fed over the USB bus.  (This is a deep-down DAQmx Channel property.)
• I don't think the device monitors the output voltage to "decide" whether or not it has settled.
• Your #'s don't really agree.  A 128 sample 1 cycle sine wave generated at 96 kSamp/sec produces a sinusoid freq of 750 Hz, not 3 kHz.  I would generate at the max 100 kS/sec, and define a 100-sample waveform that contains exactly 3 sine wave cycles.  (The reasoning why is a bit involved, see this thread for a LOT more info.)

Hopefully, your DAQ system supports the possibility of regenerating using onboard memory only.  If so, I expect that's likely the most straightforward solution.

-Kevin P

[Taki1999]

Thanks for the response.

Since I'm only doing the one waveform write I was hoping the hardware was storing the write buffer and not having to grab it from the PC for each regeneration. Sounds like I may need to find that property.

Sample Clock is internal so I think I can rule that one out.

Starting the task too soon seems unlikely since I only have one start task and it seems to kick off ok for at least several minutes.

I've been trying to dig down into the DAQmx properties to find "Use Only Onboard Memory" and haven't found it yet. I hope that doesn't mean that it is unsupported.

My sample generation was selected to ensure that my waveform has points at the full scale 10V and -10V. I'll check out the linked thread to see if I'm missing something else there.

I think my biggest beef is that there's no feedback for me to know when the AO has failed. I'm debating about throwing in a brute force solution where I just stop, clear errors and restart periodically if I can't find the "Onboard Memory Only" property.

Thanks for the help so far.

Snippet attached in case something else obvious pops out of my implementation.

EDIT: Found the property. Doesn't appear under the normal DAQmx Channel Property Node unless I clear the filter for configured devices. We'll see if it errors out when I try it.

[Taki1999]

Looks like it is working now that I've found the right property!

Thanks a bunch to Kevin for helping me find it.

Does seem like an odd default setting for NI to use the PC buffer for regeneration instead of the Onboard. 

I would still like to see NI provide some better feedback on when an AO task has failed. Even if it's just some sort of Task property that I can poll. Early troubleshooting of this was just painful since the only feedback that an error had occurred would be seen at the time of Task Stoppage.

[Kevin_Price]

Yeah, other threads related to the -200018 error showed similar frustration that calls to DAQmx Write didn't return that error.  I think someone in one of those threads reported a different function call or property query that *would* return the error, but don't now recall what it was.  Maybe you can find that thread?

    Otherwise I'd probably first try a DAQmx Write property query for "Total Samples Per Channel Generated", or a call to DAQmx Is Task Done? (but be aware that the task done query can be slow as it seems to wait for a periodic status update rather than returning an instantaneous done state.)

Other notes:

- using the PC buffer provides more flexibility for updating waveforms on the fly, that's probably why it's the default.  Onboard regeneration doesn't allow that, at least not on most common devices I know of.

- you can use your method with 32 samples per sine cycle (divisible by 4, thus you exactly "hit" every max, min, and 0) and a nominal 96 kHz sample rate.  The *true* sample rate will be slightly different than 96 kHz due to integer division quantization, but it'll be quite close.  As a result, your excitation will be very slightly different than 3 kHz sine waves.

    The method I linked would get you *exactly* 3 kHz sine waves, but wouldn't allow you to exactly "hit" every min, max, and 0.  You'd be very close though.

    In the end, it comes down to trade-offs.  Doesn't it always?   There will be no way to exactly satisfy all your desired criteria, you'll have to decide whether a small amplitude error or a small frequency error is more acceptable.

    (The basic sticking point about exactness is that you have certain integer-based constraints and the integers involved don't share enough prime factors.  The factor '3' for your 3 kHz sine wave isn't shared by your internal timebase, which is likely either 80 or 100 MHz.)

-Kevin P

[EricTheWizzard]

Thankyou, I know this is an old thread but we have been struggling with this for a couple of days, almost the exact same scenario as OP.

Setting 'Use Only Onboard Memory' and regeneration mode to Allow Regeneration seem to have solved it for us as well.