Why do we put so much faith in the source code (typically ladder logic) as the premier troubleshooting tool? Is it because:
The source code is a representation of the process?
Its available to all personnel?
Most maintenance people understand it?
Its the easiest to provide from an OEMs point of view?
It has been an accepted management practice that troubleshooting should begin with the control software. Many dollars have been spent on training and products to help the troubleshooter understand the control language (read ladder logic)the first line of defense. Has this scenario actually disadvantaged OEMs?
Yours is a very tight margin business, and additional tools might make the product more expensive. If the customers dont recognize these benefits, they are not going to pay for them!
Enter the new paradigm of control programming: flowchart and IEC-61131. Flowcharting software uses standard symbols to create decision and control blocks. The control and decision blocks individually can envelop groups of statements that execute control logic. Behind these blocks can be a collection of additional flowcharting sections or ladder logic.
The Sequential Function Chart (SFC) presentation language is similar to flowcharting in that steps (Control Blocks) and transitions (Decision Blocks) are created to control logic flow. Behind the steps and transitions are ladder logic (RLL), instruction list (IL), function block (FB) or structured text (ST). The level of encapsulation of control logic is limited only by the design of the control program.
The control engine is typically PC-based, not PLC-based, so the reasons for using either of the above as a control language or presentation in any given application is a personal choice.
Listening to the vendorswhom I know personallyyou hear that their software solves the age-old question: Can you use the source code as the ultimate troubleshooting tool? Their answer is an emphatic yes.
But wait...Whats the attraction? Simply put, it is the idea of having the source code tell you where the process has stopped. Presenting the control logic in a top-level form where the decision block or transition point flashes at the troubleshooter person accomplishes this. It screams out that the process has stopped here because the last transition or decision point has not been traversed.
Is this of any benefit? Vendors, as well some users, say yes. From Joes perspective, I submit that he might have an easier time using a control presentation different than ladder logic. The very reason hes having a problem is because of that unsophisticated, spaghetti-type ladder logic, isnt it?
Standard PLC ladder logic can be organized and presented in a similar fashion. In fact, the flowcharting guys put in ladder logic at the request of their customers. I guess they like ladder for control but agree that it needs to be dressed up.
As an OEM, you can provide the same troubleshooting benefit by simply organizing the control logic properly, and that will lead to the Holy Grail: Where did the process stop?
Breaking the process up into steps (which you have to do in flowchart or SFC) will define the transitions for you. This is akin to a sequence of operations (SOA) where each step has a beginning and an end. Sequencer-type instructions in PLCs define the SOA in PLC language.
If you dont use a sequencer-type instruction, then define a register as the step register. As the steps of the process are sequenced, the value in the register is incremented. The value in this register will tell anyone where the process is stalled. Simple. Then Joe knows where to go to begin using his troubleshooting skills.
SFC and flowcharting have other benefits, but from your point of viewand your customers point of viewwhere the process stopped is whole story. It really doesnt cost anything and provides a great selling tool as well. Presenting the stall point, in any way, will provide far-reaching benefits for all.
About the Author |