“Been there, done that,” – besides just being a great t-shirt logo, there is a lot of truth in seeking wisdom from those who can claim they’ve been there and done that. In this “System Integrators Talk” segment, we queried our System Integrators Group on LinkedIn with a question on HMIs, and gathered their collective wisdom into one beneficial post. Learn more about how to get started on your HMI projects.
We asked our LinkedIn System Integrators Group…
What do you think are the biggest “gotcha” moments when designing an HMI project?
Here is a bullet list of some great takeaways from this conversation. Note: If you have the time, you should read the in-depth posts below for more details. These guys have a lot of experience and really gave some great responses.
- Before you get too fancy, first hook up your HMI to your PLC and make sure that you have your communications working. If it’s not working, then the best HMI design will not matter.
- Talk to the actual operators. After all, if they are the ones using it, they are probably the ones who would have valuable input on how to optimize it.
- Watch the operators use your screens, and see if certain things are giving them trouble. Sometimes you will notice things that operators forget to tell you.
- Consider where the panel will be located. Observe its proximity to the user, as well as the angle of the screen.
- Remember that certain colors and symbols mean different things in different parts of the world. Red doesn’t always mean STOP.
- Make sure that your HMI design gives the operator feedback as they use it. For example, if they push a button… make it change so they know that they pushed it.
- Make sure that messages that may be displayed on the HMI are correct and clear.
- Make sure that you have a well-defined scope that includes colors, alarms and screen examples before designing your panels. Get key people to sign off on your defined scope. This could save you a lot of rework and keep you from the dreaded scope creep.
For more details read the comments below…
Brian Gallogly the President of Quantum Automation…
First – get the communications taken care of – wire it up to the PLC, configure a pushbutton and make a Discrete Output point turn on, then put a potentiometer to an Analog Input point and have a bar go up and down on the screen. The worst gotcha is when you’ve done all the work but you can’t get it to communicate.
Second – Talk to the person who will be operating the machine or process and get input from them as to how they would like the look and feel of the screens. Not talking to the ultimate operator can cause for multiple re-do’s of the screens. Get the customer to sign off on the scope of work as to what the screens will look like, colors, alarms – who to email or text and when, reports – look and content, etc. before getting started. If you have example screens that have been printed out and put in a binder to show them, it cuts the time down tremendously.
Third – Having a spreadsheet of all the I/O with Engineering Units and Hi and Low Alarm limits on all the Analogs really saves time….especially if you get your customer to sign off on the finalized spreadsheet prior to you configuring the screens.
Glenn Erickson the President at Expert Automation Design Inc…
Brian’s input is very valid. If I was to add anything, watch the various operators use the touch screen and look for hesitation. If the operator is hesitating then they are not sure what to push or where to go. Ask them why they are hesitating and find a way to make the use of the screens more natural or intuitive.
Also, watch the operators eyes. If they are squinting, then the font or the text-size is inadequate or the contrast between the desired information and the background is too low.
I have found that a dark blue or light grey overall screen background are the most practical to use. Also, avoid the fancy pushbutton effects. They tend to obscure the text and function of the pushbutton.
Remember that 8% of all human males are color-blind in some combination of colors (Typically red and green.) Design your screens so that the change-of-state of a button or lamp is as dramatic as possible so that the user can be assured of the change in state, regardless of the colors they are actually seeing.
When displaying numerical or text data, I prefer a bright color like green in a black background surrounded by a frame that looks like a meter-face.
Be aware that different cultures often use different colors to indicate the state of a bit. Here in the U.S. we use green for ON and gray for OFF. In Europe, they use RED for ON and GREEN for OFF! So when developing screens for a customer in a different culture, ask for sample screens of another system they use that they like and imitate them.
Steve Myres, the Owner of Automation Control Solutions LLC…
I second what Brian says about prototyping various types of controls, especially when working with a new HMI or PLC or both. I’ve been called into customers who drew hundreds of controls on many screens, but didn’t check to make sure they understood how to configure one before copying. It was easier to toss everything they had done and start over copying one working element than it would have been to make the corrections hundreds of times. That’s what you avoid when you create and test one control before making all of them for the entire app.
Brian Woodley, a Control Strategy Specialist at Innotech Industrial Innovation Inc…
I think you’ve all covered the important points, well written. I always took the time to ensure my units and jargon were correct for the operators, the spatial layouts were accurate from the touch screen station viewpoint, and any cycle descriptions were accurate and truthful. Here’s some minor additions to the list. Some are merely preferences, and doubtless most of you have your own ways of dealing with them.
I make sure to understand the exact location of the screen in relation to the view of the associated equipment and plan any animations or physical layouts accordingly. Pay attention to the scale and relative position of the equipment from that perspective, so when the operator looks up from the screen, it’s a clean metaphor of what’s in front of them. This forms an instant connection with the process and builds trust in the screen and what it is displaying. Graphical designs work great this way. I’ve seen so many text-based screens that operators learn to despise, as they are so disconnected from the process. Like looking at a spreadsheet instead of a dynamic operation.
I try not to put something on the screen or display a message unless it is true, with no qualifiers or conditions. I’d rather not display anything than provide misleading information. Since there’s no scripting on the C-More screens, I sometimes I find it necessary to make dedicated internal coils for this purpose in the PLC that drive specific messages or combinations of situations. If the screen says it, the PLC thinks it, so when the display doesn’t match reality troubleshooting can begin on the correct path. This means I don’t implement things until they are verified, because if operators learn that some things on the screen are not always true, they can begin to doubt it all.
My primary HMI experience is with Wonderware, and you can have many contexts for the visibility of a display element or calculation of a value. I find that by processing things in the PLC and generating a special group of dedicated display bits you can have layered, sophisticated animations on the C-More that mimic Wonderware to some extent.
I also avoid using simple pushbuttons, always use indicator buttons, since most elements are copied and pasted for simplicity when building the pages – keeps the look and feel consistent. That way it’s easier if the application requires a different status indication for certain buttons later on.
I like to show the operator they’ve hit a button even if the action they’re requesting can’t be taken for some interlocking reason. Poor feedback leads to frustration and can make a touch screen become what we call a “punch screen” as they press buttons harder and harder, as if that would cause something to happen.
This is easy to achieve with a small grey rectangle appearing around the button, visibility context of the button status being pressed. My indicator tag for a button is usually the action the button is trying to initiate, which also serves as a confirmation that the requested action is happening. If there’s an interlock preventing the action, the operator will not see a change to the button when it is pressed. In that case the thin grey rectangle appears around the button as a clear indication they pressed it, and if the cycle or action does not occur most operators know and understand there’s a reason for it. Then they can look into why the mode didn’t activate instead of pounding on the screen.
One niggly little thing I often forget is to check the visibility context tab when copying and pasting. This is more a typo style of gotcha moment, one that is embarrassing if it makes it to the user and consumes of time re-working through the pages where it was missed, because it doesn’t always show up during simulation.
That’s all the thoughts for now. Good topic!
Hopefully, some of the wisdom that these leaders in our System Integrators LinkedIn Group have so willingly shared will help you along the way as you start out on your HMI project. Also, if you’re looking for someone to help out with your project, you can be sure that you’re getting the best help by contacting one of our SIDirect partners. You can find one near you by visiting this link.
