cDAQ lock-up on Windows 7 when app idle.

[Ben]

I scarse few details to help fix an issue I witnessed while on-site yesterday.

A LV app running under Win 7 using a cDAQ chassis will lock-up LV if the app is left idle for a couple of hours.

WHile Idle it just grabs samples from the AI chnnels and displays same.

Attempts to open the FP of the sub-VI grabbing the samples locks-up so I was not able to check if there where hardware errors. memory was pegged out at the time.

While monitoring the app for over an hour I saw no memory leaks and did not have time to wait for three hours or more so my facts are limitied.

For the sake of this post I am only interested in finding out if others have seen cDAQ locking up when the app is idle.

I did check the power save options and disabled the power saving feature for the USB but the isue did happena again after siting idle over-night.

SO...

Has anyone seen lock-ups of cDAQ ?

Ben

PS I added some logging to catch low-level errors when it happens again.

[tst]

Not locking up, but I have seen a cDAQ constantly throwing errors after plugging in (or, more likely, unplugging) a USB flash drive (Win XP in that case) and it only stopped after the cDAQ was turned off and back on. It seems to me that there are things happening in the USB stack/driver which the cDAQ doesn't always like.

One thing you could try is looking the event log for Windows or search to see if there's a utility which would let you log USB events in the system. Assuming that's really the source of the issue (and it wouldn't shock me - your app might be stuck in the middle of a VISA call), then that might help to pinpoint it.

[Ben]

---

@tst wrote:

Not locking up, but I have seen a cDAQ constantly throwing errors after plugging in (or, more likely, unplugging) a USB flash drive (Win XP in that case) and it only stopped after the cDAQ was turned off and back on. It seems to me that there are things happening in the USB stack/driver which the cDAQ doesn't always like.

One thing you could try is looking the event log for Windows or search to see if there's a utility which would let you log USB events in the system. Assuming that's really the source of the issue (and it wouldn't shock me - your app might be stuck in the middle of a VISA call), then that might help to pinpoint it.

---

Your sense that it is USB related was confirmed by the log file.

I still have to follow-up with the customer to see if the issue is still re-occuring but the logged error indicated the buffer on the CDAQ backplne was over-flowing... NI Support found a KB article that explains that when doing highspeed I/O, and Windows going in to out of screen saver will stall the USB I/O long enough for the buffer to over-flow.

Customer was going to work with NI Support to fiddle with Windows and shut-down all of the power-saving etc options that could get in the way.

I THINK the error code was "-200361".

Take care,

Ben

[Travis_Ann_N]

Hi Ben,

The with USB devices the best thing to prevent disconnection or hang is to turn off power save setting for USB, as you mentioned. I have included a few links below that may help you with troubleshooting possible causes. 

USB Data Acquisition Frequently Asked Questions (FAQ)

USB Data Acquisition Device Not Responding

Regards,

Travis Ann

[Ben]

The first link did not have anything related to my issue.

The second link did not work for me.

Ad to your list;

"IT starts a backup that kills the CPU." (as per feed-back from the customer this morning).

Ben

[Travis_Ann_N]

Ben,

I'm sorry that link didn't work. This one should: 

USB Data Acquisition Device Not Responding

When your customer says, "IT starts a backup that kills the CPU." What exactly are they referring to? Do you have more details? Also, I read that your customer is working with NI Support on this issue. Do you know if they are making any progress towards a resolution?

Travis Ann

[Wayne.C]

Ben,

My experience has been that the USB connection to cDAQ does not like interuptions of any kind.  Auto-updates, backups and anti-virus scans are some of the worst offenders.  I usually just blame it on my GIS dept. 

[Ben]

---

@Wayne.C wrote:

Ben,

My experience has been that the USB connection to cDAQ does not like interuptions of any kind.  Auto-updates, backups and anti-virus scans are some of the worst offenders.  I usually just blame it on my GIS dept. 

---

Well I am beyond the customer blaming me and I am now trying to help them. I prpbably would not see these lock-ups with slower applications but this one is doing vibration analysis so we have the smaple rate cranked up to the max to catch the higher frequencies.

In traditional DAQ hardware I would just allocate a larger buffer but in my case it is the buffer on the cDAQ that is over-flowing....

So I have to dance fast and keep dancing.

Ben

[Wayne.C]

Ben,

Blaming the GIS dept. never worked with my boss for some reason.  Of course he's been complaining that they should pay part of my salary anyway.

I've seen this happen at some acquisition rates I didn't think were all that fast.  I ended up doing things like take the laptop pc off the network, disable the wireless radios, disable all the power saving features, sleep mode etc. and in general keep the distractions to a minimum.  I've even seen the switch from AC line to battery run on laptop upset things.

[Ben]

Thank you Wayne.

That is exactly what I was looking for when I started this thread.

Ben