Upgrade PLC5/30 to Control Logix

ASF

Lifetime Supporting Member
Join Date
Jun 2012
Location
Australia
Posts
3,907
Hi all,

I have been asked for a budget figure to update a PLC-5 system to a Control Logix, along with the SCADA (will be using Ignition SCADA). The existing PLC is a PLC5/30. It has an RIO network to three remote SLC racks, and a DH+ connection to the ancient SCADA PC. My initial plan is to leave the SLC racks in place, and just swap out the 1747-ASB adaptors with 1747-AENTR adaptors. I know I could get an RIO card for the Control Logix, but upgrading a PLC and buying a very expensive module just so I can leave a legacy network in place makes baby jesus (and also my OCD) cry.

Two questions:
1. One of the remote SLC racks has two chassis, with an interconnect cable between them. Can I connect to both chassis with one AENTR module, or will I need to get rid of the interconnect cable and put an AENTR module in both chassis? I know that the Control Logix chassis can't be locally expanded like the SLC chassis can - you have to use communication adaptors in each rack - but I would still imagine that I can talk to the SLC that way?
2. If I go with an L80 Control Logix processor, are there any potential backward compatibility issues I should be aware of? I've seen a handful of posts about the L8x having a very different platform to the L7x and not being able to work with some older hardware - anything I should watch out for? I can't see any issues within the scope of my current project, but I also don't want to wiin this job, then go back to them and say "oh yes, but this new system can't talk to your old system, so now you need to upgrade that old system too". I'd rather just stick with the L7x and know that I can be as backward compatible as possible.


Thanks!
 
The 1747-AENTR module has a similar capacity as the old 1747-ASB and the SLC-500 backplane chip itself; it can control 30 slots.

As long as your assembly of 1746 chassis with interconnect cables is under 30 slots, the 1747-AENTR can control it. Since the I/O chassis are already working with an -ASB, all the modules should be controllable by a 1747-AENTR as well.

I would personally default to using a 1756-L71 to replace a PLC-5/30. Run the converter utility to get an idea of the order of magnitude of the memory and logic usage, so you can decide which L7x controller is appropriate.
 
Thanks Ken, yes, it's all under 30 slots and working on the ASB, so should be good to go.

I would personally default to using a 1756-L71 to replace a PLC-5/30. Run the converter utility to get an idea of the order of magnitude of the memory and logic usage, so you can decide which L7x controller is appropriate.
Just for my curiosity - why? I've not used the L8x series yet, but in general I figure it's best to use the latest gear on a new installation when I'm developing from scratch. What is it about the L8x series that would make you default to using the L7x series?
 
I'm very conservative when it comes to compatibility, and I know that 1756-L8x controllers have some program, performance, and 3rd party compatibility factors in which they have not caught up with the 1756-L7x controllers.

I wouldn't blink twice on a 1756-L7x, but I'd have to do research for the 1756-L8x.

I was also thinking that because the 1747-AENTR only come in the "R" ring format version, you could use a 1756-EN2TR and get a fault-tolerant Device-Level Ring (DLR) network. Add a 1783-ETAP to connect to your enterprise network.

Right now I've got a 1756-L7x and an SLC-5/05 next to my desk trading MSG instructions and I keep unplugging them and re-plugging them in and trying to break the MSG logic. I could have just sent this to the customer site and been 95% sure they would work fine, but this is a site where there are so many feral gremlins that I want to be 100% sure my messaging and logic and hardware are rock-solid.
 
I'm very conservative when it comes to compatibility, and I know that 1756-L8x controllers have some program, performance, and 3rd party compatibility factors in which they have not caught up with the 1756-L7x controllers.

I wouldn't blink twice on a 1756-L7x, but I'd have to do research for the 1756-L8x.

I was also thinking that because the 1747-AENTR only come in the "R" ring format version, you could use a 1756-EN2TR and get a fault-tolerant Device-Level Ring (DLR) network. Add a 1783-ETAP to connect to your enterprise network.

Right now I've got a 1756-L7x and an SLC-5/05 next to my desk trading MSG instructions and I keep unplugging them and re-plugging them in and trying to break the MSG logic. I could have just sent this to the customer site and been 95% sure they would work fine, but this is a site where there are so many feral gremlins that I want to be 100% sure my messaging and logic and hardware are rock-solid.
Thanks Ken, that's very much what I was concerned about, so I think I'll propose the L7x series for that reason. Good idea also on the DLR network, I'll propose that as one of the options.


Make sure you check rockwell lifecycle status at https://www.rockwellautomation.com/...lity-migration/lifecycle-status/overview.page

Some 1746 modules are obsolete, so make sure you address any they are using. Throw in an option to upgrade the racks entirely, possibly in a "stage 1/stage 2" thing.
The SLC racks are all pretty standard. Just 24VDC DI, 24VDC DO and a handful of analog inputs. All of which appear to be still in the "active mature" phase, so probably plenty of life left in them yet.
 
I'd recommend the L7x for the first conversion.

The L8x is a different beast - it handles instructions differently, it handles communications differently - it is in a different category from the L5x, L6x, L7x. There is code that will happily run in an L7x that will not run in an L8x. Your converted code may not fall into that boat, but be aware.
 
I'd recommend the L7x for the first conversion.

The L8x is a different beast - it handles instructions differently, it handles communications differently - it is in a different category from the L5x, L6x, L7x. There is code that will happily run in an L7x that will not run in an L8x. Your converted code may not fall into that boat, but be aware.
Is there any RA documentation that you know of that goes through some of these differences? Particularly the "handles instructions differently"? I'd like to get more up to speed on this so that I can make an informed judgement going forward as to when an L8x is appropriate and when it is not. So far all I can find is references to there being differences, but nothing on what exactly those differences are.
 
I've used the new L8x series ControlLogix and also its little brother, the 5380 CompactLogix processors a few times now.

There are a few minor differences that I encountered (mostly the 5380) but so far haven't hit a brick wall or anything. To be fair, those were all new installations so I didn't have to worry about any "this code used to work, so why doesn't it now" issues.

The hugely improved scan times and ethernet bandwidth, along with the lower pricetag were the main selling points.

I'd also be curious to hear what known incompatabities are out there. They've been out for over a year now and the only issue I've heard of is the lack of redundancy support.

If you're using an all modern Ethernet/IP network with typical devices, I wouldn't be the least bit concerned about going L8x, but maybe I'm a bit of a risk taker in that regard.
 
Thanks Ken, that's what I was looking for. I didn't expect it to be 172 pages long but I guess I've got some light reading for the plane!


I recently used the 5380 Compact Logix and likewise had no real trouble - though again it was a new installation with the only interfaces being an Ignition SCADA client and some explicit messaging to an SLC5/05. So hardly a thorough test!
 
There's a document named the "Replacement Guidelines" that summarizes the important elements from the User Manuals and contrasts the L8x family (both the ControlLogix and CompactLogix models) with their predecessors.

https://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm100_-en-p.pdf

Excuse me as a non-expert in Controllogix in general and 5580 in perticular.
Out of curiosity I skimmed through the document, and stumpled upon this which I think is an important issue which one should be aware of (from page 70):
Communication Throughput
Unlike 5370 controllers, which shares its main core between application code
and communications, the 5380 controllers run communications
asynchronously from the user application.
This implementation provides better communications throughput in both the
bandwidth and speed of data the 5380 controller can deliver to and from, for
example, HMIs, Historians, and MES systems. It also improves the overall
application performance as the controller no longer has to task switch and
pause application execution to handle HMI or other class 3 traffic.
Because the controller runs communications asynchronously to the
application, make sure communications that are delivered to the controller are
complete before the application executes on the newly delivered data. This
practice applies to both data that comes into the controller and data that
goes out.
For example, if the HMI is writing a large block of recipe data to the controller,
application code can start executing on that recipe data before the data writing
process finishes. This action results in half of the current recipe and half of the
last recipe in the application space.
Traditionally, programmers have used the following techniques to control the
effects of asynchronous communications:
• UID/UIE pairs
• Periodic tasks
• Moving data with CPS instructions
The techniques all rely on controlling when the main core can switch tasks,
thus helping to prevent the communications task from changing data while the
control task used it. Because the 5380 controller processes communications on
an independent core of the CPU, then UID/UIE pairs and Periodic Tasks are
not as effective in all cases.
I might be wrong, but the above mentioned quote seems to point out the issue, but does not provide a solution.
How does one make sure that the data is consistent before it is used ?
 
Notice in the final paragraph the use of synchronous copy is not mentioned as "not as effective." There's a distinct difference in the COP and CPS instructions.
Personally I've been using the L8's since they came out and haven't had to change any of my programming habits, but aside from electrocoating I primarily work in discrete manufacturing, so YMMV.
 
This technote simply refers to the Replacement Guidelines document that Ken also linked...

745492 - Differences and Migration information between Logix 5000 Controllers
Access Level: Everyone

That guide is by far the best resource available.

This technote is not a comparison with the 5570 controllers but does contain a basic FAQs for the 5580 controllers and also links to the same Replacement Guidelines document and others...

732970 - ControlLogix 5580 Controller (1756-L8x) FAQs
Access Level: Everyone

One Q&A in there I found of interest, that I did not know, is How can the controller be reset?, which allows a Stage 1 or 2 reset. It might be important to know for L8x users going forward but I'll let ye read the difference between those yourselves.

Another technote here...

1072549 - FFU Instruction in ControlLogix 5580 and CompactLogix 5380 Controllers
Access Level: Everyone

...and last updated in April 2018, mentions a difference between platforms with regard to the FIFO Unload (FFU) instruction and how a Position (.POS) value of "0" affects the array values. It mentions that this difference is missing from the Replacement Guidelines document and will be added at a later date (still not there in the latest October 2018 release). So that may be of importance for some applications.

While you have not mentioned anything other than Ignition SCADA for visualization, I would add here for additional general info that the 5380 and 5580 controllers require FactoryTalk View v8.20 or higher for Logix projects up to v29. So PanelView terminals and MER runtime applications must also be at revision/version 8.20 minimum. No creating older MER versions for communications with these controllers. Not even v8.10.

For any Logix projects at v30 or higher, for 5x80 or 5x70 controllers, FactoryTalk View v9 minimum is required and similar 9.x terminal firmware/MER version must be used...

769046 - FactoryTalk View ME: Support for 5580 ControlLogix and 5380 CompactLogix
Access Level: TechConnect

This technote just reiterates the v30 requirements...

1030822 - FactoryTalk View Studio, PanelView Plus, Studio 5000 v30 and ControlLogix v30 compatibility
Access Level: TechConnect

JesperMP said:
...quote seems to point out the issue, but does not provide a solution.
How does one make sure that the data is consistent before it is used ?

AutoMax said:
Notice in the final paragraph the use of synchronous copy is not mentioned as "not as effective." There's a distinct difference in the COP and CPS instructions.

Yes, the traditional methods listed, of synchronizing data before sending or receiving/processing, are all fine for use with projects utilizing a single core in a processor. This is because all of the project's processing, and asynchronous communications, are being performed, or shared, on the same application core. Hence, we have the ability to periodically copy certain data at the Task level (Periodic Task), or interrupt to copy certain data at the Program level (COP inside UID/UIE priority pair), or for all data we can use the synchronous copy (CPS) instruction which halts all sources which may update the various types of data. The project has these various tools to help synchronize all types of executing data on this same application core. Using a single core is also why the System Overhead Time Slice (SOTS) is permitted to interrupt the Continuous Task.

When we move to the 5x80 architecture, the application and communications are executed on independent processor cores. Hence, we no longer have the ability to use either Periodic Tasks or UID/UIE priority pairs to synchronize certain data for use within the project. The communications core will update its data irrespective of a Priority Task or UID/UIE priority pair.

I keep highlighting certain data. This is because the Periodic Task and UID/UIE methods may be used to temporarily block or interrupt the likes of source HMI, Message or User Task data. They cannot be used to block asynchronous I/O, Produce/Consume or Motion data updates. For these, we must use the CPS, regardless of which platform we are referring to (5x70/5x80).

The CPS method is still viable for the 5x80 because, and as I mentioned, it has the ability to halt all sources of data manipulation, at the memory access level, giving true synchronicity. This is what it was specifically designed to do. It is intended to be used primarily for asynchronous I/O and Produce/Consume data, and Motion, but can also be used for the likes of HMI and Message data.

The CPS instruction will make itself the highest priority within the project by disabling all interrupts and OS locking. This gives it full priority at the OS and architectural level. It will inhibit the backplane ASIC chip from accessing the processor's I/O memory. It disables memory access for all Tasks, fore or background and no matter their priority (Motion, Communications, Diagnostics, User Tasks, SOTS). This ensures that all data that is copied is guaranteed to be synchronous, even from the separate communications core.

Also note that the COP and CPS will execute differently on the 5x80 platform...

Replacement Guidelines said:
COP and CPS Into Structures
Copying a 10-element array into a 100-element array now moves 10 elements
(limited by the source). As always, copying a 100-element array into a
10-element array only moves the first 10 elements of the source (limited by the
destination
)

This suggests that the COP and CPS instructions will now compare the Source and Destination element or array size to determine the best fit, and then only copy a compatible number of elements, thus avoiding erroneous results. You still need to ensure that you have assigned correct Source and Destination sizes for the correct result, but at least now you cannot accidentally overwrite contiguous memory beyond what was intended.

While you may use the CPS to interrupt all sources of data manipulation; it is still important to follow traditional good practices of not over doing it. Too much synchronous copying can delay important Tasks, both in the fore and background and may increase program scan times, or fault the controller, or external nodes. It should really only be used for exchanging larger data payloads, or anything over 32 bits. The Logix platform can guarantee data integrity up to its native 32-bit architecture. So it would be overkill and unnecessary to use the CPS instruction for atomic word level copying.

Another good practice for helping ensure integrity when communicating data is to use an integrity header/footer element at each end of the data payload. Say, the first and last element in a data array. The Source node will write these a value of "1" and the Destination node will write them a value of "0", once the data is processed. This way you can programmatically detect when both are "1" and the payload has been fully received, then CPS, or whatever method you are using.

This is mentioned in the document but has been advised as good practice for some time now.

ASF,

That's not all intended to advise you for your particular application. It's just me pointing out some things I know of, have found, or can remember to do with using the 5x80 platform.

One other thing popped into my head while writing was a recollection of the 1747-AENTR module and its ability, or inability to add more than 13 slots under one module. But upon investigating I was remembering a few years back where I looked at using one to migrate an existing SLC system which has an expansion chassis (10 + 10 slot). Using firmware revision 1.x 1747-AENTR modules and RSLogix 5000 v20 would only permit up to 13 slots in one chassis for these modules. But firmware revision 2.1 and Logix Designer v21 or above since allowed up to 30 slots in expanded chassis under one module. I'm sure that both your intended module will be at the latest firmware revision, and using either an L7x or L8x controller, the project will be further North or as far North of v21 as possible. Still important to know for other readers considering them for migration with older applications.

I'm not sure if I've actually helped you with anything there, other than some more light reading material?

Regards,
George
 
Last edited:

Similar Topics

Hello Gents, I'm tasked with preparing the replacement of our current "fleet" of PLC5's with something modern and we're going with the Control...
Replies
21
Views
8,019
I am working on upgrading all of our PLC5's to Control logix. My current project has a PLC remote rack 500 feet away from the main rack. There is...
Replies
11
Views
3,856
We wre using plc 5/20 and plc 5/30 in our plant.now the processor is giving some hardware problem. Is it wise to upgrade the processor to control...
Replies
14
Views
7,136
Has anyone had an issue with a PID control after the processor has been upgraded form a L40E to a L80E. It does not seem to be controlling...
Replies
48
Views
5,898
Does anyone know if I can upgrade the firmware in a PLC5/40E from Series C to Series F? I heard it may brick the processor....
Replies
3
Views
2,382
Back
Top Bottom