Riskinit

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

17 posts in this topic

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?

Request_Messages.JPG

Hyperterminal_Send_Text_File.JPG

Hyperterminal_settings.JPG

Edited by Riskinit
Problem was solved

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

go to properties, settings, ascii setup

hyper panic.png

1 person likes this

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

hyperterm.png

ASCII.png

1 person likes this

Share this post


Link to post
Share on other sites

btw manual shows that too:

 

crlf.png

1 person likes this

Share this post


Link to post
Share on other sites

@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?

Share this post


Link to post
Share on other sites

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?)

Share this post


Link to post
Share on other sites

this is what i would try:

02,0204,64,11,128,00

followed by ENTER

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

 

in_the_event.jpg

Edited by Riskinit
1 person likes this

Share this post


Link to post
Share on other sites

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.

2 people like this

Share this post


Link to post
Share on other sites

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.

7 data bits for ASCII word size.JPG

Edited by DanW

Share this post


Link to post
Share on other sites

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

1 person likes this

Share this post


Link to post
Share on other sites

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.

Success_In_YAT_Send_Text.JPG

YAT_Text_Settings.JPG

1 person likes this

Share this post


Link to post
Share on other sites

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.  

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