Ethernet/IP comm with SLC IO

TreyB

Member
Join Date
Sep 2020
Location
Sioux Falls
Posts
16
I want to be able to use a 3rd party device to read the IO modules from an SLC505 without the use of the CPU. All the communications modules i come across appear to require the use of the CPU to pass thru the data.
 
Welcome to the PLCTalk forum community !

The appropriate module would be the 1747-AENTR.

It allows an EtherNet/IP master device to control chassis full of SLC I/O modules, with a few exceptions.

What is your third-party device ?
 
That IS the module that I actually purchased, but reading the manual says it can ONLY be used with a direct connection to another AB controller.. for instance, upgrading to a ControlLogix.

The idea here is to bring the logic under the DCS and use one of its controllers, specifically the DeltaV PK Controller, while utilizing the existing IO modules.

This controller is capable of Ethernet/IP or modbus and supports Class 1Implicit, Class 3 Explicit, and Class 3 with PCCC messaging classes. But here comes the next hurdle.. absolutely no documentation that I can find under the 1747-AENTR in regards to what assembly, instance, attribute etc. I would use.

I can only find examples that involve writing to the program a MSG instruction that takes a data file and creates an assembly instance. This all of course requires the SLC505 CPU to remain.
 
[Deep breath in]

I have some very negative experiences with Emerson pointing the finger at other vendors, particularly but not limited to Rockwell Automation, to excuse their lack of engineering expertise and documentation in their networking products.

[Deep breath out]


Rockwell doesn't document the internal network objects of many of their I/O products because it's unnecessary to make them work with ControlLogix, and that's what they're designed and advertised to do.

The good news is that the 1747-AENTR is relatively simpler than a some of the other modular I/O like 1734 POINT.

Post some details about how the DeltaV controller configures a Class 1 implicit cyclic connection. As you noted, there will be Class, Instance, and Attribute information needed. I like to take screenshots, trim them, and attach them as PNG files to my Forum posts to communicate that kind of data, but a link to a User Manual would be great too.

Do you have any ControlLogix CPUs and Studio 5000 software to experiment with ?
 
That makes sense that they wouldn't publish that information, but the explicitly said "only works....". Now, I have to take that with a grain of salt, but I had no other information!

The DeltaV controller gives me 3 relevant options for messaging class:
Class 1 Implicit
Class 3 Explicit
Class 3 w PCCC

Also is UCMM with Logix Tags, but that is not an option with the SLC.

I attached the options screen for each of these configurations. Also, after creating the logical device, you can create the signals within each device. The options are the same with the exception of choosing an Attribute ID for Class 1 Implicit.


I do not have a ControlLogix or other controller. Just the 505.

And I hope you have patience, my PLC experience is almost entirely comprised of the last few days researching. Same with Ethernet/IP protocol. So, I hope my communications are clear. Thanks!

Class1 Implicit.PNG Class3 Explicit.PNG Class3 with PCCC.PNG Device Signal.PNG
 
Last edited:
Hello:
I have never done what you are trying to do, but my EtherNet/IP experience tells me that what you want to do is doable. I have read the manual for your 1747-AENTR which indicates that this product is an EtherNet/IP adapter, so the options from the DeltaV that should allow you to communicate with it would be Class 1 Implicit and Class 3 Explicit, but I would strongly recomend you use Class 1 Implicit.
The main problem is that the Rockwell document does not indicate the assembly instances onto which 1747-AENTR maps the IO and status information of the modules in the SLC rack. Basically, EtherNet/IP specification dictates that process data in an EtherNet/IP device has to be "assembled" in data blocks called "assemblies", which are instances of a CIP class called the Assembly Object. But Rockwell users do not care because the Rockwell tools have all this information pre-programed and only third party tools like the Emerson tool needs to be aware of the instance values.
Unless there is a document that I am not aware of and which may be revealed in a later post from colleagues who know more than I do about Rockwell, I can only help you if you know the instance attributes into which the 1747-AENTR is mapling the IO. If you do not know the instance number it may be possible to find out using the Molex ODVA Tools which can be download for free from the Molex website and doing a bit of a hack. Just remember something about the CIP Spec. The Assembly Obnject is class ID 4, the service GetAttributeSingle is service code 0x0e and the data attribute ID of the Assembly object is attribute 3. I do not have a 1747 but I do have a 1734-AENTR/B Ethernet Adapter and in the screenshot below you can see where this device is mapping its process data. I hope this helps.

20200903_1774.png
 
Alfredo,
That is exactly how we got to this point.. not having information about the assembly instances. Sniffing out the network messages is something I was afraid I'd have to do one way or the other!! Thank you so much for leading me to what seems to be the exact tool I need to do it right.

I'll report back once I've done some playing! Or if I need assistance getting this tool to work! Thanks for the screenshots also. Seems straightforward.
 
Well, I've been able to use the tool to talk to the CPU and read the Identity objects and all the others in the tabs. I then went into DeltaV and was able to mimic that signal and confirmed the data. So my messaging is setup correct in DeltaV.

However, I'm yet to find the Assembly instance. I'm going through each number until I hit on something. So far I got to 200... Wouldn't this be something people have already figured out? I can't seem to find information on it. Isn't the assembly instance always going to be the same for the PLC?

I know the CPU is not even what I want to be trying to read. I don't have the AENTR module yet. Thought we did. So, until then I was just going to try finding the assembly instance for the CPU, knowing i'd have to repeat the process for the module.

I might just test my programming skills and start creating MSG instructions to create assemblies from the data files that I can read. Might have to do this in the long run anyways.
 
The SLC-500 CPU will respond only to basic CIP messages about its objects like the network port and identity objects. Virtually all of what it does uses the old PCCC protocol. The 1747-AENTR is very different, doing all of its communication with true CIP objects and having nothing to do with the old SLC-style controller messaging.

It's a fact that Rockwell Automation distributed I/O, even on open networks like EtherNet/IP or DeviceNet, is not well supported for use with third party master devices.

[Deep breath in]
Commercially, the support cost and risk to installed base of controllers is substantial. Trey's circumstance where he wasts to retain A-B installed hardware from a generation ago but use a DeltaV controller, is exactly the sort of thing where Emerson can commercially promise ease of integration, then point their fingers at Rockwell for not providing detailed internal object models and hold out their hand for an engineering services contract.
[Deep breath out]

A close corollary for what Trey wants to do is the support for 1734 POINT I/O by the EtherNet/IP Scanner toolkit in CoDeSys. Developers made it work, but the documentation is sparse at best in the examples provided from the CoDeSys Store. Examples published to YouTube skim over the top and don't explain the selections they don't make or the limitations of the product.

Alfredo is probably the PLCTalk forum member with the most direct experience using CoDeSys with 1734 POINT.

This would be a very simple integration of the 1747-AENTR only supported one 16-bit word of input and output data for each slot of the controller. There could be just one regular old Assembly object with Instances 100 and 101, representing the data image for the whole chassis.

But that's not the way it appears to work. The 1747-AENTR supports "module connections" to CIP objects represented by each slot. This lets them be of any size, and allows them to receive configuration data like that required by analog and specialty modules. That's good for the 1747-AENTR's overall functionality in migrating SLC system to ControlLogix because it's all under the hood in Studio 5000 Logix Designer, but it's less easy to understand those objects so we can configure a 3rd party scanner.

I'm not sure if the 1747-AENT is as simple as an Assembly object for each slot, with the Instance number associated with the physical position and the Input and Output Attributes of appropriate sizes. There is probably some more complex stuff about how the data is "mapped" to the 32-Word Input and Output scanner image of the old 1747 backplane chip, and what data might be mapped to the part of that chip that handles M0 and M1 module buffers.

Trey, I'd like it if you could list out all of the 1746-family modules in your SLC style chassis. A general description is OK, like "DC output, 16-point" but a part number would be better.

If we can create a Studio 5000 project that configures a 1747-AENTR chassis like yours, the CIP objects may be well enough described in the *.L5K export file that you can use them in your DeltaV configuration.
 
Last edited:
Thanks Ken,

1-1746-IA16
2-1746-IA16
3-1746-IA16
4-1746-OW16
5-1746-NI4
6-1746-NO4I
7-1746-NT8
8-1746-NR8
9-Devicenet card ( i know this isn't supported by AENTR, which is okay) we have existing networks nearby for the drives.

Thanks for all the help.
 
The 1746-IA16 modules are extremely simple; they have only 2 bytes of Input data and an RPI time.
Likewise, the 1746-NI4 is just 8 bytes of Input data, for its four analog input channels.

The 1746-OW16 has a simple set of Configuration data that is sent to the 1747-AENTR to tell it how to handle that module in the event of the PLC going into Idle mode or a failure of the network connection.

The 1746-NO4I is similar, with a payload of 4 words of configuration data to handle Idle or Comms Fault mode.

The 1746-NT8 and -NR8 have larger I/O images than would be transmissible across the old RIO link, but that are within the 32 words of Input or Output data that the SLC-500 CPU could read and write, so I think they can be read and written by the 1747-AENT as ordinary IO links.

I'm not sure that their Configuration data is relevant, since they are Input modules and it doesn't matter what configuration is sent to them in a safe state. Including it in the module profile might have been an oversight/mistake.

Attached is a ZIP file of the *.L5K file I created in Studio 5000 v32 for a 1756-L71 and 1756-EN2T scanning a 1747-AENTR with those modules.
 
Here's an example of the text format description of the module in Slot 03, the 16-point relay output:

MODULE Slot4 (Parent := "SLC_Adapter",
ParentModPortId := 1,
CatalogNumber := "1746-OW16",
Vendor := 1,
ProductType := 116,
ProductCode := 41,
Major := 1,
Minor := 1,
PortLabel := "RxBACKPLANE",
Slot := 4,
Mode := 2#0000_0000_0000_0000,
CompatibleModule := 1,
KeyMask := 2#0000_0000_0001_1111,
SafetyEnabled := 0)
ExtendedProp := [[[___<public><PL>02<Version Name=$Q2.13$Q/></PL><CatNum>1746-OW16</CatNum></public>___]]]
ConfigData := [8,4,4,0];
ConfigScript (Size := 84) := [78,0,0,0,4,0,0,0,0,0,0,0,0,0,0,0,62,0,0,0,7,1,0,0,0,3,0,0,0,12,0,0,0,1,0,29,0,0,0,2,0,0,0,0,0,3,2,0,0,0,0,0,0,0,32,0,0,0,2,0,0,0,2,0,0,0,34,0,0,0,16,0,0,0
,16,0,0,0,64,0,0,0,0,0];
CONNECTION _21000B0324042C112C12 (Rate := 20000,
InputSize := 4,
OutputSize := 2,
EventID := 0,
Priority := Scheduled,
InputConnectionType := Unicast,
InputProductionTrigger := Cyclic,
ConnectionPath := "21 00 0b 03 24 04 2c 11 2c 12",
InputTagSuffix := "I",
OutputTagSuffix := "O")
InputData := [0];
OutputData := [0];
END_CONNECTION


The most enticing part of that description is the Connection Path, "21 00 0b 03 24 04 2c 11 2c 12"

Getting out our Secret Decoder Ring from the CIP Specification:

21 00 0b 03 Class 0x030b = 779 decimal
24 04 Instance 0x04 = 4 decimal
2c 11 Attribute 11 (input ?) = 17 decimal
2c 12 Attribute 12 (output ?) = 18 decimal


I admit I don't know how the ConfigData and the ConfigScript work in this module defintion. This is internal stuff to Studio 5000 that isn't meant to be user-controlled or configured or understood. Because it looks separate from the Connection information itself, my guess is that it is what populates the pull-down and integer fields in the Configuration tab in Studio 5000 to show the Configuration data for the module.

When you get the 1747-AENTR in hand, those are the CIP class/instance/attribute codes that I would poke around with.
 
Last edited:
Ken,
I very much appreciate the effort! I was actually in the middle of reading through the CIP specification myself. It looks like if anything... i have only 1200 different assembly instances if i really wanted to try each one:D

I haven't gotten to the part describing the message structure, but between the Molex tool and Wireshark (which conveniently breaks all the data into segments with clear labeling) I think I'm in agreement with your decoding! I'm leaving for the weekend so I'll get back to it Monday and hopefully our module arrives so I can quit probing this CPU and get to the fun stuff!!

Thanks again.
 
Alfredo is probably the PLCTalk forum member with the most direct experience using CoDeSys with 1734 POINT.
I think you are over estimating my ability Ken. But I keep learning by reading your posts in PLCTalk. I appreciate very much your input. For example, it did not occur to me the other day exporting the LK5 file, and I was trying to decode the forward open request after getting a Wireshark trace.o_O

I think I'm in agreement with your decoding! I'm leaving for the weekend so I'll get back to it Monday and hopefully our module arrives so I can quit probing this CPU and get to the fun stuff!!

Thanks again.

TreyB, I think you will get your system working.

One issue about the CIP logical segment and the quote below from Ken...
21 00 0b 03 Class 0x030b = 779 decimal
24 04 Instance 0x04 = 4 decimal
2c 11 Attribute 11 (input ?) = 17 decimal
2c 12 Attribute 12 (output ?) = 18 decimal

The logical segment 2c 11 2c 12 has the meaning I explain below:
2C 11 is the connection point for the consuming IO path of the EtherNet/IP adapter. It is from the PLC point of view an output.
2C 12 is the connection point for the producing IO path of the EtherNet/IP adapter. It is from the PLC point of view an input.

Below I show how the EZ-EDS (Easy EDS tool from ODVA) decodes the CIP segment for one simple EtherNet/IP device:

20200903_CIP_Path.png
 
hello all.

I'm back. We didn't get our module for quite a long time. I have the 1747-AENTR online.. I got it addressed and I am talking to it with the Molex tool. I'm not having any luck finding the assembly instance and my guess is that the AENTR doesn't use the assembly object to communicate with the controller the same way the IO modules do. Forgive me if I type outloud here...

The previously shared Logix design files showed the instances the individual modules used to communicate with the controller. First question, is there any free software I can use to open and at least view this. I tried getting the standard lite version for Logix, but it would only install RSLinx.. So, I'm not sure that is helpful..
 

Similar Topics

Hello, I am setting up a SLC-500 rack and cannot get my Ethernet communication to work. I have set the processor to default. Set up my serial...
Replies
13
Views
2,973
Got a quick question on ethernet communication. I have an SLC 5/05 who is talking via ethernet to a panel view and two other machines. The IP...
Replies
2
Views
1,883
We have a SLC 5/04 running and would like to communicate with it over Ethernet rather than run DH+ cable to it as there is a PLC5E unit close by...
Replies
2
Views
3,574
Has anyone used one of these? http://www.prosoft-technology.com/content/view/full/2497 We have several SLC's (mostly 5/04's) in the plant that...
Replies
8
Views
5,456
I am trying to configure my RSLinx via Ethernet/IP devices setting and am looking for 133.133.120.40 and RSLinx does not "see" it. I am an...
Replies
3
Views
3,566
Back
Top Bottom