Datalogging Frequency Reduced by Windows Events

[dml13]

Hi All,

I'm using LabVIEW to test communications with various instruments that my company uses. The program is designed to log one data point each second and write it to a text file. I have performed some overnight tests and found that occasionally the period between data points increases to a constant value (between two and five seconds), remains constant at that value for around an hour and then drops back down to one second. This can happen at any time of night and several times per night when I leave the computer running.

I think the delayed readings might be due to background processes running on Windows such as scheduled tasks. I've had a look at Windows event logger and plenty of tasks occurred overnight but I can't seem to find any that correspond to the times at which the datalogging slows down. 

I was wondering whether anyone has had experience with Windows processes slowing down their programs. Could you suggest which processes might be causing it and what I could do to stop it happening? Any help would be greatly appreciated.

Kind Regards,

Dan

[wiebe@CARYA]

At 1 Hz that should not really happen. Except maybe when Windows installs updates or something. Or IT pushes updates. Or virus scanner is activated. But still 1HZ should be no problem. This also depends on the hardware (CPU\memory\disk) of course.

How long does the actual measurement take?

Is it very CPU\memory\disk intensive?

If you replace the measurement with a simulated value, does it still happen?

Not sure how much we can do without some code...

[dml13]

Hi wiebe,

Thanks for your reply. When I run the program and check task manager it says it's using 4-7% CPU and 45% of physical memory. Unfortunately I can't share any code from my department (sorry, it's silly I know). What I can say is that it reads the transmitter by calling a couple of .dll functions, the sequence of which are controlled using semaphores. Do you think that could be an issue?

I'll have a go at replacing the values with simulated data. Thanks for the advice.

[wiebe@CARYA]

Are those dll's running in the user thread (are they orange)? If it's not needed (sometimes it is), they should be yellow (run in any thread). This could be a big difference, especially if the calls take a while or if they're called a lot.

I doubt Windows Event Log (there are other Windows Events, e.g. for managing user interaction) causes this. There would need to be thousands of these messages per second to bother other programs.

You could try to run Performance Monitor while measuring. This will make it easy to monitor\log CPU, memory, thread count etc. for both Windows in total, as just for any single application.

Another thought would be to look at power saving options. USB ports, HDD's, serial ports, CPU cores etc. might be turn off or tuned down after a few hours. I'd think that would compromise the measurements, but who knows.

[dml13]

The .dll's are called using invoke nodes. We create a .net object at the beginning of the program and then use invoke nodes to run its functions. The invoke node is yellow but I don't know whether invoke nodes can be non-reentrant anyway. 

I'll check out performance monitor and have a look at power saving too. Thanks for recommending these.

[dml13]

By the way, I ran the same labview program on my personal laptop last night instead of the computer on the rig we're using and it run with no issues. My laptop is 64 bit and the rig computer is 32 bit but that's the only difference I can think of.

[wiebe@CARYA]

---

wrote:

The .dll's are called using invoke nodes. We create a .net object at the beginning of the program and then use invoke nodes to run its functions. The invoke node is yellow but I don't know whether invoke nodes can be non-reentrant anyway. 

---

That's not applicable for .net or ActiveX dll's, only for Call Library Function Nodes (CLFN).

[wiebe@CARYA]

---

wrote:

By the way, I ran the same labview program on my personal laptop last night instead of the computer on the rig we're using and it run with no issues. 

---

Spooky things happen on rigs... Not sure why, but the harsh environment somehow seems to effect software.

On rigs they often use virtualisation. The desktop you're seeing is sometimes just a thin terminal to a server. That server might be shared by other desktops. I'm not sure if that is applicable to your situation. I've had my software run on a virtual desktop. The PC was a 24 core CPU with 12 GB ram. Still wasn't nice to find out it was shared by some SQL Server and accompanying undefined software. Some things are spec'd to the detail, but software is still the wild west.

[wiebe@CARYA]

Maybe Windows Indexing serves is the bad guy?  It might take hours, isn't normally scheduled and will use lots of CPU and Disk bandwidth.

[dml13]

I'll see whether it's running it the background and have a word with our IT people to see if the computer is just a terminal. Cheers again for your help.