03-27-2006 03:38 AM
03-28-2006 02:32 AM
Hi Kevin,
could you please post all your vi's onto the forums, not just the top level one.
When we've been talking directly you included a error bitmap showing that you was getting an error condition out of the vi at some point, saying
It appears that the system is not able to transfer data from the buffer memory on the DAQ device into PC memory fast enough. The reasons could be that the sampling rate is too high, too many channels are sampled from (you can verify if these are the causes by lowering the sampling rate and channel count to see if the same error occurs), or the system is trying to perform a time-consuming task in the background (try to close out unnecessary applications).
This can happen after an indeterminate period of time, and is a system limitation - can you lower the acquisition rate, and see if that causes the error?
You're currently set for 800 samples / second and this is software timed, so if you're hitting the default and waiting for 500ms, then this will cause a jitter in what's going on, and you're passing a larger than required 0-1500 into the counter duty cycle input which should be 0-1. (pulse period / cycle period)
You could try putting a 0ms wait into the loop, to make sure that for a tiny period of time the code isn't actually doing anything.
PID benchmarking that we have runs around 30kHz, which divides down rapidly as more channels get involved, so with the additional code you have in the loop you may be simply trying to run faster than the hardware is capable of.
Is this code running headless on the RT target, or through the LabVIEW development environment (which will be taking up extra processing time)?
Thanks
Sacha Emery
National Instruments (UK)
03-28-2006 10:08 AM
Hi,
As per the e-mail you've just sent me - you've got it working headless after removing the error cluster from between the ai and the ctr out, so any errors on the ai now won't propagate to the ctr task.
You will still however need to capture for that situation, and restart the analog input task if you want it to continue running correctly.
Thanks
Sacha Emery
Nationa lnstuments (UK)