EE - Forum Styles
  • Not Answered

Migration options. SLC500

I've not come across a CPU-less option for migrating from a SLC500.  

Goals: Move PLC controlled equipment to DCS.


-minimal downtime (no rewire)

-remove SLC CPU

-reuse existing SLC IO modules

Every communication option i've come across for the SLC series involves using the CPU as an IO multiplexer.  

10 Replies

  • Can the SLC I/O become remote I/O over Ethernet/IP? If so, you can use a QuickPanel + configured with PAC Machine Edition.

  • In reply to Jim Wiles:

    That's the question... From all the reading I've done though, all the Ethernet modules only work with a direct connection to another AB controller.
  • In reply to TreyB:

    I thought the 1747 AENTR might be a possibility. Not being an AB guy, I can't say for sure. Here is a link to the doc ...
  • In reply to Jim Wiles:

    yeah, we thought so as well, which is why we bought one to test! Appears it only works with a direct connection with another AB. If it CAN be used otherwise, it absolutely does not say how and I've yet to find anyone use it outside a "local AB network". Being an ethernet/IP capable module, we expected we would just need to verify the messaging type and corresponding assembly instances and/or class/attribute. No such documentation exists so far as I can tell.
  • In reply to TreyB:

    Hi Trey, First I don't believe this will work without an AB controller of some sort along with so sort of gateway. Do you have a CompactLogix or ControlLogix processor? How many I/O points do you have to bring in. AB is phasing out the SLC product line and typically hasn't support for a year or so now.
  • In reply to rbeck:

    We wanted to bypass the CPU altogether. Logic will be moved to the DCS. Paying for a controller to do little more than send IO through is not ideal. IO will vary by project. Most common project would be around 135 IO.

    Each hour of downtime can be thought of as being roughly 1/5 of the total project cost.. so you can see where downtime for wiring quickly becomes a factor. There are ways to mitigate that cost through scheduling, but if we can engineer the solution, that'd be better.

    Plants and others are concerned about having a CPU that can add another failpoint. Especially plants that already experience trouble with the PLCs.
  • In reply to TreyB:

    If you had an adapter harness to go from the 1747 I/O directly to DeltaV I/O card woud that be a possible solution?
  • In reply to rbeck:

    Not likely. That'd require additional space in the existing panels in order to have both backplanes mounted.
  • In reply to TreyB:

    That's going to be tough. I searched the AB knowledge base to see if I could find anything about connecting 1747 I/O to DeltaV or any other system for that matter with no success. I imagine exposing the atributes would be proprietary information that they just don't hand out much like Emerson wouldn't do for their I/O if ControlLogix needed to talk to a rack of Charms.
  • In reply to rbeck:

    Yeah, that's kinda where I'm at in regards to ditching the CPU. That's still most likely the goal.. but if we do that.. we will probably have to replace the whole SLC backplane with a DeltaV 8 wide and cards.. which is going to likely require more space than the current panel provides.. which means more cost. I'm not sure what the best space saving solution would be.