Labview SubVI to keep previous control values

[gy10c]

---

@paul_cardinale wrote:

Like this.

---

Thanks for your VIs, I am actually wondering how I should use the shift register.

[altenbach]

Actually, I used a feedback node... Same difference. 😉

[gy10c]

Thanks for the suggestion!

For example if I need a "Set" button to trigger a code when click.

Can you comment on why I should not use the "mouse up" event? If use the "value change" it will need additional case structure, isn't the "mouse up" will be more straight forward?

[altenbach]

---

@gy10c wrote:

If use the "value change" it will need additional case structure, ...

---

Why would you need an additional case structure??? (I used a case structure to avoid a second event case, but there are many other ways, of course).

If the boolean is connected somewhere, You want the new boolean value when the event fires. If the event fires on a mouse-down, the boolean might still read the stale value from the terminal, especially for "latch when released" booleans.

Mouse-up/down event trigger even if the control is disabled of even if it's an indicator. You want to fire when the button changes value. That's the most logical condition!

Always make sure that latch action terminals are inside their respective event cases so they properly reset when read by the code.

[gy10c]

Thanks, you are right!

For the value change event:

If the button is set as "latch when released", there is no problem and I think this is the usual case to use a button to trigger a event.

But there maybe problem if the button is set as "Switch until release", in this case single click will trigger two value change event since the value change twice.

Can you comment on why the latch when released option does not trigger the value change event twice?

VI attached.

[RavensFan]

---

@gy10c wrote:

"

---

@RavensFan wrote:

---

@gy10c wrote:

Hi,

I have attached the simplified VIs.

---

WARNING!!!!  Don't run those VI's.  I ran the VI and it proceeded to lock up those windows.  I couldn't abort or close any windows.

---

This is not my problem. If you set the VI property to be "show front panel when called" AND your subvi is opened when you run the main vi, it will lock. To unlock, right click the vi icon in the windows taskbar, then close, then labview will close everything and allow you to save.

---

I didn't say that was your problem.  But it is a problem for me and for anyone else who tried to help you by testing your VI.  It is a warning that executing your VI's caused my LabVIEW environment to lock up.  I did have both front panels opened because I had both VI's open to inspect their block diagrams before running them.

I'm just warning others they will have the same issue I had.

[gy10c]

---

@RavensFan wrote:

---

@gy10c wrote:

"

---

@RavensFan wrote:

---

@gy10c wrote:

Hi,

I have attached the simplified VIs.

---

WARNING!!!!  Don't run those VI's.  I ran the VI and it proceeded to lock up those windows.  I couldn't abort or close any windows.

---

This is not my problem. If you set the VI property to be "show front panel when called" AND your subvi is opened when you run the main vi, it will lock. To unlock, right click the vi icon in the windows taskbar, then close, then labview will close everything and allow you to save.

---

I didn't say that was your problem.  But it is a problem for me and for anyone else who tried to help you by testing your VI.  It is a warning that executing your VI's caused my LabVIEW environment to lock up.  I did have both front panels opened because I had both VI's open to inspect their block diagrams before running them.

I'm just warning others they will have the same issue I had.

---

Is this problem a normal behavior of labview, or it is a bug?

[altenbach]

---

@gy10c wrote:
Is this problem a normal behavior of labview, or it is a bug?

---

It is normal. That's why I placed a reminder on the front panel to close the subVI before running.

(There are probably some mitigations that could be implemented, e.g. automatically close the front panel of all modal subVIs when the toplevel is run. Not sure if there is an idea already...)

[altenbach]

---

@gy10c wrote:

But there maybe problem if the button is set as "Switch until release", in this case single click will trigger two value change event since the value change twice.

Can you comment on why the latch when released option does not trigger the value change event twice?

---

A "switch until released" boolean is a special case and rarely used (except if you want to implement a car horn or similar ;)) It is very unreliable in a polling VI, because the state might be missed if the press is short and the loop rate slow. It is correct to trigger two events, because there are two value change events cause by the users. One on "press" and one on "release".

Latch action reset when read by the code. That's not the same. Only one user interaction happens. Only one event is fired.

Trust me, a lot of thought went into all these designs and the implementation is the most logical.

[altenbach]

---

@altenbach wrote:

---

@gy10c wrote:
Is this problem a normal behavior of labview, or it is a bug?

---

It is normal. That's why I placed a reminder on the front panel to close the subVI before running.

(There are probably some mitigations that could be implemented, e.g. automatically close the front panel of all modal subVIs when the toplevel is run. Not sure if there is an idea already...)

---

Actually, there are quite a lot of related ideas. Look at all the links in this idea, for example.