Upgrade PLC5/30 to Control Logix

I'm kind of late to the party, but any upgrade I do I try and rip out all old networks.

RIO? GONE

DeviceNet, hell no, gone.

etc. etc.

Sometimes you just can't.

I just spent an early shift troubleshooting an ordinary 24V short circuit, but on a machine where I added a ControlLogix and a dozen Ethernet-enabled servos.

But the bulk of the machine also consists of 120 Profibus DP equipped servos. To replace them all just wasn't in the capital budget. So I've got a bunch of Profibus DP.

VAN said:

I'm kind of late to the party, but any upgrade I do I try and rip out all old networks.

RIO? GONE

DeviceNet, hell no, gone.

etc. etc.

Click to expand...

OK, they're ripped out. That's half the job done. But what are you replacing them with, Ethernet?

I'm always reluctant to advise the "just do what I do" option when someone is choosing a migration path. It, in my opinion and experience, and once more to the Forum, should be an application driven decision. What is the best fit for the existing machine or process going forward, to achieve the required goal, while also considering the general install base and end user knowledge at the installation, followed up lastly by the cost factors. If the cost for the recommended best option is prohibitive then compromises or alternative migration paths can be considered. This, depending on which option was deemed the best, could drive the migration path towards either all new or away from it to an alternative interim path, such as the one being implemented here.

It is very difficult for any of us, without more intimate knowledge of this existing installation and its users, to blanket advise a "rip & replace" based on our previous and possibly biased project work.

I would also certainly respect ASF's apparent experience portrayed on the Forum as being good enough to have already considered what is the best migration option here.

As for ripping out RIO or DeviceNet networks just for apparently simply existing?...

I could agree, to some degree, that RIO can be troublesome and has had its fair share of niggles over the years for various users, including myself, and the added complexities of configuring block transfers and I/O rack slot addressing has driven some to dementia. The Flex I/O point density v module size is also a negative but I could argue that POINT I/O is similarly lacking. However, the latter's footprint is quite small and they are more intended for moderately smaller installations, such as "on machine" distributed I/O. The use of RIO with PanelView terminals was also one of their more torturous offerings.

But I'll not have DeviceNet tarred with the same messy brush. It is, once properly installed and configured, one of the most robust networking architectures I have ever had the pleasure of working with. Granted, EtherNet/IP is by far the modern preference for CIP based integrated architectures and is indeed the way forward, for now, within the exploding IIoT revolution. But it will take something exceptional that the EtherNet/IP protocol and/or architecture provides, and that an existing DeviceNet architecture requires, before I would recommend replacing a working DeviceNet system with an EtherNet one, just because it exists. Again, if the existing application dependencies do not require it, I would not recommend such a migration path.

Also note how DeviceNet compatibility and functionality is still being maintained through to certain newer AB platforms. It's not going anywhere just yet. Granted, for new installs I would not be readily recommending it by today's standards, but for adding to an existing DeviceNet network, these options are still very important to have at our disposal.

Some installers (not necessarily you VAN) might just be preferring the "newer" Ethernet over "anything" else because they feel they have the necessary knowledge or experience to get and keep them up and running, and perhaps don't have as much of the proprietary knowledge or experienced required to do likewise with the likes of the somewhat more obscure DeviceNet systems. Standardisation may also be a driving factor here. But again, these desicion should not be just based on what suits the installer, with less, little or no regard to what best suits the application, customer or end users.

There is nothing essentially wrong with what each of us normally tends to do in these cases, but that doesn't necessarily mean it's also right for everyone else in a similar situation, that's all.

Regards,
George

Agree what you are saying there George.

I work in an ageing factory, where we still have 25 PLC5 systems with RIO, Panelview with I/O, and others that may also need an upgrade.

I have been asked to look at modernising and prioritising these systems, and each one is different. You cannot just say "take out the RIO", "replace Devicenet" as they each have their challenges.

One system was started as a GE PLC with Devicenet to GE remote IO and small display screens. Now it is a CLX system with the same Devicenet IO as distances between stations are too great to replace with Ethernet IO within the budget. The Devicenet works well, but is sometimes not easy to diagnose problems. The guys were ripping out a panel in a control room, so shifted one of the displays to another location. Then part of the system would not work, as Dnet nodes could not respond. After much humming and hawing, it looked like the dipswitches had been knocked at some point and a duplicate address created, which only caused an issue on a power cycle when they shifted the display.

We have another PLC5 system that has 37 stations on RIO, with part racks used in 35 different panels. That will be a nightmare to cable with Ethernet IO, as racks have been added/squeezed in over the years, but it will have to be done at some point. Mind you, we have about 40 1794-ASB modules spare from other upgrades....
Others have the Panelview with RIO and again cable distance is an issue, or yet another has 1336 drives on Devicenet, so do you go for a PLC5 change, leave the drives as is, or change them out at the same time.

Complexity and budgets are usually the restrictions...and they cannot all be tarred with the same brush. Detailed examination will have to be done on each of them

Geospark said:

But I'll not have DeviceNet tarred with the same messy brush.

Click to expand...

Its my opinion not really a suggestion that covers all situations. I'm more into getting rid of all the junk and rat nest that a lot of companies tend to work around.

Now as far as DeviceNet... I look at DeviceNet like WindowsXP, a lot of people remember it being the gold standard... but the truth of the matter is it died frequently and just wasn't reliable (BSoD). Also, DeviceNet is fairly limited with the amount of information you can push across it.

I just prefer Ethernet for its simplicity and scalability.

I too like to replace and upgrade old networks where I can - it makes my inner millenial happy to see ethernet everywhere. There are definitely situations where it's just not viable - but this application really isn't one of them. It's only a small number of remote I/O chassis and a SCADA terminal on the RIO network, and it'll be really quite simple to use the RIO cables as pull-wires to pull a new ethernet cable through to all of them. The runs are all quite short, and the cost of a few 1746-AENTR's is nothing in the scheme of full CLX and SCADA redevelopment, especially when you take off the cost of the CLX RIO module you no longer need.

Thanks for the additional technotes George, I'll have a look through them as well.

Interesting that AB have changed the behaviour of the COP/CPS instructions with regard to determining the data size to copy. Even more interesting still that they chose to make the change only to a new hardware platform, and not using a firmware update available to all platforms. I mean, I can definitely see how flashing your firmware and having all your COP instructions break might be undesireable, but then again, it would only break ones that had been poorly programmed to begin with so maybe that's a kind of poetic justice?

As to your other point, yes, all my firmware will be well north of v20/21, most likely v30. I won't use either of those versions on principle due to the minor revision SNAFU. And I hope to not have to use v31 until they make it hurt my eyes a little less the 1747-AENTR's will be brand new and shoudl therefore ship with the latest firmware revision as well.

Thanks for all the responses!