The SW team says NI Forums can't help - prove them wrong!!

[tst]

---

@santo_13 wrote:

@Mark's inputs reminded me of a similar scenario where one company had scheduled a centralized backup running at midnight which took up majority of processing power and slowed down the data acquisition application.

---

And I had a case where the screen saver came on and was using up most of the CPU drawing pipes on the screen (I guess the 3D rendering was taxing it). That was tricky to debug, because we couldn't see the issue while we were playing with it and logging didn't help, because all it showed us was that the program was running slowly. It was only after we came back from lunch and saw that the issue finally manifested and then stopped when we were there that we realized that was the issue.

Something like that could probably have been caught with monitoring the CPU usage for all running processes, and I'm not sure why we didn't do that, because I'm fairly sure we did do it for our executable, and I believe extending it to monitor all running processes shouldn't have been difficult, but maybe we just didn't think of it, or maybe it did require extra permissions, etc.

[wiebe@CARYA]

Are there any non-reentrant (sub) VIs used in multiple loops?

For instance an error handling\logging VI makes sense to reuse in each loop. But if the VI is non-reentrant, it would block execution of other loops, causing the queue to pile up, causing more overhead, causing the plie to grow...

First thing I'd do is to try to speed up the problem. So, increase 2 Hz to 20 Hz (200 Hz?), and see where the bottleneck is. The first things to break are good suspects... 

I'd also (preferably after speeding up) try to see if the problem occurs if only loop 1-5 are enabled, then 1-4, 1-3, etc..

All testing will be tedious if the problem only occurs every few weeks. How would you prove the problem is gone?