SubVI locks up main VI

[bmishoe]

I would prefer the loop stoppage override it, yes.  But I guess I"m missing something obvious because I thought if you write 'true' to the loop stop control, it stops the loop and anything running inside of it.

In any event - how do I achieve that behavior for this loop?

thanks again for the help

[crossrulz]

The event structure isn't going to detect changes to your indicators.  For that, you are going to need a shift register to keep track of the values and do a check for Not Equal.

Remember that EVERYTHING in your loop must complete before the loop iteration is complete.  When the iteration is complete, it checks the loop condition.

If you want the user to be able to cancel looking for data, then you need to have a timeout and handle anything that happens due to the timeout.

[bmishoe]

I don't think that's true...although not shown in the example I pasted, as the queue empties, it writes to the Val (Sgnl) property of the indicator.  If I register a value change event on said indicator, it executes when the indicator changes.  I've tested this out and it works...

[crossrulz]

---

@bmishoe wrote:

I don't think that's true...although not shown in the example I pasted, as the queue empties, it writes to the Val (Sgnl) property of the indicator.  If I register a value change event on said indicator, it executes when the indicator changes.  I've tested this out and it works...

---

But still, that sounds like a bad design.  Why do you need to cause the event?  Why not just use a case structure and execute that when you get the command?

[bmishoe]

Specifically, if there is a change on an indicator, be it T->F or F->T, I wish to light a separate 'history' indicator and keep it lit until the user manually clears it.

I suppose I could use the case structure, but that requires I read the value of the history indicator every time and then write logic around that (i.e. if not active, make active, else do nothing)...not to mention I also have to keep track of the previous value of the non-history indicator.  I admit that wouldn't be a huge deal, this way just seems easier to me.

[crossrulz]

---

@bmishoe wrote:

Specifically, if there is a change on an indicator, be it T->F or F->T, I wish to light a separate 'history' indicator and keep it lit until the user manually clears it.

I suppose I could use the case structure, but that requires I read the value of the history indicator every time and then write logic around that (i.e. if not active, make active, else do nothing)...not to mention I also have to keep track of the previous value of the non-history indicator.  I admit that wouldn't be a huge deal, this way just seems easier to me.

---

But each time you write to the Value (Signaling) property, the event is thrown.  It doesn't matter if the data changed or not.  So you really want to keep it yourself anyways.

[bmishoe]

that is a good point...I hadn't considered that.  The logic to light up the history indicator as part of the case structure would be easy enough for sure...