What will your customers think of the Ultimate HMI design layout?

[DamianInRochester]

And this is why the industry got skewed in the first place.
It is our responsibility to consult/inform/advise those who do not understand what the ramifications are.

You can do this to a point, but these decisions are ultimately theirs and they are the ones writing the checks. I don't consider it my place to dictate to them. And they don't always care what the ramifications are.

Generally, the only things I will not sway on are situations related to safety.

The thing I have always found amuzing with the whole Green/Red argument that I have seen hashed out many times, the people in camp A always think the people in camp B are nuts, and vise-versa. Anytime you have a situation like this, there is little hope for reconcilliation. There is too much inertia in both camps to overcome it.

I would almost like to see maybe 2 well defined standards and anything in between get snuffed out, so rather than having to go through all the details of everything it is either all the RED starndard or all the GREEN standard. I don't know how many more 80 page company specific specification documents I can swallow before I burst.

 

[iant]

it would be interesting to know, Who paid for the additional 3 months work to rewrite the HMI screens to another engineering companies specifications.

 

[Steve Etter]

I find the Red/Green issue is pretty clear once you agree on the reference.

If the lights are telling you the condition with respect to the machine's operation (production) then GREEN = RUNNING/UNSAFE for people and RED = NOT RUNNING/SAFE (maybe) for people. When the goal is to give supervisors and managers quick visual reference to operating conditions, this method is often favored.

If, however the reference is the condition with respect to personnel safety, then RED = UNSAFE and GREEN = SAFE. When the target audience is people who may be entering potentially unsafe areas, this method is favored.

Typically it simple depends on the target audience.

As Tom Jenkins points out, though, consistency is the key.

Steve

 

[SLC500]

Design Change Notice. Client was coerced into thinking that they needed the change to the HMI standard and they stepped down off the money bag and paid again for the HMI programming as well as the changes to all code to work with the new alarm scheme.

 

[Oakley]

I forgot to mention ... be aware that these systems could (and most likely are) used by color blind people. The High Performance HMI does take this into account.

 

[surferb]

I agree that the example screens aren't the best that I've ever seen. However, I like his principals. Keep it simple. Use multiple means of indication (color, shape, text). These are good ideas. I don't know about the 7 step process.

 

[jrexrode]

I've been following several of the "ultimate hmi" tenets, like the soft gray background, for several years. I gravitated to them naturally, based off what was easy and less stressful on my eyes. My predecessor liked darker blue backgrounds with black text. That really strained the eyes.

I stay away from the stylized buttons and such that really have nothing to add to function. Graphics are minimal.

I've found a that a desktop color wheel app was very useful too, when designing some of these screens. It gives you a good sense of what will and won't clash to harshly

 

[mellis]

I also have been using some of these ideas for a while now.

Gray background
Simple 2D low contrast depiction of equipment
Minimize or eliminate animation (I don't mean everything that is called animation in HMI software, but specifically things that move, cycle thru bitmaps and other eye candy)
Minimize color to things that need to draw attention (at least limit bright colors)

I do use gray = off, green = on. I can see where white = on would be ok too. But it seems to need text to clarify, where green/gray doesn't seem to need it as much

I haven't used text in addition to color to indicate status and I'm reluctant to do so for two reasons. One, it's bulky and clutters the screen. Two, it opens up another can of worms for multi language support. If I include alternate indication for color blind users, I think I will go with some simple icon instead.

While I do see what they are trying to do with alarms, I think the recommended approach is a bit too much for general alarms. It seems they agree, their example graphic only used part of the recommended solution. I question the need for text "Priority 1" when the icon already has a "1" on it. It's just too much screen space to indicate a single bit of information. I already see a problem with screens appearing too spread out because of all the "hidden" information that only displays when it's needed. This would only add to it.

All in all, some useful ideas.

 

[MadPLC]

I have created many HMI's and if I did one like shown in the first post I'd be fired. Way too busy and to be honest, it's hard to see what's going on. I've heard the argument about 2D and grayscale but I think it's invalid.

When I do an HMI I use gray background as it's the easiest on the eyes (most of these guys look at the screen for a 12 hour shft so it has to be). I use colour to represent what the actual equipment looks like. If a machine is blue on the floor the picture of it on the HMI is blue. For motors, pumps, valves I use red/green/yellow/white depending on what the client wants. But there has to be a contrast between the controlled machinery and the rest of the process. If everything is in grayscale then it all melds together and it can be hard to see what's happening. I also like to use animation where I can though as it gives the operators a sense that something is happening over basic static screens.

Mind you I've created apps in Wonderware with app server and they have turned out great. Having the power of WW graphics is hard not to take advantage of. Mind you, I've also made some nice apps in Cimplicity and Citect as well.

 

[surferb]

I like the use of icons and colors. Such as the following:

 

[harryting]

Interesting, there's some good tips there but the BIG FAIl I see with the article is that there's no justification provided for the "ULTIMATE HMI".

Basically, it just said, this is the way to do it, else, you suck.

When one deals with HMI and the users of the HMI is the human animal, it's never so simple as to say, this is THE way to do it.

 

[williamlove]

Some of the fancy, busy, colorful HMIs I used to make years ago were praised by important customer management.

After I gravitating to the principles espoused here, starting about 5 years ago, I don’t get as many of those oohs and aahs.

I’ve seen some fancy bitmap and 3-D stuff that was impressive and effective, but the highly skilled use of muted colors and clever backgrounds with horizon lines etc was key. And I’ll bet it took a lot of time. Too much time (money) and complexity for a normal project but interesting to at least consider and learn ideas from.

 

[bce123]

The site was ok, but lots of great responses in these post.there are two ways i do my hmis. I like to keeep things simple text is a must, alarm box at bottom,easy to follow.I allways try to have an I/O diag. screen for the maint. crew, just read only.simple to use nav buttons trends on seperate page and setpoints on password protected screen. the other way is the end user way. clutterd lights bells sirens animations as many as you can fit on two screens condensed onto one a cup holder to keep down on spills adjustable colors for each dept head remote control for the managers with all the tech. knowdlge,data loging to the IT server and most important a nema 4x op consol with oiltight manual operation switches and push buttons for the operators. LOL

 

[surferb]

Here are some screens that a user posted to the Inductive Automation forum here. I really like the design principals used in that they have eye candy, but are quickly understandable and use many visual cues.

 

[DamianInRochester]

what software was that developed in?