What do you do, when your scope of work for a project is to re-write an old PLC code in a newer software version, but there is a major roadblock holding you back? This is the position I recently found myself in. The code I was given had no routine names, no tag labels, and no rung comments!
Unfortunately, this is a common problem with some older PLCs. If the program is uploaded from the processor, without the engineer already having a commented copy of the program open, all of the routine names, tag labels, and rung comments are lost in translation. The situation is even worse if the customer does not have another backup of the program, leaving the engineer with a blank code and hundreds of logic rungs to figure out.
Recently, this happened to me with a customer. They were upgrading their old PLC 5 with a CompactLogix, and only had a blank code available. Typically, upgrading old programs isn’t all that difficult, thanks to Allen Bradley’s nice conversion tool designed exactly for that purpose. But, if you were like me and had no backup/copy of the original program and only a blank code, where would you start to decipher this massive puzzle?
Well, there are many different approaches to doing this, but I’d like to share some tips that I followed to make my project a success. I hope that it will make your coding life easier—in case you ever fall into the same rabbit hole that I did.
1. What is the functionality of the system, and what devices do you care about?
This is key. With any luck, there is a functional specification document laying out exactly how the system works. But, if such a document does not exist, talk to your on-site contacts, process engineers, operators, or anyone who can give you information about what this system is supposed to do. This can include different modes the system and various devices operate in, different phases involved, all of the devices in the system, and any weird anomalies the system has. Every bit of information is useful in this scenario, so take detailed notes that can guide you throughout this coding journey.
2. Do you have a list of the existing IO?
Hopefully, the customer has a drawing set that you can look at, or even better, already has a list/excel document of all the IO in the system. Given that everything on the drawings is accurate and up to date, this is the perfect starting point for code development. Before you do anything else in the code, go through and label all of your IO. If you find that you are still missing names for IO actually being used, it may be, that the drawings are not up to date. Be sure to address the problem with the customer as soon as possible.
3. Is there an HMI involved with the system?
Does the PLC talk to an HMI? If you have access to the development environment, this can lead you directly to tag names. Start looking through each template, object, or graphic and make a list of all the tag names you find (bonus points if you’re able to directly export all the tags out of the development environment). Use this as the building block for your code. This was a huge help in figuring out the last 40% of my code. I would look at the functionality of the code and think “oh, this looks like it controls the swap between compressors” – then I would work with my colleague who was working on the HMI upgrade (shout-out to Ian) and look at the tags on the existing HMI related to swapping compressors. Right there in front of our eyes were the tags that I needed to match.
4. Is there a similar system on site?
If you were lucky, like me, there was another similar system on site, that already had an upgraded PLC with fresh new code. This allowed me to go through each routine and line up my routine names, tag names, and rung comments with the same structure from that code. Unfortunately, I was only able to match roughly 60% of what my code had with this other version (mainly because my code was an older version of the system, and in the newer versions they introduced new tags and routines), so I still had some investigating to do.
5. Figure out the Routine Structure
Okay, now all of your IO is in place, and you have either compiled a tag list from the HMI, compared your code to another version of a similar system (which means you can probably skip this step), or you’re still in the dark. Either way, now you can start deciphering how the routines are laid out. There are a few common practices when it comes to writing PLC code, and the main one that I see, is to separate out all of your routines by device name. Start with the first routine and look to see if any IO is involved. For example, if you find an output to open a valve, two inputs for valve feedback, and not a lot of other logic, this routine is more than likely device based. Go ahead and name this routine whatever the valve is labeled and move on to the next routine. Maybe you’ll see multiple outputs being controlled, and some kind of sequencing logic. This is most likely a phase routine. Based on your knowledge of the system functionality, name the routine accordingly, and repeat this process until your routines have a solid naming structure.
6. Find Commonalities
At this point, you should be familiar enough with the code to start picking up on similar patterns in various rungs. For example, if there are multiple valves in the code, they are all probably using the same coding structure. Use your IO and your experience with controls to help you start backtracking your mystery logic. You will more than likely have an auto and manual mode, a mismatched/alarmed state, commands from the HMI for manual mode, other conditions to open and close the valve when in auto, etc. Start labeling logic that makes sense, and the rest of the code will slowly start to fall into place.
By following these helpful tips, hopefully, your code can breathe some new life!
Nick Bozzelli is a Project Engineer for Avanceon, a certified member of the Control System Integrators Association (CSIA). For more information about Avanceon, visit its profile on the CSIA Industrial Automation Exchange.
