Event priorities and stopping an event before it finishes

[johnsold]

Absolutely, Emergency Stop should always be hardware. Software can monitor it if you wish for convenience of the displays.

Lynn

[Will.D]

I would agree with you most of the time, but another problem arises when they wish to abort the test.  My supervisor has brought up the point that it would be best (if the safety guard is tripped or e-stop is pressed), the test is considered over, and should return to the main screen, waiting for input.  This is the same action that is desired of an "abort" button on screen...just not necessarily with safety as the first thing in mind.

What if they want to just abort the test because they realized that they forgot to use the proper coupling, or is break time (union) and they need to be there for the test, or just plain don't want to finish the test...  I see what you're saying, and all of that could be implemented with the e-stop or safety guard latch.  I guess another main reason is that in the past, some of the automated test setups here have not had the hardwired e-stop, and thus most of the operators are used to having something on screen.

[tst]

If there is a need for an abort button on the screen, there should be one, and it should do whatever it does.

In addition to this, there HAS to be an E-stop (like we said, hardware only) which will immediately do what is necessary (probably kill the power). You're right - this should NOT be used for canceling the test. When the program recognizes the E-stop was pressed, it should go to the proper mode, regardless of whether or not it is equivalent to the cancel test mode. The implementation can be done in the same way. Let's say you have a state machine with a "cancel test" state. This state could be called by recognizing an E-stop or by pressing Cancel on screen. There would probably be some differences once you enter the state (E-stop would cause a pop-up, it would log it, whatever...).

[tbob]

Lynn:  I was thinking of using a queue like a stack.  When a higher priority is detected (maybe by a notifier or something), push the next state to be executed on the queue (stack).  Go to the priority task (maybe this is defined on a second queue).  When priority task is doen, pop the queue (stack) to return to the previous operation's next state.  However, this may present a problem with instrument settings and so forth that may have been changed by a priority execution.  The entire software would have to be structured to accomodate this.  A BIG CHALLENGE....  But one that I would find interesting and fun.