Event structure doesn't fire

[Ben]

IN LV 2015 this VI

Will hang if the event registration for the first event is set to "Defer FP ... unitl completes"

It works fine if that first node is NOT configured to "defer ...until completes.

I understand what you are saying about "recomended" etc. I have read all of those notes.

The point I am trying to make is the first event is failing to re-enable FP activity.

Ben

Edit:

The fist loop is configured for a value change on the start and the second is configured for a value change on the Stop.

[Ben]

Now for another insight....

Change the latch action to "Switch when pressed" prevents the lock-up. So the example as originally posted was actually trigger two events, one when pressed and a second when LV forced it back to the default state. Since the first loop was terminating and preventing the second event to be serviced, the FP should have been disabled and it not a bug.

So now the questions are:

SHOULD the start button returing to its default state trigger a "value change" event?????

SHOULD the numeric indicator continue to update when teh FP is defered?????

Please enlighten us.

Ben

[GerdW]

Hi Pavel,

late, but for suggestion:

I didn't understand how to employ it with shift registers.

That's a shame! 😄

Shift registers (and their counterpart "feedback nodes") are so important in LabVIEW, you really should learn to use them!

[Ben]

OK I educated myself.

The boolean returing to false when I release the button is generating a second unhandled event.

The indicators will update when the FP is locked.

So ....

Using that latch action to terminate a loop with and event structure is "Bad Bad Bad".

Ben

[Ben]

I am not completely happy with my explanation above.

There is something odd going on because removing the second loop and event structure does not lock up.

I am perplexed.

Ben

Edit:

I think I got it. The return to deult is generating a second event that is never handeled.

The beter way to work with that latch action is to check for the button going false.

The adventure was fun!

This would make for a nice Certification question;

Will this VI hang?

a) Yes

b) no

C) Depends on the latch action of the button

[Pavel_47]

---

@Norbert_B wrote:

Pavel,

you can get rid of the "parallel case" by simply modifying the timeout time and get the code (increment and display) into the timeout case.

Do something like this:

Do NOT forget to set timeout back to -1 in any event case which stops the timeout!

Norbert

---

Norbert,

Your solution works perfectly except one detail: value increments each second (approximately) whereas timeout is 0.1 sec.

Any ideas ?

Regards

Pavel

[crossrulz]

You need to show more decimal places in your indicator.  The accuracy of your display is 0.1 when you are incrementing by 0.01, giving the illusion of incrementing at a tenth the rate.

[Pavel_47]

---

@crossrulz wrote:

You need to show more decimal places in your indicator.  The accuracy of your display is 0.1 when you are incrementing by 0.01, giving the illusion of incrementing at a tenth the rate.

---

Of course ! I'm getting tired.

Thanks.

[Pavel_47]

---

@GerdW wrote:

Hi Pavel,

late, but for suggestion:

I didn't understand how to employ it with shift registers.

That's a shame! 😄

Shift registers (and their counterpart "feedback nodes") are so important in LabVIEW, you really should learn to use them!

---

Thanks GerdW,

I've checked your solution, works perfectly.

Concerning shift registers ... sure I've already used them, but havn't yet really conceived their "omnipotence".

Regards

Pavel

[nathand]

---

@Ben wrote:

I think I got it. The return to deult is generating a second event that is never handeled.

The beter way to work with that latch action is to check for the button going false.

---

Ben - I'm having trouble following your explanation. A boolean with a latching action only generates one event when clicked. Also, latching actions aren't compatible with local variables, and your image shows local variables. Did you mean "Switch while pressed" actions?

Of course, if you're using a latching action, the terminal should be inside the event case that handles it, so that the terminal gets read and the button resets.