Irregular Loop Iteration Problem

[Chickentree]

Hello,

I have developed a large program with many actors running in parallel.

One of the actors has a timed loop containing XNET Read. The period is set at 500 ms.

Occasionally, the iteration is delayed and XNET Read queue overflow happens.

I made it suppress the overflow error while keeping a counter on it.

I noticed that overflow happens frequently when I click things on the UI.

Dragging scroll bars seems to be the worst offender.

Overflow happens when I leave it alone, too. I haven't figured out any definite pattern yet.

I'm aware of the Execution Priority and Preferred Execution System settings, but I haven't used them.

How would you resolve this irregular loop iteration problem?

I use LabVIEW 2018 with TestStand 2017 API.

Windows 7 Pro is the OS.

Any tips will be much appreciated!

[JÞB]

---

@Chickentree wrote:

Hello.......

I'm aware of the Execution Priority and Preferred Execution System settings, but I haven't used them.

---

Won't matter.  Timed Loops operate in their own execution systems with a special priority 

---

@Chickentree wrote:

Hello,

I have developed a large program with many actors running in parallel.

One of the actors has a timed loop containing XNET Read. The period is set at 500 ms.

Occasionally, the iteration is delayed and XNET Read queue overflow happens.

I made it suppress the overflow error while keeping a counter on it.

I noticed that overflow happens frequently when I click things on the UI.

Dragging scroll bars seems to be the worst offender.

......

How would you resolve this irregular loop iteration problem?

Any tips will be much appreciated!

---

I'd lock the dam front panel and stop letting Users hog the high priority single threaded UI Thread when the software is doing anything more important than satisfying the user's itch to doodle with the mouse!  Perhaps even provide negative feedback like Rick-Rolling when the mouse move event queues multiple times (Actually firing a tazer to incapacitate the user is optional)

It's a test system not an amusement park ride! Let it do its job controling hadware!

[Chickentree]

Is there any way to not allow the UI Thread to interfere with other important loops?

The technician will periodically check how the test is running.

Also, the PC is normally connected to the internet.

Have you seen any issue with forced Windows updates and such in the background?

The tester needs to stay on the internet since it is remotely controlled and monitored, too.

Ultimately, do I have to look into Real-Time solutions?

[Mark_Yedinak]

---

@Chickentree wrote:

Is there any way to not allow the UI Thread to interfere with other important loops?

The technician will periodically check how the test is running.

Also, the PC is normally connected to the internet.

Have you seen any issue with forced Windows updates and such in the background?

The tester needs to stay on the internet since it is remotely controlled and monitored, too.

Ultimately, do I have to look into Real-Time solutions?

---

If your 500ms period is a hard timing requirement, then yes, you will need a RT solution for reading the data. Can you read the data more frequently to prevent the buffer overflow? Is the device streaming data or are you polling and need to get the data precisely every 500 ms?

[Chickentree]

Since I'm using XNET Read (Signal XY), collected data doesn't depend on the polling rate.

I could use 200 ms, but it's a bit involved since 500 ms interval is intertwined with other parts of the program.

If 500 ms was being delayed to 800 ms, would 200 ms be delayed to much less than 800 ms under the same circumstances?

If that is the case, it would definitely be worth trying to reduce the loop period.

I'm still surprised that touching the UI can interrupt some loop iteration that much.

[JÞB]

---

@Chickentree wrote:

Is there any way to not allow the UI Thread to interfere with other important loops?

---

Yes, detask the UI Thread. 

Ensure there is nothing in the timed loop that switches to the UI Thread (hand off any UI updates to queues or channel wires)  one of the more common mistakes is to append to a Chart inside the timed loop.  That means the TL execution system has to switch to the UI Thread and wait for it to become available then execute the UI Update and switch back.  Obviously, you don't want to do that!

Do not allow splitter movement or resize events after start of execution

Use Defer FP update when needed.

---

@Chickentree wrote:

The technician will periodically check how the test is running.

Also, the PC is normally connected to the internet

Should be no problem unless the Technician is downloading porn or playing online games.

---

@Chickentree wrote:

Have you seen any issue with forced Windows updates and such in the background?

---

Yes, I have! It's a real PITA when IT reboots your test machine.  You need a policy for your test systems.

RT is a nice option but really shines when you can go "headless" I doubt your use case is that exacting.  Just remember that computers are designed to be responsive to user interaction and take steps to limit the burden on the UI Thread.

[Chickentree]

Thank you for the tips! I can try to minimize or remove any use of the UI Thread from the XNET Read loop.

I can easily move the CAN Rx Status cluster update out of the loop since it can be done in the Actor Core main loop through messaging.

Would it be important to get rid of the CAN Rx Session property node, too? That would be a bit more involved, and I wonder if reading would be much less of a burden than updating. But then, the loop will still have to use the UI Thread.

[JÞB · Accepted solution]

Pass in the session value on a notifier and you have an easy UI Thread free session value you can update anywhere 

Or even toss a value change event sentinel on it and stop the timed loop if it's invalid by name using stop named timed loop.... probably what I'd do as it takes the business logic up to an executive level manager code module rather than leaving the decision in the worker code.

[Chickentree]

I can see that the performance has improved significantly. Thank you!