Midweek PLC Musings

There was some commentary about function block programming and its suitability for the application at hand. It might be useful to offer the following for discussion: Right at the very beginning of my upcoming PLC Coding Standard, in the Audience Guidelines section, I’ve positioned this topic:

§ AG-1: Address the Right Audience

The PLC code must be written to address the audience who will maintain and work with the application.

Reasoning:

·        Maintenance and operations support staff who are tasked with troubleshooting and making improvements later on, are the target audience who need to understand the code.

·        It will do no good to claim these individuals do not have the education required to understand the code. It is up to the solution provider to determine the appropriate complexity.

·        The PLC code must not be written in such a way that it address other knowledgeable programmers as the audience.

From what I have experienced, this very much contrasts with the way most PLC program providers justify their methods. They are addressing their equals. And I’m sure it is not done maliciously, it’s much easier to assume the people you are providing your solutions for are your equals. But it does neither them, nor you much good in the long term if your solutions are deemed to be too difficult to maintain! So it is my suggestion to establish a rapport with your client, to discover what their support staff’s level of comfort is with the code you provide. Yes, it will take some back and forth, but it will be a much longer sustainable business model.

And then, much further down in a section on what not to do, I offer the following rule:

§ PN-11: Do Not Build AOIs to replace normal LD Rung Logic

Where AOIs (Function Blocks) are created they should contribute something to the understanding, methodology or standardized use, not simply hide otherwise simple logic inside a block.

Reasoning:

·        The temptation to build clever function blocks that only exist to replace simple ladder logic rungs is to be discouraged.

·        Generating logic by scripting, or other automatic means, when applied to simple ladder logic, to build these into AOIs for the programmers convenience is to be avoided.

·        AOIs are harder to understand, troubleshoot and edit. So their use must be justified by benefits such as standardization, reduction of complexity, providing a useful interface, re-use of tested and proven code.

This guideline I felt compelled to contribute because of the increasing use of function blocks I see used, that contribute nothing but making the programmers life easier – and at the same time making the maintainers life a lot harder. This is the sort of thing that happens when work is executed without guidelines, and you just have to live with the way the work was supplied. That’s a miserable way to live. But then, you get what you pay for and what you contracted for…

What’s your experience? Do you have guidelines you have found valuable that you would like to see included?