Mystery Error -50103

[CoastalMaineBird]

OK, I give up.  If NI's own software won't work, I don't think that mine has a chance.

Here's the code.  If the INCLUDE STRAIN switch is off, then I get 8 channels of data at 5 Hz.

If the switch is ON, I get 9 channels of data, at a 1600 Hz rate (that's how fast I can get it, display it, and loop, I guess).

 

[ben64 · Accepted solution]

Read the "understanding data rates" section (p 20-21) of the 9237 manual (attached). I think this will answer your question (but not solve your problem). It seem that 1.613 kS/s is the minimum possible sampling rate when you use the internal 12.8 MHz timebase.

You could increase the sampling clock and use a signal manipulation express VI to extract the 9201 data at an equivalent sampling rate of approximately 5 Hz.

Ben

[CoastalMaineBird]

OK thanks, Ben.

(Note to self: If all else fails, try reading the instructions). 

The 1600 Hz I was getting was apparently NOT the speed of the software loop, but the minimum speed of the device (Fs = 12.8M / 256 / N, N = 1..31). 

I would have expected an error message something to the effect of "sample rate too low for device", but they just default to the minimum and call it good.

Now I'll have to find a way to mix the two.  Since I apparently cannot have two separate tasks, maybe I can run the voltage channels at the same rate as the strain and do some averaging.

[ben64]

You can use the collector express VI in the signal manipulation palette.

Ben

[CoastalMaineBird]

OK, thanks to Ben, I have it working sensibly now that I see the restrictions on the sample rate.

Here's the code, just for the record.

I remember the number of channels BEFORE adding the strain channel, so that I have its index.

I compute the sampling rate according to the given formula:  Fs = 12800000 / 256 / N.

I chose an N of 25, giving a basic sampling rate of 2000 Hz.

I then use a chunk size of 400, to get an effective rate of 5 Hz.

 

At sample time, I read a 2-D array of 400 samples for each chan, then average those 400 to get a single value for each chan:

 

I still think it should be an error to ask for a sample rate that cannot be delivered, but it isn't, so I appreciate all the help chasing this problem. 

[KyleBryson]

Hi Steve,

It looks like you found a solution, so that's good.  There tends to be some disagreement as to whether a requested sample rate far below the minimum of a device should cause an error, but as you've discovered, it does not.  There is a timing property (SampClk.Rate) you can read back from NI-DAQmx to tell you what rate your task ended up at, if it was coerced or rounded up.

The new CompactDAQ chassis (8-slot cDAQ-9178 and 4-slot cDAQ-9174) take another approach to solving this application.  They each have 3 timing engines available for analog input tasks, so you could actually run one module at 5 Hz and the other at a rate above its minimum.  In the older cDAQ-9172, you're required to keep all of your analog input modules in the same task.  I don't know if you're looking for new hardware, or if that helps much in your case.

Regards,
Kyle

[CoastalMaineBird]

There is a timing property (SampClk.Rate) you can read back from NI-DAQmx to tell you what rate your task ended up at, if it was coerced or rounded up.

Yes, but you have to be looking for that sort of thing in order to use that property - if you're not expecting such a mismatch between what you asked for and what you got, then you wouldn't have the foresight to use that property.

And if you're going to go that far, you might as well go ahead and read the manual.

;->

Thanks. 

[CoastalMaineBird]

For the record, here is the reply from tech support:

Thank you for your
information on the behavior of this product. It is definitely not  expected
behavior, there should be an error with a requested sample rate of anything
less than about 1.6 kHz. I have filed your bug report with R&D to have this

problem fixed in a future release of DAQmx.