Ethernet/IP comm with SLC IO

Can someone zip and post the eds files for all of the components? Adapter, Io modules, maybe the backplane if this is a separate eds..
In theory this should completely describe the available connections, but sometimes it can be a bit opaque. And it's raining today, so...
 
Thanks for popping back in after disappearing without any feedback.

There is nothing to view in Ken's zip file. It's an empty program. Below is the screenshot of IO that Ron setup:

1746-IO.png



Attached are eds files:
 
Last edited:
Thanks for popping back in after disappearing without any feedback.

Umm.. okay.

Attached are eds files:

I was more interested in the EDS for the AENTR. But, I don't think I understand what it's showing me. The assembly information is interesting, but it doesn't tell me what instance is used, that I can tell. Or how to decipher the data that may be in these "chunks". Again, new to this so maybe there's something I'm not seeing.
 
Would that give us the ability to write to the IO though? We want to bring control under the DCS.
I don’t see why not. All you would need to do is write from the DCS to the appropriate data files in the SLC. Having said that, I don’t know anything about messaging to and from a DCS but if it supports PCCC messaging then it should be able to send data to and from the SLC via Ethernet/IP TCP. You might need to move the I/O data in/out of data files in the SLC but creating some “MOV” ladder logic sounds a lot easier then trying to reverse engineer a generic CIP connection (at least for me). It would also give you the ability to create some level of “intelligence” at the I/O level if needed. For example, if there is an alarm condition that occurs, you could program the PLC to deal with it (I.E. shut a process down?) rather than waiting for the DSC to do so. The advantage in that scenario would be that even if communications between the DCS and the SLC fails, the SLC could maintain a certain level of control and safety.
On a related note, it is worth mentioning that AB has put the 1747-AENTR and 1747-L55 (SLC5/05) on Active Mature status. There is no date set yet and it could be years but it’s worth keeping in mind.
 
If it were my system, I would very strongly recommend leaving an SLC-5/05 controller in place and allowing it to control the I/O, and to use ordinary well-understood, easy-to-diagnose, easy-to-configure Data Table Read and Data Table Write commands to communicate with the DCS.

I will try not to sound too sour, but will say that when a customer has a bad experience with third-party integration, that helps sell native Emerson I/O. This creates a perverse incentive on Emerson's part to make third-party integration projects go badly.
 
I don’t see why not. All you would need to do is write from the DCS to the appropriate data files in the SLC. Having said that, I don’t know anything about messaging to and from a DCS but if it supports PCCC messaging then it should be able to send data to and from the SLC via Ethernet/IP TCP. You might need to move the I/O data in/out of data files in the SLC but creating some “MOV” ladder logic sounds a lot easier then trying to reverse engineer a generic CIP connection (at least for me). It would also give you the ability to create some level of “intelligence” at the I/O level if needed. For example, if there is an alarm condition that occurs, you could program the PLC to deal with it (I.E. shut a process down?) rather than waiting for the DSC to do so. The advantage in that scenario would be that even if communications between the DCS and the SLC fails, the SLC could maintain a certain level of control and safety.
On a related note, it is worth mentioning that AB has put the 1747-AENTR and 1747-L55 (SLC5/05) on Active Mature status. There is no date set yet and it could be years but it’s worth keeping in mind.

Yeah, so we'd have to keep a program running on the SLC.. which is what we want to avoid. Our engineer who services the fleet's PLCs has to constantly reload program files whether due to strange faults or power loss. We obviously want the DCS to control the process, so taking the automation to the DCS but leaving the program in place (albeit in a different form) is still a half measure. But, yes, what you mention would work.
 
>Our engineer who services the fleet's PLCs has to constantly reload program files whether due to strange faults or power loss.

If that's true, then nothing you are going to install from any vendor is going to work any better.

If it's your goal to have all DCS-controlled processes, plan and budget to replace your I/O with the native DCS vendor platform, with whatever they charge you to maintain it.

Leave the Rockwell support guys, and the obsolete 1746 I/O system, out of it.
 
We are trying to phase out the PLCs altogether. It doesn't make sense for us to have a DCS to automate the entire plant, but still have these little "black boxes" everywhere. The plants love when we convert a PLC. There's transparency for operators that is consistent with how they control... nevermind, I won't justify the reasons. That's not important here.

So, the number one priority is moving from PLC control, but commissioning down time and electrical rework would be drastically reduced if we kept the existing IO.
 
If that's true, then nothing you are going to install from any vendor is going to work any better.

If it's your goal to have all DCS-controlled processes, plan and budget to replace your I/O with the native DCS vendor platform, with whatever they charge you to maintain it.

Leave the Rockwell support guys, and the obsolete 1746 I/O system, out of it.

This is what we typically do. Mind you... i don't create the budget and the projects are more attractive when we tell the plants that they will have reduced downtime. And eliminating electrical contractors is a plus..
 
We are trying to phase out the PLCs altogether. It doesn't make sense for us to have a DCS to automate the entire plant, but still have these little "black boxes" everywhere. The plants love when we convert a PLC. There's transparency for operators that is consistent with how they control... nevermind, I won't justify the reasons. That's not important here.

So, the number one priority is moving from PLC control, but commissioning down time and electrical rework would be drastically reduced if we kept the existing IO.
Keeping in mind that I completely understand the position you are in (so this isn’t a comment on you) but from what you just explained, a phrase I learned a long time ago and something I’ve experienced many times (in both Automation and Automotive repair) comes to mind. “Cheap comes out expensive”. That said, that’s not the reason you reached out so I’ll leave it at that. At least you do have a couple of options if you aren’t able to reach the ultimate goal. Good luck with it.
 
Success!!
I have found the class object that holds the IO data. It is 30Bh. Each instance represents a slot in the chassis. So far I have read and wrote to DI, DO, AI and AO modules. The inputs use Attribute 9 and the outputs use Attribute 8 for the data. From there it was pretty easy hookup a test setup to figure out what the bytes in the data were doing.

I did all the communications so far in the Molex EIP tool software. I am yet to actually get it talking to the DeltaV controller, but that uses explicit messaging the same as the EIP tool. So, that will be a challenge, but most likely just a process.

What I did was wrote a Perfect Keyboard macro to type in hex 1-xxxx. I figured out what the range for valid class objects was and used Instance 0 as my class level instance. Then let the macro run, put the counter high enough and came back to check the log file for any hits. Did the same for Instances for each Class I got a hit... then followed course with the Attributes. Without the macros it would have taken me weeks of manual typing! I would have given up.

Hope someone finds this useful!

I did run into a problem with the potential to use the AENTR card.. it lost its IP address when it lost power... that's going to be a deal breaker if I can't resolve it... maybe I'll be back with a separate post.

Thanks everyone for the help.
 
Great approach and great solution!

I did run into a problem with the potential to use the AENTR card.. it lost its IP address when it lost power... that's going to be a deal breaker if I can't resolve it... maybe I'll be back with a separate post.

This is almost certainly a very simple fix. Check that after you assign it an IP address you have disabled BOOTP/DHCP in the module.

I can't be sure on the 1747-AENTR specifically, but on a lot of other AENTR modules there are also specific combinations you can set the addressing switches to, which will do various things on a power cycle (like factory reset). Check the position of those switches as well, assuming they exist on this particular module.
 

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,972
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,882
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