Standard colors on HMI

Dear reader, this is an old version of the article. You can find the new version on my new blog.

The lack of a standard on what colors use on HMI systems is a serious problem. After watching many applications and searching for a standard, i noticed that the most of panels' graphic pages depended on taste of the engineer that realized it.
It's not the first time that i see purple buttons, blue leds and green backgrounds.
Even if there isn't a written standard on what colors you should choose, i searched for the best ways to realize graphic page and keeps updating myself on making HMI colors as helpful as possible.
This is the standard that i use as much as i can:

• Led : green for active, gray for inactive, red for alarm.
• Reserve leds: gray for inactive, red for alarm/reserve.
• Motors and valve: green for active, gray for inactive, red for alarm
• Pipes and tanks: cyan for water, gray empty, other colors if acids or special liquids.
• Momentary buttons: all grays and possibly with windows style and an image associated. All buttons must have a description (don't use only images, better use only description if you are forced to choose).
• Toggle buttons: i like UP-DOWN switch levers. A button that stays pushed isn't a good way on how to represent a switch.
• Alarm banner and log: Red (everything in red should be associated to something wrong)
• Background: gray for numerous reasons, like it doesn't hurt eyes, no problem if there is low light of too much light, all operators are used to see gray backgrounds, gray means inactive - nothing wrong.
• Animations: i use them only when i have to attract the attention of the operator, usually for alarms status or to pay attention at some particular operation. An abuse of animation distract the operator from it's job, so it should be for a good reason (NOT FOR A LOGO!). I don't even like to represent bottles that get filled and capped (for example), because the operator is not blind and can see what's happening inside the filling machine. A good animation can be a blinking gray-red led when it is in alarm state, a gauge that is changing value, a small alarm popup in the corner and so on... useful things anyway.
• Pictures: use ISA symbols or schematic symbols if possible; 3D is your worst friend while representing a plant. It's important that the operator understand what's happening, not that he get fashinated.

Why gray or blue for inactive: gray means "it's all normal", is the color of the background and a color that you wouldn't pay attention. Green is the color of "go on" with semaphore, it means that a component it's running. So why to make a button green? The button will never run. Same as red for buttons: red means STOP !, DANGER! EMERGENCY SWITCH, not "finish automatic mode".
A button is a component that the operator should not pay attention at all, he just know when to push it, no need to say him "PUSH IT!". Except for Reset Alarms of course :)

I took some samples of what i think are bad screens:

Blue background with light green pipes, green and gray tanks and green valves and pumps. Definetly not a good contrast and not good pictures too.

Here pictures are better, but the contrast green on green is still bad. And on top there buttons or tag without a graphic modeling, so i can't imagine how they can help an operator.

This is what i call a useful screen.

with good contrast, not much led and the active ones in green (as you can see you notice them instantly on gray) and alarms in red.
This can be useful too, even if more complex:

Notice the good contrast for liquid levels on tank. I don't know if components are red because they are not active or in alarms (as i hope), but it's definetly a good representation.

There is a very good article about using colors, animations and setting up a Graphical User Interface; you can read it here: http://www.rollthunder.com/SoftwareThatDoesntSuck/WpfForGoodAndNotEvil.htm
Even if it's really long, i try to write his points in short:

• First Principle: That the software that you write has zero value in and of itself. You write software for one reason and one reason only: to create value by making the user of your software happier than he would be without your software.  The only value that your software ever has or ever will have is the degree to which it increases the happiness of its users. It is extremely rare that users are willing to pay for software that decreases their overall happiness. 
• Second Principle: That computer programs increase the happiness of users in one of two ways.  The majority of applications help a user solve a specific  problem – writing an email message or an article, buying groceries or an airplane ticket, viewing a bank statement and paying bills. The user’s only goal in using this type of program is to finish the task and get on with his life, or at least on to the next task. The faster a program converts a task from not-finished to finished, the happier the user will be.
  The second way in which a program increases a user’s happiness, less common than the first, is by putting the user into a pleasurable state that he wants to maintain as long as possible, or at least as long as it remains pleasurable, like Games.
• Third Principle: That in neither of these cases do users want to think about the programs they are using.  At all. Ever. In the former case, they want to think about the problem they are solving: the wording of the document they are writing, or whether they have enough money to pay their bills, and which unpaid creditor would hurt them the most.  They don’t want the program to distract them from the problem they’re thinking about.  If they want to goof off and waste time, they’ll bring up Solitaire, not admire the flashing video buttons in the word processor. 

The point that i liked the most is this one: Motion attracts a user’s attention. Natural selection brutally pounded that design pattern into the human brain and visual system. Our savannah-based ancestors that noticed the twitch of the saber-tooth tiger behind the tall grass avoided being eaten and passed their attentive genes on to their descendants. The ones who didn’t notice the motion got eaten, and didn’t.  Every single user is the inheritor of roughly 13,000 generations of homo sapiens who noticed motion better than the ones who didn’t make it.
[...]
As user interface expert Jared Spool wrote of his test of a Disney web page containing an animated logo, that corporate branding icon so beloved of marketeers everywhere: “Users first tried to scroll the animation off the page, and when they couldn’t, actually covered it up with their hands so they could read the rest of the text.”

I really reccomend to check this article, is well written and with tons of examples.
And i hope you enjoyed this reading.

Example on how to write sequences with Siemens Step 7 (S7-300)

The last post with RsLogix 5000 showed how to write sequence in an understandable way with Allen Bradley PLCs. Here it is a sample for Siemens Step 7.

I will analyze the exercise #3 of learning pit, you can find the full text here:

http://thelearningpit.com/lp/doc/bl/bl-ctr.html 

This is the system with I/Os:

And the state machine that we have to realize is this one:

With green arrows there's the sequence that we should respect, and with black arrows the start/stop conditions.
Notice that when the cycle gets interrupted, it must restart from the last state (this means that you can't drain if you didn't heat before, and so on...); at the end of the cycle you can choose if restart the cycle to do more batches, or to stop it if the batch count is done or if the selector was in single batch position.
The sequence can be realized in this way:

You can write each step of the sequence in a word (DB4.DBW0) and pass every step with a SHL_W (equally as BSL for Allen Bradley) instruction.
If you notice, you can read every rung of the sequence as you could read a green arrow in the diagram above, like "When Step1 and High Level Sensor GO TO Step 2" and so on.
With those steps we know how to enable outputs, because in STEP 1: Fill Mixer i should enable the filling pumps, checking if the product count respects the % of product 1 and 2:

 Step 2: Heat and Mix

 

T1 is meant to keep the mixer running for 4 seconds after the step change, so you can mix for 4 seconds then start the drain pump.

Step 3: Drain Pump

Step 4: Increment batch count and reset product counter (because the mixer is empty)

Step 5: check product count and restart the cycle or stop it.

How to read this: in the last step of a cycle the 1st thing to do is to reset the steps of the cycle.

Then, if the selector is in Multiple batch, i check batch-count to see if i have to restart the cycle (2nd coil) or to stop the process (Reset automatic mode.)

Of course if the selector is not in multiple batch mode i should reset the automatic mode wihtout checking for anything.

To start the cycle use a segment like this:

The important part of this post is anyway the one with SHL_W, the rest is just about turning ON and OFF some outputs. I post the AWL code for the change steps sequence, just translating it from ladder, to show you how it's made.

As you can see you can write a sequence using a SLW obtaining the same (almost...) readbility as with KOP.

You can download the full exercise with simulation (to be used with PLC-SIM) here: http://www.megaupload.com/?d=83C551Y6

WPF User Controls: 7 Segment Display

7 segment displays is one of the best way to show present values in industrial programs. Operators are used to see numbers and values with  7 segment led characters, and if the operator feels comfortable with what he sees, he works better and in a more correct way.
So it's our work to make them feeling "at home" with the graphic of our programs.
To make a 7 Segment Led it's just a question of adding a custom font.
The one that i like more is NI7SEG (you can download it from here: ni7seg) or google it adding a .ttf at the end.
The code to add a Custom Font is pretty simple:

        /7SegmentLed;Component/Fonts/#NI7Seg
        

where fontfamily refers to /nameofproject;Component/font_folder/name_of_font (to be seen inside the file, not the name of the ttf file).

Then you can just create a label and apply the style:

A sample program can be found here:
http://www.mesta-automation.com/Downloads/7segmentled.rar

What features a supervision / SCADA system should contain

There are many ideas on how to make a good supervisor system and this make also a lot of confusion to engineers.

Actually HMI panels are so powerful that they can be compared to SCADA, and when i visit some clients and i see their systems, 80% of times i can't understand why they choosed an expensive SCADA package instead of a simple panel.

HMI panels are better than scada for human machine interface, as they require less time to be programmed, they can just get replaced if they get broken and they require less downtime; they doesn't require an updated Operative System and they doesn't require an OPC Server.

And most of all, they are cheaper!

With this post i don't want to make a comparison with SCADA and HMI panels, but just to point out what a supervisor system should contain, it is up to you to understand if you need a simple Panel or a complex SCADA.

So a SCADA program needs:

1. Communication driver: can be OPC , Modbus or what else, the communication is the most important thing of those systems. It must refresh values on read at least once every second.
2. Graphical User Interface: should contain plant schemes, motors, valves, leds, pipes, sensors' state, everything connected with the plant. It should represent all the plant status and its peculiarity, and also it should be as much dynamic as possible. This means that if you represent a motor (grey), when it runs you should represent it Green, and when it is in alarm state make it blinking grey-red.
3. Set Points entry and Present Values visualization: to permit the configuration and troubleshooting of the plant. A good way to create set point entry is to set the value on PLC, and when you receive the refresh events from communication driver you visualize just what the PLC contains in the memory.This can be not instantaneous, but you can always see if communication is up and running.
4. Alarm management: usually made with databases, your supervisor should contain at least an alarm banner, an alarm log and a page with active alarms.
5. Recipes management (if needed): it's made with a database too, that contains various set points that should be transmitted once the operator select the recipe. An interface CRUD is needed for this database.
6. Plant Control (if needed): when there are heavy algorithms to be described with PLC language, for example when recipes are complex and the supervisor controls many PLCs, you can use the PLC to control drives and motors based on high level inputs (like "go to position", "set speed") coming from SCADA. 
7. Data logging: based on database too, with a SCADA you should log all the critical process variables (pressures - temperatures - speeds and so on) and visualize them in charts like (x -> time ; y -> Set Point and Present Value and Max Threshold  + Min Threshold).
8. Production tracking: while a product is being made, it should be associated with all the process variables' values during it's making time. This will create a database containing all the statistics needed to analyze the production and improve quality and times.
9. Reporting: if you give data about production, you should also give to clients a way to use those data. You can show them with reports and you can also analyze them with special recipes to check for production flaws automatically.
10. Multilanguage support: if you are going to sell the software worldwide you need to support all messages and labels with a language database (in this case an Access file is the best choice, because EVERYONE know how to compile Access tables).

Scada are systems very powerful and expensive (in working hours or in money spent to buy all packages),but it's good to see them running once you made them :)