Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Watlow EZ-Zone PM ENET RS-485

Solved!
Go to solution
Highlighted

I found more time to experiment VISA. I am still not getting a response from the Watlow controllers. Attached is a screenshot and vi of the vi that I am playing with. I think I have all the settings (posted above) correct.

 

Also attached is the "snooped" serial commands sent by the Watlow DLL.

 

What I don't understand from snooping the serial commads is that after the write Request, the data is read back 1 byte at a time...

 

000884: Write Request (DOWN), 02.02.2015 13:30:42.713 +0.0 (1. Device: RS-485 Port (COM4))
Buffer size: 0x10 bytes
 55 FF 05 10 00 00 06 E8 01 03 01 04 01 01 E3 99   U�.....�......��


000917: Read Request (UP), 02.02.2015 13:30:42.715 +0.0 (1. Device: RS-485 Port (COM4))
Buffer size: 0x1 bytes
Status: 0x00000000
 55                                                U

000925: I/O Request (UP), 02.02.2015 13:30:42.730 +0.0 (1. Device: RS-485 Port (COM4))
IOCTL_SERIAL_GET_WAIT_MASK: Retrieve current event mask
  WaitMask=None

000927: Read Request (UP), 02.02.2015 13:30:42.730 +0.0 (1. Device: RS-485 Port (COM4))
Buffer size: 0x1 bytes
Status: 0x00000000
 FF                                                �

 

 

Any ideas?

Download All
0 Kudos
Message 11 of 16
(3,251 Views)
Highlighted

I got the communication working. Turned out there was an issue with the wiring:

1) missing 120 ohm resistor

2) TX- needed to be connected to RX-

3) TX+ needed to be connected to RX+

 

As shown here (RS-485 topologies, 2 wire multi-drop network): http://www.ni.com/pdf/manuals/371253e.pdf

 

Now that I got it communicating, I need to work on reverse engineering the serial. This is what I have so far:

 

To read zone 1, parameter 4001, instance 1, the following hex needs to be written:

 

55 FF 05 10 00 00 06 E8 01 03 01 04 01 01 E3 99
         ||          ||          |---| || |---|
        Zone        Check?         |    |  Check?
                              Parameter |
                                       Instance

 The controller responds with a value of -34.4565 (thermocouple disconnected) stored as an IEEE 754 float:

55 FF 06 00 00 00 0B 88 02 03 01 04 01 01 08 C2 09 D3 75 AA 85
                                             |---------|
                                              IEEE 754

 

It seems like there are data checks in the hex strings. Does anyone know how these checks work?

 

Attached is a spreadsheet with the commands I used to identify the hex.

0 Kudos
Message 12 of 16
(3,206 Views)
Highlighted

onlyjus,

 

It looks like these "checks" are specific to the commands and data returned from the Watlow EZ-Zone PM. 

The format for commands and returned data may be better explained in the manual for the device. Have you seen any mention of the checks in the Watlow User Manual?

 

Regards

Carli S.
Troubleshooting & Maintenance Digital Business Manager - National Instruments
0 Kudos
Message 13 of 16
(3,179 Views)
Highlighted

There is no documentation for the RS-485 Standard Bus Protocol from Watlow. I tried talking to the tech support and they wouldn't give me any details...

 

FYI, I posted on the Reverse Engineering Stack Exchange to see if anyone over there has any ideas:

http://reverseengineering.stackexchange.com/questions/8303/rs-485-checksum-reverse-engineering-watlo...

0 Kudos
Message 14 of 16
(3,160 Views)
Highlighted
Solution
Accepted by topic author onlyjus

Thanks to the awesome response from Jason Geffner over at RE stack exchange, I managed to create a set of vis to read and write to the Watlow EZ-Zone PM controllers:

 

  1. serialTest.vi - main program
  2. watlowhexgen.vi - generates the correct hex strings for various commands
  3. headercrc.vi - calcuates the header crc check byte
  4. datacrc.vi - calculates the data crc check bytes

It works well at reading. I only tested limited writing mainly to parameter 7001, the process set point.

 

Message 15 of 16
(3,138 Views)
Highlighted

Your topic is old, but you can try  https://www.com-port-monitoring.com/ I also used it in my work to "sniff" the serial commands over the serial port.

0 Kudos
Message 16 of 16
(501 Views)