Labview running slow for set period randomly throughout the day

[Bazk73]

Hi guys,

I have a very strange issue and maybe someone here has experienced similar issues and maybe help to point me in the right direction as I have very little LabVIEW knowledge and any help will be much appreciated.

So for the past 7/8 years we have been using LabView 2013 SP1 32-bit as part of our automated testing system, there are 2 test stations that supply a defined voltage to our product and we require an LED count, pattern matches and some OCR readings. Over 2 years ago randomly the 2 executable LabVIEW programs started running slow for approximately 45 to 50 minutes no more than that and then just start running normal again (Normal test time is 45 seconds and when its running slow it can be anything up to 120/145 seconds). This slow period can happen at any time over a 24 hour period. 

In January this year there was a fire in the same department as the automated testing system, no damage was done at all to the testing system but there was down time for a week when some rewiring was been complete. When we got back up and running after the week the issue with running slow for the 45 to 50 minute period seemed to be gone. It ran as normal for 9 weeks and then the running slow started happening again and continues to do so today. The issue may not be LabView related and maybe running normal after the fire was a coincidence but I am all out of ideas and maybe someone here can point me in the right direction. Thanks for taking the time to read this,

BK

[crossrulz]

Things to look at:

Updates being pushed by the network

Antivirus software

Other network traffic

Whatever else could be taking away resources

My guess would be the network to those computers was down for the 9 weeks where everything worked well.

[altenbach]

Some good guesses already!

I assume that you did not write the LabVIEW code. Do you know who did? Are these people still around? Do you have the source code?

• How regular is the rate when it is slow and when it is fast. How do you measure it.
• Does everything work correctly under both states, with timing the only difference?
• Are both always running slow at the same time?
• Are the two program otherwise identical, just running on a different PC? Do they communicate with each other, with other devices, with other servers?
• Can you give an outline of the entire system topology. What's is connected to what? What communicates with what? etc.

[rolfk]

My guess:

- Antivirus running. These can have a huge impact. In the past Norton and Semantec Antivirus had more than once the tendency to pretty much monopolize the computer.

- Network backup: Have had that at a customer years ago. Always around noon, the whole systems would get slow as snails for half an hour to one hour. Turned out IT was running a full backup every day.

Both could be not running or not as strongly when the network to the IT servers is down and that might explain the disappearance of the issue after that fire as the network infrastructure may not have been reconfigured to match new hardware and/or network layout.

[N_743]

Just throwing out a slightest possible stuff and sharing my experience:

Got a brand new sbRIO-9638 plugged it into a brand new laptop, used USB connection. When attempting to install software and on this new sbRIO, it took up to hours. Connected sbRIO to labview project, everything slowed down drastically each operation taking up to a minute. Repeated everything on a desktop PC it all worked fine with no issue.

After a month long support ticket, it turned that USB port my laptop (and other laptops in general) were not supplying enough current required for sbRIO-9638 to function properly. I was told that it requires slightly higher current to function properly. Thus, it was dropping connection and attempting to reconnect over USB which extended time.This could be monitored using Wireshark. Currently I use an externally powered usb hub.

Considering the fire situation and re-wiring, I would want to monitor network activity, just to cross out one possibility of network connection being dropped out continuously.