Event priorities and stopping an event before it finishes

[Will.D]

I have an event structure that handles a number of unrelated events.  I was wondering if it were somehow possible to set event priority...  As in, one event is running, but the user clicks on a more important event, and the other event stops, and the more important event is run.  I realize this could cause a lot of problems with some programs, but it wouldn't be anything but helpful in mine.

Failing that, is there a way to abandon an event during its execution, say, in the event of a safety guard being opened?  I currently have this done via a loop running parallel to the event structure's loop, but all that does is detect and shut off all equipment, but the event still has to complete, even if it just runs through a bunch of "false" or "error" cases.

Thanks for any help

[johnsold]

I am not sure I understand completely what you are asking. Do you have Lock front panel until event case completes checked? That can make the front panel appear unresponsive.

If one of your controls is a button Start Process 1 and Process 1 runs for a long time (minutes or hours), then rather than running Process 1 inside the event case for the Start button, have it run as a parallel process with commands and data passed via queues or LV2 globals. The event case for the Start button only feed the command into the queue and then exits. Then the higher priority events can still take place and a command (like Stop) can be sent.

Lynn

[tbob]

To take Lynn's suggestion one step further, use a state machine architecture inside your parallel loop.  The first loop will contain only the event structure to capture events, like user pushing a button, emergency shutdown, etc...  Inside the event case, send a state string to the queue.  You can even set up a priority number.  Inside the second loop, put your state machine (dequeue element and send the element to the question mark of a case structure).  Within each case, your code will have to periodically test to see if a higher priority function is on the queue (you can preview the queue without dequeing).  Then you could queue the higher priority one up and then exit your current case.  To return to the spot you left off will be quite difficult.  Perhaps your code for each state can be another state machine with another queue.  When you leave one case to service a higher priority, you would push the next state onto the second queue, finish the current state, then exit.  Then when you return, you could dequeue and resume with the state that was supposed to be next.  State machines within a state machine.  Sounds complex.  I like that.

[Will.D]

Sounds almost like the beginnings of an OS!

Thanks for the suggestions guys.  Just to clear things up though, I didn't have "Lock Front Panel..." checked, since I generally try not to use that feature (emergency stop needs to be accessable). 

I'll play around with your suggestions, but I'm not sure the size of my project really warrants that much complexity.  Maybe I'll try to put together a better worded request and post it on the wish list...

Thanks again

[johnsold]

tbob's state machines within state machines could get quite complex. However, a basic state machine is not very complex and can be very powerful, robust, and easy to maintain. I recommend you learn about them; they could well become your best (programming) friend.

Lynn

[tbob]

State machines within a state machine....  Hmmmm.....  Anybody up for a challange???  Yes it would be very complex.  But just think of what you could do with this.  Interrupt one state to service another, then return to where you left off.  Yeah it does sound like an OS.  Isn't this what a HSM (Hierarchial State Machine) is all about.  There was this guy that was pushing his HSM software here on this board at one time....  Might want to do a search on Google on Hierarchial State Machines, and see if his code is worth while.  I looked at it once and found it to be very very complex.  I had no need for it so I dropped it.  But this could be what you are looking for.

[tst]

One other thing - if your emergency stop is a real emergency stop, you should have it implemented in your hardware. Personally, I think that it's preferable to have a real E-stop button near the terminal than on the screen itself, because no matter how much you play with LV's options, your program can still become unresponsive, for whatever reason.

Oh, and it's called LabHSM. Haven't tested it myself, but it looks interesting.

Message Edited by tst on 07-21-2005 10:08 AM

[Will.D]

Well as it is, the test stand is well designed, and there is a saftey latch that responds either to a physical button press (very close to the monitor), and if the safety guard is opened.  It cuts all power to the equipment being tested (all connected within the safety guard). 

It just looks a little weird to have things still going on on screen when everything else is stopped.  It's less about actual saftey as it is about trying not to confuse an operator...

[johnsold]

That is a good approach. If you monitor the safety circuit from LV, then when it goes into safety shutdown, have a dialog pop up notifying the user. By the time the user has responded to the dialog, your state machine should have had enough time to also respond and change the user interface status.

tbob, I spent my entire commute home last night and back to work this morning trying to figure out how to handle a prioritized queue. It does sound like a challenge! Do you continually rebuild the queue or maintain an array of queues, or a circular buffer in an LV2 global, or, ... or, ...? How many priority levels? How to encode them? Very interesting!!!

Lynn

[tst]

I was refering to what you said about "Lock FP...".

It seemed that you didn't want to lock the FP so that the operator could press the E-stop on the screen. As far as I know, FP locking is only relevant to user input, so if you don't have an E-stop on the screen you can lock the FP and still indicate to the user that E-stop was pressed.

Just to make sure - I think that an E-stop button on the screen itself is a bad idea - if the operator needs to use it, he\she should automatically go for the hardware one.