Converting Old PLC Code: Benefits and Pitfalls

Converting Old PLC Code: Benefits and Pitfalls

Sounds great, doesn’t it? Buy the new programmable logic controller (PLC) equipment, run the old PLC code through a translator program, and the new system is up and running. Now to give credit where credit is due, very few people would actually believe a control system upgrade would be this easy. What are the pluses and minuses of converting code compared with rewriting it? Why are some systems well suited for this approach and others problematic? This article looks at some of the issues related to converting PLC code and provides some insight into ways to capitalize on this technology without some of the problems that may result.

Why convert compared with rewriting the software? The quickest answer is cost. But is that the correct answer? While it may not take much time to run a translation tool on the old code to create the new, how much extra work is required to get the new program fully operational? Most translation tools will have the disclaimer that they don’t translate 100 percent of the code and have a fairly long list of items that need to be manually handled — and this is if you’re staying with the same manufacturer. If you are switching brands, translation tools may not be available. It is possible to have custom software written to do the conversion, or just do it manually (which may not be practical for a large program) but these alternatives may add significant cost.

How good is your base?

The usefulness of converting an existing program depends on its condition.

• Is the source code available in editable form, i.e., the program and programming software exists electronically?
• Is the source well documented with rung comments and meaningful symbol names?
• Is there a document that explains how the program is organized and how it works, maybe in a technical manual from project commissioning?
• How much of the program is still applicable? There may be equipment included in the program that no longer exists, leaving “dead code” for disconnected inputs and outputs. If the code is no longer needed, delete it.
• Is the technical staff intimately familiar with the existing logic? If so, it may be easier to maintain translated code than to learn a new program. If not, then it may be better to have a new, well-designed program that’s easier to understand.
• Finally, does the existing program operate consistently and problem free for the most part? There could be sensor, actuator or wiring problems that get lumped in with the control system here. In this context, we’re just talking about the logic. Does the program ever “lock up,” requiring a restart? If you translate a bad program, you end up with a bad program translated.

Supporting engineering materials are useful regardless of whether you are converting the program or not but can be invaluable if you decide on a rewrite. This includes a functional specification, process and instrumentation diagrams (P&IDs), state transition diagrams and electrical schematics. Are these materials relatively up-to-date  and accurate?

In the worse-case scenario, there is no original source code and no documentation as to how the system was designed. While you may be able to upload the existing code, we would not recommend converting any but the simplest ladder logic programs. We recommend doing an initial engineering phase to fully document the existing system and developing a new program with modern software and programming tools.

After-Conversion Expectations

What do you expect to end up with when the conversion is done? If the converted system just needs to work exactly as it does now, then translation may be a good choice. If your reasons for the new PLC includes making significant operating changes, incorporating new equipment or meeting new regulatory requirements, then it’s probably a better idea to rewrite the program.

Thoughtfully considering the design may also lead to combining smaller systems into one new PLC, or incorporating functions from another device (e.g., a computer) into the more powerful and capable PLCs offered today. This step may also help justify the conversion cost over just replacing an obsolete device.

Issue 1 – Decide how to convert the data structure

Let’s say you have a good base to start with and decide to translate the existing program. One of the first options to consider is do you want to keep the existing data structure or move to the new processor’s structure?

Older central processing units (CPUs) are organized around data types. For example, bits are stored in a bit table, integers are stored with other integers, real numbers with real, timers with timers, etc. For the control of any particular device, say a variable frequency drive (VFD), one might have a few bits, a timer, a couple integers, a real or two, and a counter. These are selected as elements from the various data tables to be used in the logic for the VFD.

New CPUs are object-oriented. Our VFD data is built as a template (i.e., user defined type or UDT), where each item is added to the template with a meaningful name and description. The UDT is replicated for each object of that type. So if there are 20 VFDs, you would have 20 instances of the VFD UDT, each named for the specific drive. And each one would have all the signals included in the UDT for that object (e.g., M101.bRunning). Once the tag is created, the actual memory used is handled behind the scenes by the operating system.

Translation tools generally don’t have enough smarts to map from data type organization into the object-oriented one. What you’re left with as a result is a whole collection of tags (as named from the previous data element name) to be used to troubleshoot a VFD.

Issue 2 – Are the symbol names useful?

Translation programs may give the user the option of using the symbol name (if it exists) to generate the tag name, or just using the data element name to generate the tag name. If the program is well documented, the symbol names are the best way to go. If there is only a smattering of existing names, or if you generate the program by an upload with no documentation available, then you are stuck with the element names.  After translation, you may wish to spend some time documenting the data element names with a useful description in this case.

Issue 3 – Determine how the new program should be structured

Older CPUs have one program, which may include a series of subroutines, jump statements/targets, interrupts and other mechanisms, but at the end of the day only a single program. New CPUs have significant capabilities not only to separate code into modular chunks, but to allow the modules to be called in a variety of ways including sequential, timed, interrupt and on error, along with prioritization between modules. They even allow new language elements to be created for key functions as add-on instructions (AOIs).

Both the data structures and code modules must be manually implemented but add significant value to the long-term support of the control system. Specify that these extra steps are needed when undertaking a code conversion project

Not All-Or-Nothing

Converting the old code doesn’t need to be an all-or-nothing proposition. Some of the old program logic may be quite useful and provide key sequencing, interlock and alarm information that can save time compared with rediscovering these design details. Pick the best useful parts of the old and use them in the new program, while taking advantage of object-based tags and new capabilities.

Fundamental Changes

Even if you run exactly the same code from the old processor in the new one, it may not work exactly the same way. New processors will execute converted code differently because their internal architectures are significantly different. This may result in unexpected results. Here are some things you might see and ideas to mitigate the problems.

• New processors are fast. Older PLCs may have code optimized to squeeze every bit of performance from the processor of the day. For example, conditionally scanning blocks of code is a way to reduce scan time, but was often confusing when troubleshooting because it was not obvious some of the code was not being scanned. Consider moving each block to a separate routine or removing the instructions that cause the code to be skipped. Previously skipped code may require some individual edits to make it work properly when it is executing every scan.
• Old and new processors handle input/output (IO) updates differently. Old processors had all IO updated at ends of scan. New processors usually update asynchronously to the program scan. If programs include IO mapping routines, this will probably solve the problem; the program logic should not use the actual IO image table as the data may update as the logic is executing.
• Old logic may count scans for delay periods or some other scan-based logic. Changing these to timer-based logic should solve the issue.
• If changing from one brand to another, logic networks may be executed in a different order (brand M vs. brand A in particular). Often this can be mitigated by breaking down more complex networks into a number of rungs with less complexity.

HMI Considerations

Don’t forget about the human machine interface (HMI) when making control  system upgrades. If you plan to reuse the existing HMI, you will most likely need to readdress the tags the HMI is accessing at a minimum.

Some very old systems use HMIs of a style that are actively controlled by the PLC code (think terminals or data displays). There may also be PLC code that reads an active screen number in the HMI and performs logic based upon that screen being displayed. In these cases, a new HMI will be needed and may require new PLC code to support it, plus removal of old code no longer needed.

Inter-processor Communications

If the old system is not connected to any other PLC systems or networks, inter-processor communication is not a concern. However, many installed systems are modified over the years as a data source for reports or provide information upstream or downstream in the process.

If you are lucky, the old program contains a message instruction that includes the source and destination data address, processor, and under what circumstances the message is exchanged. If not, there may be devices that read and even write information from the old PLC without any indication of it in the program. Unless there is some local knowledge or documentation of this, you may not discover it until the data is missing from the report or screen, and may need to add it back. (Use messaging this time.) If the data is used for an alarm or interlock, it may need to be resolved quickly. If possible, test for this case as early as possible by disconnecting or shutting down the old PLC as a test prior to the conversion.

Testing Converted Software

Once the new PLC program is ready, it should be tested thoroughly before being placed into operation. The testing may use simulation software or actually run in a “shadow” mode prior to being allowed to control. In shadow mode, the inputs are run to both systems in parallel and only one set of outputs is allowed to control (generally the old system). If the new system is using the same IO, transfer the IO image to execute the new logic. Software is configured to detect any differences between the two sets of outputs, and then differences are logged to a file or database. The shadowing is complete when all of the differences can be resolved.

Depending on how much code is converted and how much technical information is available on the old system, testing can be tricky. If you don’t know exactly how the system should work, how do you evaluate if it’s in fact working properly? Having the engineering basis for how the system operates is another benefit of a rewrite.

Conclusion

Converting old code to run in a new process can be an effective, fast and low-cost way to get new controls in and working. It can also result in software that never quite works right and is very difficult to understand, troubleshoot and change when needed. This article outlines some of the issues often encountered in control system upgrades and provides considerations so that you can end up with a properly working program that is maintainable into the future. If you need help deciding the best way to implement your new PLC, give Matrix Technologies a call.

Matrix Technologies is one of the largest independent process design, industrial automation engineering, and manufacturing operations management companies in North America. To learn more about our industrial automation capabilities and manufacturing process control solutions, contact Dave Blaida, PE, CEO & President.

© Matrix Technologies, Inc.