Standards for HMI Programs

Steve Etter

Lifetime Supporting Member + Moderator
Join Date
Apr 2002
Location
Morristown, TN
Posts
965
Hi all,



We have discussed standards for PLC programs several times in the past, but I can't recall if we have ever discussed standards for HMI application programs.



I work for a company that buys a lot of custom built machines from a variety of builders. Often we have to find new builders and, of course, we have a Machine Specification manual that covers much of what we look for from a machine builder. Unfortunately, we have never addressed HMI's other than to specify what kind.



So what we have now is a vast variety of applications styles ranging from the really bad (not intuitive, no alarm annunciation, difficult to read, etc) to the very good and everything in between. Because of this variety, it has been suggested that we amend our Spec manual to include some program standards.



In thinking on it so far, I have really not been able to come up with any good overall specifications and I am hoping someone else might have something they can share.



Does anyone have general specifications for HMI applications?



Steve
 
I know this isn't a spec but some thoughts on the topic.
  • All HMI pushbuttons should be of the momentary type. All latching should be done in the PLC.
  • Multistate pushbuttons can be confusing as some you need to cycle through the states in a certain order.... but what if you want to go from state 3 to state 5? Can't do it. Use a drop down selector or series of momentaries to select multiple states. Use a separate indicator to show the actual state as determined by the PLC.
  • Use TAGS. Some HMI software lets you enter direct addresses. This might be quicker at the outset but for re-usability and adaptability it's a no-no.
  • Use the GRID and alignment tools. It is so easy to get things lined up and sized right... and still I see a lot of sloppy screens. !!!!! (pet peeve)
  • Use a common color scheme.
  • Use a common Font/Text scheme.
  • Use similar sized objects for similar functions.
  • Use common locations for screen functions. For example, the back or return button is always in the lower right corner of the screen.
  • If the software has the functionality, use a "background" or "base" screen for common elements visible on multiple screens. This gives only one place to change/troubleshoot if something is not right... and makes sure the items look exactly the same on all referenced screens.
  • Use Alarms. Most sytems have great built in functions for alarms and histories.
  • Just because you "can" do something in the software, doesn't mean you "should"!!
Again, just some thoughts...
 
ndzied1 said:
I know this isn't a spec but some thoughts on the topic.
  • All HMI pushbuttons should be of the momentary type. All latching should be done in the PLC.
  • Multistate pushbuttons can be confusing as some you need to cycle through the states in a certain order.... but what if you want to go from state 3 to state 5? Can't do it. Use a drop down selector or series of momentaries to select multiple states. Use a separate indicator to show the actual state as determined by the PLC.
  • Use TAGS. Some HMI software lets you enter direct addresses. This might be quicker at the outset but for re-usability and adaptability it's a no-no.
  • Use the GRID and alignment tools. It is so easy to get things lined up and sized right... and still I see a lot of sloppy screens. !!!!! (pet peeve)
  • Use a common color scheme.
  • Use a common Font/Text scheme.
  • Use similar sized objects for similar functions.
  • Use common locations for screen functions. For example, the back or return button is always in the lower right corner of the screen.
  • If the software has the functionality, use a "background" or "base" screen for common elements visible on multiple screens. This gives only one place to change/troubleshoot if something is not right... and makes sure the items look exactly the same on all referenced screens.
  • Use Alarms. Most sytems have great built in functions for alarms and histories.
  • Just because you "can" do something in the software, doesn't mean you "should"!!
Again, just some thoughts...

(y) I agree !!!!! . Bottom Line is the SCADA/HMI is there to assist Operations etc. and should be as simple as possible, Operations will quickly get used to "glancing" at the screen to decide wether or not they need to step closer for a more detailed examination of process or finish their coffee first. Some SCADA packages have some form of background code (Cicode , VBA etc) Resist the urge to create fancy logic in these,do the the logic in the PLC after all thats what the L stands for isn't it ? (my pet peeve) I once came across an old DOS package and the safety interlocking had been done in the SCADA! Shutdown the PC and even the lanyard switches no longer worked.
 
Good points made, here are a few more

Please dont use all upper case text.

If functions are not available grey them out but don't hide them, ideally make the reason they are not available clear.

Make process flows go left to right (or at least consistent), do not just copy the P&ID's.
 
I appreciate the responses. I think I should be able to use almost all of this to draw up a draft specification change.

Posted by FrancisL

Please dont use all upper case text.
I am curious why you don't like all upper case. I always thought it easier to read, myself.

Steve
 
I don't mind upper case if everything is in upper case. Again, for me, it's consistancy. If you use uppper case in all your PB graphics, then have one with mixed or lower case it looks bad. But if they are all upper case I think that's ok.

I think this one is personal preference. Maybe the e-mail standard of UPPER CASE = SHOUTING is having an influence here?
 
It is not just the Shouting thing - I did once read that Upper case has been found to make users uncomfortable. I cannot find it now but I think it was in a Microsoft guide to screen design. And it certainly looks uglier to me
 
If you use lowercase in most of the text you can reserve UPPER CASE for those instances where you want the operator to feel uncomfortable. like EXPLOSION HAZARD!.

Mix it up baby!

Brian.
 
Not much I can add. I suggest creating standard displays and or buttons. I keep a "scratch" window in each application where I save frequently used items.

ndzied1 said:
I know this isn't a spec but some thoughts on the topic.
  • All HMI pushbuttons should be of the momentary type. All latching should be done in the PLC.
This is an interesting one. We happen to do it this way. Most of our Intouch buttons are momentary. Lately, after upgrading from KT cards to CLX ENBT and DHRIO modules and IT v7.11 to 9.0, we've experienced "stuck" button bits. That is, the initial 1 gets to the PLC but the subsequent 0 gets lost somewhere in ciber space so it's as if the button gets stuck on. Happens about once every few months.

I've posted this issue here and at the other forum asking for advice. A lot of responders said they do the exact opposite. Latch with the HMI, then unlatch in the PLC (once you've done doing what you're going to do with it).
 
wildswing said:
Not much I can add. I suggest creating standard displays and or buttons. I keep a "scratch" window in each application where I save frequently used items.

[/list]This is an interesting one. We happen to do it this way. Most of our Intouch buttons are momentary. Lately, after upgrading from KT cards to CLX ENBT and DHRIO modules and IT v7.11 to 9.0, we've experienced "stuck" button bits. That is, the initial 1 gets to the PLC but the subsequent 0 gets lost somewhere in ciber space so it's as if the button gets stuck on. Happens about once every few months.

I've posted this issue here and at the other forum asking for advice. A lot of responders said they do the exact opposite. Latch with the HMI, then unlatch in the PLC (once you've done doing what you're going to do with it).

I had a similar problem with some Pannel views attached to some really old PL5 (so long ago I do not even remeber the model number) So I would program the PLC to just act on a high signal and reset itself without prompting from the HMI. I still do that now just for simplicity.

One of the things I like on touch screens is a Menu screen. Stepping thru several screens to get to the one you want is annoying. I also set my limited adjustment screens this way. So if a maitneance tech needs to get to it to make adjustments it is password protected. I also feel that if you are using multiple screens then an automatic toggle back to the main status screen should be used. How the toggle works varies with the process.

Also...ALL passwords should be stored in the PLC program. That way if the password list gets "lost" or someone decides to change them you can find them again.

I also use the same image for a running status for my screens. It is a smily face that frowns when the machine is down. Yes it is corny but can been seen from a distance and I have been told acts as a promt for operators getting the machine running again.
 

Similar Topics

Hello, I am in the process of updating our control panels and was wondering if anyone could give me a little more information on the guidelines...
Replies
7
Views
2,504
Sorry for the long narrative. The factory I work for has asked our team to build a machine "in house". This is drastically different than what we...
Replies
24
Views
6,138
Anyone building cabinets according to Korean standards? What to think about? Do you need to use components with Korean approvals?
Replies
0
Views
837
I'm at a new company in the USA that hired me because they have no clue about controls. I have to start the controls division from the ground up...
Replies
6
Views
1,399
Could someone point me to the relevant sections of the UL 508A or other standards that talks about fabricating your own enclosures? I can't...
Replies
9
Views
3,196
Back
Top Bottom