My first interface with sequential function chart (SFC) programming was with a mining application whereby the developers of a new diamond core drill were using an Allen Bradley (A-B) PLC with SFC. This was in the 1990s, folks.
The code was written by a representative of a distributor for A-B, and I was told by the president of the mining company who wanted to hire me to rewrite the code. Of course, I asked him why.
As he moved toward me with his cane in hand, he related the story of how the breaker blew on the underground power supply. The hydraulic pump, however, came back on immediately after the power was restored, and the hydraulic hose feeding the main core drill flexed. He, or, more specifically, his knee, was caught between the rock wall and the hose. Well his knee was ravaged, and he was recovering from surgery.
Well, I thought, how could that happen? I decided to take the job, and I was given a nondisclosure agreement (NDA) and the code that was already written in SFC.
The “programmer” had decided it would be a good idea to make the hydraulic pump retentive, using a latched output, in one of the SFC’s steps. He had no way to reset the output, unless he was in that step. I guess that part of the test plan wasn’t written.
I was the managing director for PLCopen for about eight years starting in the ’90s, as well. PLCopen is the organization that was created from a vendor pool to support the IEC 61131 standard, and then it also accepted users to help expand the benefits for PLCopen members.
Also being an Allen-Bradley PLC specialist, I knew a thing or two about SFC. And having retentive real world outputs is a no-no. ISA has released the third edition of “A Guide to the Automation Body of Knowledge”, in which I wrote the chapter on control languages.
A Control Design reader recently asked a question about how many IEC 61131 languages he needs to use. There were many answers—some vendor-slanted and some user-slanted. A common thread was that ladder logic should “probably” be used, due to the myriad people who could be using the code to develop and troubleshoot.
This falls right at my doorstep. The paradigm shift to IEC-based programming—which really means tag-based systems with abstracted hardware and five languages to choose from—has gained a lot of steam over the past 10 years. 3S-Smart Software Solutions is the developer of CodeSys, an extendable IEC integrated development environment (IDE).
The benefit of so many people using 3S software is it minimizes training and usage issues. What it doesn’t do though is teach people how to properly use the different languages and how to implement them to a level commensurate with the end user or customer.
SFC is great for sequential applications, such as machine control. It isn’t really suited to batch process, as such, but, if there is a sequential process within the process, then have at it.
SFC and function block are representative languages. They are a way to aggregate ideas and abstract code so that certain people, such as electricians at 3 a.m., don’t have to think too hard to find and troubleshoot a problem.
But training is needed, regardless. Most of the answers to the Control Design reader’s question about IEC 61131-3 languages, for example, did not touch on the issue of proper implementation of the language, regardless of which language it was. The training needed to be a good ladder-logic architect/designer, let alone trying to be a good programmer using abstract ideas such as SFC, is huge.
To answer the question doesn’t require a long, drawn-out explanation of multiple HMIs and process diagrams and automation standards. As I warn in my chapter of the ISA book on automation knowledge, you should choose the right language based on the application. Nothing more. Nothing less.
However, being an OEM, you want to protect your code and intellectual property, and being an OEM is different than being an end user. A user wants different things, but can the end user dictate to the OEM?
Many times, I have seen an OEM shoving its “standard” down the user’s throat.
Users have to be willing to learn, and OEMs may need to be more sympathetic to the user’s needs. I’m not sure that is happening. Due to the rise of remote-access solutions, it seems OEMs are content to support their own stuff.
Users might want to get with the IEC program a bit more, so that, when something lands on the doorstep other than ladder logic, they aren’t frozen like a deer in the headlights.
