Problem: LV-program slowed down by Windows occasionally

[johanneshoer]

Hello,

ok this problem is rather a Windows-problem than a LabVIEW-problem, but maybe you can help me anyway.

The problem is the following: I have a program, which controls endurence tests on a test bench. The program has to run reliable and may not be slowed down by other tasks, so I always start LabVIEW with "abovenormal priority".

Still the program kind of freezes for 10 seconds approx. once a week, which results in a test interruption. I don't know why the program freezes - maybe Windows is doing some sh**, maybe the virus scanner causes the problem, maybe my VI has a problem.

What do you think might be the reason for the problem?

In this picture you see all the tasks which are running. Is there something which might cause the problem?

I don't know what these tasks are doing. Do I need them all?

(meIDSControlCenter is for the Meilhaus I/O-Module)

My latest workaround was to start LabVIEW with high or realtime priority - I don't know yet if that helps

The system: Win XP Professional SP 2, no network connected to the computer, 2 GB RAM, McAfee and AntiSpyware are installed and running, LabVIEW 7.1 professional, VI running in Debug-Mode, Meilhaus PCI card and ADDI DATA PCI card installed.

Please let me know if you need more information!  

[P@Anand]

Are you using while loops without time delay...? If so atleast give a time delay of 10 ms.... If not post a screen shot of your code......

[johanneshoer]

@P Anand: Of course not 🙂 The code is quite complex and a screenshot will not be very usefull. The VI consists of a producer consumer structure and when I start the program the CPU load goes to approx 50% due to quite excessive data processing. As far as I can see the RAM is not much used, in other words I have enough working memory. I have the feeling that the problem is caused by windows.

[Paul_F-MCP]

Hi,

it's quite likely that your problem is caused by a regular high priority WIndows task executing. Likely candidates are auto-updates or anti-virus. Unfortunately it's usually the case that you want these running unless the PC is stand alone and no-one ever plugs USB sticks in.

I've had similar issues recently and what I've tried to do is to program my application such that where the loop timing is not critical I build in the ability to cope with significant delays (say by allowing the acquisition to fill the DAQ buffers). Where there was a time critical task I put it in a separate timed loop running at the highest LabVIEW priority and minimised the code contained in it. In this way when another process starts using up resource my LabVIEW program prioritises the time critical bit over the rest. Of course if it runs out of processor power then it will still fall over, but it's the best solution I've been able to find without moving to Windows Real-Time and the expense/complucation that would involve.

Incidentally the PC running my application is connected to our internal network but the link through to the internet has been blocked by our IT guru. We have therefore removed the anti-virus, turned off auto-updates etc to minimise the additional processor loading.

Hope this helps

Paul

[johanneshoer]

@Paul:
Thanks for your suggestions. I have already tried to optimize the program but it will allways be time critical because it is not only controling but also regulating and if the input data has a delay then I get into trouble and the best thing what the program can do is to stop with a timeout message. Programs which occasianally take away CPU power are a real pain in the ass when you have time critical regulation.

Now I am observing all the tasks and I am waiting until that problem occurs again. I suspect the McAffe virus scanner of causing the problem... So I will either deinstall it or give this **bleep** the least priority.