RSLogix5000 - Readng I/O on Ethernet

I am developing an EthernetI/P network enviornment with 4 ControlLogix PLC's. Each will have its own Enet controller. Each PLC will directly talk to 2 Flex I/O enet modules.

How can one PLC read data from another PLC's I/O Modules on the network? Is it possible?

The Logix PLC's can use produce/consume to pass data to one another, but it's not 100% control reliable, but the update time is very fast.

You can access other PLCs input modules directly. Only one PLC processor may "own" or control an output module. To access an input module in Rack B from a processor in Rack A, assuming both racks have ethernet cards in it, from Processor A in Rack A's program, under IO Configuration and under that racks Enet card, add a second enet card (not in the rack, but under the card so that it is on the cards network) and configure it to the IP address of the card in Rack B. Now you can add the input cards from Rack B under that ethernet card. The IO information will be in your input image table.



To control an output owned by processor A from processor B you will have to message processor A and program processor A to respond to the message to either turn on or off the output. However, processor B in Rack B can own an output card which resides in rack A with pocessor A. In this case, processor A does not own the output card.

Clear as mud?

Explanatory information of non-L5K users: Becuase of the producer/consumer data model the Logix5000 system does not require that the processor reside in a certain place in the rack, nor does it limit a rack to only one processor. It is completely valid to place four processors in one rack and have each processor own some of the cards in the rack and some of the cards in another rack - which may or may not contain a processor.

Gotta love the flexibility of the ControlLogix.

... So shall it be done (ASAP)

Alaric,
That is perfectly clear and exactly what I am going to try later today. It makes good sense also. When we bought our systems we were told this was possible, but now as we try to make it all work together, our supplier didn't know whatto do.
I will keep you posted when I have sucessfully followed your instructions.
Thank you very much! The quickness of the response on this forum amazes me also!
WebRanger Jim

WebRanger said:

The quickness of the response on this forum amazes me also!
WebRanger Jim

Click to expand...

i find more that i can get a better answer here from someone who has had the problem or been there done that then i can from "most" manufacturers!

I am still waiting a reply from AB UK on a BTM Issue, its been a week now, the funny thing is they havent a clue so emailed the states...........
Now this is the funny part i emailed the states with the original query and asked for them to deal with it as i knew the Uk office had little knowledge of these modules! The us sent it to the uk because thats where i am based and after a week the uk send it back to the states and i am still waiting!

Listen-Only I/O Connections

With FLEX I/O and with 1756-series I/O on EtherNet/IP you can, as described, configure ordinary owner connections as well as Listen Only connections to I/O modules.

For each controllers "own" I/O modules, you will put the 1794-AENT modules in the I/O tree with connection types of "none" to the AENT itself, and connections to each module of "Input Data" or "Output Data" types.

You will also put the "other" controllers 1794-AENT adapters into your I/O configuration, but you will create a connection to the 1794-AENT's of type "None"... and a connection to each I/O module of type "Listen Only - Input Data".

I don't think you can do Listen Only type connections on a "Rack Optimization" connection.

Make sure that you carefully match the RPI values for your Listen-Only and your ordinary owner connections. Network modules will produce data at the fastest rate it is requested.

Ken Roach said:

With FLEX I/O and with 1756-series I/O on EtherNet/IP you can, as described, configure ordinary owner connections as well as Listen Only connections to I/O modules.

For each controllers "own" I/O modules, you will put the 1794-AENT modules in the I/O tree with connection types of "none" to the AENT itself, and connections to each module of "Input Data" or "Output Data" types.

You will also put the "other" controllers 1794-AENT adapters into your I/O configuration, but you will create a connection to the 1794-AENT's of type "None"... and a connection to each I/O module of type "Listen Only - Input Data".

I don't think you can do Listen Only type connections on a "Rack Optimization" connection.

Make sure that you carefully match the RPI values for your Listen-Only and your ordinary owner connections. Network modules will produce data at the fastest rate it is requested.

Click to expand...

Ken,
Thank you for your response!
I followed your instructions to the "t", but was unsucessful in trying reading a 1794-IT8 TC INput module. It gave an "Unknown Module Error". Then I deviated from your instructions and created the 1794-IT8 as Input Data, not Input Data- Read Only. By doing this I had another configuration screen to tell the card the inputs were type "J" and this connection worked, but only when the RPI rates were the same on both controllers. I am on Logix5000, V13.03. SO, not quite as you detailed but limited success. Any Comments?

Alaric said:

You can access other PLCs input modules directly. Only one PLC processor may "own" or control an output module. To access an input module in Rack B from a processor in Rack A, assuming both racks have ethernet cards in it, from Processor A in Rack A's program, under IO Configuration and under that racks Enet card, add a second enet card (not in the rack, but under the card so that it is on the cards network) and configure it to the IP address of the card in Rack B. Now you can add the input cards from Rack B under that ethernet card. The IO information will be in your input image table.

To control an output owned by processor A from processor B you will have to message processor A and program processor A to respond to the message to either turn on or off the output. However, processor B in Rack B can own an output card which resides in rack A with pocessor A. In this case, processor A does not own the output card.

Clear as mud?

Click to expand...

Alaric,
I tried your suggestion, but had to adapt it to 1794-AENT modules based on Ken's posting. As I responded to Ken, I had to be inventive but I had positive results in reading the TC Input data. Is there an AB Pub that addresses the approach on how they recommend to do it or have you learned through the forum? Once again, thank you for your posting.

Ken's approach is probably more accurate as I've only done this once before so I probably left out something. Search the AB knowledgbase at www.ab.com for technotes on ethernet IO.

If both controllers have an ordinary Input Data connection, then one of them is going to send it's configuration data to the module (generally whichever powers up first !) and the other will get an error indicating the module is owned by another controller.

I have only personally done this with 1756 series I/O on ControlNet so I'm not totally certain about how to do it with 1794-AENT on EtherNet/IP.

I do have all the hardware to perform this function back at my office but won't have time in the near future to test it.

WebRanger, this is just a guess, but it sounds like when you set it up that you only had a Listen Only connection without any plc owning the I/O module.

First make sure that you setup the local PLC to own the I/O module. Configure it as if there is no remote PLC. Then download the project and verify that the local PLC can talk to it.

Then, once that has been verified, go to the remote plc and setup the Listen Only connection. The Listen Only connection will not have the configuration data so the setup will be very brief. Once this is done then download to the remote plc.

If you downloaded to the remote plc first then the I/O module will not function as it is not owned or configured. If you download to the local plc later that should configure the I/O module and "wake it up" for the remote as well.

From your description, that is what it sounds like might have happened. As I said, just a guess.

Also, both the local and remote plcs can own the module provided their configurations match EXACTLY. If one is slightly different then whoever downloads first will "win" and the second plc will see the module as faulted. But a power cycle could cause the roles to reverse.

OG

I have also found that if the "owner" controller fails or looses communications with the I/O that the listen only connection will not recieve data. This might be important depending on your application?

I am sure it is documented somewhere. This would be the only reason to configure both as owners that I can think of. If both were "owners" then the connection should be ok to the remaining controller if something happened to the other or it's connection.

I was not aware that both could own a module. It is interesting. I have accidentally configured multiple owners before and one of them always said "waiting" I believe? I might not have had them both set exactly the same though.

I find this type of connection to be a little more stable on ControlNet. I have used it on Ethernet too though.

RSL

Continuation....

I read through your postings with much interest and get a level of understanding from all of them. When I had tome to get back and check I was still reading the remote I/O point on the "Local" controller OK. I deleted that and tried the Input Data - Listen Only and the Local controller would not talk to the other remote controllers I/O. Since some of the postings mentioned that this had been sucessfully done on 1756 modules, I downloaded a 1794 ENET-UM001E-EN-P and started ingesting that information. The manual gets into creating Produced tags & Consumed tags. I followed the instructions but did not have enough time to finish. My understanding is that a seperate connection (TCP/CIP) is established and there are rules for the amountS and type (DINT, REAL , ARRAY OF REALS OR DINTS) that can be passed by that connection. Hopefully I will be able to continue tomorrow if there are no "fires" to fight.

Comments from all you learned wizards is welcome!

Webranger (Jim)