LabVIEW
Slow Producer Loop - Mulitdevice DAQ
Solved!
So I've only looked at the "CHF Loop" so far (good job with documentation 🙂 ) but the loop rate will be controlled by the slowest of:
- The 4 Read/Write nodes - I can't see if this is the case because you're using configured tasks, but essentially the sample rates of these could be slow - you're reading or writing a single value.
- The "CHF Loop" wait timer. If this is more than 1, your loop will run slower than 1kHz. The value stored on the front panel seems to be 100, which would make it run at only 10Hz (but still faster than the 2 Hz you're reporting seeing)
It seems unlikely any of the processing is taking problematic amounts of time, so I expect a problem in the task configurations for DAQmx, but I will note that you can use the "Boolean to (0,1)" node in place of your For loop and Select node. If you need DBL values, you can also add the To DBL node straight after (but it will be coerced if you connect it as it is now).
Edit: As an additional comment that won't help with your speeds, but might help remove some unnecessary elements from the BD (your choice) you don't need to wire sequential indices to Replace Array Subset (or Index Array). Just wiring the first is enough - the next will automatically be the first value plus 1. Then you can wire any non-sequential values.
It's possible I'm misunderstanding the setup (indeed, quite likely) but here I go anyway...
The 1303 appears to be a thermal block for connecting thermocouples to - this provides essentially cold-junction compensation. It doesn't read the thermocouple values as far as I can see...
As you mentioned, the 1303 mentions a 2Hz filter on V_tempout (when used with a 1102 B/C module?). However, this is as far as I can tell only the temperature of the thermistor installed in contact with the block, which is used for CJC.
If you can acquire the voltages from the thermocouples faster (as you should be able to using the NI-6239) then you can certainly just use an old V_tempout (if it is only the thermistor temperature).
Mcduff commented on the acquisition rate of the 9213 C-series module you're using in your cDAQ. This can't acquire temperatures quickly (and there's really nothing you can do about that). However, 75S/s (aggregate) can still get you about 13ms resolution if you have only one channel (multiply the time period by number of channels for more - e.g. with 5 channels you're down to 15S/s per channel, or 13.3*5 = 66.7 ms period per channel (also not simultaneous)).
Can you move the critical temperature measurements to something that's connected to the 6239 (fast device) and use only less critical temperature measurements on the slower (but perhaps more accurate?) cDAQ device? Failing that, you could slightly (not sure how much) speed up the cDAQ acquisition by opting out from some of the accuracy improving measurements, e.g. CJC updates and auto-zeroing).
@elward wrote:
mcduff,
Thanks for the reply! With your prodding, I investigated my hardware and I have NI-1303s scanning for temperature, which seems to have a time filter on the temperature out of 2Hz, which likely explains my 500ms response time. Do you know of a way to get around that filter?
There are some properties in the DAQmx Channel Property node that may have access to the filter. See below. (Note I have never messed around with any of filter properties.)
However, the filter does not control the A/D conversion so removing the filter will not speed up your acquisition, and may make your measurement worse by introducing noise, aliasing effects, etc.
Your thermometer that you are using to measure temperature, (not the digitizer), has a certain thermal inertia, that is, it takes XX seconds to respond to a temperature change. You need to find out what that time is; it is quite possible that it is over 1 ms. So before you solve your slow analog to digital conversion woes, you need to make sure you have the right sensor in place first, otherwise your measurement will still not work correctly.
mcduff
