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.

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.  

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

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.

@DanW You were right on the money with everything basically. The project got delayed for several months and I've spent the 5 days worth of my time trying to get this system working with the ASCII format. 1) There was no Modbus operating in this system. 2) There were only 4 controllers talking the magical ASCII language while the dual controllers served as high limit like you said. 3) At some point somebody did have a 1746-BAS (BASIC) program communicating with the controllers over RS485 ASCII but that program was lost. This took place over an RS485 network. 4) I found a spare controller and the ASCII manual and I have been unable to send a properly formatted command that gets a response. 5) One of the controllers did have a Modbus card installed and I was able to talk to that one successfully using a Prosoft card. At this point my boss has thrown in the towel and Monday we are going to offer the customer 3 upgraded controllers with Modbus if they are willing to program them.

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?

This sounds like the simplest approach at this point. Thank you for the info!

Well based on what an EEPROM module looks like and the empty 28 pin socket from my picture I think you are right pturmel about them running the entire thing in RAM. However, the setting RS422 does suggest it is MODBUS. See the picture below from the manual.  

I get another error when trying to program the EEPROM also... when I initially got on with the system the LIST command gave me nothing. I am 99% sure it wasn't me that erased whatever was here previously... the hello world program was me though. I take responsibility for that.  

So since I couldn't get the system back up and running I took the 1746-BAS back to the office. When i type in ROM I get the message "ERROR: PROM MODE". I haven't been able to access the EEPROM.  

The device was set to: Comstate-RS422, Shedtime-30, Parity-Even, Baud-9600, Duplex-Half, Shedmode-Last, Shed SP-TO LSP So are you saying this is Modbus? So I would need a modbus master to replace the 1746-BAS?

Good morning, this is a lot of information but any advice or insight is appreciated. After another trip I have found the following information: The SLC 5/04 has a single rung of logic to copy 64 integers from the 1746-BAS card #M1:1.0. In the N7 data table I can see there are 8 old values no longer updating. They are in addresses N7:0, N7:1, N7:2, N7:3, N7:34, N7:35, N7:36, N7:37. The 1746-BAS is supposedly talking to nodes 1, 2, 18, and 19. #####1746-BAS##### The 1746-BAS card was found in the following condition which translates to the following settings. JW1: RS232/-423 (shipped configuration) == PORT 1 configuration JW2: RS485 == PORT 2 configuration JW3: 1747-M1 EEPROM or 1747-M2 EEPROM or 1747-M3 UVPROM (shipped configuration) JW4: PRT1: Program port with programmed communication settings PRT2: ASCII interface port DH485: Runtime DH485 Only From the default settings we know that PORT 2 was setup for RS485 as an ASCII interface port. I modified JW4 so PRT1 would start with default communication settings (Command mode at 1200 KB, no parity, 8 databits, and 1 stop bit). This allowed me to access the 1746-BAS with Hyperterminal.  One key setting I had to make was setting flow control to xon/ xoff. I was then able to issue commands. The LIST command returned no program. I think the program was lost. ##########   #####Honeywell DC330B##### 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 Only the first device in each node listed is connected to the blue hose. Node 18 has 2 blue wires per terminal. Node 19 has 1 blue wire per terminal. Node 1 has 2 blue wire per terminal. Node 2 has 2 blue wire per terminal. On node 2 I checked the UDC3300 settings. The device was set to: Comstate-RS422, Shedtime-30, Parity-Even, Baud-9600, Duplex-Half, Shedmode-Last, Shed SP-TO LSP. ########## I have attached pictures of the 1746-BAS card and the Node2 Honeywells... I think there was a program in the 1746-BAS that got lost and it was sending commands to the Honeywell to get a response (over ASCII). My immediate problem is I don't know what commands I have to send to get a response and then I don't know what hardware I have to buy to replace this 1746-BAS. In the meantime I will keep researching. Thank you for any more insight into the path I should be pursuing.

According to the 1746-BAS manual port 2 can talk over RS485 (the protocol) and from my limited understanding it is doing it over half-duplex since it is reading multiple Honeywells. I think I will have to gather the BASIC program to fully understand... hopefully no math besides scaling involved.

Thanks, I will plan on doing that early next week. I didn't get the exact model number of the Honeywell but these were the listed terminals. It looks like it talks over RS485 (the wiring). Does that mean it probably uses DH485 (the protocol)? Would a control logix DH485 card be the simplest path here?