adding slc 500 to rs5000 for messaging

Rippey574

Member
Join Date
Dec 2015
Location
Elkhart
Posts
26
Is it possible to add 1747-L541C to RS5000 so I can use message to get some float values?

I am using 1761-ENI/D for Ethernet conversion on the slc.
This is for personal not work.
 
Right now I just using Mac10 activeX in ME to pass on the information. I don't have much experience with direct messaging; so I am wanting to practice and learn that method.
 
If both PLC's are on a network then yes it should be easy to do. Should be able to setup a MSG block in both PLC programs to send information back and forth.

I know we have some PLC's setup at work like this going back and forth from a SLC500 to a new controllogix using RS5000.
 
For messaging, you don't need to add anything at all into the I/O configuration of the Logix5000 project.

You can specify the "path" to the remote controller explicitly.

The "path" you enter must follow this simple algorithm....

Port, Destination, [Port, Destination]

Repeat those pairs of specifications to reach the remote device.

As you enter the path, if the system believes it to be valid, it will echo it below the entry line. Any part of the path that already exists in the I/O configuration will be replaced by the device name.

An example is always best.... Suppose I want to read some data from an SLC5/05 (ethernet).

From my controllogix controller, I will communicate via a 1756-EN2T in slot 6 of the local chassis, so the first part of my path will be...

1,6

this means go out on port 1 (port 1 is always the backplane), to destination 6 (slot number). as soon as you enter the 6, below the path entry line the software will echo it back 1,6 because it "understands" it (doesn't mean it's right, just valid). The software will also echo it back as the name of the module instead if the module exists in the I/O configuration.

Now we go from the ethernet module to our SLC5/05 (let's assume it is IP 192.168.1.76)...

...,2,192.168.1.76

this means go out on port 2 of the ethernet module (the ethernet port) to destination 192.168.1.76

So the full path specification is...

1,6,2,192.168.1.76

That is all there is to it, create the path using as many "hops" as you need.

This example was really easy, but also easy enough to outline the principle involved.

Second example, showing a bit more work involved....

I want to communicate with another Logix5000 controller located in a remote chassis. I can only get to this by going over ControlNet to another chassis that has an ethernet connection to yet another chassis that has a ControlNet connection to the chassis with the remote controller in.

1,8,2,7,1,7,2,192.168.1.34,1,3,2,2,1,0

Break it down...

1,8 out my controller on the backplane to slot 8 (the ControlNet Bridge module).

2,7 out from the CNB to Node 7 (first chassis hop).

1,7 onto the backplane to slot 7 (an ethernet module)

2,192.168.1.34 out from the ENxT to IP address 192.168.1.34 (second chassis hop)

1,3
onto the backplane to slot 3 (a ControlNet module)

2,2
out from the CNB to node 2 (the CNB in the final chassis)

1,0
onto the backplane to slot 0 (the final destination where my remote controller is).

Not quite as easy as the first example, but what it shows is that if a destination is "reachable", you can specify it in the path explicitly, without having to build anything into the I/O configuration.

I've just put that path into a message configuration (see the pic) so you can see that it echoes if it is a valid path (not necessarily correct). That echo is invaluable to make sure you've got your syntax correct, you then just need to get the numbers right.


2017-09-11_004554.jpg
 
I'll add that not only do you "not have to" add the Net-ENI to the I/O tree of the Logix 5000 project, but that it can interfere with communications if you do so.

The Logix controller will try to open a cyclic I/O connection, which the Net-ENI will have to keep on rejecting, which uses up one of the precious TCP connections in the Net-ENI.

Not a huge deal if you are only using one connection, but it becomes a frustrating troubleshooting challenge in a hurry if you are need a little more capability from the Net-ENI.
 
Mixed Messages?...

Rippey574 said:
...I don't have much experience with direct messaging; so I am wanting to practice and learn that method.

To save confusion here, seeing as you are new to this, Rippey574...

Jon82387 said:
...Should be able to setup a MSG block in both PLC programs to send information back and forth...

Rippey574 said:
...adding slc 500 to rs5000 for messaging...
Is it possible to add 1747-L541C to RS5000 so I can use message to get some float values?...CompactLogix 1769-L23E-QB1...

By "get" I assume you want to use messaging to Read float data from the SLC 5/04 into the CompactLogix?

To do so you would only require a MSG instruction in the Destination controller set to "Read" the data from the Source controller. You would not also require a MSG instruction in the Source to say write the same data. Although, that option is also available - MSG Write the data from the Source to the Destination. Again, not needing to also use a MSG instruction in the Destination to Read the same data. However, reading the data from the Source into the Destination, using a MSG Read in the Destination, would be the preferred method to use here. The point being, I did not want the above statement on using a "MSG block in both PLC programs" to confuse you. This should not be necessary when you just want to pass data from one controller to another, and not back the other way. One MSG instruction is all that is required i.e. either one MSG instruction in the Source controller set to Write, or one MSG instruction in the Destination controller set to Read.

If you wanted to say pass data "back and forth", as suggested above, then you could have to configure MSG instructions in both controllers. But not necessarily so, either. For instance, you may want to also send data back to the Source. Instead of the Source reading from the Destination, you could use a MSG Write in the Destination. This way, all required MSG instructions for the two way transfer of data is handled in the Destination. Likewise, all MSG instructions required could be handled in the Source. I'm not saying which is best to use in such cases. More, I'm simply pointing out that the option to do so is available. That messaging is a versatile two way option.

Sometimes, the preconditions required to trigger a MSG instruction may dictate where the instruction needs to reside. You may, for instance, want to MSG Write data from the Source to the Destination when something happens in the Source to trigger the MSG. Here you may have to use a MSG Write in the Source, preconditioned with the trigger event. However, and showing the versatility of messaging once more, you could also use a MSG Read in the Destination to continuously monitor the trigger condition in the Source. Once this first MSG Read in the Destination detects that the trigger condition is true in the Source, another MSG Read can then be enabled in the Destination, reading in the Source data, essentially when the trigger condition happened.

Note: All this is assuming non time-critical control, where perhaps some values are being read at certain times, or a non-critical control operation is being influenced. It is also assuming two way data transfer between compatible Source and Destination equipment. I know you are only looking to play around with this for personal use, but I feel it is important to point this out to you or anyone else who may be reading the above.

Another reason, in your particular case, to use the MSG Read instruction in the CompactLogix (Destination), as opposed to a MSG Write in the SLC (Source), is because of the different addressing syntax used between the Logix 500 and Logix 5000 platforms. The SLC controller, being older, does not recognize the newer symbolic tag addressing used in the somewhat more Modern Logix 5000 platform. The Logix 5000 platform, however, does have backward compatibility and so can recognize the older Logix 500 addressing. The advantage here is that in the Logix 5000 controller, users can simply enter the SLC Data File address (Example: N7:0) as the Source or Destination in a MSG Read or Write instruction, and it will execute upon that address without any further configuration in either controller. Whereas, an SLC controller, for instance, cannot enter a Logix 5000 symbolic tag address into a MSG instruction Source or Destination as it will be unrecognized.

However, an SLC, or a PLC5 (older Logix 5) controller, can MSG Read and Write to a Logix 5000 controller, but it requires further configuration in the Logix 5000 controller. A feature known as "PLC/SLC Mapping" is available for the Logix 5000 platform which allows users to map symbolic tags to PLC/SLC type addressing. This exposes, or masks the symbolic tags as PLC/SLC type addresses for use with older controllers.

Example:

Logix 5000 tag: MyINT
Data Type: 16-bit Integer

Mapped Tag: N7:0
Data Type: 16-bit Integer


This way, the PLC/SLC controllers can execute MSG instructions to Logix 5000 controllers by defining the exposed mapped PLC/SLC addresses in their MSG instructions, which will effectively execute upon the pre-mapped Logix 5000 tags. A viable option, where necessary, but when there is a choice, using the Logix 5000 controller to handle the MSG instructions is simpler.

Regards,
George
 
We are Virtually there...

daba said:
...You can specify the "path" to the remote controller explicitly.

The "path" you enter must follow this simple algorithm....

Port, Destination, [Port, Destination]...

...An example is always best...

...my controllogix controller...

...1,6,2

this means go out on port 1 (port 1 is always the backplane), to destination 6 (slot number)...out on port 2 of the ethernet module...

...Second example, showing a bit more work involved...

...That is all there is to it...

They are good examples Dave. They are specific to the Logix 5000 platform and the method you have demonstrated, "Port, Destination" is correct in all cases. It's just I feel we need to be a little more specific here. Our friend is using one of the older CompactLogix controllers, which are quite specific for this setup. I know you know this, and it just didn't enter your mind while typing those examples up or else you didn't feel it necessary to point this out. It's just that the ControlLogix examples may suggest to our novice friend that this is how you go about configuring paths for all Logix 5000 controllers, including the CompactLogix. The beginning of the path is very specific and fixed for these controllers. Something I feel worth pointing out here, especially when someone is just starting out and specifically using one of these controllers. So the following is not directed at you in particular Dave.

We've covered these controller's quirkiness here before, I'm sure, but either way...

For the older CompactLogix controllers, with embedded Ethernet ports, namely the 1769-L23E, 1769-L32E and 1769-L35E controllers, the I/O Configuration structure is quite unique and very particular. If you view the structure under the I/O Configuration, you will see the CompactLogix System is the higher level where basically all the key components of the CompactLogix System reside. The System represents a Virtual Chassis. Here you will see the processor and its embedded Ethernet port as separate instances. There is also the CompactBus instance where any Local 1769 I/O modules would reside...

CompactLogix_System.bmp


Even though the Ethernet port is embedded in the processor, it is treated as though it is a Local Ethernet Bridge (ENB) module separate to the processor in the Virtual Chassis. As such, it must be assigned a Slot number unique from the processor. Because the CompactLogix processor, and hence its embedded ENB module, cannot be placed in any Slot, similar to a ControlLogix processor, and 1756 ENxT modules, they must be assigned fixed Slot numbers.

The CompactLogix processor is always assigned as Slot 0. It's embedded ENB module is always assigned as Slot 1. What is fixed throughout all Logix 5000 systems is of course the backplane Port. For the CompactLogix System, this is known as the Virtual Backplane, and is indeed always assigned as Port 1. Each device in a Logix 5000 system that can access the backplane will have a backplane Port number of 1. So the CompactLogix processor is in Slot 0 and can access the backplane via its Port 1. So, as Dave pointed out, the first port number in the path is 1 to the backplane, from the processor in Slot 0. The next entry needs to be an address, which would be the ENB Slot address, but in this case it is always fixed at Slot 1 for the Local ENB. It will not vary depending on where the ENB module is placed because it is virtual and using fixed addressing. It is a subtle but important distinction, I feel, between these Logix 5000 controllers.

Also mentioned by Dave - when you are typing the message path and you have entered the initial "1,1", this essentially represents the predefined Local ENB module. To simplify (or confuse?) things, this entry will automatically change from "1,1" to "LocalENB" in the validation entry beneath, informing the user that they are communicating out the Local ENB...

CompactLogix_MSG_Path_01.bmp


Note how the validation is representing the "1,1" with "LocalENB". However, the path has not yet been applied proper. This is denoted by the asterisk beside "Communication*" on the tab and the fact that the "Apply" button is enabled. Once the path has been validated and then applied, it will then also change from "1,1" in the entry field to the "LocalENB" shortcut. If this does not happen immediately then close the MSG Configuration window and reopen it on the "Communication" tab. Both entries should now be identical...

CompactLogix_MSG_Path_02.bmp


Also note the "Browse" button option. Using this you can initially browse the CompactLogix System, or Virtual Chassis, to locate the Local ENB module instance. Once selected, it will automatically apply "LocalENB" to the beginning of the path in the entry field. You can of course always just quickly type "LocalENB" in the entry field and it will be just as valid. It is not case sensitive either. "localenb" will still result in "LocalENB" in the validation. Once applied it will update the text to the correct casing.

It's possible they could have gone one step further here. The Ethernet port on the Local ENB is always fixed as Port 2. For any communications directed out these controller's embedded Ethernet ports they will always have to take this path. So we will always see...

1, 1, 2, <network>

Or...

LocalENB, 2, <network>

I don't see why the shortcut "LocalENB", which is of course representing the ENB module, could not have represented "1, 1, 2", reducing the path entries by another one. The port is, after all, also a part of the virtual ENB module.

Of course, for the newer 5370 and 5380 CompactLogix controllers, the embedded Ethernet ports are not treated as separate Local ENB modules in a virtual chassis. Instead they are treated as simply a direct port out of the processor, for which they are. So we do not need to virtual hop from the processor Slot 0, to the backplane 1, to the ENB module Slot 1, to the ENB module Port 2...

1, 1, 2, <network>

Instead, we can now simply hop directly to the Ethernet Port 2...

2, <network>

K.I.S.S.

While I don't mind explaining the quirks of these older CompactLogix systems (I haven't even gone near the CompactBus) I will say that their architectural design does leave a lot to be desired.

p.s. If you can use AutoMax's services, I'm sure it would be of great benefit to you.

Regards,
George
 
I totally agree with everything Geospark has noted, however I want to come back on a couple of points.

The "older" CompactLogix platforms absolutely do adhere to the Port, Destination, [Port, Destination] ... method of describing a communications "Path". For that hardware the first part of the "PathSpec" will always be 1,1 and this represents "out of port 1, (the "virtual" backplane), to slot 1 of that {virtual backplane}, which is the embedded ethernet port".

It's easy to see how the Processor and Ethernet "module" are glued together, and glued into slots 0 and 1. Of course, as Geospark points out, this is already pre-defined as "LocalENB", so you can use 1,1 or lOCaleNB (case insensitive), and the "path" is defined up to the ethernet module.

It's possible they could have gone one step further here. The Ethernet port on the Local ENB is always fixed as Port 2. For any communications directed out these controller's embedded Ethernet ports they will always have to take this path. So we will always see...

1, 1, 2, <network>

Or...

LocalENB, 2, <network>

I don't see why the shortcut "LocalENB", which is of course representing the ENB module, could not have represented "1, 1, 2", reducing the path entries by another one. The port is, after all, also a part of the virtual ENB module.

Doing so would violate the pathing rule, in that only a destination can have a name. You cannot describe a module's port by a name, you can only have a name associated with a "landing point". Adding the "2" to the destination name isn't a landing point, just the start of the next path hop.

Of course, for the newer 5370 and 5380 CompactLogix controllers, the embedded Ethernet ports are not treated as separate Local ENB modules in a virtual chassis. Instead they are treated as simply a direct port out of the processor, for which they are. So we do not need to virtual hop from the processor Slot 0, to the backplane 1, to the ENB module Slot 1, to the ENB module Port 2...

1, 1, 2, <network>

Instead, we can now simply hop directly to the Ethernet Port 2...

2, <network>

And that still follows the pathing rule

Port, Destination, [Port, Destination}, ....

For those newer controllers, the ethernet port is a physical port, not a virtual port, so there's no "hop onto the backplane to slot 1" requirement.

It is very clear in my mind that there is a well-defined structure to this, and if you adhere to the explicit path rules, you will not go wrong.

Of course you do need to know the difference between "virtual" comms modules, and actual physical ports on the controllers.
 
Dave,

No need to come back on point 1, or 3 for that matter...

As I pointed out clearly to you, twice just in case, you defined the path rule very well and correctly and that it does indeed apply to all Logix 5000 controllers. You don't need to come back on it and defend it. It stands for itself and I have acknowledged your excellent contribution, not dismissed it or argued its merit. The CompactLogix does follow the path rule you have defined.

All I was doing was adding some finer detail as to how you define one aspect of the path for these particular controllers as opposed to the ControlLogix. The selected communications module for a ControlLogix may vary in Slot number, as pointed out in your examples, but it is fixed for the older CompactLogix. As I said, a small, but I feel important distinction to make. It does not detract from what you have outlined or demonstrated and is in no way attempting to replace or correct your contribution. It is intended as complimentary information. If I feel an important fact, in particular to the OP, who is a novice, has not been mentioned and warrants mentioning, for their benefit, then I will always do so, regardless of whether I appear to in any way undermine another contributor. I would make no apologies for doing so, which I'm sure you can respect.

Also, what is "easy to see", and "very clear" in your mind might not be so easy and clear to others, especially when they are just starting out. This is something I always try to keep in mind when considering what level of detail I'm going to get into. Often, what can appear to be glaringly obvious info to some, can be a nugget of Gold to others and it hurts none, other than my fingers, I hope, to add it. My attention to detail can be quite nauseating, I'm sure, but if it gets the job done of informing someone as best I see fit, then I will always sleep well.

On the shortcut notion of mine. That is quite true. But I'm not viewing it in such a constrained fashion as you are. I'm more looking at it from a design perspective, where the software developers have taken a step or two back. They don't necessarily have to follow the path rule, or any other rule, for that matter i.e. they can ignore or break the rules. It's their rule book. There is no "cannot" or "can only" if you break it down at the design level. You define what is allowed and what is not. A shorcut, which may define a complete and fixed path to a communications device port, should be able to contain as many hops as it likes. It is simply a shortcut to define a portion of an entire path. As long as the entry either side of it is in keeping with the path rule, no harm is done. It is simply a predefined shortcut...

1, 1, 2, 192.168.1.76 = Port, Address, Port, Address

1, 1, 2 = LocalENB

LocalENB, 192.168.1.76 = Port, Address, Port, Address

Nothing has changed or broken any rules except the path is simplified. If this was how it was always defined I don't think we'd be looking at it all funny or incorrect in any way. It would just simply be how it's done. Typing "1, 1, 2" validates as "LocalENB" and then finish the path.

As these controllers are parked at revision 20, and getting on in years, I'm sure all this is an irrelevant pipe dream. But retrospectively, it would have made sense, to me.

Respectfully yours,
George
 
Ken Roach, thank you for the additional info. No need to add a connection that is just waste.

AutoMax, I may take you up on that, I will try hands on first; this is the best way I learn the quickest. I really do appreciate the offer to!

Geospark, I love these style of write ups with the detail. Thank you! Get was to read a float in the slc, just used to calling retrieving "get" from visual basic back on dos.

I was able to get the read to work, and very happy! That has been my first msg! Enjoyed the lesson. It is not time critical, I actually put it on a timer and likely will move it a one shot when the internal clock reads 30 on the minutes for this particular message.

I personally enjoy the details on why its done a certain way, how it can be also done, pros and cons; not just its done this way. I believe that is the best way to learn and understand.

Thank you all for your input again, has been very helpful! I am sure others will read this and find the same value in it I did.


In case your curious as to the use..
In my electrical work space\office out in the pole barn is a slc 5/04, it runs a custom built AC from salvage parts back when I worked at a "mobile climate control" facility. It has evolved from relay logic to Aurdio based board, to to the slc. Now the plc reads T.C. from ambient, hot gas, liquid out, office temperature.

In my house has the 1769-L23E-QB1. It runs a 230 3 phase (home brew DC bus for it) 525 for my well pump, reads analog off of the high pressure, regulated pressure and flow meter. It also reads a 3 wire ptc100 to analog probe in my attic. The attic probe is my current work for fans for ventilation to regulate the absurd temperatures up there; they leach through all the insulation and drive my cooling bills through the roof. I have an attic furnace\ac that drives me insane with waste from it due to location.

In addition, but not on my network I have another 5/04 that run my heating and cooling in the house, that one is my education\training one. One day I will switch it out with a one of the micrologix I have around here and get some sort of analog cards to read thermals; but that's a future thing.

Here is the home one, forgive the mess I am still working on it in my spare time. Original size is here.

homesmall.jpg
 
Last edited:
That is great, I love hillbilly home automation (no offense, and it's nice to see AB hardware instead of a DirectLogic for a change.) What's the philosophy on the 525 for the well pump? Cheaper motor, obviously, and I guess perhaps better material life from the ramp, but is there something else I'm missing?
 

Similar Topics

I have project using slc 500 and have to add two 4 to 20 Am signal in to one 4 to 20 Am analog out so that i can get total generator Kw I...
Replies
2
Views
11,863
Hello, We have an older machine that has a standard PanelView (2711-T10C3) connected over DH485 to a SLC 5/04 PLC via a 1761-NET-AIC module in...
Replies
1
Views
658
Hi all, First thing in the new year I'm off to a remote site to add a second chassis to an existing SLC installation. All of the hardware is...
Replies
10
Views
4,532
Hi there, I would like some advice in regard to adding an Allen Bradley SLC 5/05 to an existing Fix32 V7.0 installation. At the moment there is...
Replies
1
Views
1,907
Dear , problem : Adding and configuring analog input module 1794-IE8 to existing running system SLC 5/03 through 1747-BSN (DH485) System: - 2...
Replies
1
Views
3,735
Back
Top Bottom