[SOLVED] How to send ASCII commands over Hyperterminal to old Honeywell UDC

[Riskinit]

I have a very old Honeywell controller that only supports an ASCII protocol and another DMCS protocol (proprietary to Honeywell).

I am using this manual: http://www.amarketplaceofideas.com/wp-content/uploads/2019/07/51-51-25-35h1.pdf

and Hyperterminal "Send a text file" function to try to send an ASCII command to the controller. 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. Does anyone know what the correct format might be?

Edited October 5, 2022 by Riskinit
Problem was solved

[IO_Rack]

The CR will happen when you press Enter.

I haven't used Hyperterminal in a while but there is an option somewhere to "Send Line Feeds with Enter" or something like that.

I would use RealTerm. It's a free download from Source Forge. This program gives you a lot more control and visibility to these invisible characters. 

[panic mode]

go to properties, settings, ascii setup

[Riskinit]

Thanks for the pictures. I gave it another go and haven't gotten anywhere with it. The other system just refuses to respond. Without throwing an oscilloscope into the mix I don't think I am going to get anywhere at this point. I am recommending to the end customer we upgrade to new Honeywell controllers.

[panic mode]

changing hardware for a newer may be a smart idea to avoid obsolence but it will come with a cost (hardware and programming) and will not change anything if message is in wrong format. and i think that is what you are dealing with...just checked your post closer and see this:

The "CR LF" is supposed to be just a pair of characters (only 2 bytes), but based on your screenshots you have entered it as string of 5 characters. also since you are sending message without checksum, the last comma is likely also not needed... (maybe)

CRLF is normally added when you type command using keyboard and hit ENTER.

CR is Carriage Return and has value 0x0D 

LF is Line Feed as has value 0x0A

in a file you would need to do the same so that next line is shown (see lines 3 and 4)

for more details change view to show all characters and you will see why.

 

[panic mode]

btw manual shows that too:

 

[Riskinit]

@panic mode Thanks for getting back to me. If we switch over to another Honeywell controller it will have Modbus and I am already able to talk to Node 1 using Modbus so programming wise we are done.

I will grab Notepad++ and try communicating once more. I have literally sent a couple hundred different commands using various terminals. In your recent example you have 1 byte for the CHECKSUM. Is that correct or should I sent 00? Or because I am ignoring the CHECKSUM should I drop it all together?

[panic mode]

no idea... i would try all options. i think manual mentioned that checksum is options but it did not specify if it is to be omitted or populated with something random like "00" so you will have to try. my main point is that termination was incorrect and instruction was likely rejected because of that, even if correct CRLF is encountered after that... this really should be quick and easy to try. now that i think of it, it is probably needed (same fixed format) but value is simply not evaluated by device. so your message looks ok other than CRLF.

other than i would question if COM port settings match the target or if wiring is correct. Are you getting any response back? if so what does it look like?  if you do not get anything back, chances are that wiring is incorrect. if replies are garbled, then port setting config is not right (wrong baud rate, data bits etc.). also are you sure that node address of target device is correct (2?)

[panic mode]

this is what i would try:

02,0204,64,11,128,00

followed by ENTER

 

 

[Riskinit]

I have gotten no response from previous tries with any configuration or any text editor.

I will try what you said and post back later today.

[panic mode]

no response at all? i would check wiring, terminations, baud rate, correct node address...

[Riskinit]

So after banging my head against a wall for 5 days I decided to open up the box and look for physical damage to the communications card... which is evidently missing.

Apparently you can select the various ComStates even when that card physically doesn't exist. This is counter intuitive to me because in the field I had 2 similar models of controllers that limited the user to only selecting RS422 while the test model I had on hand was able to select any ComState.

I'm off to the field again tomorrow to try and send an ASCII command directly to one of the Honeywell controllers.

 

Edited October 3, 2022 by Riskinit

[panic mode]

also note that comma separator is still needed when no checksum is sent (see 3.9 Loopback example)

so the message should be 

 

02,0204,64,11,128,

followed by ENTER,

 

Loopback can be used to scan network for attached nodes.

[DanW]

Serial settings for Modbus RTU, by the standard, is 7 data bits, not 8 data bits.   

Apparently the ASCII protocol uses 7 data bits, too.   When you get a comm card, give 7 data bits a try, instead of 8.

Edited October 5, 2022 by DanW

[pturmel]

Modbus RTU absolutely cannot use 7bits per character, and says so in the standard (Modbus Serial v1.02 § 2.5.1) .  Data in RTU is transmitted in binary--7bit characters would clip 2 bits per HR, and drop one coil in 8.

Official standards are here:

https://modbus.org/tech.php

[Riskinit]

SOLUTION: I went back onsite yesterday to send commands directly from a terminal to the UDC. Basically my 2 problems, besides not having proper hardware, were the 7 bits of data and the CR LF format not being correct.

I could not get Hyperterminal to work in any conditions.

I was able to to send commands in YAT (Yet Another Terminal). I have attached screenshots of the settings I used.

The exact text is: 02,0204,04,18,118,<CR><LF>

02,0204,04,18,118,\r\n also worked when sending text.

Nothing worked with Send file. YAT has a setting to automatically send CR LF though which did let that feature work.

The I/O settings had to be 9600 baud, 7 data bits, even parity, 1 stop bit, no flow control. All other settings were default.

My new problem is identifying hardware that can take ControlLogix strings and send the ASCII out over the network but that is another forum post for later.

[DanW]

Good catch Pturmel.   I can't proof read my own writing.  

Yes, Modbus RTU uses an 8 bit data word.   I meant to write "Modbus ASCII" is a 7 bit data word.