One ACD - 7 Identical PLC's

Hi all,
I have a plant that has 7 identical production lines, each controlled by a 1769-L36ERM PLC running 32.11 firmware. These systems are as identical as they can be, by design. Same IO tree, same IP addresses in the devices, including the PLC itself. Each line has an identical control panel, with the only difference being a 1783-NATR router with different NAT rules. Same private IPs, unique public IPs.

So given all of this sameness, I had decided that maintaining a single ACD file rather than 7 would be a good idea. To that end, I created a master template program, and downloaded it to each of the 7 PLC's without issue. My thought was that after doing so, I could then go online using the one original template file with any of the PLC's by only changing the comms path to point to the desired target. However, this file requires an upload or download upon connecting with any PLC but the one used originally to create the template. After each download, I did save a unique copy of the template, and those copies go online with their respective controllers just fine, and each line works as far as process control, so no issues there.

In a nutshell, I'm not able to detect any differences between the template file and the saved copies that should prevent one going online with any other. The only difference I can see between each controller at this point is the serial number of the PLC itself. Has anyone else tried to do anything similar and found the secret handshake I'm missing here?

Welcome to Rockwell world... I don't think you can do what you want to do.

It looks at the Controller Serial Number for a match. Check out the Advance Tab on the Controller properties page. There is a match serial number check box. Not sure if unchecking box will allow you to do what you want but, if box is checked you can change the serial number. Or maybe clearing serial number will work?

Going from experience, one program for more than one device will soon be made useless by the customer.

One of the lines is GOING to be updated with a change to the operation, or added feature, not added to the others, and it will then have a different program. I have gone through this with sister machines built for Right or Left or Front or Back parts and each time one of the 2 had a change requested by the customer - and only that one.

Best to have 7 .ACD files in the folder, each named with the line number for that PLC.

+++ Aabeck

Aabeck said:

Best to have 7 .ACD files in the folder, each named with the line number for that PLC.

Click to expand...

This is good advice, clearly named .acd files and clearly labelled controller names is ultimately a better choice.

1 file for 7 plcs is great on paper, it rarely works out like that a few years down the road.

cardosocea said:

Welcome to Rockwell world... I don't think you can do what you want to do.

Click to expand...

We were in a similar situation (L33ERM, 9300-ENA, v24) with 11 identical machines. I submitted a tech support case for the issue raised by dcooper33, and the response was basically "yes, that is the way it is." Something about a changelog file storing the specific path of the last save. This was a long time ago, so maybe there is now a work-around.

Though, in my experience, the benefit of maintaining one offline file (vs. individuals) outweighs the problems, such as usually needing to upload when going online, and added code to identify the machine (via processor serial number) for data display and collection. The success of this approach depends on how identical the machines really are, and if there is a compelling reason to keep them that way. In this case they are used interchangeably for inspection, so identical behavior is critical for plant operations.

cwal61 said:

It looks at the Controller Serial Number for a match. Check out the Advance Tab on the Controller properties page. There is a match serial number check box. Not sure if unchecking box will allow you to do what you want but, if box is checked you can change the serial number. Or maybe clearing serial number will work?

Click to expand...

I've tried this when I had a similar issue, and it still asks for an upload or download even with this box unchecked and everything in the program is identical between two controllers. Must be something in the background related to the controllers that Studio doesn't like.

I'm in the same situation.

Even when they start out identical, I have never seen machine systems that *stay* identical. There's an upgrade, or a workaround, or a substitution, or a test, and you're back to maintaining a branch for each machine.

I do this frequently, with machinery that's audited for compliance with FAA and USAF security and consistency. My record for "identical" machines is eight that stayed identical since 2012, but next month I'm upgrading an obsolete failed power monitor, so that breaks my streak.

The CPU serial number is the issue. You simply can't have "identical" programs with different CPUs; you will always require upload, not just correlation, to go online.

I just use project folders for each machine serial number.

That actually comes in handy for my audits; the auditors are satisfied with comparison reports on the program files, while simply telling them "all the software is identical" gives them nothing to look at except my assurance.

Ken Roach said:

My record for "identical" machines is eight that stayed identical since 2012, but next month I'm upgrading an obsolete failed power monitor, so that breaks my streak.

Click to expand...

Quote them 8 matching power monitors and keep your record, and a few extra dollars.

Well, sounds like the serial number is an immovable roadblock to my plans.

In any other scenario, I would agree with the collective wisdom of maintaining separate files per line as being the best course even without the serial number roadblock. However, as in mispeld's case, these machines require portability and interoperability. The Ignition SCADA system that these systems are connected to manages storing line specific set points, work orders, etc in a database and updating the necessary settings to the PLC at the line's public IP at first scan. In this way, in the event that a machine is moved from one line to another, the only requirement for portability is that the SD card in the NATR stays with the line. If any of the individual components (including the PLC) are swapped between panels, then everything works without an engineer or programmer having to touch anything.
The only hiccup is that if the plant swaps a PLC or swaps a machine location, then any of our support engineers will have to upload from that PLC in order to go online. I'd like to avoid that, but it sounds like there is no way around it, whether I maintain 7 ACD files or one.
I can see Rockwell's infinite wisdom in the SN match requirements, protecting the end user from themselves...but this is one of those cases IMO where the benefits outweigh the risks, and for what my company pays annually for RA hardware and licensing, we ought to be able to give it a go. Oh well. Thanks for all the feedback folks.

As I see it you are using 1 Ethernet port on the processor and no rack Ethernet module
And you say you have a fixed IP address for each device on the remote IO for each line
As well as the HMI for each line.
So the processor would have a fixed IP address as well as the IO (Private Network)
And the processor will have a public IP address as well, I assume that this public IP address will be assigned by the DHC server on the public network as well. I don’t know how that would work.
All 7 of the private networks will have the same IP addresses for the same devices.
The public / private networks are connected with a common router.
If this is the case then it is a disaster looking for a place to happen.
I have never run into multiple IP addresses on a single Ethernet port but maybe some equipment will allow it.
I have seen and installed multiple Ethernet ports ( RJ45 and WIFI) on a single computer and they worked fine without any problems.
I have worked on and install PLC’s with multiple networks each network has a different IP addressing assignment. And I have had multiple Ethernet networks on a single RJ45 or WIFI connection using a VM machine again with no problems. But each port must have it own IP address.

Here’s the thing if all the lines are separate and will never get connected together the system will work.
But once you connect the networks through a router all IP addresses are available to all devices on the network so when the processor poles the IO it will receive a reply from all 7 remote IO modules with the same IP address. The same will happen with when any one of HMI’s poles a processor all 7 processors will reply. Hopefully before that happens you will get a duplicate IP address alarm.
But the question is can you guaranty that no 2 lines will ever get connected together let alone all 7
If that were to happen while the lines are running it would be a disaster motors could stop or start when you don’t want them to endangering both personnel and equipment.
Every port / device on any network must have a unique IP address for things to work.
Think about the internet IP6 addressing
Think about what’s going to happen when the new guy tries to connect to a line to trouble shoot and crosses the networks even for just a minute and one or more of the lines crash and somebody gets hurt who is going to take the blame for that.
You can connect all 7 lines together and not have any problems as long as you remember deal with the addressing.
All the lines can run the same programs but with different addresses.
Really what does it take to set up the IP addresses when you set up the line. If that’s all you have to deal with you are fortunate.
What does it take to back up all 7 lines if you have those networked together 5 min per line.
I worked in one plant that had hundreds of PLC’s on a single network all had different IP addresses and I could access any of them from my desk in the office all I needed was the IP address all the programs were backed up to a common server where everybody that needed it had access.
I have seen many hard to find problems due to IP addressing problems you spend hours chasing th problem with one or more machine down until you fix it.

dcooper33 said:

The Ignition SCADA system that these systems are connected to manages storing line specific set points, work orders, etc in a database and updating the necessary settings to the PLC at the line's public IP at first scan.

Click to expand...

Just curious, how exactly are you accomplishing this? I ask because if it's with a bi-directional transaction group as DB wins, I have found this doesn't work. If you were to download to the PLC, those values in the PLC will overwrite the DB, even if DB is set to win.

Also, I agree with everyone on having one PLC file. It sounds good on paper, but in the end it just doesn't work. I add drawing packages to this as well. Trying to maintain one set of drawings for multiple machines sounds good, but can get out of hand easily.

I tried this approach also a couple of times, but at some point I just store the "identical" ACD files for each machine in a folder with clear names and hand it over to the customer. The only thing I care about is that the logic is identical the moment I give the final software to the customer and for that the Logix Designer Compare tool is required.

When I do the final compare I just want to see that the Logic and AOI's are identical. Many times the only difference I see is the PLC serial number and some random bit changes on the Ethernet/IP devices.

At the end of commissioning I found it easier to go online with the 4 identical machines at same time and when I change a rung, just paste it in the other three using the online edits. This saves me a download and having to beg for a production stop (3 times!).

This approach I also use for Robots using different compare tools, the HMI (FactoryTalk) is just one APA/MER that is loaded in each HMI.

In the end it saves me time during engineering/testing and partly commissioning. The customer just gets x-ACD files, x-robot backups, 1-HMI backup.

GaryS said:

And the processor will have a public IP address as well, I assume that this public IP address will be assigned by the DHC server on the public network as well. I don’t know how that would work.
All 7 of the private networks will have the same IP addresses for the same devices.
The public / private networks are connected with a common router.
If this is the case then it is a disaster looking for a place to happen.

Click to expand...

Not a common router - a 1783-NATR per line, each with a unique public IP and set of public IPs for each of the devices with a common private IPs.

Here’s the thing if all the lines are separate and will never get connected together the system will work.

Click to expand...

The systems are completely separate. Each NATR has a connection back to the Layer 3 business switch, no need for any of the systems to talk to each other. The systems work just fine - wasn't looking for design input or anything there.

You can connect all 7 lines together and not have any problems as long as you remember deal with the addressing.
All the lines can run the same programs but with different addresses.

Click to expand...

No need or advantage to changing the networking schema here. Wouldn't be the same programs then, would they?

Really what does it take to set up the IP addresses when you set up the line. If that’s all you have to deal with you are fortunate.

Click to expand...

When it's 2am and I'm on call, and the maintenance tech is more comfortable with a pair of channel locks then the intricacies of a public vs private IP, subnet mask, and gateway address, and said tech is 1400 miles away...quite a bit, actually. We support hundreds of facilities 24/7. Time is money and technical expertise is in short supply in quite a few of those facilities. Turnover is high and the labor pool usually isn't deep enough. We have to err on the side of KISS for the end user, or automation gets written off as "too complicated". As with anything else, the temperament of the cat often determines the best way to skin it