Once you are familiar with their capabilities and methodologies, Siemens PLCs have the potential to make controls programming quicker and easier than ever. With support for function blocks, text-based programming, libraries, and user defined types, Siemens lets developers attack problems with a much more object-oriented approach than traditional ladder logic programming. But for programmers and technicians less experienced with the Siemens line of PLCs, The S7 and S5 product lines often seem overly complex and hard to troubleshoot.
On a recent project, I had the opportunity to develop a set of training exercises for industrial technicians troubleshooting Siemens S7 PLCs. Here are some of the examples I put together. They include some of the most common, overlooked mistakes I see people banging their heads on all the time, especially those new to the S7 line of PLCs.
-
Using the wrong type of memory for your global variables. Sure, implementing an M-bit can at times be a little faster than creating a data block. But in all but the simplest applications, data blocks are the way to go. Data blocks are entire consecutive sections of memory specifically allocated for your data. M, T, C, etc., memory on the other hand is completely accessible, and has no checks to make sure you are accessing the memory properly. For instance, if you use bit M 70.0, but also use word MW 69, your bit and word will overlap, and neither variable will work properly. Just staying away entirely from M, T, C, etc. memory is in general good practice, unless you have a good reason not to.
-
Failure to re-compile a function block when you change the interface. If you add or remove anything to the inputs, outputs, inouts, or static variables of a function block, you have changed the memory footprint of that block, and you need to re-compile it, as well as every parent block that contains it. If you don’t, you can see some pretty wacky results. For example, I once created a TON timer, and proceeded to watch it stay off for well over its time setpoint, even when I hooked up a constant TRUE to its input. Of course, the problem wasn’t the input. I had added the TON instance to my static variables, without checking block consistency. Without allocated memory, of course the timer was unable to count up and turn on. Be sure to take a look at Check Block Consistency whenever you see anything seemingly “impossible” like this occur.
-
Using scan-based Organization Blocks where interrupt based Organization Blocks are needed. Some people like to just throw everything into OB1. This is okay until you need to throw something very time-dependent in, like a PID control loop. Putting a CONT_C PID block anywhere except a cyclical time-based interrupt OB is a recipe for poor control. OB1 and similar blocks will have varying scan times each scan, depending on what is happening during that scan. Blocks like OB33 and 35, on the other hand, are dedicated to re-starting on a constant time schedule, just like things like PID control blocks are expecting.
These are just a few of the things I have seen enough times to take notice. When I have time I will jot down a few more, and as always please write a comment or question if you so desire!
Learn more about DMC's Siemens S7 PLC programming services.