Setting IP address from Control Logix ladder

Hi All,

I'm fairly experienced in Allen Bradley PLC programming but have come up against a problem I've not encountered before and wondered if anyone could help me.

I've got 12 almost identical machines each with it's own Compact Logix L35E, several racks of Flex ethernet I/O via 1794-AENT cards and a drive connected via a 20-Comm-E, all the PLC's, I/O and drives are on a common ethernet network.

What I would like to do is make all the software identical, I have 4 spare digital inputs on local I/O in each PLC, I have wired these differently so the PLC know's what machine it is connected to and can set it's own configuration parameters.

I have found a Knowledge Base article that explains how to set the PLC IP address from ladder code which is great but I can't work out how to set the IP address info of all the AENT remote adaptors and drives. The actual physical addresses have been set and the machines operate OK, but I would like to be able to set the module info in the PLC via Ladder, or function bock etc, oo that if I load the code on machine 1 it will look for a drive at 192.168.0.11, on machine 2 it will look for a drive at xxx.xxx.xxx.21 etc.

If I can do this it means that I have one backup and when the code is modified I can load it on all the machines without having to go through and edit the IP addresses for all the remote I/O and drives.

Many thanks in advance.

Andy.

You can change them from boot p and logix 5k. Why would you want to do it from ladder?

andypot said:

What I would like to do is make all the software identical

Click to expand...

That is one of those ideals that sounds good until you try to put it into practice. It is much easier to have routines and tasks that are identical, but allow for settings and configurations to be different, as well as network names, etc.

andypot said:

I have 4 spare digital inputs on local I/O in each PLC, I have wired these differently so the PLC know's what machine it is connected to and can set it's own configuration parameters.

Click to expand...

This is just my opinion, but I would rather have all the wiring identical and each one have a unique program. I think you will find your self jumping through hoops to try to make this work, when simply managing multiple variations of the PLC code is much easier. I guess I would have to understand what is to be gained in order to become a believer in doing this. I have seen it attempted in the past more than once, and it has always worked out better in my experience to keep the programs separate.

Having unique programs means having unique setup values and fine tuning and having a distinct place to save and restore that data. The end result is simpler to implement and better running proccesses.

Making them all the same, does that mean that every HMI value is the same, and that every timer must be kept at the same preset? What happens if one of the PLCs croaks? Do you lose all that fine tuning?

Again, this is just my opinion, but I have always found the goal of having a common program for multiple machines to be more full of flaws and headaches than the alternative.

Paul

usually when I've seen this "one program fits all" approach attempted, it's been based on the idea that a spare processor (etc.) can be kept on the shelf - but already loaded with the "universal" program ... then a basically untrained person can easily "plug-and-play" the spare processor into the system without having to tweak various addresses, etc. ...

personally, I've never seen this work out the way it was intended ...

PLC Kid, I think you have missed my point, I have 12 machines all with a different IP address, setting the IP address from ladder enables the same PLC code to be loaded on each machine without worrying about the PLC's IP address as it is set automatically when the PLC goes into run mode. What I haven't worked out is how to configure the IP addresses of the connected drives and I/O racks.

Andy ... are you trying to make the ladder "go to the I/O and CONFIGURE it" or just trying to make the ladder "use the existing addresses of the I/O" ??? ...

specifically, suppose that you have a brand new I/O system just installed but NOT configured with IP addresses, etc. ... are you trying to make the PLC "push" the IP addresses out to the I/O and set the I/O up automatically? ...

or ...

are you just trying to make the PLC "adjust ITSELF" (and ONLY itself) to the existing IP addresses of any previously configured I/O? ...

I do understand what sort of situation you might want to do this in; you have a master program you are still developing, testing, and downloading.

You need to modify and deploy that program to all 12 machines with a minimum of labor to "duplicate" the program, and you don't want to go make the same changes online to all 12 projects in all 12 controllers.

But the IP addresses of adapters are part of the module definition. You can't change them programmatically.

What I have done in the past for this is to export my "master" program to *.L5K format and use a text editor to change the target IP addresses, saving each newly modified copy as a new *.L5K file. I open each *.L5K file with RSLogix 5000, which creates a *.ACD, which I then download. I've gotten the labor down to about 2 minutes per machine. Not perfect, but a big improvement to clicking and filling out fields inside RSLogix 5000 (and less error-prone).

UltraEdit is my favorite text editor for this kind of work.

Hi Ron,

Ron Beaufort said:

Andy ...

are you just trying to make the PLC "adjust ITSELF" (and ONLY itself) to the existing IP addresses of any previously configured I/O? ...

Click to expand...

Yes that's exactly what I'm trying to do, I was surprised to find that you can set the IP address of the processor from ladder but it's actually quite easy using a message instruction, just wondered if I can do the same with the module information. I have read / writen to the 20-Comm-E to change /read IP address in the past, but this time I just need to change the address set in the module's Add on Profile in the PLC.

Hi Ken.

Ken Roach said:

I do understand what sort of situation you might want to do this in; you have a master program you are still developing, testing, and downloading.

You need to modify and deploy that program to all 12 machines with a minimum of labor to "duplicate" the program, and you don't want to go make the same changes online to all 12 projects in all 12 controllers.

Click to expand...

Well that's partly it, but this is for one of my customers and when they ask me to make changes remotely and email them back the programe, I have to email them 12 programes. They have in the past loaded the wrong program onto the wrong machine which causes havoc, as you then have one machine trying to control the I/O and drive of another machine!!

Hi Paul,

OkiePC said:

That is one of those ideals that sounds good until you try to put it into practice. It is much easier to have routines and tasks that are identical, but allow for settings and configurations to be different, as well as network names, etc.


Again, this is just my opinion, but I have always found the goal of having a common program for multiple machines to be more full of flaws and headaches than the alternative.

Paul

Click to expand...

I agree in some situations this can be a problem but in other cases it can work well.

Back in the 90's I worked for a large multi-national company with 10 sites around the world. We brought some large machines from a German company (2 x PLC 5/80's, 30 nodes ControlNet and 25 drives per machine). All the machines were similar but had different upstream and downstream equipment, over a period of several years the PLC code in each became more and more different so that if the local engineers in France made a change to their machine, before the same change could be implemented in the UK / USA / China etc the modification had to be re-written, re-tested, and debugged at each site. This started to cost a lot of money both in time and lost product. It also meant that if one site started running into unusal problems it was difficult for engineers at other sites to offer help as the PLC code was diverging. To get this under control we moved to a baseline version of code that contained interfaces for all the sites upstream / downstream equipment, this was a major job but once achieved it meant we all had the same code, if anyone ran into product problems we could say it's not the code, it may be mechanical but not software. If any site made an improvement to their machine it could be implemented on all the other machines worldwide without any re-engineering.

In my case now I'm supporting a customer remotely relying on thier electricians to load the code but their skill level is low so having identical code will reduce their chances of making an error. As the machines are all identical apart from IP addresses I haven't got to worry about any tuning parameters or timer presets.

Andy.

This might work for you.

If you have a drive connected to 192.168.0.11 will it always be exactly the same drive? Is the same true at 192.168.0.21, is it always exactly the same device?

If it is always exactly the same kind of device then you could configure an instance of each possible device so long as each possible kind of device had a unique IP address. IOW, you aren't configuring the IO at runtime, but you configure all possible IO, including missing IO, at program time. Your program then runs with errors for the missing devices. The program has IO tags for each of the missing devices, but you can programatically detect if the device is present and ignore those tags and errors.

One fairly common example of doing this is in an MCC with a number of drives, some of which may have their disconnect switch turned off. When the disconnect is off it is as though the drive is absent from the system and an error exclamation point inside a triangle, /!\, appears in the IO tree in RSLogix5K. The program can use a GSV instruction to determine if the device is up or not (present or absent) and respond accordingly. Really the only difference I see between what you are proposing and something like an MCC is that in the MCC devices are removed from communication and added back into communication even while the PLC program is running whereas in your system some devices are never present.

Have a look at this thread, hopefully something in it will help.
http://www.plctalk.net/qanda/showthread.php?t=47388

Even though it works, its somewhat "messy" to me since in what you propose the devices are forever absent, so that said, for your case I'll side with those who advocate using separate programs. If you want to prevent accidentally loading a program into the wrong processor then make use of the "Match Project to Controller" feature on the advanced tab under controller properties, which only allows the program to be loaded into a specific controller.

BTW, even though you registered some time back it looks like today is your first post, so welcome to the forum. We hope to see more of you.

Are the machines in one network or are they seperated? Can each machine be on it's own network? If so make the code and the addresses the same.

Do they ever need to communicate with each other if not simple. If they do alarics method is about as close as you will come. I use this same method for drives in MCC cabinets.