In case you’ve never read my blog before, let me bring you up to speed:
- Write readable PLC logic.
Now, I’m a fan of ladder logic, because when you write it well, it’s readable by someone who isn’t a programmer, and (in North America, anyway) maintenance people frequently have to troubleshoot automation programs and most of them are not programmers.
That doesn’t mean I’m not a fan of other automation languages. I think structured text should be used when you’re parsing strings, and I like to use sequential function chart to describe my auto-mode logic. I’m also a fan of function block diagram (FBD), particularly when working with signal processing logic, like PID loops, etc.
What I’m not a fan of is hard-to-understand logic. Here’s FBD used wisely:
Here’s an example of FBD abuse:
I’m still reading Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin. He’s talking about traditional PC programming, but one of the “rules” he likes to use is that functions shouldn’t have many inputs. Ideally 0 inputs, maybe 1 or 2, possibly 3, but never more than 3. He says if you go over 3, you’re just being lazy. You should just break that up into multiple functions.
I think that applies equally well to FBD. The reader can easily rationalize about the first image, above, but the second one is just a black box with far too many inputs and outputs. If it doesn’t work the way you expect (and it’s doubtful it does), you have to keep going inside of it to figure it out. Unfortunately once you’re inside, all the variable names change, etc.
I understand the necessity of code re-use, but not code abuse. If you find yourself in the situation of example #2, ask yourself how you can refactor it into something more readable. After all, the most likely person who has to read this later is you.
The PIDE has to be the biggest FB block there ever was but I couldn’t imagine separating it out and having to wire everything together for it.
You can make your unused inputs/outputs invisible and ‘clean it up’ a bit. Just click the elipsis button and uncheck the VIS column next to the parameter.
Love your blog.
Well, I’ve seen larger function blocks, usually when someone tries to write one function block for their entire assembly line.
There are a couple things that could be done to the PIDE function block here. It could default to only displaying the most common ones, and then expanding with extra inputs/outputs as needed. They could also group some closely-related inputs or outputs into user-defined types. If some of the inputs are merely configuration, then it would be better to move those into the elipsis popup box.
You could also have different versions of the block for different common sub-tasks.
I know it’s difficult, but I never said it was easy to make stuff readable. 🙂
Well they don’t call it ‘enhanced’ for nothing 😉