Wait on Front Panel Activity crashes labview?

[msoflaherty]

I have a program in Labview 2018 that does system monitoring and control.

It's driven by an event structure in a while loop, with front panel events being handled by the event structure to execute requested actions. There's then a timeout on the event structure of 1000ms, so if no user activity happens, it automatically triggers a background read to keep the displayed data up-to-date.

All this is great, but because those background scans are a bit slow, a user actively trying to work with the system can find it a bit sluggish, so i put a button that allows the user to disable background scanning while they work. But, what if the user forgets to re-enable it? Oh dear.

So I'd like the system to keep track of front panel activity, and re-enable the background scans after 10 minutes of activity.

I added the little bit of code attached, but now my program intermittently crashes about once a day. Disable it, and the problem goes away.
Does anyone know what might be the problem?

The only other event handled is a stop button, to exit the loop when the program terminates.
The false case of the case structure is empty.

[msoflaherty]

I should probably clarify that other than crashing, it does exactly what it's intended to do, but sadly the stability is more important.

[altenbach]

The wait for FP activity is a relic from the ancient times where the event structure was not available. Would be hard to find the cause of the crash, though. Something NI would need to investigate. Did you submit the crash reports?

Can you explain the rest of the code architecture?

Couldn't you just count how many times the timeout case has executed in a row by incrementing a counter that would reset in all other even cases? (or just measure the elapsed time, resetting in the other event cases?)

[msoflaherty]

Hi altenbach. Unfortunately the computer is on a secure network with no internet access, so i can't submit any crash reports. That said, I don't immediately seem to have any to submit - it appears to take down the whole OS, not just labview - the entire computer appears to have rebooted.

The rest of the code is pretty elaborate, and does a lot of things. It's communicating with several serial and network devices, logging things to file, and maintaining a website. This part of the code ought to be relatively isolated from that all, though, but I do wonder if having event structures waiting on FP activity and the 'Wait On FP Activity' block don't get along nicely.

I appreciate the suggestion for using a counter, but the timeout case triggers other cases (via signalling property node writes), and those would be indistinguishable from user triggers (unless in every case I added code to check the event source, which would be a fair bit of work). So it's not as easy as counting how many consecutive timeouts occurred.

[altenbach]

Have you tried to put the wait for fp activity in it's own parallel loop?

[msoflaherty]

They are in independent parallel loops. The wait for FP activity is in the code in the first post - that's all it does. On 10" timeout, it resets a couple of local variables.

[altenbach]

No, that code also has an event structure.

[msoflaherty]

Oh, right! Sorry, i see what you mean.  That's a good point, I'd had it in the event structure so that the user clicking 'stop' would break the loop, but I can implement that by checking the stop button after it returns. I'll implement that and see if it helps, though it might be a few more days before I can report back with a verdict.

Thanks for the suggestion. 🙂

[johntrich1971]

---

@msoflaherty wrote:

I have a program in Labview 2018 that does system monitoring and control.

It's driven by an event structure in a while loop, with front panel events being handled by the event structure to execute requested actions. There's then a timeout on the event structure of 1000ms, so if no user activity happens, it automatically triggers a background read to keep the displayed data up-to-date.

All this is great, but because those background scans are a bit slow, a user actively trying to work with the system can find it a bit sluggish, so i put a button that allows the user to disable background scanning while they work. But, what if the user forgets to re-enable it? Oh dear.

---

I think that you are trying to solve the wrong problem. The problem is that the background scans are causing the system to be sluggish. I'm guessing that you are doing the background scans inside the event structure. If so then the background scan has to complete before the event structure will move on, and if these are slow and you're doing them once every second then you will definitely slow down the system. Why not use the event structure to trigger the background scan, but let the background scan occur in another loop? This would allow the UI to run in parallel to the background scans. It's generally not good practice to put operations other than trivial calculations/updates inside the event structure.

[msoflaherty]

Good suggestion john, but delegating actions to a parallel loop is indeed what happens. Most of the events the system performs, though, are commands to set and monitor a very slow serial system, which can only be working on one thing at a time. If the user tries to change a setpoint, it has to wait for the background read to complete before that action can begin - even though it's in a different parallel loop. Events that don't use the same resources are plenty responsive.