NI USB-6001 analog output ignores configured min/max limits

[Nate@UT]

NI USB-6001 multifunction DAQ device configured to analog output single channel and single sample on AO 0 terminal.  Min and Max limits configured during task creation or with subsequent calls to DAQmxSetAOMax/DAQmxSetAOMin are ignored:   generation of updated voltage values exceeding this range happen without any errors that indicate configured limit is being exceeded. 

Problem is reproducible using both C-based application as well as LabVIEW.  DAQmx version 20.1, LabVIEW 2018 64-bit. 

Same code works as expected (error returned when limit is exceeded) when tested with NI USB-6008 and NI USB-6211.

Is there a different sequence of function calls needed for the USB-6001 or is this a DAQmx or firmware bug which needs to be fixed by NI?

I don't see a "firmware updater" in NI-MAX.  Is there somewhere that I can go to insure I have the most recent version of device firmware?

[Kevin_Price]

Did you read the device's specifications?

Unlike some DAQ devices that support multiple possible voltage ranges for input & output, the USB-6001 supports *only* the +/- 10 V range.

The other piece to the puzzle is that it's normal behavior for DAQmx to silently select and configure for a voltage range your device actually supports.  It will try to use the smallest feasible range that encompasses your stated Min and Max. 

    That's what the Min and Max are for.  They define *your* agreement with DAQmx that those are the Min and Max values you need to generate with your AO task.  They do *NOT* define the actual voltage limits for the D/A converter circuitry.  The available physical limits are defined in the specs on a per-device basis.

Given what I see from the devices' respective spec sheets, when you tell DAQmx you have a Min and Max of -4 and +4:

- the USB-6001 will configure for its only range of -10 to +10 V

- the USB-6008 will configure for its only range of 0 to 5 V

- the USB-6211 will configure for its only range of -10 to +10 V

Voltages between -10 and -4 or between +4 and +10 should end up generating without error on both the 6001 and 6211.  Voltages less than 0 or greater than 5 should produce an error on the 6008.

Given this, I'd suggest you double-check the 6211 behavior compared to the 6001. 

Getting back to your actual app, perhaps you want to feed your values through "In Range and Coerce" to make the voltages saturate at +/-4 V?   Note: due to nuances of floating point, I'd use a range more like -3.9999 to +3.9999.  I recall a discussion where similar out of range errors were created when someone had a voltage value that was something like 0.00000002 volts too high, due to some kind of round-off error in a calculated waveform.  

-Kevin P

[Nate@UT]

@Kevin P, thank you for taking the time to reply.

Yes, I'm familiar with all of the specifications for these devices.  I've been using the 6211 device in my application for years, and the Min/Max properties are configured to use as "safeguards" to prevent a user from exceeding the voltage limit (e.g. to protect downstream connected electronics) when subsequently generated using  DAQmxWriteAnalogF64 or DAQmxWriteScalarF64 in a C application, or the DAQmx Write (VI) in LabVIEW.

In addition to double-checking the 6211 (screenshot attached), I also tried a USB-6343 and it behaves consistently with the 6211 & 6008:  regardless of the D/A range that the device internally selects (for reasons of maximizing precision), they provide an error when a value outside of the pre-configured Min/Max is written to the channel.  The error given is:   Attempted writing analog data that is too large or too small. Change Minimum Value and Maximum Value to reflect the range of the channel.(-200561)

The USB-6001's behavior is different than the other three models.  Whether ignoring the Min/Max range is intended (but not well documented) or a bug in either DAQmx or the USB-6001 firmware, I don't know.

I can certainly move this safeguard behavior up to my application level, but that requires additional run-time application logic (i.e. if this device than A, if that device then B) which I would prefer to avoid by having the 6001 behave at the driver level in a similar fashion to these other NI USB multifunction devices that I've mentioned.

I am hoping someone else with the same experience has any ideas on solutions. 

[Kevin_Price]

I'm on board with you now.  I observe the same thing under DAQmx 18.6 using simulated devices for the USB-6001 and USB-6211.

Dunno if my memory's wrong or if DAQmx changed its behavior about coercing voltage ranges without error (neither is unprecedented).  Either way, this kind of inconsistency sure looks like some kind of bug to me.

I even used a DAQmx Device property node in LabVIEW to query for all the available AO voltage ranges, just to double check what was in the spec sheets.  For both devices above, only the +/- 10V range was returned, confirming the spec sheets.

Anyone from NI?   What's the explanation / workaround here?

-Kevin P

[mcduff]

Unfortunately I cannot add anything to help with a solution but I have noticed the following with DAQmx AI tasks:

1. For some cards if you specify the wrong voltage range you get an error, others it coerces to the correct value.
2. For some cards if you specify the wrong sampling rate you get an error, others it coerces to the correct value.
3. For some cards the order of operations matter, for example, a property read before or after timing information entered would sometimes give an error sometimes not depending on the card.

This was noticed for simulated devices, so I assume the they have ideal firmware.

I really like the DAQmx API, but these kind of inconsistencies are really frustrating.

mcduff

[Nate@UT]

NI Tech Support ack'ed bug and filed it for consideration in a future driver release.  (1231522 )