LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Splash Screen Issues

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.

 

Main_BD.png

 

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.

--
Tim Elsey
Certified LabVIEW Architect
0 Kudos
Message 1 of 33
(1,447 Views)

I had a similar problem recently.  I just did a quick test that you can see below and it confirms my original guess:

Loops.png

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

0 Kudos
Message 2 of 33
(1,427 Views)

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.

Scientists STAND on the shoulders of giants! They don't ride "piggyback" to keep their heads down.

"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 33
(1,422 Views)

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.

 

0 Kudos
Message 4 of 33
(1,418 Views)

@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.

--
Tim Elsey
Certified LabVIEW Architect
0 Kudos
Message 5 of 33
(1,404 Views)

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.

Message 6 of 33
(1,403 Views)

@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.

Scientists STAND on the shoulders of giants! They don't ride "piggyback" to keep their heads down.

"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 33
(1,399 Views)

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. 

--
Tim Elsey
Certified LabVIEW Architect
0 Kudos
Message 8 of 33
(1,361 Views)

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 nastySmiley Wink  I'm sure one of your co-workers did that unintentionally.

Scientists STAND on the shoulders of giants! They don't ride "piggyback" to keep their heads down.

"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 33
(1,353 Views)

I'm seeing the same as Jeff.  After I saved the VIs all issues went away.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 10 of 33
(1,343 Views)