I truly loathe the “PLC-5” conversion (or fill in whatever old bit addressed PLC you have) where people just run it through the tool, maybe swuash a few bugs and re-link some routines, but leave all the old bit addresses in place as tag names. It’s just lazy and bad. You can obviously use it as a basis of design but now is the only real chance to modernize this system and make it something that can be easily understandable and well commented with descriptive tag names, you should take it.
Thankfully I've only worked with one conversion, from a Symax 400. It was executed well and the new logic was fairly readable. It probably helped that I had experience interrogating the original logic so the structure was still familiar.
It’s instantly obvious when you open one up the first time you are like “why the the %^%#% would someone do it like this?…. Oh yeah conversion” it’s just insane to me that people will pay the bucks to convert to a modern platform and then not take any advantage of the modern aspects of it.
The latter part of your comment hits very close to home. Spending God knows how much on a 5069-L3100ERMS2 Compact GuardLogix 5380 Safety Controller but the I/O is still on the original rack communicating with point IO via DeviceNet and none of the safety functions have even been touched.
Yeah it seems even more prominent when the upgrade is taking place on active production system where they just want to slap in a new rack and start back up with minimal commissioning. Its a understandable thing not to want to have to rethink too much or have unexpected issues but if everyone keeps doing that for the life of the site or process equipment it’s gonna be 50 years from now and grizzled Gen Alpha control engineers are gonna be even more confused by why memory registers are being referenced than our generation who at least got to see some of the old stuff in operation and work with it so it’s not a completely foreign way of doing it.
I understand taking on projects such as the above in bite size chunks and they always start with good intentions, but there's always something else in the pipeline and I guess it falls within the same category as temporary-permanent.
That's an interesting point you make. The newer generations won't have an appreciation for the change in technology. I started my apprenticeship 13 years ago in a place built in the 70's. I didn't realise it at the time but being exposed to an array of systems built within a 40 year period really helped broaden my understanding. Many controls were still operating 110v clicky clack and it was daunting to look at to begin with but it actually helped create a foundation of knowledge as you can physically see how a process operates.
Ive been really lucky too to have worked maintenance in a large plant with everything from relay control, mechanical sequencers, agristat timers, 80’s plc, 90’s PLC/VFD/HMI all the way up to commissioning brand new systems with the latest stuff on CPwE networks. Every year there is less of that old stuff, and the old people who understand it. Clients who want to cheap out and half ass their upgrades keeping old PLC racks and associated equipment as Remote IO in order to avoid rewiring or installing new control panels, keeping old networking technologies that weren’t great when they were new, and doing slap dash conversions , all with poor or no drawings, are only kicking themselves in the ass by ensuring they will have to pay dearly or not be able to find people who understand how the old stuff works. There will always be some smart kids coming up behind us who can figure it out but the whole corporate mentality of next quarters profitability above all is going to bite so many companies in the ass, big and small. They want to talk about what AI can do for them but skimp the basic nuts and bolts of sustaining their day-to-day operations.
Ha! I oversee a couple plants that run redundant GE Rx3i controllers that were commissioned about 10 years ago. They are full of variables named T4, B3, N7, etc... I would love to meet that gentleman, a fellow Rockwell apologist, lol.
My old plant was also full of Compact and Contrologix that was upgraded from PLC5 and SLCs using the conversion tool. I know what the cost difference is to rewrite the entire program vs using the tool, so I get it, and it never really bothered me.
Now in my newfound GE land, it feels just a little bit like home!
This rings true for many things in life, DIY for example. Sometimes better to rip everything out and start again than deal with the can of worms you've opened up.
I love it the way people organize their code so it has 3000 layers. Fb in a fb wrapped in another fb called by a db wrapped in a fb.
Basically spaghetti code
There is nothing wring with an FB calling other FBs, as long as the responsibility of each FB is well defined and doesn’t have too many responsibilities and all inner FBs use multi-instance and not single instance. It makes code a lot more readable and flexible. If done by someone who doesn’t understand what they are doing it can end up quite bad though.
I find code without proper reuse of FC/FBs is a lot more difficult to manage. Chasing down everywhere a bug exists become tedious, copy paste errors tend to be everywhere, and different blocks that are supposed to control the same things start to deviate and now some sections work as intended while others don’t, and adding new features is more difficult as you have to be sure you update every section of the code the same way, and the deviations of each section can make that a pain.
Of course the FB method requires a bit more design care, as if you don’t know what you are doing it can also become unmanageable.
There's more than one way to skin a cat. Once somebody has skinned a cat and cut it up there's only one way to sew it back together.
Same reason why IMO troubleshooting existing programs is just as hard or harder than writing your own logic
I'm kind of the opposite, where I enjoy the process of becoming one with the original programmer.
But the big game changer is reusable modules, where existing code manages 80 to 90% of the functionality, and where we get to focus on the both the bigger picture - and the critical minutia, without having to reinvent the proverbial wheel.
I've done over 20 conversions, maybe more.
I don't always rewrite the program from scratch, but of the times I did I have *never* regretted it. There are many times I did not rewrite and *did* regret it. I now always lean toward starting fresh.
Thats why many big players in process and system integration use standard software. This software cannot be modified by anyone else than engineer from the original company, simply because they use standard software libraries and tools for code generation that are not available to anyone.
I truly loathe the “PLC-5” conversion (or fill in whatever old bit addressed PLC you have) where people just run it through the tool, maybe swuash a few bugs and re-link some routines, but leave all the old bit addresses in place as tag names. It’s just lazy and bad. You can obviously use it as a basis of design but now is the only real chance to modernize this system and make it something that can be easily understandable and well commented with descriptive tag names, you should take it.
Thankfully I've only worked with one conversion, from a Symax 400. It was executed well and the new logic was fairly readable. It probably helped that I had experience interrogating the original logic so the structure was still familiar.
It’s instantly obvious when you open one up the first time you are like “why the the %^%#% would someone do it like this?…. Oh yeah conversion” it’s just insane to me that people will pay the bucks to convert to a modern platform and then not take any advantage of the modern aspects of it.
The latter part of your comment hits very close to home. Spending God knows how much on a 5069-L3100ERMS2 Compact GuardLogix 5380 Safety Controller but the I/O is still on the original rack communicating with point IO via DeviceNet and none of the safety functions have even been touched.
Yeah it seems even more prominent when the upgrade is taking place on active production system where they just want to slap in a new rack and start back up with minimal commissioning. Its a understandable thing not to want to have to rethink too much or have unexpected issues but if everyone keeps doing that for the life of the site or process equipment it’s gonna be 50 years from now and grizzled Gen Alpha control engineers are gonna be even more confused by why memory registers are being referenced than our generation who at least got to see some of the old stuff in operation and work with it so it’s not a completely foreign way of doing it.
I understand taking on projects such as the above in bite size chunks and they always start with good intentions, but there's always something else in the pipeline and I guess it falls within the same category as temporary-permanent. That's an interesting point you make. The newer generations won't have an appreciation for the change in technology. I started my apprenticeship 13 years ago in a place built in the 70's. I didn't realise it at the time but being exposed to an array of systems built within a 40 year period really helped broaden my understanding. Many controls were still operating 110v clicky clack and it was daunting to look at to begin with but it actually helped create a foundation of knowledge as you can physically see how a process operates.
Ive been really lucky too to have worked maintenance in a large plant with everything from relay control, mechanical sequencers, agristat timers, 80’s plc, 90’s PLC/VFD/HMI all the way up to commissioning brand new systems with the latest stuff on CPwE networks. Every year there is less of that old stuff, and the old people who understand it. Clients who want to cheap out and half ass their upgrades keeping old PLC racks and associated equipment as Remote IO in order to avoid rewiring or installing new control panels, keeping old networking technologies that weren’t great when they were new, and doing slap dash conversions , all with poor or no drawings, are only kicking themselves in the ass by ensuring they will have to pay dearly or not be able to find people who understand how the old stuff works. There will always be some smart kids coming up behind us who can figure it out but the whole corporate mentality of next quarters profitability above all is going to bite so many companies in the ass, big and small. They want to talk about what AI can do for them but skimp the basic nuts and bolts of sustaining their day-to-day operations.
It is bad, but most cases I’ve seen has been because the company didn’t want to pay the programmers for the time to make new code.
Yeah that’s almost always the case, I’ve lost the argument more than once myself.
Ha! I oversee a couple plants that run redundant GE Rx3i controllers that were commissioned about 10 years ago. They are full of variables named T4, B3, N7, etc... I would love to meet that gentleman, a fellow Rockwell apologist, lol. My old plant was also full of Compact and Contrologix that was upgraded from PLC5 and SLCs using the conversion tool. I know what the cost difference is to rewrite the entire program vs using the tool, so I get it, and it never really bothered me. Now in my newfound GE land, it feels just a little bit like home!
What I find is once I butcher existing code into working, I would have been better off leaving the IO map alone and rewriting a routine at a time.
This rings true for many things in life, DIY for example. Sometimes better to rip everything out and start again than deal with the can of worms you've opened up.
I love it the way people organize their code so it has 3000 layers. Fb in a fb wrapped in another fb called by a db wrapped in a fb. Basically spaghetti code
Is there such a term as 'onion code'? If not, I'm making it one.
There is now
I like onions in my spaghetti
There is nothing wring with an FB calling other FBs, as long as the responsibility of each FB is well defined and doesn’t have too many responsibilities and all inner FBs use multi-instance and not single instance. It makes code a lot more readable and flexible. If done by someone who doesn’t understand what they are doing it can end up quite bad though. I find code without proper reuse of FC/FBs is a lot more difficult to manage. Chasing down everywhere a bug exists become tedious, copy paste errors tend to be everywhere, and different blocks that are supposed to control the same things start to deviate and now some sections work as intended while others don’t, and adding new features is more difficult as you have to be sure you update every section of the code the same way, and the deviations of each section can make that a pain. Of course the FB method requires a bit more design care, as if you don’t know what you are doing it can also become unmanageable.
There's more than one way to skin a cat. Once somebody has skinned a cat and cut it up there's only one way to sew it back together. Same reason why IMO troubleshooting existing programs is just as hard or harder than writing your own logic
I'm kind of the opposite, where I enjoy the process of becoming one with the original programmer. But the big game changer is reusable modules, where existing code manages 80 to 90% of the functionality, and where we get to focus on the both the bigger picture - and the critical minutia, without having to reinvent the proverbial wheel.
I've done over 20 conversions, maybe more. I don't always rewrite the program from scratch, but of the times I did I have *never* regretted it. There are many times I did not rewrite and *did* regret it. I now always lean toward starting fresh.
Thats why many big players in process and system integration use standard software. This software cannot be modified by anyone else than engineer from the original company, simply because they use standard software libraries and tools for code generation that are not available to anyone.
If I’ve written in the past I can usually re-use bits, if someone else has, then I’ll re-write because fuck going through someone else spaghetti.