04-02-2013 05:57 PM - edited 04-02-2013 06:00 PM
I'm seeing some behavior I can't quite explain in regards to a Call by Reference node and some front panel updating. I have a splash screen which calls a vi (Launch.vi) which uses the factory pattern to load in my main screen and VI hierarchy. Also on the splash screen I have a loop which simply moves a status bar so the user gets to see something pretty while everything is loading up. Problem is that the progress bar doesn't start moving until everything has been loaded up, which is less than desirable.
Here's a video of my splash screen starting up. http://screencast.com/t/awwgq7ZtlsQ You can see that it sits idly for about 5 seconds then starts spinning up. Even my version indicator doesn't get updated until everything starts moving.
This is an image of the block diagram. When I put a probe on the i terminal of the top loop, the first value I see in the probe is somewhere >600, because it's not getting updated until all the action starts on the splash screen, which is after Launch.vi does it's business I'm pretty sure. Here's a video http://screencast.com/t/oWvqSxyB
So, why? What am I overlooking? I've tried about 40 different things to get this working how I want. Everything from using Start Asynchronous Call instead of Call by Reference, updating the slider in a different loop from the calculations. Getting rid of the notifier in the top loop. etc. etc.
04-02-2013 07:07 PM
I had a similar problem recently. I just did a quick test that you can see below and it confirms my original guess:
When I execute this, I can hear the "Beep" while my very large VI is loading. Similarly to what you describe, I cannot see "Numeric" update until after the VI is fully loaded. So, my guess is that the "Open VI reference" is somehow involved with the UI thread (or this could be internal to Windows) preventing the redraw (as well as any user input) until it is done with that action.
One way to work around this problem, but I have not tested it, is to create a list of the main subVIs and load them inidividually before loading the top level VI. Once the top level VI is loaded, close all the other references. You could load them one at a time inside a "For loop" with a "Wait 1ms" in between to release the CPU to process your GUI update.
Let me know what you find out, this is interesting
04-02-2013 07:37 PM
OK Tim, that may be a problem. Did you upgrade LabVIEW Versions? Is there a defer FP updates involke node? What OS? and can you publish a knocked down version that demos the problem so we can try to duplicate it? Is there a SR number too reference?
Sorry for grilling you but, I can't think of a smoking gun here without some more info.
04-02-2013 08:07 PM
I can't speak for Tim but I tested my sample VI under LV2009 (9.0) and LV2011 (11.0), both 32 bits. They both exhibited the same behaviour of not updating the GUI until the VI was loaded but the "Beep" is definitely happening regularly during that time. There is definitely no explicit "Defer FP Update" in my code.
Running on Windows 7 Home Premium SP1 64bits.
04-02-2013 09:11 PM
@JÞB wrote:
OK Tim, that may be a problem. Did you upgrade LabVIEW Versions? Is there a defer FP updates involke node? What OS? and can you publish a knocked down version that demos the problem so we can try to duplicate it? Is there a SR number too reference?
Sorry for grilling you but, I can't think of a smoking gun here without some more info.
There's nothing like that that I can think of (obviously, or I wouldn't have posted a question), but that doesn't mean it's not there. I'll see what I can cook up and post tomorrow morning when I'm in front of LabVIEW again.
04-02-2013 09:11 PM
The classic root loop problem. The GUI and dynamic VI loading do not play nicely together. Usually you see the opposite effect, a context menu or modal dialog will stop all dynamic loading in its tracks. Here the dynamic VI is blocking the GUI.
This is a lingering problem with the rampant parallelism, anything anywhere that requires thread safety gets pushed through the UI thread.
04-02-2013 09:20 PM
@elset191 wrote:
@JÞB wrote:
OK Tim, that may be a problem. Did you upgrade LabVIEW Versions? Is there a defer FP updates involke node? What OS? and can you publish a knocked down version that demos the problem so we can try to duplicate it? Is there a SR number too reference?
Sorry for grilling you but, I can't think of a smoking gun here without some more info.
There's nothing like that that I can think of (obviously, or I wouldn't have posted a question), but that doesn't mean it's not there. I'll see what I can cook up and post tomorrow morning when I'm in front of LabVIEW again.
Looking forward to breakfast.
04-03-2013 10:23 AM
Open and run Main.vi. It calls Launcher.vi which loads Class 1 and blocks updating of the Main.vi front panel while it does it.
04-03-2013 10:51 AM - edited 04-03-2013 10:53 AM
OK, I see the trouble. Mass compile the project in the LabVIEW version you call it from or seperate source from compiled code. There seem to be a few unsaved changes that require a recompile during the loading of Launcher.vi and that is the delay you are seeing. After resaving Launcher.vi I saw no more hiccups in Main.vi's operation. You should also clean up the BD on Launcher.vi that hidden code in the for loop is fairly nasty I'm sure one of your co-workers did that unintentionally.
04-03-2013 11:05 AM
I'm seeing the same as Jeff. After I saved the VIs all issues went away.