LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Spooky: Front panel has lost control of the block-diagram code

Solved!
Go to solution

I have a LabVIEW program (Win7-64b LabVIEW 14.0 32bit ) which behaves a bit spooky.

 

On some occasions, while the LabVIEW program is running, suddenly the front panel controls are no longer read by the block-diagram process. So this is what I see:

  • The program runs, processes data and updates the indicators as expected.
  • The run button is switched to no-run mode even though the program continues to run.
  • The red abort button is not functional - push has no effect.
  • The block diagram can be debugged, single stepped and breakpoints taken.
  • The front panel controls are not read and the program cannot be stopped as it relies on front panel action for this to happen. 
  • The run button is non functional in the sense that it can be pressed into run-mode, but it has no apparent effect on the state of the already running block diagram.
  • The only way to stop the program is by closing the front panel. 
  • The behaviour happens at random times, is annoyingly frequent, but not enough (frequent) to make debugging by code elimination efficient.

The program is a state-machine construction using queued messages and accesses cRIO hardware via shared variables.

I know this information is rather sparse with respect to debug suggestions, but any ideas in what direction to search are welcome.

 

0 Kudos
Message 1 of 8
(3,381 Views)

Are you using an event structure? And if so are you generating an event by value signaling anywhere in the code? That caused a similar issue with me once.

PaulG.

LabVIEW versions 5.0 - 2020

“All programmers are optimists”
― Frederick P. Brooks Jr.
Message 2 of 8
(3,360 Views)

Hello PaulG,

Thanks for your reply. I use an event structure with "value change" event handlers, but no property node signalling. This is what you refer to I suppose...

signal by value.png

0 Kudos
Message 3 of 8
(3,350 Views)
Solution
Accepted by topic author heel

Some of this could possibly be explained by things like the UI being locked by an event structure or the defer updates property being set on the panel or being stuck in a DLL call, but there is one more option which seems to at least somewhat match your description: https://lavag.org/topic/17049-windows-aero-theme-and-lockup/?p=104728

 

When I saw it it was in an EXE, so I can't comment on things like run arrows, but it was definitely a case where the VI was definitely running and updating the UI, but wasn't receiving updates from the UI.


___________________
Try to take over the world!
Message 4 of 8
(3,301 Views)

I have no custom DLL call's, nor a defer front panel property in the code.

But it is a very useful hint about the theme. The symptoms described in the link above are very similar to what I see.

I have changed from the Default Win7 (Aero) theme, to the Windows 7 Basic theme. The Basic theme is not part of the alleged buggy Aero theme family.

The program is running nicely, but it will have to be tested a bit more before I can declare the problem for circumvented, because it also ran for extended period's before, but failed at random instants. I will report back.

0 Kudos
Message 5 of 8
(3,273 Views)

The program has been running now for two days, and has not failed a single time after the desktop theme was changed to Win7 Basic. It is very promising and if it ever fails in a similar way again, I will report back. But for now the problem is considered solved until the opposite is proved.

Thanks for the good help.

0 Kudos
Message 6 of 8
(3,196 Views)

I've seen this also, but only in connection with faulty RT deploys.  I had VIs which were NOT running but LV thought they were and showed them as reserved while others definitely WERE running but LV didn't agree and showed them as not reserved.

 

I tried once to set a probe on a VI which was shown as running but wasn't really.  Of course I loaded LabVIEW again after the crash......

0 Kudos
Message 7 of 8
(3,183 Views)

The error described has been present in my program since the beginning - nothing has cured the problem completely - the error happens at irregular intervals.

 

New is however I had a version where I could provoke the error every time the program was started.

The only change was the addition of an indicator to the error output of a shared variable. The result was like this:

 
xxx.png

 

It should be added that the network shared variable had deployment warnings - in both cases.

As the code is in constant operation and relies on attached cRIO HW it is not so easy to experiment with it and I did not try to minimize the code to make debugging more simple.

0 Kudos
Message 8 of 8
(2,783 Views)