ControlLogix: Missing "Path" in Application

[SoftwareJanitor]

<Broke this question out for searching capability>

When I recently opened an application, it was missing the "Path" in the "bar" at the top, and so I was unable to go online until I could figure out what it was supposed to be. Since I still don't know what I'm doing, this took me a little while. Fortunately I knew of *one* path (for another app), then was able to parlay that into the one I needed (searching through all the PLCs here).

Question is: All these "Paths" are SOOO cryptic, with the IP address, followed by some ridiculous name that doesn't even *begin* to describe what it is. Is this the problem - the dumb names that someone assigned? And can I change these names? I mean - who cares about the IP address when you're looking for a particular APPLICATION. Can I slap an alias on top of all these dumb names, or is that just the way it is ...???

 

[Gomez_]

You'll have to be a bit more specific about what you are having issues with but here's the general layout of the path:

Protocol\Address\Hardware and possibly PLC file name

So for example:

Protocol would be AB_ETHIP which is the allen bradley EthernetIP protocol "driver". This you can rename in the RSLINX program.

Address on EthernetIP would be the IP address because thats how devices on ethernet are identified.

After that it depends on the hardware, it could be direct to a PLC or have to go through a backplane.

Here's a project I'm working on now, the path stored in the file does look like a bunch of garbage, but when you browse the network it makes more sense.

 

[ASF]

The reason it's called a "path" is because you're not just telling telling your laptop which PLC you want to go online with, you're telling it how to get there

Let's say you have a Control Logix that you want to go online with. How does your laptop get there?

1. Let's say we're going online using an ethernet connection. So the first step in your path is an ethernet driver - basically saying to your laptop "go out this door".

2. Now, the Control Logix (unless it's a new L81E model) doesn't have an onboard ethernet port, so to access it you're going to have to go in through an ethernet card in the same chassis. So, you've sent your laptop "out the door" onto your ethernet network, and now you need to tell it where to go once it's there. What's the IP address of your ethernet module? Let's call it 192.168.1.50. So now your path is Laptop>Ethernet Driver>192.168.1.50

3. However! This only gets you into an ethernet module. That's not helpful - you want to get online with the PLC. So, we have to continue our journey. If our PLC is in the same chassis as the ethernet card, the way to get there is across the backplane. So, having come through the front door of the ethernet module by it's IP address, you now need to go out the back door onto the backplane. Path now is Laptop>Ethernet Driver>Ethernet Module>Backplane

4. Now where are we going? Well, to whichever slot the PLC is in. If it's in slot 0, that's where we'll point it. So, your path is now:
Laptop>Ethernet Driver>Ethernet Module>Backplane>PLC Slot

Now you're online!

So your path is actually quite complex, and at each step of the way you might see part numbers or module names that someone has defined. But when you step back, it's actually quite a good way of doing it, because whether your path to get online is extremely simple or extremely complex, it's always the same theory.

If you're plugged directly into the ethernet port of a 5370 Compact Logix, your path is literally just Laptop>Ethernet Driver>IP Address

In another place I worked, there was one PLC that had no ethernet module on it, but did have a controlnet module, connected to another PLC that did have an ethernet module, which was connected to the plant network. So I could still get online with that PLC, using the path:

Laptop>Ethernet Driver>IP address of ethernet module in second PLC>Backplane>ControlNet card in second PLC>ControlNet Network>Node address of ControlNet card in first PLC>Backplane>PLC in first PLC.

Much more complicated, but still the same process - it's just about physically tracing the connection from where you are, to what you want to connect to.

 

[RET]

Read about MSG instructions in the RSlogix instruction reference manual.

 

[SoftwareJanitor]

So your path is actually quite complex, and at each step of the way you might see part numbers or module names that someone has defined. But when you step back, it's actually quite a good way of doing it, because whether your path to get online is extremely simple or extremely complex, it's always the same theory.

Well, thank you for that explanation. Once again - a top-notch post! At least now, I understand.

But I don't like it. If the PLC has an IP address and it's sitting on a network somewhere, I should be able to connect with just the IP address. Better yet, I shouldn't even have to *USE* the IP address! I should be able to use an ALIAS which is just the *plain English name* of the application.

Here's how it should work:
=================
Which application would you like to go online with?

1.) Chillers
2.) Oxidizer
3.) Etc...

I select it, and the system makes the connection. It should be that easy.

But "easy" isn't in Rockwell's vocabulary.

 

[nhatsen]

In fact, you can create a shorcut to the chassis of any controller. Open RSLinx, go to Communications > Configure Shorcuts. You can choose the shorcut name (Chillers, for example) and look for the chassis where is installed the controller. I think you can also select a network.

Then you can go to RSLogix and select that shorcut when you open the path popup.

 

[dmroeder]

But I don't like it. If the PLC has an IP address and it's sitting on a network somewhere, I should be able to connect with just the IP address.

Your thinking runs into problems when you come to the ControlLogix platform. The IP address isn't the part of the system that has the data in it, the controller is. Let's say your chassis has 3 controllers and one Ethernet module. You want to read some tags. Let's say that the Ethernet module is 192.168.1.42. How would using that IP address get you to the tags you wanted to read? You have to specify what slot the controller is in to know where to read the tags from.

Of course the L8 series has an IP address, but you might be working with a L6x or L7x. And even though you might have an L8, you man be accessing it via a module from another slot.

 

[SoftwareJanitor]

In fact, you can create a shorcut to the chassis of any controller. Open RSLinx, go to Communications > Configure Shorcuts. You can choose the shorcut name (Chillers, for example) and look for the chassis where is installed the controller. I think you can also select a network.

Then you can go to RSLogix and select that shorcut when you open the path popup.

nhatsen:

Well, that sounds like an improvement, but it's still not quite where it should be. All this backplane stuff, raw IP addresses, slots and modules is all gory detail that should be hidden from the user.

dmroeder:

As far as network communications go, the IP address *is* the Controller, for all intents and purposes. If I want data from a computer on a network, I just have to request it ... using the machine's IP address. Imagine if the Internet were designed by Rockwell??? Every time you wanted to access another machine, you'd have to specify the ENTIRE PATH from your machine to the other!! Who would want to do that??

Frankly, I'm surprised the Ethernet Card doesn't do what I'm asking for.
It should listen for requests to any configured IP Address and act as the go-between to the Controller, if the Controller can't just do it itself. To the outside world, a PLC should look just like any other computer sitting on a network, regardless of how many cards, modules, slots, backplanes, or airplanes it might have...

 

[dmroeder]

nhatsen:

Well, that sounds like an improvement, but it's still not quite where it should be. All this backplane stuff, raw IP addresses, slots and modules is all gory detail that should be hidden from the user.

dmroeder:

As far as network communications go, the IP address *is* the Controller, for all intents and purposes. If I want data from a computer on a network, I just have to request it ... using the machine's IP address. Imagine if the Internet were designed by Rockwell??? Every time you wanted to access another machine, you'd have to specify the ENTIRE PATH from your machine to the other!! Who would want to do that??

Frankly, I'm surprised the Ethernet Card doesn't do what I'm asking for.
It should listen for requests to any configured IP Address and act as the go-between to the Controller, if the Controller can't just do it itself. To the outside world, a PLC should look just like any other computer sitting on a network, regardless of how many cards, modules, slots, backplanes, or airplanes it might have...

The Ethernet card can possibly get you to many processors. You can have a 17 slot rack with all processors and 1 Ethernet module if you wanted. How is the Ethernet module supposed to know what processor you intend to get information from by just the IP address? All of the controllers can have the same name, and even the same programs running in them. How is it supposed to know without you specifying?

edit. Your assertion that simply knowing an IP address of a computer on a network to get information out of it is absurd. Ping yahoo.com, then ping mail.yahoo.com. Now go to those IP addresses in in your web browser.

 

[ASF]

Your assertion that simply knowing an IP address of a computer on a network to get information out of it is absurd.

dmroeder is right. In a ControlLogix chassis, the ethernet module(s) and CPU module(s) are entirely separate entities, and may not even be related. Try to step back and see the bigger picture.

Yes, for a very small, very simple setup, a straightforward "this is the PLC I want to go online with" would suffice. But Allen-Bradley does not exist in that world. You might not like it, but it's not changing for you, or anyone else. And I for one am grateful for that - because I have taken the time to learn how AB controllers communicate, and no matter whether I've got a Compact Logix plugged directly into the USB port on my computer, or a Guard Logix connected via 3 different network mediums on a network halfway around the world, the process is the same, and I don't have to re-learn it every time I want to do something slightly differently.

 

[JohnCalderwood]

Aye, but once you have established the path to that PLC, you save it as part of the project.

You then open up the PLC offline, click "go online" and up it comes (as long as your PC has the same RSLinx path as the saved project). Not difficult.

 

[robertmee]

nhatsen:

As far as network communications go, the IP address *is* the Controller, for all intents and purposes. If I want data from a computer on a network, I just have to request it ... using the machine's IP address.

Before you jump up on your soapbox and start bashing software, you might want to have a better understanding. An IP address has little to do specifically with a controller. The IP address is a GATEWAY to get to the controller. You can have ONE IP address and 16 Controllers that communicate through it. Your hung up in the DCS world where one IP is one Controller. It's not like that in the PLC world. Take some time to understand and stop using every thread to try and shoehorn a PLC into your DCS world. I've worked with DCS's 15 years ago (they're not so popular anymore for a reason), and they aren't that great either. But I don't take every opportunity to call the manufacturer's of DCS systems *stupid* or *ignorant*. It's just different.

 

[rdrast]

And, robertmee, you can also have situations like we have here, where any controller can have multiple IP addresses. The IO network is separate completely from the drives network, which again is separate completely from the HMI and enterprise networks.

Then there are cases where you need to connect through Ethernet, to the backplane, and out to oh, say DH+ or ControlNet to reach another processor not connected to the EtherNet network.

A path isn't anything difficult, or special, and it is infinitely better then other solutions like (and I actually like these) AD's Productivity PAC's, where you open a program, and the path is not part of the program. True clustermuck opening up one program, and downloading it to the wrong (live) processor just because it was the one last connected to.

If you don't like the paths, just go ahead and lug the laptop around, connect via serial or USB to each individual processor. No issues.

---

Telling me you live at 123 Main Street tells me nothing about how to reach your home. I need directions.
Directions are the path.
Now, if 123 Main Street is an apartment building, I also need the particular apartment number.
That would be the processor name.

As far as "Strange Names", that is entirely dependent on who wrote the program, and their conventions.

 

[dmargineau]

And one more blow to the poor horse...

The Monkey See/Monkey Do approach of "modern application development", where everything needs to be "built-in" or have some "feature" where the "user" doesn't have to do or know much in order to accomplish some task might be applicable to the "Internet-of-Things" or "Personal Assistant" devices.

A screw-up when your fridge orders too much beer but forgets the milk could (and would!) be overcome by getting the lazy folk on their way to the store; when one who doesn't have any clue about the system's functionality is allowed to poke around with "modern features" could generate an irreversible catastrophe or worse.

There are reasons why one cannot do what one wants (or feels like!) when approaching real world automation...

My $0.02...

 

[janner_10]

A screw-up when your fridge orders too much beer but forgets the milk

That's not a screw up, that's a good result!!