Why is DAQ -200714 error fatal?

[StephenB]

I'm experiencing an issue where a system that runs fine for a while, with good margin (1 kHz loop rate, 300uS PCL loop duration), suddenly throws error -200714 and shuts down. I have filter DAQ errors on, and this is performance related, so why does this shut down the system instead of incrementing HP count?

Thanks,

The error explanation is "Acquisition has stopped because the driver could not transfer the data from the device to the computer memory fast enough. This was caused by computer system limitations.

Reduce your sample clock rate, the number of channels in the task, or the number of programs your computer is executing concurrently."

[WireWeaver]

Hi Stephen,

What version of VeriStand are you seeing this on?

Also, does the error call out a source or specific DAQ channel? Any information about the DAQ configuration on this system may be helpful. Are you using Slow Background Conversion Mode?

Thanks,

Trent

[StephenB]

• NI VeriStand 2015
• Hardware is a PXI-8110 in a PXI-1045 chassis.
• Error points to PXI1Slot18 which is a PXI-6225 which I'm reading 64 channels from. Conversion rate is set to maximum
• Not using slow background convert
• I've attached my sysdef, but deleted out everything but the hardware as I cannot share beyond that
  • Note I left in 1 hardware custom device, the NI-Switch Relay device: https://decibel.ni.com/content/docs/DOC-19072

So yeah, it would be nice to know

1. Why the error is being thrown (which I hope the above answers help)
   and
2. Why is the error fatal (which is independent of my additional information here)

I can tolerate the error if it is not fatal

[Jarrod_S.]

We will have to see if this error is recoverable from a DAQ perspective. The VeriStand engine in 2015 will instruct the DAQ driver to convert late errors to warnings for the single point tasks if specified by the user. It appears this error is not processed as such by the DAQ driver. I am curious if the DAQ task can recover from this error. If for some reason it cannot, then the VeriStand engine can't really ignore the error.

[StephenB]

Any word from DAQ?

[WireWeaver · Accepted solution]

Hi Stephen,

The reason you're getting this error is because the program isn't keeping up with the sample clock.

I recreated this (external to VeriStand) by running the HW-Timed Single Point LabVIEW shipping example and increasing the rate until I got this error. I actually got Error -209802 a few times before getting -200714. The first error is recoverable and I was able to ignore it and continue, the second stops execution when it's thrown. 

Error -209802:

"DAQmx Wait for Next Sample Clock detected one or more missed sample clocks since the last call to Wait for Next Sample Clock which indicates that your program is not keeping up with the sample clock.

To remove this error, slow down the sample clock, or else change your application so that it can keep up with the sample clock. Alternatively, consider setting the Convert Errors to Warnings property to true and then handling the warning case appropriately."

Error -200714:

"Acquisition has stopped because the driver could not transfer the data from the device to the computer memory fast enough. This was caused by computer system limitations.

Reduce your sample clock rate, the number of channels in the task, or the number of programs your computer is executing concurrently."

Based off what Jarrod mentioned above, the initial error would be filtered out by VeriStand judging by the blue highlighted portion of the first error. I suspect that error -200714 is fatal because of the red highlighted portion above; the acquisition has stopped.

If you monitor the DAQ Error System Channel, do you see Error -209802 as well? Does slowing down the PCL rate resolve these errors?

Hope this helps!

Trent

[Thør]

I don't mean to dig up this old thread, but I remember reading somewhere a while ago that one of the newer DAQmx drivers can now successfully recover from this error (and subsequently the "filter DAQ errors" option in VeriStand becomes truly useful).  Is there a version of DAQmx out there that can continue with acquisition after error -200714 is converted to a warning, and actually recover from running late?