In my column, “Back in the ’90s, there was this SFC,” and it stirred Kim Ground of Falcon Labs to respond with a high degree of detail and anecdotes, which I want to share with you.
There are philosophical differences and similarities, which can lead to great discussions about system design, language preference and proper implementation of software.
My main point of the column was that SFC control programming was not properly implemented back in the 1990s. The person who wrote the initial program did not fully understand SFC, and the fundamental fact, according to my memory, is that all nonretentive outputs are reset by default once the step is deactivated.
In checking the specification directly I could find no reference to that claim as well in the multitude of books I have on the subject.
So I decided to do some more investigation by researching an SFC editor. I reference Rockwell’s publication 1756-PM006I of February 2018, where I was pleasantly presented with a multitude of options of how to handle nonretentive outputs once a step is deactivated.
The SFC implementation on the PLC-5 is rudimentary, to say the least.
Ground contended that the programmer did not do his due diligence on some basic machine safety functions, which is the fact that nothing starts up automatically after a power reset or emergency stop. But he also contends that retentive outputs make programmers lazy. He asks, “Why do vendors in their systems allow for retentive outputs period?”
He also contends that the programmer would have made the same mistake using straight ladder logic. He may be right.
Yes, we can forget to turn them off at the appropriate time, but that is caught at startup. In my programming, I use retention only when needed. I admit that I have run into trouble when the system craps out and a restart is required, and I have not pre-conditioned a retentive bit in my startup routine.
I also admit that, when something doesn’t work, we tend to rely on the code as our troubleshooting tool, which is where we discover that the retention has not been properly dealt with.
He suggests that programming standards be written and adhered to, which would include a rule that no retention be used so that all output instructions automatically reset on a system cycle. We disagree on that point but agree that you must not use retention for output devices.
We also agree on the fact that due diligence has to be done on startup. This means making sure that the system is in a safe but operable state.
Ground laments that PLC vendors are selective in their support for languages. They have their preferred languages. A machine-control PLC vendor that he is familiar with has built a robust SFC implementation that he has used and prefers, but the ladder logic editor does not have a full instruction set as such.
Rockwell Automation, however, has a preference for ladder logic; thus, its implementation is complete and then some.
He also suggests that as a senior electrical engineer with multiple packing OEMs, he implemented ladder logic due to the 3 AM phone call rule. He suggests that, while multiple threaded processors can be helpful for the designer, it may not be so cool for the floor electrician at 3 AM.
To that note, he, as the designer, was expected to support the end product at the customer’s site. The advent of modern-day control systems has made it harder for the floor guys and gals to maintain an OEM system, but remote access was not permitted. And service revenue was a line item on the balance sheet.
Some responsibility lies at the feet of the customer, I think. It should be up to the customer to determine whether it wants self-reliance on the machine or not.
However, Ground suggests that having the customer monkey around with the software may not be a good idea. It complicates the support process when the machine builder is called to solve a problem. He relates an incident where a floor electrician downloaded the wrong HMI program to an OIT, which created havoc.
He contends that it is an either/or situation, but it can’t be both.
A note to salespeople: Check with engineering first to see if what you are promising can be done. But engineering can do anything, can’t they?
He also isn’t impressed with the upgrade path that the migration from 32-bit systems has carved. Much cost is involved from upgrading the OIT to the software that it is programmed with. That’s progress, I guess.
I would like to thank Kim for his feedback and thoughts. It is appreciated.
