Popup sub VI without running

[Narry723]

Sorry for late because I couldn't use LabVIEW in this past week.

I understand what I'd like to do isn't simple.

Consequently I created a simple application with Python to call each LabVIEW files.

Anyway, thanks everyone for all message!

[TomMc7.1]

I do this simple method frequently for debugging, and sometimes for modifying a Sub VI's behavior on a target machine from compiled code. 

For debugging: Put a new control & pin on the Sub VI icon and set it to "recommended".  Set the control's default to the "normal" (false) state you want.  This way, leaving the pin unconnected in your main VI lets it run the way it always has, (default mode).  I use a hidden button on the main VI that passes a true to this pin while opening it.  In the Sub VI, wire this pin to "STOP"  Yes, this stops the main VI also, but this implementation is for debugging.  The Sub VI front panel is now open and can be run when/how you want. 

For Sub VI behavior changing at runtime, expand on the above method, passing whatever parameters you want to the Sub VI when needed.  "STOP" may become 1 of many choices for this Sub VI's behavior in this implementation.  

[wiebe@CARYA]

---

@TomMc7.1 wrote:

For debugging: Put a new control & pin on the Sub VI icon and set it to "recommended".  

---

The lingo is: "Put a new control on the front panel (FP) and connect it to the connector pane (CP) and set it to "recommended"".

(I hope you're not Tom McQuillan 's new account 🙄.)

---

@TomMc7.1 wrote:

In the Sub VI, wire this pin to "STOP" . 

---

The lingo is: "In the SubVI, wire the control to the "STOP" function". "Control" could also be "control terminal" or "control's terminal".

What you say makes perfect sense, but the language might be hard to get what you're saying.

Of course, there's always an image:

@TomMc7.1 wrote:

Set the control's default to the "normal" (false) state you want.  This way, leaving the pin unconnected in your main VI lets it run the way it always has, (default mode).  I use a hidden button on the main VI that passes a true to this pin while opening it.  In the Sub VI, wire this pin to "STOP"  Yes, this stops the main VI also, but this implementation is for debugging.  The Sub VI front panel is now open and can be run when/how you want. 

---

Another option is to not connect the control to the CP.

This way, it's default when you open the project and in an executable.

But when you open the VI, change the value, it won't automatically change back. This allows you to turn on a debug mode (globally) that will stay on until you change it, or until you restart your project or build. 

[wiebe@CARYA]

---

@TomMc7.1 wrote:

I do this simple method frequently for debugging, and sometimes for modifying a Sub VI's behavior on a target machine from compiled code. 

For debugging: Put a new control & pin on the Sub VI icon and set it to "recommended".  Set the control's default to the "normal" (false) state you want.  This way, leaving the pin unconnected in your main VI lets it run the way it always has, (default mode).  I use a hidden button on the main VI that passes a true to this pin while opening it.  In the Sub VI, wire this pin to "STOP"  Yes, this stops the main VI also, but this implementation is for debugging.  The Sub VI front panel is now open and can be run when/how you want. 

For Sub VI behavior changing at runtime, expand on the above method, passing whatever parameters you want to the Sub VI when needed.  "STOP" may become 1 of many choices for this Sub VI's behavior in this implementation.  

---

I let your idea sink in a bit.

I wandered why I never do that... I finally figured I'd use a breakpoint for that.

Breakpoint would have the same effect, but a breakpoint will paused the VI. You then have the choice to abort the VI, pretty much exactly like the stop will, but optionally.

Breakpoints also have a breakpoint manager, allowing you to enable\disable them, or to remove them.

If Stop works, keep using it, but I'd give breakpoints a try.

[TomMc7.1]

Hi wiebe@CARYA,

Yes breakpoints rock in development mode, I use the method I described in compiled (built) mode on the target machines.

And yes, the technical writers I work with would reject my post for improper term usage 😂

Nope, different Tom Mc. I lost connection with my original name on NI when I changed jobs 😁

[wiebe@CARYA]

---

@TomMc7.1 wrote:

Yes breakpoints rock in development mode, I use the method I described in compiled (built) mode on the target machines.

---

Well if it works for you... I Don't recall ever going that route.

---

@TomMc7.1 wrote:

Nope, different Tom Mc. I lost connection with my original name on NI when I changed jobs 😁

---

At the rate NI's staff is changing that's actually becoming quite inconvenient. But another battle we won't win.