Watlow EZ-Zone PM ENET RS-485

[onlyjus]

I am having trouble talking to Watlow EZ-Zone PM controllers with labview.

I cannot get the ENET to RS-485 to show up in Max. I discovered that this is due to 64 bit windows? However I can talk to the ENET to RS-485 using VISA Resource Name: ASRL::xxx.xxx.xxx.xx::1::INSTR where xxx.xxx.xxx.xx is the IP of the ENET to RS-485.

I also tried using the Watlow driver however if I put the above resource name in for the PC Comms Port in the example included with the driver and try to initialize the port, I get the following error:

Error 1 occurred at an unidentified location

Possible reason(s):

LabVIEW:  An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488:  Command requires GPIB Controller to be Controller-In-Charge.

I assume this is beacuse the  ASRL::xxx.xxx.xxx.xx::1::INSTR is not a valid input to the Watlow driver.

Please let me know if you have any solutions. Thanks!

System:

Windows 7 64bit

labview 2011 32bit

Max 5.5.0f0

ENET to RS-485

[onlyjus]

Links to documentation:

Watlow Documentation

Watlow EZ-Zone PM Driver

[SeaSick]

onlyjus,

I am not very familiar with the Watlow Driver as it is not a National Instruments supported driver. However, it appears when the device is initialized the input Coms Port is used to call a dll. I would assume that since the Resource Name that you're using is not a Coms Port you are receiving this error. Without knowing how the Coms Port is used in the dll you can't know how to reformat the Resource Name to an IP address. I would recommend contacting Watlow to find out how the dll is reading the Resource Name. Hopefully they can give some input on how to send a different Resource Name to the dll.

Regards

[onlyjus]

Carli,

Thanks for the response. I just spent a an hour waiting for some from Watlow to tell me in ~5 seconds that I can not pass the the resource name to the .dll. It is looking for a "COM" etc...

Any luck on a new driver for the ENET to RS-485? Or any hacks to get com ports out of it?

If not, seems like I am out of luck and need a different RS-485 box (probably USB).

[SeaSick]

onlyjus, 

I don't know of any hacks to get a com port resource name instead of an IP address. However, there is an option for you to request a new driver for a third party instrument on our website. Drivers are prioritized by customer need so there is no guarenteed time frame for when the driver will be made. My recommendation is to request the driver. Other than that, I don't think you will be able to use the current driver with the resource name as an IP address. 

http://www.ni.com/downloads/instrument-drivers/

Regards

[Dennis_Knutson]

What protocol is being used? Think about writing your driver.

[onlyjus]

These Watlow controllers have both Standard Bus and EtherNet/IP™. Im trying to use the Standard Bus which is how the Watlow driver works. I would write my own if I knew what serial commands to send, however they don't seem to be documented anywhere and the Tech at Watlow indicated that they are not documented anywhere and will not tell me what they are.

Anyway to watch a COM port and reverse engineer the signal?

[Dennis_Knutson]

I've used portmon from Microsoft to sniff a serial port.

[onlyjus]

So I borrowed a USB to RS-485 from another project and got it working with the Watlow controllers. I also used Free Serial Analyzer to "sniff" the serial commands sent/received over the serial port. Here is what I found out:

Seems like the .DLL sets up the serial port with the following parameters:

Baud Rate=38400
WordLength=8
StopBits=1 stop bit
Parity=No parity
EofChar=0x0
ErrorChar=0x0
BreakChar=0x0
EventChar=0x0
XonChar=0x11
XoffChar=0x13
ControlHandShake=1
FlowReplace=64
XonLimit=2048
XoffLimit=512
ReadIntervalTimeout=4294967295
ReadTotalTimeoutMultiplier=0
ReadTotalTimeoutConstant=0
WriteTotalTimeoutMultiplier=0
WriteTotalTimeoutConstant=0

 Then the .dll continuously sends a purge command:

Purge mask=TXCLEAR: Write requests

 Followed by a write command:

55 FF 01 03 00 00 00 E4

 This must be some kind of connection check?

When I try to read a value from the controller, in this case the controller at address 1, parameter 4001, instance 2, the DLL writes this:

 55 FF 05 10 00 00 06 E8 01 03 01 04 01 01 E3 99

 It then reads:

 55 FF 06 00 10 00 0B 88 02 03 01 04 01 01 08 C2 09 D3 75 AA 85 

 Which is a float on the order of -100 (the value is bouncing around).

I tired sending the read value hex to the controller with VISA however, I never got a response.

Any ideas on how to re-engineer this driver/get it to work with VISA?

[SeaSick]

onlyjus,

If you are interested in re-engineering the driver then Watlow may be a better resource to help you with this.  Since NI only access to the very limited portions of the .dll you attached above, it is hard to say how you can motify it to work with VISA. 

However, the link below provides directions for using HEX commands with VISA. This looks like it will be helpful when you are trying to send the commands you discussed above. 

.

http://digital.ni.com/public.nsf/allkb/19B075803E013125862575CF006B37F8

Regards