Prior to run my DAQ software, the application checks which Global Virtual Channels are present in the system in order to prepare the tasks I need to run.
So far using various cDAQ modules I did not run into any problem. Typically the code in question looks like this:
Now, when the Global Virtual Channel (GVC) is a channel on either NI 9435 or NI 9229 I get the following error:
Error -201087 occurred at Property Node DAQmx Channel (arg 1)
Task contains physical channels on one or more devices that require you to specify the Sample Clock rate.
Use the Sample Clock Timing function/VI to specify a Sample Clock rate.
Task Name: Volt_Test
So I don't quite understand what is going on here.... Why does it ask for a clock rate, as I am just checking properties of the GVC ?
After trying a few things in vain, I decided to give it what it asked for by adding the sample clock setting...
... and the error is gone. But that does not really make sense.... I should not have to set a bogus clock rate to obtain soem channel properties...
It looks somewhat similar to this old post...
Virtual cDAQ 9178 with NI 9435 ( accelerometers) and NI 9229 ( 4 simultaneous AIs)
Any way to not have to use the sample clock setting ??
From what I have found, using this DAQmx Channel property node with the read properties that you have specified forces the Global Virtual Channel to go to the "Verified" state. In order to go into the Verified state, NI-DAQmx checks the timing, triggering, and channel attributes/properties for correctness. If there is a required timing, then this error would be triggered.
This issue seems very similar to one that has already been reported to R&D (CAR ID #196640) for further investigation, as you mentioned a current workaround would be to configure the channel timing. Thanks for the feedback!
Are you aware of any other work around with other DAQmx properties? Some modules may not work with internal timing clock, and I am trying to keep my cDAQ modules check generic.
Passing a DAQmx global channel to a property node creates a task and transitions it to the verified state before returning the property. It may also coerce the property value, as discussed in this Idea Exchange posting: http://forums.ni.com/t5/Data-Acquisition-Idea-Exchange/Importing-MAX-Input-Voltage-Configuration-int...
There is a way to access the same data without creating a DAQmx task, but it requires more code than just a property node. Export the MAX configuration to an INI file (use a .ini file extension, not .nce) and then use the configuration file VIs to retrieve the needed attributes.
This sounds like a great suggestion. I will see how to revise my code accordingly.