05-11-2012 01:30 PM - edited 05-11-2012 01:30 PM
Hi,
I attached a solution using user events for stop the others loops, i don't sure if this is a good programming technique.
Best Regards,
05-11-2012 01:51 PM
@Luis_AM3C wrote:
I attached a solution using user events for stop the others loops, i don't sure if this is a good programming technique.
Why are you making your life difficult with all these dynamic events. Here's a 2 minute rewrite that does basically the same thing.
(note that the stop button should be latch action and its terminal should be inside its event case so it correctly resets when read)
05-11-2012 02:22 PM
Hi,
altenbach if you use the same event at two event structureS dont always work good.
Try the code now, first press stop and later stop 2.
Best Regards,
05-11-2012 02:47 PM
Well, that has nothing to do with my suggestion. Your problem is not caused by the use of the same event in multiple event structures.
You are placing interactive while loops inside event frames and this is ALWAYS a bad idea. Once the code is trapped inside the inner loop the outer event structure is no longer able to service events.
05-11-2012 03:04 PM
Hi,
I remember someone weigth code (with no while inside while inside event structure or weird examples, sorry) where using the same event in multiple event structures dont work. But i dont have the example right now.
Best Regards,
05-11-2012 03:13 PM
@Luis_AM3C wrote:
I remember someone weigth code (with no while inside while inside event structure or weird examples, sorry) where using the same event in multiple event structures dont work. But i dont have the example right now.
I'd like to see it. Most likely the problem is caused by something else...
05-12-2012 05:28 AM
As I see it from the picture you show, the biggest design problem you have, and the reason for the while loop with the SV not stopping is the error cluster wire.
The only way you are able to stop the top big while loop is with an error.
This error is propagated out of the while loop and into the write to SV boolean.
The write to SV will NOT do anything when a error is on the input.
That is why the boolean is never set to true. And again that is why you never stop the lower while loop with all the SV reads.
And as the rest has pointed out, you don't need the small while loop and the STOP/about vi.
Place the stop button in the top while loop, make an "OR" with the output from the first case structure, and connect the "OR" output to the stop therminal.
Make sure that when you write to the SV boolean, the error cluster going in has no error.
Place a small (10ms or 100ms) wait in the SV read while loop.
Try this, and the show us the code (vi)
05-14-2012 07:17 AM
@Luis_AM3C wrote:
Hi,
I remember someone weigth code (with no while inside while inside event structure or weird examples, sorry) where using the same event in multiple event structures dont work. But i dont have the example right now.
Best Regards,
Let me help you out a bit.
There are two situation (that I know of) that can be an issue and both of those can be handled as long as we understand what is going on.
1) Single Event registration (node) feeding multiple event structures. Like reading from queues there should only be one "reciever" of the event since one or the other will get the event. This can be avoided by using one register node for each event structure.
2) Filter events - since the first can cancel the event the second will never get it. TO handl this we must be aware the filter events are serviced in the order they were declared and knowing that static events are registered fist. So use one one filter event or be aware of the order.
But I will use multiple events for the same control when it serves my needs.
They are legal as long as you are aware of "which end the bullets comes out of".
Ben
05-14-2012 07:23 AM - edited 05-14-2012 07:33 AM
*DELETED*
Had some issues in the attached code. Sorry for posting invalid code from old discussions...
Norbert
05-14-2012 07:38 AM
Just to add something to my previous post:
I had the issue that instead of navigating to the dedicated "Shutdown" case, the Quit event stopped the machine. So maybe, i should have kept the example because we encounter issues as in the example here in the forums from time to time.
On the other hand, keeping "negative examples" is a dangerous thing....
Nevertheless, correcting the example removes the issue of hanging (for those who downloaded the example before i deleted it), but will introduce the issue that the button "is stuck" if hit in the "wrong case". So even if the general functionality is working as expected, the UI will not perform as such.....
Norbert