Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

cDAQ 9189 disconnections, DAQxReadDigitalLines error

Hello Everyone,

 

I am Jérémy, automation engineer at Medelpharm, we are designing and manufacturing pharmaceutical tablet presses.

We are using DAQ system for acquisition (between 4 and 6 modules in function of machine options), and our software needs to be permanently connected for a permanent acquisition.

However we have trouble on some of our last machines, our software loose the connection with NI card, so the production is aborted which is not acceptable for our customers.For information, we haven't had the issue for the ten last years.

 

So I have used I/O Trace and I saw this for every disconnection :

"DAQmxReadDigitalLines error -200279" "The application is not able to keep up with the hardware acquisition".

 

If I understand right, our buffers are saturated but why only on these last machines ? (the software and configuration is exactly the same than previous ones).

 

For information we have this configuration :

- Dell Computer

- Windows 10

- Wired by ethernet

- 40kHz sampling for each channel (analog or digital)

 

Could you help me please ?

 

Thank you very much and have a nice day,

Best regards,
Jérémy

0 Kudos
Message 1 of 3
(647 Views)

It could be as simple as you're running some additional items in the background which is taking away processor time from the DAQ application and causes a slowdown.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 2 of 3
(617 Views)

So the "connection" is intact because the DAQmx driver is delivering data to your PC task buffer but your app isn't keeping up with pulling it out fast enough.

 

Since the problem only shows up on some of the recent machines and not others after many years of running successfully, I wouldn't tend to suspect a systemic slow & gradual build-up in the buffer.  I'd suspect something more like an occasional brief surge of processor demand from something else that starves your app of CPU long enough to overflow the buffer.

 

Sometimes, all you need to do to protect from these demand surges is to make your buffer bigger.  It's the same theory as reservoirs, capacitors, and emergency savings accounts.

 

Another thought is to do some further diagnostics.  I'd recommend you try *decreasing* the buffer size(s) by factors like 2, 5, 10.  Since DAQmx likes to auto-size, you may need to do some explicit buffer sizing calls to enforce the smaller size.

 

The purpose is to look at the relationship between buffer size and timing characteristics of the overflow error such as MTBF.  Systemic errors will tend to have a somewhat linear relationship between buffer size and time-to-error.  Demand-surge issues will often tend to show more scattered, random-looking patterns.

 

Making a bigger buffer might turn off the error right now, but you won't really know whether it's solved for good.  Diagnostics with smaller buffers may help you understand the root cause, giving you more reason for confidence in whatever your solution ends up being.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 3 of 3
(609 Views)