To Convert or Rewrite? That is the Question.

Finally, your boss agreed to fund a PLC upgrade and he put you in charge.  You’ll sleep better at night knowing you can keep the machine running reliably.  You’ve got the new hardware ordered, so now it’s time to figure out the programming.  Can it just be converted for the new hardware? Does it need to be rewritten? The answer is usually a resounding “it depends.”  Both methods are usually an option in some form, and each has its own benefits and drawbacks. I’ll talk about PLC programming here, but the same thought process applies to HMIs, robots, and anything programmable.

When considering any programming, I think context is important.  Who will work with the program? How often? In what capacity? How long will the program be in service?  What happens if the program has a bug? Ultimately, the program has to perform a certain function reliably enough for the application, and be readable/maintainable for the person/people tasked to do that.  

Convert

When I say “convert” the program, I mean make a program that works on the new hardware and is as similar to the original program as possible.  This can often be automated with tools from the manufacturer, and it doesn’t require full knowledge of system function. For these reasons, it tends to be a lot faster/cheaper than rewriting.  Also, since the program is very similar to the original, maintenance personnel can quickly pick it up. The good and the bad of this approach is that you’ll keep the code how it was – all the features and also any quirks and mess present.  

Rewrite

When I say “rewrite” the program, I’m talking about starting from scratch.  Document every function the machine should perform, every interaction a user might have with it, every fault scenario, and every kind of data the machine should hold.  Then make a program to do that. This can be a significant investment of time – I’d guess 2-3 times as much on average – but it also creates additional value. A 30-year-old PLC program is usually harder to read than a modern one.  They used to be database and address-based, and processing speed often required nonlinear programming techniques like interrupts. Now, imagine that old program after it’s been patched, modified, and tinkered with by countless people of varying skill levels and conflicting programming conventions for 30 years. Can anyone say big mess? Can it be converted?  Yes, but that just perpetuates the problem. In this case, rewriting the program can bring significant benefits to any future maintenance and programming personnel, making their jobs faster, easier, and less error-prone. It will also make the machine function more predictably since messy code often has hidden quirks. On a personal note, I’m usually more proud of the finished product after rewriting the program.  I want to leave things in a clean, readable state, and rewriting is a good way to do that.  

The biggest challenge with a full rewrite is trying to figure out exactly what the machine is supposed to do.  Documentation rarely covers all the important details, so interviewing operators, maintenance staff, and others is necessary.  It also helps to watch the machine run if possible. This may be sufficient, but you don’t know what you don’t know. Are there “audit” and “cleanout” modes that nobody thought to tell you about?  Is there some hidden code that interfaces with another machine that nobody knows about? Has functionality changed since the manual was made? This can usually be figured out during debug, but it’s important to note that there is some risk and it’s hard to predict.

Rules of Thumb

It’s always a good idea to get some professional advice on machine upgrade, but here are some guidelines to get you started.

Reasons to convert:

  • Maintenance is comfortable reading and troubleshooting current program
  • Budget is a concern (most of the time)
  • Program hasn’t changed much over the course of its life
  • Equipment owner doesn’t look at the program (doesn’t have software/expertise)
  • If system is complex (more chance to miss details, more effort to define/implement)
    • Lots of recipes or different products?
    • Lots of manual functions?
    • More than 40 IO?

Reasons to rewrite:

  • Original program can’t be retrieved
  • The system is simple
  • Maintenance isn’t comfortable reading and troubleshooting current program
  • Current program has undesirable quirks
Jon Breen

About the Author

Jon is an engineer, entrepreneur, and teacher.  His passion is creating and improving the systems that enhance human life, from automating repetitive tasks to empowering people in their careers.  In his spare time, Jon enjoys engineering biological systems in his yard (gardening).

Leave a Reply