run a vi in separate while loop, minimize flashing of window

[RavensFan]

Those VI properties exist in two places.  One in the right click VI setup menu of the subVI on the main diagram.  The other is in the VI properties Window apppearance section within the subVI itself.  You need to change your settings there because it is set so show when called, and close after done if originally closed.

If you want finer control over when the subVI shows the front panel or not, look in the examples for property nodes using VI server.  Look for an example called "Front Panel States.vi"

[MinerHokieRamp]

RavensFan,

The requirement from the users is to toggle between two states: (1) subVI executing and subVI panel visible, and (2) subVI not executing and subVI panel invisible. My original post title was probably misleading as well. When I said '....minimize' flashing of window' I meant how to make the flashing less annoying instead of 'minimize' the window.

What you're suggesting (deselect 'close if previously closed' in VI properties window appearance) is option #2 in my original post. In that case, the VI toggles between run and stop but the window is always open. I think that would be acceptable for this initial version of the code if the user could easily determine if the subVI is running or not running. It's not so easy for me to discern the difference when I sit right in front of the screen. A small indicator that blinks to indicate that the subVI is running (not so annoying as the entire window-blink with the other option) would help the operator know when the subVI is actively requesting status.

I'll look for the example VIs you mentioned when I'm at work tomorrow. Thanks.

Any idea what's going on with that spastic string combo box on the main VI, during execution?

Thanks,

---

@RavensFan wrote:

Those VI properties exist in two places.  One in the right click VI setup menu of the subVI on the main diagram.  The other is in the VI properties Window apppearance section within the subVI itself.  You need to change your settings there because it is set so show when called, and close after done if originally closed.

If you want finer control over when the subVI shows the front panel or not, look in the examples for property nodes using VI server.  Look for an example called "Front Panel States.vi"

---

[RavensFan · Accepted solution]

You can't have your cake and eat it too.  You can't have it open and close every second, and not flash.  You can't leave your window open if that is too confusing.

I said if you want finer control over your subVI appearance, then look at the examples.  You need to figure out your logic as to when the window should open, when it should close, when is it "running", when is it "idle".

As for your combo box.  I don't see any problems with it.  It doesn't act spastic for me.

[Yamaeda]

---

@MinerHokieRamp wrote:

RavensFan,

The requirement from the users is to toggle between two states: (1) subVI executing and subVI panel visible, and (2) subVI not executing and subVI panel invisible. My original post title was probably misleading as well. When I said '....minimize' flashing of window' I meant how to make the flashing less annoying instead of 'minimize' the window.

---

You can open and close the sub-vi's panel from the main program through Invoke nodes. Thus if you have a boolean button to toggle running the sub-vi it can open the front panel, and close it when turned off.

/Y

[MinerHokieRamp · Accepted solution]

---

@RavensFan wrote:

You can't have your cake and eat it too.  You can't have it open and close every second, and not flash.  You can't leave your window open if that is too confusing.

I said if you want finer control over your subVI appearance, then look at the examples.  You need to figure out your logic as to when the window should open, when it should close, when is it "running", when is it "idle".

As for your combo box.  I don't see any problems with it.  It doesn't act spastic for me.

---

Used FP:STATE for the subVI and used a shift register in the secondary while loop to prevent setting of FP:STATE before the subVI is called. It now works acceptably for a first release.

Thanks,

[MinerHokieRamp]

FP:STATE means FRONT PANEL STATE. 🐵

[MinerHokieRamp]

No problems with the solution so far, thanks to RavensFan.

I'm working on another project but when I return to this one to implement users' requested changes, etc., I'd like to change the state machine to make it easier for those maintaining the code in the future to understand: I'd like to make the state names = cluster controls' labels or captions.

I figured the solution would involve a property node of the cluster within the 'home state' case.  Instead of converting the cluster to an array and scanning the array for an array index = True, how would I output a string to the 'next state' that's the chosen control's label or caption?

I've had problems with unwanted changes in control indices when I relocate controls in the cluster; I'd also like to stop that if possible.

I'm trying to acquire a LV license on my office PC so I can explore these types of questions on my own without having to trek out to the lab and post questions like this before trying something. The 11 year old laptop (XP with LV 7) I have at home (where I created the example posted in this thread) is a pain to use.

Regards,

[Yamaeda]

---

@MinerHokieRamp wrote:

I'm working on another project but when I return to this one to implement users' requested changes, etc., I'd like to change the state machine to make it easier for those maintaining the code in the future to understand: I'd like to make the state names = cluster controls' labels or captions.

It has to be Labels, as captions can be changed during run time. 

I figured the solution would involve a property node of the cluster within the 'home state' case.  Instead of converting the cluster to an array and scanning the array for an array index = True, how would I output a string to the 'next state' that's the chosen control's label or caption?

 You can either get a clusters ref[] property and scan through the cluster items label properties, or use a cluster to array of variant (through variant to data) and get Variant data to get label.

I've had problems with unwanted changes in control indices when I relocate controls in the cluster; I'd also like to stop that if possible.

 Have the cluster as type def, and only do small changes before comitting (apply changes). It's no guarantee, but usually works.

---

/Y

[MinerHokieRamp]

---

@Yamaeda wrote:

---

 You can either get a clusters ref[] property and scan through the cluster items label properties, or use a cluster to array of variant (through variant to data) and get Variant data to get label.

 Have the cluster as type def, and only do small changes before comitting (apply changes). It's no guarantee, but usually works.

---

/Y

---

I'll try it. Thanks.

[MinerHokieRamp]

If I make the state machine work with states = cluster control labels, it won't matter if the index of each control changes as I move them around within the cluster. Control indices become don't cares.

Regards,