Showing posts with label Tips for programmers. Show all posts
Showing posts with label Tips for programmers. Show all posts

Useful resources for PLC programming: PLC-DEV website


I want to make a review on plc-dev website that contains some posts that i think they are really helpful and complete for PLC programmers.
The website has 3 main sections for the 2 most used marks of PLC, Siemens and Allen Bradley, and a talk about Modbus protocol, one of the most used protocols and a protocol that is supported from all PLCs:

Allen Bradley
Even if I think that the best blog to learn Allen Bradley programming (and ladder in general) is Nearly In Control with his RsLogix 5000 tutorial, PLC DEV contains a mass of documentation about Allen Bradley and their products.
Some useful post for starters are:
and a big collection of manuals that must be read (depending on the hardware you are using) is here:

Siemens
The section of Siemens programming is really helpful.
The pain of Siemens PLC is AWL / STL language of programming, both for programmers than for "readers" of programs.
Also this section contains some useful article that resume how to connect, upload and download programs with Step7 (not the best User Interface in the world as you already know), a quick reference for Siemens Libraries (OB, FC, FB, SFC, SFB), and it contains also some useful information about AWL/STL language and addressing.
The parts that i found more useful are:

Modbus
Modbus protocol is a very common protocol that every device support.
This section explain what is a Modbus (RTU, TCP, Modbus +), the electrical wiring (RS 232, 422, 485, Ethernet) and it solves many doubts about the difference between Protocol and Networks.
Modbus FAQ

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.

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 :)

A good (free) set of 240 icons

A big problem and a big waste of time for a programmer is the research of icons and images to associate to buttons, panels, toolbars and so on.
I really hated to do that with Google image-finder, so i searched a lot until i found a site that contained a million of icons.
Of course it can't exist that for every program i search in a database containing so many designs, so i want to show you a set of icons that in my opinion cover almost all that a programmer needs.
As usual remember that an icon should HELP the operator, not just be pretty. If you feel that the icon is not so meaningful, it's better to remove it and just leave text on the button (so the operator is forced to read it).
This is a small (and almost useless) preview of the set, that contains more useful icons for sure:

But i invite you to visit this page: http://www.iconarchive.com/category/application/aesthetica-2-icons-by-dryicons.html to see the complete set (that is really big, around 240 icons).
I want to point the attention on some icons:
- Accept, Add, Remove and Edit are pretty straightforward. I think that no one can do confusion with this set of icons.
- Back, Next, Down and Top are pretty useful too, even if i don't like to abuse of them because they are not always understandable if the context is not well defined.
- Info, Help, Search and Warning are awesome. It's impossible to don't understand what they means and they are similar to windows ones too.
- Lock - Unlock icons for password login is always useful.
- Charts, Folders, Databases, Home, Word and Calendar got always a use in programs, and they are included too.

The rest is quite trashy, or not so useful, but it always depends on what you are doing.
I really invite you to check out this set, downloadable from the bottom of this page:
http://www.iconarchive.com/category/application/aesthetica-2-icons-by-dryicons.html
selecting Linux (.png) files included (so you get the version with the set of 16x16 - 32x32 - 48x48 - 64x64 - 128x128 pixels)
Remember that if you use them you should read carefully the license, that permit a free use of this set, and to respect the work of this guys.

Comments on code are good or bad ?

In this days i read a discussion on a forum between some programmers and they were discussing about "Write or not to write comments on programs".
The discussion result wasn't so obvious, because many of them said that comments were not only useless, but also dangerous, and in the most of cases it would be better if they weren't ever written.

This is an example of bad comments:
channel++;   //increment channel 

The good thing about this line was that both the code and the comment agreed (experience shows this is quite often not the case). The bad thing about this code is that they are both wrong, the problem being that the original coder didn't understand the difference between channel and timeslot [2] and chose the wrong variable name. Fortunately, when he (or someone who came along later) realised the mistake he used a snazzy re-factoring tool that avoids the problems with global "find and replace" and understands the code enough to only change the relevant variable name and not other occurrences of the string or the same name in another scope. The code now reads:
 timeslot++;      //increment channel 

You might ask why the re-factoring programmer didn't change the comment to match and it was because he wasn't looking at that particular line, but at this one:
 uint32_t channel; // I think this is probably timeslot, not channel. 

The first person to come along realised the poor choice of variable name and "fixed" it by adding a comment. The second decided it would be better to change the variable name. Obviously, the second programmer believes in saying it in the code and disregarding comments, because the changed line now reads: uint32_t timeslot; // I think this is probably // timeslot, not channel. 

So what's the truth about comments? is it better to write them or not ?
Another example can be this:
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
  r = 0.5 * ( r + (n/r) );
}
System.out.println( "r = " + r );

Any idea what that bit of code does? It's perfectly readable, but what the heck does it do? Let's add a comment.
// square root of n with Newton-Raphson approximation
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
  r = 0.5 * ( r + (n/r) );
}
System.out.println( "r = " + r );
That must be what I was getting at, right? Some sort of pleasant, middle-of-the-road compromise between the two polar extremes of no comments whatsoever and carefully formatted epic poems every second line of code? Not exactly. Rather than add a comment, I'd refactor to this:
Codice:
private double SquareRootApproximation(n) {
  r = n / 2;
  while ( abs( r - (n/r) ) > t ) {
    r = 0.5 * ( r + (n/r) );
  }
  return r;
}
System.out.println( "r = " + SquareRootApproximation(r) );
I haven't added a single comment, and yet this mysterious bit of code is now perfectly understandable.

This guy (http://www.makinggoodsoftware.com), that got a blog where he writes about tips to make a good code, wrote an interesting page on "writing comments or not", and you can find his article here:
http://www.makinggoodsoftware.com/2009/06/06/comments-are-evil/
where he basically says that:
  • The worst code is: Bad code without comments.
  • Bad code is: Bad code with comments.
  • The average code is: Average code with comments.
  • Good code is: Good code with a few comments…
  • …but… Great code doesn’t need comments!!!
And he gives some advices on how to increase the readiblilty:
http://www.makinggoodsoftware.com/2009/06/22/how-to-write-readable-code/
and
http://www.makinggoodsoftware.com/2009/06/04/10-commandments-for-creating-good-code/

It's important to keep improving our code, to help us and other people mantaining the applications.