03-13-2015 11:23 AM - edited 03-13-2015 11:26 AM
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 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.
Solved! Go to Solution.
03-13-2015 12:01 PM
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.
03-13-2015 12:23 PM
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...
03-15-2015 07:07 AM
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.
03-15-2015 04:40 PM - edited 03-15-2015 04:43 PM
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.
03-17-2015 10:38 AM
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.
03-17-2015 11:40 AM
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......
03-20-2017 10:05 AM - edited 03-20-2017 10:07 AM
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:
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.