One of the first projects I was involved with was in a mining town underground at a base metal operation. This new company was developing a new core drilling machine that would operate underground to pull core out of the rock for the geologists to examine and see where the vein of minerals goes and how to mine it.
The original PLC was a Rockwell Automation PLC-5, which was introduced with sequential-function-chart (SFC) capability, as well. As luck would have it, the distributor said that it would develop the program for the drill, along with the HMI graphics pages for operator interaction.
Also read: The PLC flexes its muscles
The president of the company later told me the story of how he came to use a cane. It seems there was a problem with the hydraulics, so they shut the system down. When they reapplied power, the hydraulic hose flexed and whipped, and it took out the president and almost broke his leg. Torn ligaments however caused him to use the cane. He was not happy.
When I looked at the code, the control strategy that was used was, in fact, SFC. The power circuit has the normal interlocks with one exception. The developer used a retentive output in a chart to turn on the hydraulic pump, and he did not have a startup routine to initialize the system; thus, the pump came on in its last state. This is an example of a bad strategy.
It was very disturbing to see this lack of understanding in such a new control methodology that was used. SFCs have their place for sure, if properly designed and developed.
The IEC-61131 specification/standard really doesn’t tell you or show you how to create a proper control strategy with any of the five languages that encompass the standard. When I was training for Rockwell Automation, I would always try and use practical examples of how to use methods and instructions that would keep the students out of trouble when they returned to their employers.
Well, I was contracted to develop a ControlLogix refresher course for another mining company, which used process skids from five different suppliers. They included a potable water system, a lime application and a carbon kiln for treatment of the ore, among others. I never did see the actual installation, but I had to review all five pieces of code in order to help them with their processes and how to interface with each skid.
Was I ever surprised to see what I saw. I shook my head many times during the process.
The code strategy must have been created with less than experienced personnel in my honest opinion. I would not have created these programs in the way that they were, but that’s just my opinion.
The first problem is that the user did not specify any control strategy at all. While this may be more common than not with OEM-based skids, the vendors all had their own way of doing things. All five were completely different.
Ladder logic was used by all five for the main part of the control. Some used function block add-on instructions (AOIs) for functionality; and the programs underneath were ladder, except for a few AOIs that employed structured text. That in itself isn’t a big deal since the exposed I/O and data values were evident in the instruction.
There was one program that for some reason used a function block program file to schedule ladder-logic subroutines, which is beyond my comprehension. I’m sure the maintenance guys and gals I was developing this course for were not IEC-61131 experts, and I was proven correct. In fact, their computer literacy was suspect when I introduced the concept of objects and context-sensitive help.
What were the vendors thinking? They obviously did not create their control strategies for the benefit of the user. There were so many traps that the maintenance staff could fall into that I had real trouble creating a methodology for them to follow when something wasn’t working right or, in fact, had failed.
There was a lack of obviousness. Intuitive control strategies are needed so that the product and/or process can be easily understood and then fixed when it fails, which of course it will.
The tools that can be used within the software can only take you so far, and the code being interpreted has to allow itself to be used with the tools. Haphazard design creates confusion for the maintenance staff, as well as longer recovery times for a broken process.
I always have preached that a design strategy for the 3 AM crowd will always serve you well. Your control strategy always needs to take that into account. Sleep well.
