Watlow F4 and I need couples counseling (communication issues)

N

Thread Starter

Nate

Hi everyone,

I've got a dilemma here--I'm trying to communicate with a Watlow F4 which is controlling an environmental chamber. The controller uses RTU and has an RS232 port. The manual states there should be no parity.

I've made an RS232 cable using 3 wires--straight through. I've also tried a null modem cable but have been informed that I should be using a straight-through cable.

I've tried Modbus Poll, Watlow's ModbusTest and Comm7, and found some MATLAB code (which would be ideal and my end goal to use). All of these have been confirmed to be outputting what appears to be a valid RS232 signal with an oscilloscope. However the F4 does not reply. (I've fashioned a little connector that allows the F4 to be hooked up while the Rx and Tx lines are being monitored by the scope) Not even an error message. I am under the impression that if a Modbus slave receives an invalid command it will report an error, am I wrong?

Answers to inevitable questions:

The baud rate matches (9600 but I have also tried 19200 on the slave and the program) Slave address is correct (1)

Comm port is correct (especially seeing as how the signal is getting to the controller)

I am trying to read from register 100, relative addressed, in which the current temperature of the chamber is stored

Here are the settings I am using to attempt "contact" with the timid controller:
-8 data bits (RTU standard, amirite?)

-no parity

-1 stop bit (I understand this defaults to 2 stop bits when there is no parity but I have been told this is what I should be using)

-Additionally, I have systematically tried every combination of 7 or 8 data bits, even/odd/no parity and 1 or 2 stop bits.

Anyway, I have been at this for over a week now without a single peep from the F4 and I am at a loss. I have talked to 4 different tech support guys from Watlow and Tenney (manuf. of the chamber) and stumped every one of them. One of my predecessors, who has since left the company has gotten it to work with Modbus Poll about a year ago. He said he was in a similar situation and he just had to "fix the port" to get it to respond. Well there are not a whole lot of options in Modbus Poll for me to mess around with. The only thing beyond the data bit/parity/stop bit options are DSR, CTS, RTS and Echo which I am not too familiar with but tried messing around with them to no avail.

I am new to Modbus and can't help but think: there is no way this 2-year-old $1000 controller stopped working over the course of a year of inactivity. I have GOT to be missing something, and hopefully someone more seasoned in Modbus can point out the obvious. If you have a suggestion that seems obvious, I'd love to hear it. If you have any other suggestion, same deal. I am really starting to resent the poor F4 and I would like to be able to cultivate some sort of relationship, I just need her to talk to me!

Thanks in advance for your help.

All the best,
Nate
 
S
Not sure how to digest "straight through" vs. "null modem" in the context of a terminal strip on the controller, but it looks like the wiring should be the following:<pre>
F4 - DB9

14 - 2
15 - 3
16 - 5
24 - 9</pre>
Plus shield to 5 and 7-8 jumpered on the DB9.

First confirm that this is what you have.

(NOTE: The F4 terminal 24 is kind of strange because the graphic of the terminal strip only goes up to 16. Presumably it's on some strip other than the comms one.)
 
B

bob peterson

Is the comm port perhaps in use by another program? RSLinx is (in)famous for taking over a serial port and never releasing it, even if RSLinx is shutdown.

--
Bob
 
S
Nah, there's bits coming out the port. He can see them on his scope. One thought would be to put a PC on the line in protocol analyzer mode and look at the packets. I bet it's something simple though like he's missing his RTS-CTS jumper or the controller has a setting to enable comms that needs to be turned on or something.
 
Page 77 of the manual says that when a F4 controller cannot process a command it returns an exception response and sets the high bit (0x80) of the command (command + 80hex).

So it should respond to a bad command, too, if you're reading the transmit line on the F4 with respect to the RS-232 ground.

Is Modbus an option on the unit or standard?
 
Indeed; I have seen the waveform with my very own eyes, so the COM port, software and everything leading up to the actual transmission of the signal are not the issue at hand here.

Furthermore we have gotten the unit to work with Modbus Poll before, so Modbus functionality is present.

And yes, the unit SHOULD be responding even when it receives an invalid command. So I am not sure what is going on here.

A few more recent discoveries:

-Today I talked to the guy who got it working last time and it turns out we had different issues. He could not read into the COM port, but the controller was responding. For me, the controller just does not respond as confirmed by the oscilloscope on the Rx line. So I am thinking that however improbable, it IS possible that something happened internally between then and now. I would like to open up the chamber to check the wiring but my boss is unfortunately not exactly keen on the idea and I will need his go-ahead before I can touch it.

-The nearest computer with a serial port is about 50 feet away and in use heavily. The computer I have been using has a USB-to-serial adapter and as such is outputting a +/- 5V signal as opposed to the +/- 12V that RS232 calls for. I have tried using a long cable to the computer that has a serial port, but it only produced +/- ~10V due to the extra resistance, and the slew rate has been slightly degraded due to the extra capacitance (does not seem to be degraded enough to be an issue at 9600 baud)--it's also entertaining to see the massive EM crosstalk between the Rx and Tx lines with a ~50ft cable. Anyway, the controller remains unresponsive. (While I am aware that the RS232 protocol dictates that anything between 3 and 12V should be a valid signal, I do not think it is wise to rule out lazy engineers. ;)

Thanks in advance, again, for your help.
 
S
So you don't even know for a fact that the cable extends all the way to the controller? (Since you can't open the control cabinet) For all you know, someone unplugged the comms connector from the back of the unit when they were no longer using the comms functionality, or it fell off, or the wire's broken.

I suspect either that there is some wiring issue, either between your point of connection and the controller, or in your cable.

Tell your boss you can't fix stuff unless you're actually allowed to see it and touch it.
 
1) The lowest blinkie light on front panel column of status LED's appears to be a comm status LED indicator (phone handset symbol). Does it ever blink?

2) Is your 5V USB/serial converter RS-232 or RS-485? 5V sounds like 485 . . .

Is there a model number printed on it? (lot of Asian devices are not labeled at all . . .)

3) Pg 78 (F4S/D manual): Register numbers listed are relative values. To convert to absolute values, add 40001.

Have you tried 40101 as well as 40100? Addresses and registers are offset by one in Modbus.

4) I see that reference that Steve Myres makes about wiring F4 terminal #24 to PC COM port terminal

#9. But F4 terminal #24 seems to be Digital output #7 (page 12.9), and the diagrams above the table do not follow the table at the bottom of page 12.11. Isn't pin 9 in a 232 DTE DB9 typically 'ring indicator', or some such function?

http://www.watlow.com/downloads/en/manuals/f4sd_eng_g.pdf
 
H

Highland Controls

I would download Specview or Watview (same as Specview) and try communicating using either of those programs. They will run for 10 minutes in demo mode. If it still doesn't work, then you know it is a hardware issue.
 
So, apparently all the controller needed was a restart.

There's no power button for the controller, so I never thought to restart it before. Luckily I did not attempt any percussive maintenance.

All works well now, except of course that I feel like an idiot who ignored the first rule of IT.

Thanks again for all the help.
 
R
It's a while since i had to do much RS-232 work but for what it's worth.

Take your multimeter and connect one probe to pin 5. With the other probe measure voltage at pin 2 then pin 3, the one with the voltage is Tx, the other is Rx. Now do the same for the other piece of equipment. Now all you have to do is match Tx at one end to Rx at the other, simple as that.

When getting two devices to talk I start out at a low baud rate, say 1200 then once they are talking speed it up.

If you have a laptop with a serial port use a terminal emulator and connect the laptop Rx and ground in parallel with each of the Rx-Tx wires, you will see one device trying to talk to the other then by switching to the other wire you will see the response so now you tweak the parameters until all of a sudden they start chattering away.
You can even use the RS-232 laptop to monitor RS-485 traffic, just connect to the negative wire and ground.

Try it out
Roy
 
Try a B&B electronics 485 to usb or rs232 to usb

I use them all the time on F4s,

and parity should be 8 N 1
 
Top