Upgrade a SLC 5/04 to ControlLogix

26 posts in this topic

Posted (edited)

Have you ever pressed to see whether this network ever actually worked to any degree? 

The mix of Honeywell products and their protocols makes me think that someone might have attempted and then abandoned the project, given the mix of protocols.  The absence of the program in the Basic module might disclose how the project actually got before being abandoned.

There are 8 Honeywell devices I located in the field and they come in pairs.
Node1: UDC3000 VERSAP PRO and UDC2000 MINI PRO
Node2: UDC3300 and UDC2000
Node18: DCP1021111110 and UDC500 CONTROLLER
Node19: DCP1021111111000 and UDC2000 MINI PRO

1. Pairing - High Limits
I suspect that one of the UDC's for each pair of controllers is a high limit controller for a temperature control loop.  The fact that the comm cable only runs to the first controller in the pair confirms that.

a. UDC 500
The UDC 500 is way past its expected life span.  It was obsolete when I started selling Honeywell in 1988.  I only one I ever saw was one that was replaced in about 2004.   If it still trips as a high limit, why not use it until it dies, but it could be lights out any day.  

b.  UDC 2000
The blue bezels were obsoleted in about 1993. Blue bezel 2000's had no communications option
The gray bezel DC200x models were obsoleted in 2000.  Gray bezel DC200x models had no comm option.  
    A DC200H is a high limit model
Replacement models were gray bezel UDC 2300 (DC230x) and the current model UDC 2500  (DC250x)

2.  Single loop Controllers

a. UDC 2300B
DC230H is a high limit version.  DC230x-xx-1x had an "RS-485 ASCII/Modbus option".  The ASCII is a proprietary ASCII protocol, not Modbus ASCII (106 page manual).  The Modbus option was Modbus RTU.   Very few sold with the comm option, even fewer implemented.  No one ever implemented the ASCII version to my knowledge.

I know that a UDC 2500 UL-approved High Limit controller (Modbus slave) will not accept a Modbus "write" Function Code (FC 06) for the operating setpoint variable.   One of the main operational uses in heat treat is to use a setpoint appropriate for the load for the high limit controller, but UL does not allow remote (comm) change of the operating setpoint.   I never tested to see whether a reset function (to reset the latched output) could be implemented via Modbus (I see that there's an output override value at (4)0035 that might reset the output)

b. UDC 3000
The UDC3000 VersaPro (first generation) had one of two comm options, a proprietary DMCS protocol or communications RS-422/485, for another proprietary protocol with a 135 page manual.  As a Honeywell distributor we were aware of a couple OEMs who used DCMS; but I never encountered anyone who actually implemented the none-DCMS proprietary protocol.  That early, first generation model did NOT run the Modbus protocol.

c.  CSP mode
For Modbus comm, the UDC used a "CSP" mode to accept remote setpoint writes to the UDC to save the EEPROM.  The CSP mode held the remotely written setpoints in RAM and those updated setpoints were not written to EEPROM, because the EEPROM has a life-time limitation of the number of writes it could accept before bits failed.   Anyone communicating setpoint ramp values should have used the CSP mode because the constantly changing setpoints could crash the EEPROM (which is the units firmware) in a matter of weeks.

d.  UDC's could have had a Setpoint programmer/profile option for a single SP program profile.  Could the comm have been tasked to just RUN, ABORT or STOP the profile?

3. DCP setpoint programmers
The DCP102 is either a Yamatake "setpoint programmer" (runs 1 of x internal preconfigured ramp/soak setpoint profiles and can run the associated PID control) sold by Honeywell as a private label or a Honeywell France import.  I can't remember, but I suspect the latter because the configuration uses letters and truncated words, as opposed to Yamatake's love of numerical codes ("function 17" instead of "Inp 1 Type")

A DCP 100 spec sheet dated 1996 says, "RS485 ASCII serial communications", (which is table 4, code #1 in the model number).  It is not likely to be Modbus ASCII.  The user manual does not cover communications and I never had manual for the ASCII communications.   A numeral 1 in the model number says that these DCP102 had the 485 ASCII comm card.

A different, undated, but later DCP100 model selection guides shows that Modbus (RTU/485) was available only on the DCP10T model, not the DCP102 model.

The Yamatake DCP's never ran Modbus RTU or Modbus ASCII protocol.  

4.  Summary

This is really, really old, obsolete stuff.  If it fails, Ebay is the only source of a replacement.

What tasks are communications supposed to support/implement?  Select and program and RUN?  Generate ramp/soaks?   

How much time can you put into writing drivers for proprietary ASCII protocols (plural)?  Do you even have the manuals?


Edited by DanW
1 person likes this

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now