A simple solution to source code problems

“Hey Joe, where you goin’ with that laptop in your hand?” Jimi cried out... Now, if you read my last column, you’re probably saying, “Well, there he goes again.” But you see, Poor Joe still has no additional tools to help him diagnose his control problem. He’ll be there for a few hours before he re-learns the process well enough to understand the logic in order determine the problem area and solve the issues at hand. Remember, the only tool he has available is the PLC source code—the modus operandi every time a problem arises.

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?

It’s available to all personnel?

Most maintenance people understand it?

It’s the easiest to provide from an OEM’s 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 don’t 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 vendors—whom I know personally—you 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...What’s 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 Joe’s perspective, I submit that he might have an easier time using a control presentation different than ladder logic. The very reason he’s having a problem is because of that unsophisticated, spaghetti-type ladder logic, isn’t 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 don’t 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 view—and your customers’ point of view—where the process stopped is whole story. It really doesn’t 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

Jeremy Pollard, CET, has been writing about technology and software issues for many years. Publisher of The Software User Online, he has been involved in control system programming and training for more than 20 years. He’ll be pleased to hear from you, so e-mail him at[email protected].