1660601534738 Backinthe90ssfcfb

Back in the '90s, there was this SFC

July 23, 2018
Programmers get to decide a lot of things when controlling a machine or process, and training and understanding best practices are a good decision

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.

READ MORE: IEC 61131-3 specifies syntax and semantics for a unified suite of programming

About the author: Jeremy Pollard
About the Author

Jeremy Pollard | CET

Jeremy Pollard, CET, has been writing about technology and software issues for many years. Pollard has been involved in control system programming and training for more than 25 years.

Sponsored Recommendations

Is the Vision of Fully Cabinet-Free Machinery Finally Becoming a Reality?

Learn more about the innovations in industrial automation that are making cabinet-free machinery a reality.

2024 State of Technology Report: I/O Systems and Power Supplies

2024 State of Technology Report: I/O Systems and Power Supplies In the electrical enclosure, uninterruptible power supplies and I/O are important components. These devices are...

Boost Material Handling Operations with the New Assist Wheel Drive

Transportation and material moving are repeatedly among the most frequent workplace injuries and also a leading cause of days away from work, job transfers, or restrictions. Learn...

EV Battery Pack Manufacturing with AC Servos and Robotics

This white paper from Yaskawa examines the increase in demand for electric vehicle (EV) batteries and explores different steps in their manufacturing process where AC servos and...