What's wrong with this RS232 connection?

Factual Questions
1

This is one of the most maddening debugging problems I can remember.

I had my laptop talking to a motor controller over a RS232 serial connection to COM1, in a program I wrote. Then I unplugged and moved everything to a different location. Now there doesn’t seem to be any communication at all.

Everything was 9600,8,N,1 which is the default for the motor controller.

Neither my own program or a serial communications program seems to do anything with the motor control.

The serial communications program still works normally with a precision thermometer that also communicates with those settings. I can have it send data, and they scroll by on the laptop screen.

I have alternates for the motor controller and removed one from service to try it here, but there is still nothing.

The serial cable still tests good with an ohmmeter.

If I put an AC voltmeter between pins 2 (Rx) and 5 (ground) on the PC end of the cable, I see a few volts AC when the motor controller is supposed to be transmitting, and I see about the same thing when I do this to the cable from the precision thermometer. So, while pins 2 and 5 seem to have similar signals as seen by a voltmeter, the terminal program does not register if the source is the motor controller.

I have tried wiggling each component I can think of while data should be flowing from the motor controller to the laptop, but don’t see anything.

I just verified the settings of 9600,8,N,1 for probably the 8th time on the terminal software, the thermometer, and both the motor drives I have available.

There’s no gibberish, no lights showing RX or TX changing state, nothing.

I don’t have any serial diagnostic equipment but am going to go try to find an oscilloscope…

2

Let me know when you have the 'scope. One of the fun things I get to do at work is troubleshoot recalitrant RS-232 connections for the modbus communications the equpiment we manufacture uses. Also, are you positive the motor controller’s baud rate is 9600? Some of our equipment uses 1200 while others use 9600, and if you confuse the two, the symptoms are largely as you describe.

ETA: Also, is it two-wire or four-wire RS-232?

3

Have the scope and am making up connections into the cable.

Positive the motor controller is 9600. I have looked it up in several different pieces of software that talk to it. And I have used two. Besides, don’t you usually see gibberish instead of nothing, when the baud rate is wrong?

Moreover, I am using RealTerm on the laptop, and it has “lights” (little colored squares" that track the state of Rx, Tx and the handshaking lines. None of them are lighting up with the motor controller.

4

The scope shows a signal going from the PC to the motor drive, but nothing going from the drive to the PC. Now, I can’t reproduce the AC voltage measurement of several volts for a few seconds, which would have been the timeframe for the motor drive automatic initialization to be reporting its brand and model number over the serial link. Whether the scope is connected or not, the multimeter shows no AC voltage, or nothing over a few mV.

The motor drive has a fault detection activated by no motor connection, but that should not effect the initialization string output, and I am trying it both ways with 2 different units of the same motor drive model.

I went back and forth between the thermometer and each motor drive before, and saw voltages for the first few seconds on both drives, and now I don’t.

Still trying things.

5

I’d check the cable and make sure that both ends see the proper handshaking signals (DSR, CTS). For future use, get one of those little RS-232 breakout boxes that has LEDs, jumpers, test points, and DIP switches. It can save you a lot of time.

6

I wonder whether there’s a loading coil or some such inductance on one of the wires of the new serial line? Does the serial line run alongside telco phone lines?

7

There’s no handshaking, only Tx, Rx and GND.

I have tried pulling the connector off the motor drive and shorting the Tx and Rx pins together. Then, when I send anything from the PC, I see it as a reply. There is a convenient behavior in the motor drive: whatever you send it is by default echoed back to you, but letters are converted to uppercase. I have been using these drives for many months now and they always do this, but now neither of them return anything at all.

The oscilloscope is flatlined looking at the drive’s Tx to GND, and Rx to GND, when I cycle power on the drive (it should send its init string during a power on sequence, out the Tx line).

Looking at Rx to GND on the motor drive while I send things from my terminal program, I see a waveform that has a very different duty cycle when I send an ASCII 00x versus a FFx. This is as expected.

I’ve been trying troubleshooting procedures out of the motor drive manual, like enabling the port explicitly, and forcing it to echo everything. But these things weren’t necessary before, and don’t fix anything now, and are obscure commands it would have been some trouble to look up and change. I’m the only one working on these.

And it’s TWO DRIVES. One was working fine this morning. The other was working fine on Sunday, the last time I tried it. Both of them light up their Power LEDs. Both of them show their Motor Fault LEDs if I unplug the motor.

8

The cable may only have three wires, but there may be jumpers on the connectors.

Do the serial I/O ports, at either end, have any jumpers or DIP switches that are used to configure the port? Are there any internal ribbon cables that might be loose or improperly installed?

9

I don’t know how to fix your problem but I would suggest you try asking at PLCS.net. Even though this isn’t a PLC problem there’s enough expertise there with this type of issue that I’m sure there’ll be some helpful replies. They’ll want to know specifically what type of drives, etc. Best o’ luck.

10

Tough one. Since the computers COM port clearly works, and you have this issue with two drives, I wold look at the things the setups have in common, particularly the cable connecting the PC to the drive. Are any pins bent or missing? Have you tried swapping out the comm cable?

11

Is the serial port hardwired to the laptop or do you use a USB-to-serial converter?

12

Does the motor drive have a separate (ideally socketed) UART IC?

Do you have a USB serial port to try? Some devices are more sensitive than others to non-compliant RS232 signals.

13

What jnglmassiv said. Any chance you have a schematic or can determine what’s driving (or supposed to be driving) the connection at the motor drive end? And then what’s driving that? If it’s proper RS-232 levels I’d expect a chip there.

It sounds like something that happened has either reset it or locked it up in some strange way. Or (and with what you’ve said this seems more likely) damaged the transceiver.

Have you checked the start-up string on both of the motor drives that don’t work? Are you testing that with or without the cable attached? I’d start there, since it should be possible to test that without any PC involved.

14

The hardware is a three-wire RS232 connection without any of the pins connected except 2, 3 and 5, and I am now using two different cables that I made, both of which worked either Sunday afternoon or Monday morning.

On the motor drive end, the cable is wired into a terminal block that plugs over recessed pins. With the terminal block unplugged, I have tied the Rx and Tx pins together with a short piece of wire sticking into the Rx and Tx pins of the terminal block. That is, mechanically, the jumper itself actually looks like the drive’s Rx and Tx pins, except that it is one piece of metal. With this setup, any text I send with my terminal program comes right back. I think this confirms the cable is good.

I can also get clips onto the recessed pins on the motor, where the terminal block normally goes. When I do this with a DMM and cycle power, I should see a few seconds of voltage, as the drive transmits its wakeup string. One weird thing is that I am sure I was seeing this earlier in this debugging process. But, now, when I do this, I see no voltage. When I do this with an oscilloscope, I also see no signal. Like I said earlier I can see my laptop transmit signal when I send text strings to the DMM or to the oscilloscope.

There is an obscure feature of these motor drives, that they can attempt to run a program at power-up, and that this can override their transmission. I found out you can turn this off by sending a “!K” string to kill any running program. I tried this to no avail - and I’ve never used this feature.

And the damnedest thing is that when I lost the ability to communicate with the one drive, I pulled another out of service, and it was now magically working the same way. It seems logically impossible, and it seems as though there must be something else in common. But, actually clipping a DMM onto the recessed pins and cycling power is about as basic as you can get; I still can’t imagine any way to simultaneously change multiple unconnected drives to change this behavior.

I’m pretty stumped!

15

OK, what’s in common:

Not the drives; there are two, and both worked recently.

Not the cables; there are two, plus treatments of the terminal block and the pins under it directly (without cable).

Not the device talking to the drives; there’s my laptop, and a DMM, and an oscilloscope. The laptop can talk to a precision thermometer with the same settings. The DMM and the oscilloscope can both see the laptop signal.
Bad chips:
It is possible, I guess, that UARTS in both drives simultaneously died, even though one wasn’t powered up between the last good use and the beginning of this test.

Weak signals:
How can the signal be too weak to see with the DMM or the oscilloscope? Especially, when it worked fine Sunday or yesterday morning?

Sorry to be shooting down various ideas, and I guess there is always something to test, but it still looks like there’s a missing piece I’m supposed to be noticing here…

16

It’s really supposed to be RS-422? :stuck_out_tongue:

Seriously, that sounds like a stumper.

Question: you stated earlier that you pulled a motor controller “from service” in your diagnostic quest, yes?

Have you tried putting that one “back in service” to see if it’s still working properly?
Not-So-Amusing-Anecdote: Our IT dept. frequently downloads OS patches to our laptops that we use “in the field.” One such recent patch blocks serial, TCP/IP, FTP (heck, just about everything!) when we run on battery, but otherwise doesn’t give any indication that anything is wrong.

There were dozens of field techs like me nationwide pulling their hair out of their heads the day after that patch hit, I can tell you.

17

>It’s really supposed to be RS-422?

Thank God!!! Some of us are still having fun! Where would we be without that?
>Seriously, that sounds like a stumper.

Oooofah. Yes, I’m sitting at my desk with wires and bits of insulation all over the place, and easily 50 lbs of instruments and test devices forming a crusty circle around me, with a worn spot in the middle.

I am using a development system and a target system. The target system went down because of an unsuccessful software update, and yesterday they rolled that back, so now the target system works again. The development system, where I have been having these problems, is now idle. I don’t know if this rot is going to magically spread 1/8 mile through twisting corridors and security gates to the target system, but a couple minutes ago its PC and motor drive were chatting like long lost soulmates, and I could probably keep a cup of coffee warm if I could rest it on those UARTS.

So, I am cleaning up the crusty circle, and nervously going back and watching the target system, and hoping that I can proceed on it and it alone, and if that works I don’t think I’m going to chase the development system problem for now. If it stops working, I’ll post again. Though, maybe in the Pit, I dunno.

>Have you tried putting that one “back in service” to see if it’s still working properly?

No. This would be very interesting. I am actually afraid to, though, the way we once were when the gods became angry. This project has gone way, way beyond the realm of reason.
>field techs like me nationwide pulling their hair out of their heads

Wow - something to feel good about on my end, then - I am working in our own shop with no outsiders in range. That must have been misery squared.