How to programmatically determine whether a DAQmx property is supported by a device?

[banksey255]

I am developing code that I want to work with any NI DAQ device because I do not know what devices will be used prior. Not all DAQmx properties are supported by all devices, and when I attempt to set an unsupported property, either it immediately reports error -200452, which is fine, or less helpful, only reports that error when DAQmx Start Task is called, in which case it appears the only way to recover is to create an entirely new task and not set the unsupported property as part of the workflow.

Is there a way to determine programmatically at runtime whether a DAQmx property is supported by the device so that I can prevent my code from attempting to set unsupported properties, rather than having to rely on error -200452 being thrown?

It would be nice to have a general solution, but to be less general, the particular DAQmx property that I am having problems with is setting AIConv.Rate, with some devices requiring ActiveDevs be set first, whilst other devices do not support the ActiveDevs property, and then there are some devices that don't support the AIConv.Rate property at all.

[JÞB]

---

@banksey255 wrote:

I am developing code that I want to work with any NI DAQ device because I do not know what devices will be used prior. Not all DAQmx properties are supported by all devices, and when I attempt to set an unsupported property, either it immediately reports error -200452, which is fine, or less helpful, only reports that error when DAQmx Start Task is called, in which case it appears the only way to recover is to create an entirely new task and not set the unsupported property as part of the workflow.

Is there a way to determine programmatically at runtime whether a DAQmx property is supported by the device so that I can prevent my code from attempting to set unsupported properties, rather than having to rely on error -200452 being thrown?

It would be nice to have a general solution, but to be less general, the particular DAQmx property that I am having problems with is setting AIConv.Rate, with some devices requiring ActiveDevs be set first, whilst other devices do not support the ActiveDevs property, and then there are some devices that don't support the AIConv.Rate property at all.

---

The simple answer is "RTFM".  The longer answer requires that you recognize that you have not.

Would you like the long answer?

I virtually slapped your face.  Please forgive me!  

Now, what can I,   I, help you with understanding what you want to apply your knowledge to DO?

[banksey255]

I'm sorry, but does your "RTFM" initialism, paraphrased, mean "read the manual"? If so, I have searched for a solution. The only method I could find is only valid at compile time, such as that described in the following link, but that doesn't solve my runtime problem: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019MPKSA2&l=en-US. Moreover, the LabVIEW documentation on the DAQmx Timing Property Node, like the link, only states "Right-click the Property Node and choose Select Filter from the shortcut menu to make the Property Node show only the properties supported by a particular device installed in the system or supported by all the devices installed in the system.", which, again, does not solve my problem, because I don't know what hardware my application is going to be used with.

[mcduff]

I, too, have a general purpose DAQ program where you need to read/know properties that are available. Nothing is perfect but here are a few things to try. I don't use that property myself, so I am not that familiar with it.

1. What happens if you try to read that property instead of setting it for an unsupported device? Do you get a nonsensical value or an error? That could be your indication that it is not supported.
2. Rather than using Start Task to see if there is an error, try using either Verify Task or Reserve Task. (They are located in the Advanced Task Options Pallette) You should get an error if you use an unsupported value. If you get an error you should be able to change back to the default value and possibly not have to restart your task.
3. AIConv.Rate is only supported by devices that do multiplexing. You can look at the Simultaneous Sampling Property. If true, the device is not multiplexed and no need to try and change the property.
4. For some things, you need to create a "dummy" task. I create a task just to find out things about the devices. For example, multiple devices in a single task may have different sample rate than individual devices. I create a task with those devices, check the allowed sampling rates, then clear the task. I then update the UI with allowed sample rates.

Below is a screenshot of my general purpose program where properties are read, no manuals required.

[mcduff]

Below is part of an example where some DAQ device reported an incorrect gain setting. 

So I would just try to set all the gain settings and see if they work, below is the loop that does that.

[JÞB]

---

@banksey255 wrote:

I'm sorry, but does your "RTFM" initialism, paraphrased, mean "read the manual"? If so, I have searched for a solution. The only method I could find is only valid at compile time, such as that described in the following link, but that doesn't solve my runtime problem: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019MPKSA2&l=en-US. Moreover, the LabVIEW documentation on the DAQmx Timing Property Node, like the link, only states "Right-click the Property Node and choose Select Filter from the shortcut menu to make the Property Node show only the properties supported by a particular device installed in the system or supported by all the devices installed in the system.", which, again, does not solve my problem, because I don't know what hardware my application is going to be used with.

---

Unfortunately,  sometimes,  when we RTFM, we actually find out.  It won't work!

Then we go back to the drawing board or, watch Willie E. Coyote chase the Road Runner again.

[banksey255 · Accepted solution]

Thanks, mcduff. It's cool to see someone else develop a general data acquisition application as well.

I found a solution by working out how LabVIEW filters the attributes shown in the DAQmx property nodes, which I'll come back to below, but regarding your suggestions (for reference, it was an NI USB-6008 that broke my code):

1. No, the value I got reading the attribute didn't appear nonsensical, at least to me. It reported 48 khz, which is greater than the 10 khz aggregate maximum sample rate, but since it must always be greater or equal to the sample rate, it didn't seem crazy.
2. Even reading the value and then writing it back caused the error (that is, it appears there is no way to reset this attribute from the LabVIEW DAQmx interface, albeit it appears it is possible from the c and .NET DAQmx APIs).
3. Yeah, it was already part of my code reading whether the device supports simultaneous sampling, which the USB-6008 doesn't, yet it doesn't support the AIConv.Rate attribute, which is what broke my code.
4. Yeah, your suggestion of a dummy task is more or less conceptually what I wrote in my original post, which is what seemed like the only solution initially.

As mentioned, I developed a solution by analysing how LabVIEW filters the list of attributes it shows in a property node. I've attached a VI for LabVIEW 2019 demonstrating it as I'm sure working code is worth a thousand words. It shows the fundamentals, which will hopefully help others if they are faced with the same problem.

[mcduff]

Impressive. Can't say I can follow all the DLL's, a bit above my pay grade. But thanks for posting, will be useful in future once I can follow it.

About this

• Even reading the value and then writing it back caused the error (that is, it appears there is no way to reset this attribute from the LabVIEW DAQmx interface, albeit it appears it is possible from the c and .NET DAQmx APIs).

Rather than try to write the original value back, try setting it to its default value; that should work for an unsupported value and allow you to correct for any errors.

No little triangles

EDIT: Setting it back to default value works for me when I use the FileWriteSize Property in a Log And Read mode, not Log Only mode. (The FileWriteSize is a good metric for large sample rates, ie 10MSa/s or so.)

[mcduff]

Had some time to do a quick check with a virtual 6008. Task starts without errors after resetting value to default. See snippet below.

I had highlight execution on and wanted to see errors after verifying, you can decide whether to check again in production code.

[banksey255]

Thanks again, mcduff. After all these years I had never ventured into that part of the shortcut menu and wasn't aware of the "Change To" > "Default Value" option. I tested it and verified that it indeed appears to be an alternative solution.