Identify what protocol this Honeywell UDC330B is talking over and how do I talk to it?

Background information:
I had an existing system with a SLC 5/05 and a 1746-BAS card that was talking to 4 Honeywell controllers but broke at some point (most likely because the 1746-BAS lost power and lost its program).

I replaced those components with a 1756-L81E and a Prosoft MVI56E-MCM card. After tracing all the wires, and identifying 1 bad cable, I disconnected 3 of the Honeywell controllers from the chain.

Before the disconnect: Prosoft card --> Node 2 --> Node 1 --> Node 18 --> Node 19
After the disconnect: Prosoft card --> Node 2

The previous wiring was very strange. See the picture labeled Back.jpg. I have rewired things so they match the Schematic.jpg except there are no resistors.

Node 2 information can be found here: - Model DC330B.pdf

Node 2 settings are the following:
ComState: RS422
ShedTime: 30
Parity: Even
Baud: 9600
Duplex: Half
Shedmode: LAST

I cannot get this new temporary system to work with any settings I try. I have tried RS422 and RS485 on the Prosoft side. I feel like I have tried every combination of 9600 baud available. I have tried RTU and ASCII. I have tried 7 data bits and 8 data bits. I typically do a warm boot when changing settings but have tried some cold boots also. The only result I get from the Prosoft card is -11 which means "wiring issue".

Looking at the documents and pictures for this Honeywell controller; does anyone know what settings I should use to talk to it?

I appreciate any advice and/or thoughts.


The protocol that is intended to be used is Modbus, because the Prosoft MV156E-MCM is a Modbus module.

The UDC330B also had an earlier proprietary serial ASCII protocol, but you select MODBUS under ComSTATE to get Modbus RTU.

I think one of your problems is the parity setting. The note in a 330B manual (dated 2000, the date code on the controller is 1998), states that parity is set to NONE when Modbus is the selected comm protocol, so go with No parity (more recent UDC versions do not even offer the parity setting; parity is fixed to NONE.) So set the Prosoft to: no parity, 8-N-1. You might have to power cycle the Prosoft module for serial setting changes to take effect.

Parity is fixed at NONE when ComSTATE is Modbus.JPG

The UDC is a slave only, so somewhere you need to find the slave node ID number; that parameter was called Com ADDR.

Be aware that Modbus read functions run OK, but Write Functions, like writing setpoint after setpoint for a ramp/soak program can destroy the operating system EEPROM over time. EEPROM only take so many changes before given cells fail and repetitive writes to the same register will cause an EEPROM to fail.

Enabling the SHED function was supposed to write to RAM instead EEPROM to avoid damaging the EEPROM. If the action is to read only then SHED does not need to be enabled.

The notation (+) and (-) or A/B used for the RS-485 driver lines varies from vendor to vendor. If the lines are reversed, there's no damage to the drivers, but you'll never get comm to work. Swapping the lines on one end resolves it.
The Comm setting for Modbus is RTU, multidrop, therefore RS-485.
Thank you for the valuable information. One difference between what you stated and what I have is this particular Honeywell UDC only allows the option of RS422 for ComSTATE which I think is achieved through an expansion card of some sorts because the Model Selection Guide does not match the capabilities of the controller. Nodes 1 and 2 are the same way. Nodes 18 and 19 are a newer Honeywell model with Modbus available as a communication option.

I am pretty confident I don't have the DMCS Communication (proprietary) option so no worries there.

Since the ComSTATE is RS422 does that mean I need another communication protocol (different hardware) to talk to it? I think some confusion stems from the fact that there are communication protocols and hardware setups named the same thing. The 1746-BAS was a basic program so it makes sense it could talk to multiple pieces of equipment over different communication protocols.
That ASCII card (if that's what it is) was added to a basic UDC 3300B, as indicated by the model number on the case label in your first post.

The selection RS422 enables the ASCII protocol (the pdf conversion of the manual apparently screwed up the Parameter Definition column; the distorted word should be "allows"
RS422 is the comms setting for ASCII.JPG

I gotta ask. Unless your time is of no value, can you afford to code what's needed to get a proprietary protocol talking, when there's a reasonable chance that the Modbus card in a used 3300B (going for $300 on ebay) will work OK? Is the Prosoft module even programmable for ASCII comms?|tkp:Bk9SR5ielMvvYA

Honeywell hasn't sold 3300 parts for two decades now, and there's little chance of finding a Modbus card as new old stock.

If the other drops are Modbus RTU, why not stay with Modbus RTU?
I'll admit this has been an extensive learning experience and luckily my boss also sees it that way.

On Thursday I am going to verify once more that I can't change the ComState.

The Prosoft card cannot talk ASCII as far as I know but we will recoup some of the cost by selling it or using it on another project.

I have an alternate hardware solution that might work for me:

If the manual commands are correct it should take me a day or less to program (I only need the current temperature and setpoint).
The three digit field in the model part number has one digit for a comm card. If there were two comm cards, one for ASCII and a different one for Modbus RTU, then the model number would have had one numeral for ASCII, a different numeral for Modbus. But there is only one numeral, in this case the numeral 1, for the comm card, which is described as ASCII or Modbus. Hence there must be only one comm card whose functionality is determined by configuration. The graphic shows the choices for model number selection for the three digit field, which on yours is -000-, but the point is that there's only one comm card that does either Modbus RTU or ASCII.
Third field, 3 digit has the digit for the comm card.JPG

Generally, the settings on a Honeywell UDC controller do not show up in the config menu unless there's hardware for that setting. So the presence of the ComSTATE setting should mean that there's a hardware comm card present. By model-number reasoning, that comm card should be configurable for either Modbus or ASCII.

I think I agree. Either the card is broken or I misunderstood I could change the setting when I was onsite previously. Hopefully that is the case and this can all be resolved with Prosoft Modbus on Thursday. I'll post back updates :)
I am onsite today and have some results. After figuring out how to unlock the configuration so I could change the ComState to something besides RS422 I have bad news (for me). The ComState options available are None, RS422, and DMCS (proprietary format).

So my options are:

1) Get hardware to send ASCII commands as needed.

2) Upgrade the communication card to support modbus.

Neither option is that good in my situation. I am going to try and send some commands from Hyperterminal today to verify I can talk to it using ASCII.
Another update. This system originally had 4 nodes. I extended the network to the next node in the chain which did have the ability to be changed to Modbus and I am successfully reading values from that node.

Therefore the problem really does lie with a single node not being Modbus capable.
Well... after looking closer at the situation I now realize Node 2, 18, and 19 don't have MODBUS at all. I don't know why I missed that initially... but I continue to learn a lot from the situation.

I am using this manual and Hyperterminal to try and send an ASCII command to a spare Honeywell controller I have on hand in ASCII mode.

My command looks like this: 02,0204,64,11,128,0,CR LF
When I do this in Hyperterminal I get no apparent response.
My hypothesis is I am not sending the correct formatted ASCII. Do you know what the correct format might be?