TDC3000 DH+ to ControlLogix

Flyers posted this to an old thread, and I'm putting it into a new thread to separate the issues and questions.

I'm new to CLX, this is something new to me, I do not know the CLX module can work as bridge!

Can we bridge a controlnet (AB CLX) with a DHRIO module into KF2 to communicate with Honeywell DCS on serial?

CLX (CNET) ---- CNET+DHRIO(bridge) ---- KF2 ---- Honeywell DCS (TDC 3000).

Existing is PLC5 --- KF2 ---- Honeywell DCS (TDC3000).
We do not want to change anything on the KF2 & Honeywell, as DCS is beyond our job scope

Click to expand...

The ControlLogix can emulate PLC-5 messaging on a DF1 or DH+ channel by configuring INT or REAL tag arrays to correspond with particular PLC-5 type data files.

The complication is when you use a relatively simplistic interface like that provided by the TDC3000. The DF1 commands that the TDC3000 sends to the 1770-KF2 module can only communicate with a DH+ node on that particular DH+ network and has no ability to bridge to another DH+ network.

That's why you can't go TDC3000 -> 1770-KF2 -> 1756-DHRIO -> 1756-CNB -> ControlNet -> 1756-CNB -> ControlLogix CPU.

All the "hops" past the 1756-DHRIO would require a remote DH+ packet, which the TDC3000 does not (to the best of my knowledge) support, since it's interface was built to communicate with local PLC-2, PLC-3, and PLC-5 controllers on DH+.

The 1756-DHRIO does have a "default Slot" parameter, which will allow local DH+ packets to be routed to one CPU in the same chassis as the 1756-DHRIO. If you can put the 1756-DHRIO in the same chassis as the CPU (and eliminate the ControlNet segment), then this interface can work.

Ken Bridging is possible only thing the DCS won't read CLX tag architecture

Would a routing table in the DHRIO module work?

We're trying to do this here also where we are trying to talk to a Controllogix via DH+ through a 1785 KE module, which we have successfully talked with SLC 5/04 emulating PLC2's. (remembering to set the CIF bit) We're trying to emualte a PLC2 in the Control Logix but are getting ABSTS_=0 message on the DCS arrays. We've set the 1756 to the correct controller slot # and have the octal address set correctly. We can plug into the 232 port on the KE module remotely and see the program and all just fine over DH+, but we can't seem to emulate the N9 file correctly. Anyone out there can give us some ideas or have been able to accomplish this?

Ideally we'd create this as a new thread, since this thread is broken off from an old one and contains incorrect information about a different problem.

To determine if the ControlLogix setup for Default Slot Number and PLC/SLC Address Mapping is done correctly, I would recommend connecting a PC with RSLinx set up to poll a PLC-2 controller to the RS232 port on the 1785-KE. If that works, you can move next to the DCS configuration.

Describe exactly which module (I presume Honeywell TDC3000 with an APM/HPM and an SIO module, but I don't know for sure) on the DCS side and precisely how you configured the DCS master.

Sorry about the thread, wasn't sure if it should be new or not.

You are right in your assumption - we have a TDC3000 with HPM's. We talk to 1785-KE via a Honeywell A-B SI FTA.

This new controllogix has been added to an existing DH+ network with a bunch of SLC 5/04's that we have (and are) successfully talked with. (remembering the CIF bit) Controllogix is new to us and was required by a project that has seen a new MCC talking device net to several VFD's and a whole bunch of E3's.

Our SLC's are supposedly set up to emulate PLC 2's. This is confirmed as our existing TDC arrays have "2" under PLC type. We have successfully communicated for years in this fashion.

We can see the Controllogix program and files fine over the DH+ by plugging into the RS232 port on the KE module.

The error we get on the TDC array is ABSTS_=0. Usually the errors are 2 digits without an "=" sign. When we were trying to explain this to Rockwell tech support we got the line "I've been doing this for 15 years and zero means it's okay..". The normal message on the array for SI ERROR is OK_POLL. The TDC documentation states when you have a ABSTS_nn message consult the Allen_bradley device documentation for the error code, but they didn't want to hear that. So, this seems to be pointing to the controllogix configuration. (Rockwell hasn't been very helpful)

We have been trying the PLC2 emaulation on the Controllogix file which gives you the N9 drop down which matches the way we do the SLC's. (all info to the TDC must be mapped to N9)

We are considering trying the PLC5 emualtion, but since we've built everything to go the N9/PLC2 route we'd like to see if we can that to work. We're trying to followup with Honeywell also, but in the past all we seem to get is a lot of finger pointing between the two vendors.

I figure since we can see the program okay via DH+ there should be some kind of way to get the info to the TDC without putting in an intervening PLC. It also seems inlikely we are the first to try this and someone must have made this work somewhere before.

I have been surprised by how scarce this kind of information is. After several years of this coming up occasionally, a customer of mine finally came up with one hardcopy of the Honeywell SIO module documentation. It promptly disappeared in my office. I think the documentation is haunted.

The Rockwell tech support guy was right, and so are you, but you're maybe talking about different things.

In the DF1 protocol, there's a Status byte that is part of a DF1 response, and its abbreviation is "STS". When the value of the STS byte is zero, it means that the poll was successful.

But in your TDC array status, the label "ABSTS" might not refer to the value of the STS byte. After all, "OK" isn't a value of the STS byte.

If the "=0" does not mean "equals zero", it might mean "ASCII representation of the value 0x3D30 hex". Just a wild guess. Or it means that the TDC3000 has not ever encountered the STS value or extended STS code that it's getting now.

It would be really great if you could put a serial analyzer in line between the TDC3000 and KF2. That data capture along with a list of the DH+ node identities would go a long way towards solving this problem.

Check your PM's; I have a serial analysis kit that I can easily loan out for this kind of thing.

I have all the Honeywell SI card documention, I implemented one talking Modbus just this week.
This is by far the most popular route even with AB products (yay for ProSoft) due to Honeywell not really embracing anything but PLC5.

I've successfully done SLC (using PLC5 emulation) and native PLC5 implementations without too much hassle but never a CLX one.
What do you guys need regarding the documentation?

Thought I would tell everyone we managed to get it working.

The thing that was getting us was setting up routing tables in the 1756-DHRIO module. Rockwell support said we didn't need to do anything to the routing tables, but until you actually set one up you don't get any data for a non-routed poll like the 1785-KE uses. RSLinx is a little deceptive since it can use CIP protocol which the 1785-KE can't. (cf Rockwell publication DH+ Remote I_O comm interface module 1756-um514_-en-p) You need to put the controller slot number in the 1756-DHRIO, but also you need to put a number for the link ID for the channels in it as well and get a routing table created.

We set up the MAP PLC/SLC as a PLC5, with that file 9 with the name N9, and configured our TDC3000 arrays accordingly. For those conversant with TDC3000 the array parameters were PLCTYPE 5, FILENUM 9, DATATYPE 7 for integers on the numeric array, DATATYPE 3 for bit on the flag array. (cf Honeywell publication OP01501 "APM/HPM Serail Interface Options") Obviously we built 2 arrays. The DEVADDR was the Octal node address set on the bottom of the 1756-DHRIO module for channel A, which is where we landed our DH+.

We spent a lot of time with Rockwell tech support, getting 5 different people with different opinions over the course of two days, some of who said we couldn't make this work, so I'm leaving this post as a trail so that someone else who comes across this can use this info.