Biggest obstacle one faces in migrating to newer system

I just want to get others thoughts on what is the biggest obstacle one faces in migrating to a newer system?
For me with the few systems I have done would be is deciphering someone else's code especially with no documentation.

For the most part if the process is staying the same, the logic should migrate to more modern hardware fairly smoothly most times. I've found indexed addressing from PLC-5 era controllers can get complex and lost in translation.

But it can also be a moment if you grasp the process, rewrite and make it your own. Often flaws from the existing design can be improved upon and operators can have input for added functions/processes.

Well that would depend on what is a new system... SLC to ControlLogix...

Control Logix to Fanuc...

Total lack of a good IO List with no docs added to points for what they are... have to go through every routine and every rung.. Identify everything.

I'm embarking on a replacement of a system controlling 4 reactors and 2 mixers. The documentation I have is from the previous PLC (not the existing one, the previous Toshiba Ex500). The existing code running on SLC is really awkward to read and understand as it's pointers galore.



And the plant doesn't really have an awful lot of space available.



The software side isn't really the challenge, we know what it does, we want a DCS style control system and added functionality and more safety layers and can describe it pretty well.



The issue is that we will have 3 weeks to swap over, test and commission. So we're looking at building everything new with IO next to the reactors and a field network, new PLC and when the plant shuts down we start connecting the instruments and replacing the backplate of where the existing PLC sits now.

I think time is going to be the most common issue mentioned here.

Migrations

As an IEC-1131 fan I believe that the more the old and new systems conform to 1131 the better things will go at migration time. This may be wishfull thinking for the future as a lot of the migrations that are going on right now are from pre-1131 processors.

It seems that byte ordering doesn't come up very often in processor migrations anymore. Maybe they largely disappeared when companies tended to switch from Motorola to Intel processors years ago.

I'm involved in a migration right now that is going from an intel-based CPU to an ARM-based cpu. The register aligment on real and double-integer variables is causing a lot of extra work since ARM tends to be fussier on address alignment.

There's a few notes on migrations in the PLC class outline at corsairhmi.com. The biggest point is DO NOT trust any manufacturers code translation software. It can serve as a starting point for the work but that's all it can do. I got paid several thousand dollars a few years ago for updating some CPUs where the customer believed the manufacturer about what could be done with the translation software.

I wish you well with your project.

Biggest challenge for running plants is minimizing downtime for migration.
I recommend you read old logic, write new functional descriptions, have all agree on path forward, programming wise.
I am against migration tools that auto convert logic, never the best way.

I have been involved in a number of projects to upgrade systems and for the most part using totally different hardware i.e. from Modicon or Ferranti to Siemens, on the Ferranti, the I/O was on plugs (Harting type) so we were able to build looms from the new PLC I/O to sockets then just plug them in, it also had a Factorylink Scada system on it as well.
In short, we took the original software (a sort of basic come pascal come C if I remember correctly) we were given time to write the SDS & FDS, simulate the software before taking it to site, the PLC panel was in a new cabinet & it took us a day to change over, a day to do I/O & function checks and sit there for another week while in production, so planning & testing is key, in reality the plant was only down for two days. The customer decided the PLC hardware as it was their latest standard, software test simulations were done in our offices with the customers engineers & operators, a couple of nights out with them sealed the relationship & spending a week with them on production runs became a pleasure.

In my opinion a more hazardous subset of poorly-documented code is code that has been abandoned in place. Often it relates to hardware that has been removed or decommissioned, or it was implemented to perform a function that never worked correctly.

That's one of the hard decisions to make: "does it not work because the conversion is wrong, or because it never did ?"

I worked on a machine this week that had just four lines of comments in several pages of BASIC-like control scripts, and one of them was "This is largely self explanatory", before an array of POKE instructions to numbered physical memory addresses.

Experiences like that often stir resentment against the last guy, but should also spur humility and a renewed effort to ourselves not be the one who left poorly documented code behind.

Another big challenge is custom or complicated HMI and enterprise software.

That same machine has a custom-written HMI with custom-written communication drivers, and of course the author retired two years ago. All we have is the compiled executable.

Maybe what irritates me the most is that the executable opens up a little diagnostic CMD window console, and the very first line it prints is his copyright notice and "Version 1.00".

Mgw1970 said:

I just want to get others thoughts on what is the biggest obstacle one faces in migrating to a newer system?
For me with the few systems I have done would be is deciphering someone else's code especially with no documentation.

Click to expand...

I'm not sure that I can rank the obstacles. But here is my list:
- feature creep. Adding things to the scope 'since-you're-changing-it-already'. From Operations, from Maintenance, and from your programming peers (or even YOU)
- keeping the system running while you change one piece at a time. Most of my upgrades have been done on 8 to 12 hour downs. Getting the old system to talk to the new system with no changes to the old system is quite a challenge
- wiring. If you replace wiring, it takes time to run it and terminate it. If you keep the old, you have to .. usually .. mess with the IO order since the wires are not long enough to reach the new IO terminals. This causes drawings changes, programming changes, and documentation changes that never seem to quite match what you have
- operators not remembering how it worked, or if it worked. People's memory is not perfect. They may truly believe that it used to do THIS .. but that's not what the code says. It does THAT, and always has. Particularly troublesome on activities that are done once a year, or less often.
- time to commission the new system and verify that alarms and safeties still work. Operations always gives it to you late and wants to start it early to work out the bugs.
- surprises. Everything you know about, you can create contingencies, alternates, backups plans. What you DON'T know about, you can't plan for. So it bites you in the A**. And the scramble is quite stressful!
- orphaned code. Parts of the HMI, the PLC code, the wiring .. that were changed. But the IO wiring is still there. No doc in the other 2 but there are wires. Or PLC code that references IO that no longer has wires. HMI code that sets and clears bits that the PLC does not reference. It takes a lot of time to clean all of this stuff properly up when you remember what was done. It's VERY time consuming to clean it up when you have to investigate drawings, code, and graphics that you have no idea if it still works, never worked, or is a pet project that is future and no one else was told about.

Your biggest obstacle is going to be your attitude.

Don’t go into it thinking “aww this sucks, because I already know this system”. Or “this is stupid why would they do it like that, we’ve always done it like this”, etc, etc.

Take your time, ask questions and proactively teach yourself about it. Don’t expect for someone to hold your hand.

Biggest obstacle is always the time allowed to test the system with new plc and software.
Another obstacle is if you don't succeed in the time allowed can you put the system back to what is was before you started.
Another obstacle is since your shutting power down, do you have spares for components that don't power back up. Its always a VFD that goes south. Since its a VFD or other device, do you know what parameters are changed on the unit?

Sometime, it's almost easier to just program it as if it's an green-field system. As other said, there are always too much abandoned code and it may not be worth it to decode every line of old code especially if the last programmer went "off the reservation".

When the down time is of the essence, planning and testing are your best friends.

Something as simple as where you place terminal strips and how you lay them out can make or break the project.

Walk through every step of the retrofit many times documenting each task. You will find things you never thought of at the outset; you'll discover tools you will need that you didn't think about.

Do mock run throughs with everyone involved and get as many eyes on the process as possible. Each participant will see things a little differently and point out things others may have missed.

Getting one of these right gives you an awesome feeling. Getting one wrong leaves a bad taste in your mouth for ever.

Undocumented wiring changes

A written methodology statement is a great tool for making you fully think through each step, and for allowing others to check your thought process. Plus, when the client signs off on it then there's shared responsibility to make it work.

I did a wastewater pumping station PLC upgrade from a modicon Quantum 534 to a M580 hot standby. The station overflows in 90 seconds at peak flow if no pumps are running (4000L/s rated flow). We had about 5 minutes at normal flows though, so every part of the job had to be planned with the possibility that we'd need to pull the pin and stop work if a storm event occurred, so we had to be able to have 10 pumps operational by the end of each day.

My methodology statement was about 70 pages long, down to the detail of "move wire labeled 30034 to terminal T34. Enable level sensor LIT301 in new PLC. Uncomment MOV instruction #56 to copy value back to Quantum."

It took about 3 weeks to write and plan it, and about the same amount of time to move over all the wires to new terminal blocks, 1 at a time, keeping as much operational at any one time as possible. My colleague did all the code, I did the wiring. The plant manager came down for a look-see after day 2 and nearly had a heart attack when he saw what the PLC panel looked like. I think he thought it would stay a birds nest once we were finished!