-200284: Samples Have Not Been Acquired - Hardware Issue?

[StuartLamb]

I am attempting to diagnose the error above which is occurring intermittently on an analogue acquisition VI used for a multipurpose test cell. The VI runs with no problems during most tests, but will occasionally throw this error during a test which produces higher shock and vibration. It had been infrequent for a number of months but is now happening during every test and causing disruption.

When the error occurs, attempting to stop and restart the tasks result in the same error appearing immediately. The only resolution I've found so far is to hard reset the cDAQ chassis. In the past the issue wouldn't crop up again for a few weeks, but recently this approach just gets the VI to run again up until the vibration level increases. 

The hardware is a cDAQ-9178 chassis with the following modules: NI 9205, NI 9375, 2x NI 9237, 3x NI 9230, NI 9212. I have checked for loose connections both in the power supply and USB, although if one of these opened I would expect a different error of the 'hardware unavailable' type. There are various analogue input transducers attached (10V, 4-20mA, mV, IEPE) and one encoder connected to the cDAQ BNC ports. Typically 15-20 channels are in use during a test. 

I have attempted to physically isolate the chassis from any vibration and it should now be low, Although potentially above the 0.3g_rms maximum in the unit specifications which is fairly low. There are limits to what is possible with the existing hardware and cell configuration. If vibration is the most likely cause then I can invest in further changes but would first like to rule out any alternative causes. 

The VI is hardware timed, continuous sampling at 10kHz per channel and reading 1k samples per loop iteration. The DAQmx Read timeout is set to 0.3s but I have tried increasing this to 1s with no change. I've also tried manually increasing the input buffer. For the encoder there is a counter task which shares and is start triggered by the main AI task clock, which is using the on-board cDAQ clock.

Running these tests requires equipment and personnel with limited availability, so I've had very little time to play around with different hardware/VI set ups. Hoping to put together a diagnostic plan for next time a window comes around.

Any advice is much appreciated

[StuartLamb]

Today I was able to perform some testing and narrow down the problem.

Firstly, vibration does not appear to be a contributing factor. The error occurred while the machinery was spooling up - the VI was acquiring pressure and rotational speed data but the vibration had not yet started.

Secondly, the error is related to the counter task, as when I disable it the error does not occur. My guess is that it is in some way related to the shared clock between the two tasks. The code for sharing and triggering is below.

To investigate further, I added a case structure to specifically clear error -200284 from the counter task if it occurred. I wondered if this might result in counter data stopping but the VI continuing to run. However, I still got the timeout error after a few minutes so the source must be the AI DAQmx Read. 

The counter task is used for an incremental rotary encoder (Kubler KIH40). The A and B channels are connected to the PFI ports on the cDAQ chassis. 

[StuartLamb]

A further update and correction to the above. The counter read task is the source of the error, I had mistakenly updated the code in the wrong case structure instance. So it appears that while running the counter task looses its connection to the sample clock.

My next test will be to monitor the encoder output on an analogue channel during operation to see if there is anything unusual. I also have a spare NI-9423 DI module so I can try using that to access the chassis counters instead of the PFI ports.