Midweek PLC Musings

Last week I regaled you with the ever lasting impact of ladder logic. Turns out I’m not done with that topic, because there are a few things that I only learned to pay real attention to a few years ago. Due to the increasing amount of function block (FB) programming we are all doing it turns out! The more FB programming you do, the more you realize how ill suited the language is to straight forward logic expressions. Stuff that is dead simple in ladder logic is painful in FB. Like “if this is true and this is false then copy this word to this other location”. In ladder logic that is three inserted instructions, type in the tags and you are done. In FB you either pull down, or insert the tag icons, then you insert an And gate, then an Invert gate, and then - then you realize there is no simple Move nor Copy instruction in FB. So you reach for the Select instruction. But that requires another three tag icons because the inputs and output of the Select instruction needs to be directed somewhere. If you kept track, that’s eight objects, plus the seven lines that need to be attached between the FB objects. Clearly not efficient (never mind the extra hit on execution time).

So what we have learned over time, is to let each language do its best work where it can. The great process control efforts are done in FB, and the quick logic decision making in LL (or Structured Text (ST) if we feel adventurous). The routines get the same name so they are alphabetically sorted next to each other in the project organizer pane, with the LL routine getting the adder “_Aux” or “_Lad”. Now you have a nice solution, each contributing their own strength.

The thing to keep in mind, is to leave the pins that need to interact with the LL logic unconnected on the FB side. Otherwise the logic outcome from the LL execution is difficult to transfer to the FB logic. 

Let's make it a bit more real by setting up an example: A motor control FB instruction will need a momentary start and stop signal. The FB instruction reacts to positive logic signals. A one (1) on the start input will initiate a start, and a one (1) on the stop input will initiate a stop. This way we can write a simple self-holding start/stop rung in ladder logic, just the way we always would. And the outcome of the rung, the run condition is addressed to the start signal of the FB and then, since the FB has a stop input that must be addressed (otherwise the stop being left at zero will result in the motor never stopping). So we simply invert the start signal and address it to the stop input of the FB.

One other item I used to get irate about, because I witnessed shift support staff doing a double take whenever they encountered it: Placing output instructions in series on the same rung. Yes the design software allows for it, and simply following the instruction sequence there is logically nothing wrong with it. But the electrician looks at it and jumps to the conclusion that each “coil” only gets half the voltage if there are two in series. And while he is thinking about that, he is no longer actively pursuing the troubleshooting problem. So I even made up a rule against doing that. But now, when we mix in ladder logic to support FB, there are a lot of instructions dedicated to configuring the function blocks. We might have half a dozen configurations we need to apply for a function block, so it is quite reasonable to group together the output latch or unlatch instructions in a single configuration rung (with no condition instruction), so the right FB inputs are turned on and off. Long and short of it, Dave, I’m no longer mad at you. Anybody else have something related to share?