How to alternate between 1 sample and N samples

[altenbach]

(1) I have a task consisting of one single ended AI and three differential AIs. Is this the correct way to create such a task? (see attached, LabVIEW 2010). (shoud I instead read all of them in differential mode and simply ground the second input of the ai0?)

(2) I have a slow loop where I chart the state of all four AI inputs at a leisurely rate using "4 channels, 1 sample". Occasionally, I want to do read 1000 points at a higher, hardware timed rate on demand (e.g. triggerend by a button press), then again continue with the single samples.

I came up with the attached. (It seems it was needed to insert the "stop task" functions. If I don't use them, I get fewer than 1000 samples in the array, depending on how many times the single sample case has executed in the meantime.)

Anyway, using similar code seems to cause funny behavior in the real application, for example some channels (e.g. ai1) no longer gets read correctly after a while, even thought I can confirm the presence of a voltage with a voltmenter. Resetting the device makes it work again.

This is using a USB-6211.

So, the question is: What is the correct way to implement all this?

Thanks!

[Henrik_Volkers]

No LV here, but i would configure all differential, have one task (with fixed samplerate) and just change the number of samples , commit, start task ...

The ai1 problem sounds like a missing bias path ... (first guess) or a talk over due to mux (second) or both (just to have my tree;) )

[Brad_K]

Hi altenbach,

(1) The RSE vs. differential channel creation looks fine. Textbook, even.

I see that you're using input limits of 0 V to 10 V on one channel and -10 V to 10 V on the other three. Using RSE doesn't limit you to 0 V to 10 V, since AI0 can be up to 10 V below AIGND and still be in range. The USB-6211 hardware doesn't support a 0 V to 10 V (unipolar) input range, so DAQmx will use the -10 V to 10 V (bipolar) input range instead, because that range is the smallest one that covers the input limits you specified. You can check what range it used by reading back the DAQmx Channel >> AI.Max and AI.Min properties.

(2) The DAQmx task remembers that you configured a sample clock, and it continues to use that sample clock to acquire 1000 samples, even when you do a 1Samp read. Then each 1Samp read returns the next sample from the buffer, instead of acquiring a new one. I think this explains why read returns <1000 samples, and it probably explains the funny behavior too (stale data).

To switch back to "on demand" mode, which acquires a single sample at a time, you need to set the DAQmx Timing >> SampTimingType property to "On Demand". Then you should be able to remove the calls to DAQmx Stop.

Also, calling DAQmx Read on a task that hasn't been started will automatically start the task for you and stop it afterwards. This might take more than 10 ms. You can eliminate this overhead by calling DAQmx Start outside the loop. However, you will have to stop the task before changing the value of SampTimingType, and start it again afterwards.

Brad

[altenbach]

---

@Brad K wrote:

The USB-6211 hardware doesn't support a 0 V to 10 V (unipolar) input range, so DAQmx will use the -10 V to 10 V (bipolar) input range instead, because that range is the smallest one that covers the input limits you specified.

---

Thanks Brad,

OK, that's fine. 16 bits is overkill anyway for my application, so it does not matter even with -10 to 10V. I'll set the correct range.

---

@Brad K wrote:

(2) The DAQmx task remembers that you configured a sample clock, and it continues to use that sample clock to acquire 1000 samples, even when you do a 1Samp read. Then each 1Samp read returns the next sample from the buffer, instead of acquiring a new one. I think this explains why read returns <1000 samples, and it probably explains the funny behavior too (stale data).

To switch back to "on demand" mode, which acquires a single sample at a time, you need to set the DAQmx Timing >> SampTimingType property to "On Demand". Then you should be able to remove the calls to DAQmx Stop.

Also, calling DAQmx Read on a task that hasn't been started will automatically start the task for you and stop it afterwards. This might take more than 10 ms. You can eliminate this overhead by calling DAQmx Start outside the loop. However, you will have to stop the task before changing the value of SampTimingType, and start it again afterwards.

---

OK, I am starting to understand what's going on, but I have a hard time implementing your changes. After changing the timing to "on demand", I get an internal error at the next Nchan1Sample read operation in the false case.

(currenty using a simulated device, maybe the USB-6211 is different?).

Thus I have a hard time following your suggestions. Could you make the changes in my above example and attach it for a better illustration.

[Sean_N]

I believe the attached is what Brad had in mind (at least it seems to be working on my computer).  Like he said, explicitly starting and stopping the task when needed will remove that overhead.  Hope this helps!

Thanks,

Sean

[altenbach]

Thanks, that's basically what I had last night on my laptop at home, but I kept getting errors. Since I did not have access to hardware, I used a PCI-6221 simulated device. For some reason, even your code throws an error when using the simulated device once it switches back from N samples to 1 sample and hits the single sample read in the false case.

 

I am now at work and just tested on a real PCI-6221, and the error no longer occurs. I guess there is a bug in the simulated device. Can you verify that?

I'll try it with the USB-6211 later (that's in a different room and currently in use)

I made one small modification to your code, though. Since the false case executes predominantly, I took the reconfiguration at the end of the true case so it only occurs when actually needed. Do you agree with this? (See attached).

[Sean_N]

I did verify that this error occurs, and I feel that this is a corrective action for the DAQmx drivers.  I will follow through with that.

I agree that your modification is better since it will default the task to On Demand when you don't specify the sample clock so now you don't need to stop the task at the beginning.

Thanks,

Sean

[Brad_K]

Hi altenbach,

Your modified version of Sean's VI is exactly what I had in mind. I just tried it with a PCIe-6259 and a USB-6210, both real and simulated, running on NI-DAQmx 9.3.5, and I can confirm that the error is related to simulated devices, not to the USB-621x. Both simulated devices displayed the error, and both real devices did not.

Sean, thank you for filing CAR #317154 about this problem.

Brad

[altenbach]

I implemented the changes In my real application and tested now on the correct hardware.

The software is working as expected. Thanks for all your help!

Obviously, I had some misconceptions: I originally thought that if I do a "finite sample" run, it would revert to "on demand" automatically once we have desired number of elements. 😉