Virtual controls vs hardwired

[Money4Nothing 0]

What is the general consensus on what type of functions are appropriate for control via virtual pushbuttons on an HMI sceen or should remain hardwired to plc (or other controller type) inputs? I am in disagreement with some at my company about what is appropriate. There are certain critical control functions that we cannot risk being accidentally activated by someone bumping an HMI panel, yet also require a very fast response to human input. It made me think of what types of controls would you never put on a virtual pushbutton on an HMI or Scada device. Some believe that all critial control features that should be protected from accidental activation should be hardwired to introduce a physical, mechanical element into the process of activation. Maybe this type of protection can be implemented in logic in some applications? Obviously E-stops (which should be independent of a control system anyway) are an exception....but I'm talking about hardwired PLC inputs vs virtual. For example, I've never seen a hellfire missle launch enable switch in a jet fighter cockpit on a touch sceen button, its always a toggle switch with a mechanical safety. But I've seen a radar countermeasure activated by a touch sceen control. I'm sure that very few of us are desining control systems for such critical functions, but I'm curious about the prevailing philosophies on this matter. Thanks. $

[TERdON 9]

It's very unusual that we use hardwired switches at all. The only exceptions I can think of are 1) emergency stops and emergency stop reset switches (required by law to be hardwired), 2) switches added not for physical security instead of programmed ones, but in addition to programmed ones, for addded convenience on behalf of the operators (very frequently used functions etc), and finally 3) mehanical switches on a portable remote radio control. Frankly, I don't think it's a good idea to mount an HMI so the operator is able to touch it be mistake at all, regardless if the inputs make potentially dangerous actions happen. The place you choose to mount it on shouldn't be chosen that way... The one reason you mention that seem reasonable is that some of the functions require very fast input. Normally, you have several different screens in an HMI. It WILL require some time to switch screens. If you can't live with that time (perhaps even as much as 10 seconds depending on navigation layout and operator training), you'll obviously have to make a hardwired input, instead of or in addition to the HMI ones.

[Ken Moore 23]

With the exception of E-stops all inputs are soft. If it is time critical, we put the same "button" on every screen. Then, no matter which screen is active, the critical input is there if needed.

[IO_Rack 181]

We use physical push buttons for our more frequently used functions such as 'Start', 'Process Stop', and 'Reset'. The reason for this is to alleviate the ware and tear on the HMI. As for your concern, our less used functions that we do not wish to be accidently activated, we will generally not allow during automatic (running) operation or program a slight delay into it. You say it requires a 'fast response' so I'm not sure this would be acceptable for you.

[TConnolly 13]

What buttons are required to render the machine to a safe state (for both operator, process, and equipment) should the HMI fail? Sometimes this is just a E-Stop. Sometimes it involves much more than that. In additon to the E-Stop I usually have at least a (non emergency) process stop button and open or jog buttons to operate the machinery.

[Chris Elston 79]

My take is anything that I need to run the machine WITHOUT the HMI, I make a hardwire button. This normally means I put a Power On, (white, hardware e-stop ok), E-stop button, Cycle Start (software input green), Cycle Stop, (software input red), and a Reset (software input blue) on the panel. So if the HMI dies, you can still run the machine without the HMI. Start and Stop the machine. I've been in situations before where this came in handy. I don't know if it works in all cases, but works for us.

[TimWilborne 108]

All buttons except Estop, Cycle Start, and Cycle Stop on on the touchscreen here. Estop because it should be hardwired. The Cycle buttons so they don't wear a hole in the touchscreen

[Beuwolf_1 0]

We also hardwire all safety circuits as well, plus any manual overides that may need to be cycled if there should be a controller fault that would prevent the operator from initializing the machine that needed to be cleared prior to the fault reset. Any buttons that are continuously hit are hard wired, as well as any controls located in a hostile environment that require frequent changes.

[IO_Rack 181]

That is a very good point. We use that rule as well. It eluded me when I was writing my first post. That is the reason we always wire a Start, Stop, and Reset. Although it seems more and more each day we are becoming more dependent on the HMI's. Data collection has become part of our documented process for example. Also we are programming machine setups by HMI. If the HMI breaks then the operator could continue to run but could not set the machine for a different product. I didn't mension E-Stop as this is generally a given.... and the law.

[Keith Menges 0]

While I tend to break my own rule, I try to keep selected jog functions hardwired. It is too easy to slip off of an HMI-based jog button while you are looking at the axis you are jogging. I say 'selected' because trying to put all the jog buttons in hardware will tend to add alot of buttons. I have thought about doing an axis select on the HMI and having a single jog pushbutton but I think that would get a little confusing. Outside of that and e-stops, everything goes on the HMI. Keith

[TimWilborne 108]

We can't make our machines run without an HMI because of parameter entry so what we do is pair machines up in the plant. If an HMI breaks on one, the other machines HMI can be used to enter parameters for both machines. It has been tested and works in theory but I can't say how it works in a real application. We have never broke an HMI (knocking on wood)

[IO_Rack 181]

We had an operator [sarcasm]accidentally[/sarcasm] put a fist into one.

[GerryM 2]

Same here! You could see the knuckle prints in it. What pissed me off is no one even got as much as a hand slap for it. The Area Manager was a big wuss. Usually, most of my HMI's are for recipe changing, display info. or maint. functions. Everything else is hardwired.

[TimWilborne 108]

Not here. HMIs are too cheap to bother tearing up. Had an operator ram a crane through a panel containing a Controllogix Plc. Busted the plastic on the power supply and buckled the chassis. Surprisingly it continued to work until 4 of July shutdown when we replaced the panel, power supply and chassis. I should have sent it back to AB, they would have been proud. We had to straighten the chassis out before we could pull the modules out Edited 3 May 2006 by TWControls

[BobLfoot 302]

Put me on board with the keep the critical to run functions hardwired. {Start, Stop, etc} I must also ask though no one mentioned Safety PLC's which I now believe allow E-Stops to be incorporated into a software , be it not hmi platform.

[OkiePC 14]

Any function that could cause dangerous motion should be hardwired. How many of you have expereinced "Stuck Button Syndrome" because of communication delays when using a momentary PB control on an HMI? http://forums.mrplc.com/index.php?showtopic=7661

[Groo 7]

If you don't want to accidently press buttons, then its usually a safe option to make certain critical buttons a two button process, i.e. with a question are you sure and a different button to press. I remember once when I worked for Heinz, the sauce batching tank was controlled from a Siemens WF470 graphic station. These old systems used to have the keyboard directly into the PLC via normal I/O and the screens driven by special cards. On heavily used systems the screen would sometimes be slow in changing pages and one day an operator pressed a button to change screen, the screen delayed for anything up to 3/4 seconds before changing so the operator pressed the button again!!! because the keyboard was now set up for the new page, the change screen button had a new function ------ DUMP TANK Yes that was changed to a two button option, ARE YOU SURE....

[OkiePC 14]

So what happens when the operator presses the YES, I'M SURE touch cell, and the appropriate bit has a one written to it in the PLC. Then the comms goes dead. There is still a one in that PLC address. You must be able to supply an alternate method to stop dangerous or potentially destructive processes that are started via comms channels. Watching the communication status won't work either. Sometimes a packet gets lost or rejected due to noise and guess what, it was the packet that contained a write 0 to turn off a momentary pushbutton. I have seen it with every AB product I have ever worked with, and read about it with many many others. My practice is to use a time limit on momentary buttons in the PLC. Then, if the operator needs to JOG something with a touchscreen for more than my time limit, He/She will have to release the button and hit it again. A very small price to pay for safety. I try to use other controls besides momentary pushbuttons when possible. A maintained button in the HMI that is unlatched in the PLC is my favorite for one shot type operations, like recipe downloading or other selections. On DH+ and RIO connected HMI platforms, I use the communication error bits to CLeaR momentary pushbutton addresses in the PLC. Those status bits are pretty quick responding to problems. Making sure the buttons are ignored during screen changes is a separate matter entirely. Using global buttons that do the same thing on every screen is the easiest way, and there are other methods when that's impossible. Paul Edited 10 May 2006 by OkiePC

[Groo 7]

Ah that's easy, the YES, I'M SURE button is a different button, so when the screen eventually changed the operator would gulp and press the NO key. The keys only set the bits when pressed and the PLC resets it and sets the bit that brings up the question, which only resets on yes/no or changing screen again, therefore its altready on. As far stopping dangerous processes etc, that's why you maintain the hard wired E-Stop. Having said that, on my current job, the whole safety system is contolled from safety PLC's (PILZ) where the E-Stops and guard switches wire direct into the PILZ I/O cards which are linked to the processor via profibus. They also have ASi safety systems available, so the whole safety thing is turning upside down now and no longer seem required to be totally hard-wired.