tales
tales
tales
tales
tales

Don’t let the brain become a gray matter

March 15, 2006
Because code visibility is low, it can be tempting for a controls programmer to cut corners, especially when there’s a deadline. Yet this is one of the biggest mistakes a programmer can make. Read why.
By Scott Bivens, PE, Packaging Technologies

IT'S RARE these days to find an industrial machine controlled by simple relay logic. The relays have been replaced with a brain we know as a PLC or computer. Today’s control engineer must have the ability to tap into the machine brain, and fill it with code that produces desired results.

Similar to the thought processes in our own brains, code in the machine brain typically is invisible to the purchaser and machine operator. Machine programs are overshadowed by the physical workings of the machine, and are thought of only when there is a problem. Because code visibility is low, it might be tempting for a controls programmer to cut corners, especially when there is a time crunch to finish a project.

This is one of the biggest mistakes a programmer can make. As with human brains, we can do some pretty dumb or crazy things when our thought processes aren’t firing on all cylinders. The same is true for machine-based brains. With that in mind, here are some programming tips and techniques we use that you might find helpful as you develop code for your machine operations.

1. Choose the best program language for the application.
Many controllers let the programmer use several different languages in the same processor. One of the most common used by machine builders is ladder logic, which works well for general machine control and complex logical operations. Structured text is a good language to use when handling complex mathematical operations. Function-block diagram works well for process and loop control. While one type of language probably can handle each of these areas, you might find it easier to write and troubleshoot a program by using a language more suited to the application.

2. Modularize by machine function or station.
Break your main program into smaller subprograms that concentrate on individual machine areas. Each subprogram can be broken into subroutines that focus on more specific details in the subprogram. Categorize or order the subprograms and routines to match the flow or order of machine events. This technique helps programmers stay focused on just the code that needs to be developed for that section, and it helps troubleshooting and program navigation later.

3. Be generous with comments.
Working through someone else’s maze of programming is difficult, even with comments. Be kind, and give others a clue about how you intended your code to work. This also will benefit you if you’ve been away from the program for a while, and suddenly have to remember what you were thinking when you originally wrote the code.

4. Use intuitive names for tags and variables.
Establish a good naming convention, and use it consistently in all your programs. Many machine builders assign a name to an input or output that indicates its function when energized.

5. Remove or deactivate unused code.
Many times when a programmer reuses code from other applications, the result is a long program with sections of unused code that don’t apply to that machine. Unused code makes the program more difficult to troubleshoot, increases processor scan time, and consumes processor memory. We think more efficiently when focused. The same can be said for processors.

6. Keep it simple.
It might be tempting to show how smart or creative you are by implementing complicated or tricky code for a simple function. This only makes it more difficult for others to understand your program, and you may find that, rather than being praised for your great programming skills, you’ll be criticized instead. There are many opportunities to be creative, so choose wisely.

7. Validate the machine program prior to shipment.
Don’t place this burden on your customers. Field bugs can be a costly warranty expense, and deplete customer confidence. Create a check-sheet that lists all the I/O, diagnostics and alarms used in your program. Physically test each one, and verify that the right function is performed and the correct alarm is triggered. Your customer might appreciate having a copy of your validation form with the initials of the person who performed the checks.

  About the Author
Scott Bivens, PE, is electrical engineering manager atPackaging Technologies, Davenport, Iowa, and will be an attendee atCONTROL DESIGN’s 2006 AutomationXchange. You can contact him at[email protected].