From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI controls are frozen on second run.

Solved!
Go to solution

I have a VI that I call within another VI. Let's call them VI-a and VI-b.

Now, when I try to run VI-a alone, it works as it is supposed to. No matter how many times I run and close it.

 

But when it is called within VI-b, it works ok for the first time and all the controls freeze up on the second call (closing and trying to open it again).

What can be the reason?

 

 

I am calling VI-a by wiring inputs to connectors in VI-b.

0 Kudos
Message 1 of 12
(3,508 Views)
Impossible to say without seeing your code. Attach the VIs or snippets of the block diagrams.
0 Kudos
Message 2 of 12
(3,505 Views)

Here's the VI-b.

 

EDIT: It's VI-a. My bad. It's connectors are connected to inputs on an event in another VI.

 

0 Kudos
Message 3 of 12
(3,488 Views)

Are these VIs part of a LabVIEW Project?  If so, zip up the whole Project and attach that.  Also, it would help for you to explain just what this code is supposed to do.  Since you are using sub-Panels, you might take a look at another recent Forum post from Glenny about sub-Panels -- it may give you some good ideas.

 

Some things to avoid (in my personal "order of badness") ...

  1. Stacked Frames.  Actually, this is so high on my list that the others are trivial in comparison.  I've never seen an example where a Stacked Frame was a Good Idea.  If you want to make a State Machine, use a Loop (While, usually, but occasionally For) and Case Statement.
  2. Tab Control.  I've used them, myself, but the general feeling is that sub-Panels (which you also use) are preferable.

 

Now that I'm writing this brief note, I realize I have a specific question -- when you are in a Tab, you clearly start some sub-VI.  What stops the sub-VI?

 

Bob Schor

0 Kudos
Message 4 of 12
(3,473 Views)

@Bob_Schor wrote:

What stops the sub-VI?


The tab change event stops the previous VI and loads a new one.

0 Kudos
Message 5 of 12
(3,461 Views)

@Bob_Schor wrote:

Also, it would help for you to explain just what this code is supposed to do.


This code is supposed to switch between tabs and loading new VIs on tab change event while closing the previously running ones.

0 Kudos
Message 6 of 12
(3,451 Views)

OK, you have a Tab Control with 7 tabs, each of which contains a Sub Panel (all of whose name is "Sub Panel" -- I was trying to figure out how you could put one Sub Panel in all 7 Tabs, and didn't realize that you had 7 identically-named Controls -- very confusing).

 

Here are some observations:

  • It is not obvious how you get the first Sub Panel populated (before any of the Tab Controls are pressed).  Is it your intent that you have to press a Tab in order to Start?
  • You never remove any VIs from their Sub Panel.
  • It is not clear if the VI References are ever properly Disposed.

Here are some thoughts:

  • You could mitigate some of the above problems (and get rid of the Stacked Sequence) by constructing a real State Machine.  You could have one State for every Tab Control.  You could also incorporate the Producer/Consumer Design Pattern (Events), so the Event loop has almost no code in it, but only puts the appropriate State ("Read from File", "Reset Tab", "Write Sys Para", etc.) on the Queue to the Consumer (Queued State Machine).
  • All of the State Parameters would be kept in Shift Registers in the State Machine.
  • One of these would be the VI Reference for whatever is running in the (single) Sub-Panel.  When you enter a Tab State, you test this Reference -- if it is not Empty, you remove the VI from the Sub Panel, Abort the VI, and Dispose the Reference (you can make a sub-VI to so this).  You then start the appropriate sub-VI running in the Sub Panel, saving its Reference in the Shift Register.
  • As part of your Exit State, you also test the Sub Panel reference and stop whatever might be running (using the sub-VI you used previously).
  • I don't recall if LabVIEW 2009 has Start Asynchronous Call, but it is much simpler to use this than setting the Control Values using VI Methods.  See my reply to Glenny in today's Forum posts.
  • So how do you get one Sub-Panel to serve all 7 Tabs?  Simple -- adjust the size of the Tab Control (in its Properties) to have a height of 1, and put it above the Sub Panel.  Alternatively, create 7 Boolean Switches, arrange them above the Sub-Panel, and make them all Latch When Released.  As yet another alternative, use a Radio Button Control for your 7 choices.  See which looks most Visually Appealing and User-Intuitive.

Bob Schor

0 Kudos
Message 7 of 12
(3,426 Views)

So, I disabled this part from the VI and my issue was resolved.

Is there anything wrong with this part?

The other case which is not visible in snapshot is for stop button value change.

0 Kudos
Message 8 of 12
(3,387 Views)

You are registering for an entire array of controls for mouse leave and enter, rather than just specific controls.

 

That doesn't make any sense.

0 Kudos
Message 9 of 12
(3,382 Views)

@RavensFan wrote:

You are registering for an entire array of controls for mouse leave and enter, rather than just specific controls.

 

That doesn't make any sense.


Can that be the reason for freezing?

The issue persists even when I make array of specific control references.

0 Kudos
Message 10 of 12
(3,357 Views)