9237 can't read physical channel names

[kent.wedeking]

I'm trying to programmatically read physical channel names out of a DAQMx task.  I'm using a cDAQ, two 9221 modules, and a 9237 module.  Everything works when I only use the 9221s, but when I try to read the names off the 9237 it errors out with error code -201087 and states:

Task contains physical channels on one or more devices that require you to specify the Sample Clock Rate.

Specify a Sample Clock Rate.

I have specified a sample rate, with no luck.  I still get the same error.  Has anyone else run into this problem?

[Brad_K]

Hi kent.wedeking,

The text for that error message is not 100% complete: in addition to setting the SampClk.Rate property, you also have to set the SampTimingType property to Sample Clock. The standard way of doing this is to call DAQmx Timing (Sample Clock).vi, which sets several related properties: SampTimingType, SampQuant.SampPerChan, SampQuant.SampMode, SampClk.ActiveEdge, SampClk.Rate, and SampClk.Src. The equivalent function in ANSI C is DAQmxCfgSampClkTiming(), and in .NET it's myTask.Timing.ConfigureSampleClock().

Brad

[kent.wedeking]

I'm not getting any love out of your response ... that does make absolute sense, but its not working.  I'm still getting the same error, whether i use DAQMx Timing.vi or property nodes ... any other suggestions?

[Brad_K]

Could you post some code that shows what you're doing?

Brad

[Kyle_A.]

Hi Kent,

First, please verify that you are selecting a sample rate within the specified range of your NI 9237 Module.  Please reference the link below:

Valid Sampling Rates for the NI 9233, NI 9234,and NI 9237

If you are using a property node to read the physical channel names off of the task, be sure you are reading after you specify the timing in your code.  Also, if you are using global virtual channels to read your physical channel names, and not a task, the default sample rate is On Demand, and thus would cause this error.  The 9237 does not have support for a clock rate of On Demand timing.  The simple workaround for this is to create a dummy task and specify the clock rate in the task as either finite or continous.

Finally, posting your code will help our efforts in finding a resolution to your issue.  Thank you.

[icebear]

Hi Kyle, Kent

I have this same behavior and continue to see it even if I create a copy of the task and set the timing properties. I've copied all of the initialization from the acquisition vi to make sure I didn't miss anything.  I, too, use global virtual channels, in this case I am trying to tie a virtual channel string name back to the actual physical device name (look up).  Hardware is also a 9237.  Thanks -Stefan

[Kyle_A.]

Hi icebear,

Are you setting timing properties before or after your DAQmx Timing.vi?  What rate are you sampling at?  If you do not use a global virtual channel, do you still see the error? 

[icebear]

My apologies, I was able to "re-write" the code on another machine and it worked fine.  It turned out to be a simple wiring mistake in referencing the channel rather than the task in the loop/property node read.  Thank you for your help.