Data sniffing from a RS232/485 network

[Signode]

Hi;

Though my topic is related with communication but may someone could help me out.
We have a cutting creasing machine having 20 tools. Each tool has a separate servo motor and servo motor is connected with a servo drive. The control system is based on a DOS based PC which controls all the operations of machine. The DOS PC sends/receives parameter values to servo drives in HEX form. The structure of communication from DOS PC to servo drives which is also mentioned in below images. I want to sniff the data following from MS DOS control system to drives during a sequence of operation. We can not break the comm link of DOS and servo as system immediately goes into fault. Please help.

MS DOS Slave PC RS232 port >>>> RS232/485 Converter >>>> To all Servo Drives.

 

[CDRIVE]

When you say "Data Sniffing" are we to assume a second PC that's reading the data somewhere along the line?

I would highly recommend reading "Serial Port Complete (2nd edition) by Jan Axelson. She's an iconic figure on all topics of PC and uC data communication.
http://www.lvr.com/spc.htm

Chris

 

[brevor]

Jan Axelson. She's an iconic figure on all topics of PC and uC data communication.

She's Hot

 

[CDRIVE]

She's Hot

Uh, she's a few years younger than me.
https://www.google.com/search?q=jan...&ei=FJaJUtbbBs6gkQeMhYDoDw&sqi=2&ved=0CEEQsAQ

Her brain is a real turn on though! I think it's safe to say that female electronheads are as rare as hen's teeth. Back when I was reading her books (I have three) I had no idea she was female. Jan could also be a male name and I was convinced that what I was reading could not be written by a female. ..Yes, I'm obviously a Neanderthal sexist pig!

Chris

 

[Solidus]

Are you merely looking for a method to receive the data on another machine for sniffing? Hopefully this one, because it is easier than trying do that AND interpret the data - without the structure or format of the commands, we can't advise much more than that.

The simplest way to sniff the connection on a PC would be to wire/solder a jumper cable - that is, a 1-2" inert cable that is a male-to-female connection, but with a second leg that goes to a PC (think a 'T' junction).

If your PC doesn't have a standard DB-9 RS232 serial connection, you can use a FTDI chipset to transform that into the USB protocol for receiving. I stand to think that would work, although I'm wondering whether during initialization that chip would attempt to transmit a packet header, which would send the entire system to hell in a handbasket fast.

Basically, without breaking down the protocol too much, the packet header is what is sent during startup. It consists of 96 (if I remember correctly) pulses across the TX line (from host to device, should my memory be good) to synchronize clocks, as RS232 doesn't provide a clock transmission line (that's where the term asynchronous serial comes in). If either end of the system receives it, especially if it's been connected prior to, it may jimmy things up - essentially it will read the 01010101 of the sniff line as nonsense commands. I may have to do some thinking on this.

You could use a cheap microcontroller to sniff the line and do reporting as to what occurs. If it is installed fairly permanently, that one-time setup transmission may not be an issue.

Assuming this all works out, all you would need is something to read the serial input on the PC side and log the data. I could write you something in Java or C# that would read the serial line and print it to the screen if you'd like.

 

[KrisBlueNZ]

If your DOS machine has a 25-pin serial port, it transmits data on pin 2, and pin 7 is ground.

If you have a second machine with a serial port, and you just want to capture the transmitted data from the DOS machine, you can link the grounds together and feed the data from pin 2 of the DOS machine's connector to the received data pin on the second machine.

If the second machine has a 25-pin serial connector, it receives on pin 3 (and pin 7 is ground). If it's a 9-pin serieal connector, it receives on pin 2 and pin 5 is ground.

If you want to monitor the received data from the servo units as well, your simplest option might be to monitor the data at the RS-485 level, where both directions are visible, using an RS-485-to-RS-232 converter. You can use the RTS (request to send) output from the PC to determine data direction; when RTS is active, data is flowing to the servos, and vice versa.

If you want to reproduce the data, so you can retire the PC, you will also need to capture the timing. You may find it better to hire a protocol analyser for that, rather than writing a program to receive and timestamp data, although there may already be something written for MS-DOS that does that - try an MS-DOS archive such as Simtel.

Please let us know how you get on.

 

[Solidus]

If your DOS machine has a 25-pin serial port, it transmits data on pin 2, and pin 7 is ground.

If you have a second machine with a serial port, and you just want to capture the transmitted data from the DOS machine, you can link the grounds together and feed the data from pin 2 of the DOS machine's connector to the received data pin on the second machine.

If the second machine has a 25-pin serial connector, it receives on pin 3 (and pin 7 is ground). If it's a 9-pin serieal connector, it receives on pin 2 and pin 5 is ground.

If you want to monitor the received data from the servo units as well, your simplest option might be to monitor the data at the RS-485 level, where both directions are visible, using an RS-485-to-RS-232 converter. You can use the RTS (request to send) output from the PC to determine data direction; when RTS is active, data is flowing to the servos, and vice versa.

If you want to reproduce the data, so you can retire the PC, you will also need to capture the timing. You may find it better to hire a protocol analyser for that, rather than writing a program to receive and timestamp data, although there may already be something written for MS-DOS that does that - try an MS-DOS archive such as Simtel.

Please let us know how you get on.

Just a tidbit in addition to what you said - usually, machines of this era (DOS/3.x/etc.) had really colorful user documentation (actual paper, yay!) that would contain information like the baud rate of the communication. The user manual for my father's Texas Instruments Travelmate laptop of this time even had a glossary with information about the serial and parallel protocols and their usage in custom programming.

It's worth a try, and even if not, it may be easily determinable from user settings. I think the OP might find that preferable to installing executables or performing protocol analysis.

 

[CDRIVE]

I'm going to go out on a limb here by stating that I don't think Jan would ever advocate simply tapping into data lines without proper buffering / impedance matching. That cable should be treated as a transmission line. As with any transmission line,.. we simply don't "T" or "Y" them.

Chris

 

[Solidus]

I'm going to go out on a limb here by stating that I don't think Jan would ever advocate simply tapping into data lines without proper buffering / impedance matching. That cable should be treated as a transmission line. As with any transmission line,.. we simply don't "T" or "Y" them.

Chris

This is true (and I'm not disagreeing with you), but as a 'proof-of-concept', it holds. Transmission line matching and buffer elements are facets of how to ensure positive results; but they are, I believe for the purpose of the post in question, exactly that - facets. You can't hone a gem or get to the faceting if you don't know how to cut it from the raw first.

I made that post trying to illustrate the basic mechanics of how to carry out the sniffing, making it fairly irrespective of the higher notions that would go into it. (Admittedly, I shied from this when I started going into protocol specifics :/)

For the sake of clarity, I was intending to use a short length of PCB that would have all necessary parts and traces properly laid out. I certainly wasn't meaning cut into a shielded cable and T-off the individual wires

At any rate, I didn't know what the OP's experience with this sort of analysis is, so I generalized. In a pinch, I'll say that at 9,600bd. (a legacy rate), transmissions are slow enough in terms of frequency to where T-line theory can (strong emphasis on somewhat) be disregarded in lieu of simplicity. Not that it's the right way to do it or that there isn't the possibility of unexpected consequences, but if nothing else, a short 1" span of FR-4 doubling to a USB bridge probably wouldn't interfere with things too much.

Eli

 

[CDRIVE]

Assuming the OP has zero electronics aptitude and also considering that he is not in a home shop environment, I think he should be looking at a plug and play solution. It's a more practical solution for an industrial scenario.

http://www.fte.com/products/SerialAnalyzers.aspx

Chris

 

[CDRIVE]

For a much cheaper alternative have a read through this article. It also contains a link to a free port monitor program that you would install on the sniffer PC.
http://www.compuphase.com/electronics/rs232split.htm

Some FYI:

(1) The fact that your system is DOS based is irrelevant to the sniffer PC. The sniffer can be any PC with or without serial ports. This is because USB/RS232 converter dongles work seamlessly, or at least appear so, to the user.

(2) Over the years I've made comparative tests between hardware serial ports and virtual (USB/RS232) ports. These tests were performed using VB6.0 / MSComm32.ocx. The only difference that I've noted was returns from the InBufferCount and OutBufferCount. A virtual serial port does not contain a UART where these buffers reside. Because of this Windows creates the needed buffers using system RAM. That said I think that this is also irrelevant to your application.

(3) PortMon.exe is another sniffer app that I have. It's free for download.

Chris

 

[MikeG]

I know this is an old thread but I'd check out the versa tap from stratus engineering. I've used the one from the FTE site mentioned above, but the versa tap is cheaper. Hopefully that helps someone. Sorry for being 3 years late. Haha

 

[CDRIVE]

Hello Mike and welcome to Electronics Point. The friendliest tech forum on the planet. Mike the price on that dongle gave me heart palpitations!

If there's a Chinese clone on fleabay (probably is) it will have the $ decimal point moved two decimal places to the left.

Chris

BTW: The OP of this thread is AWOL!

 

[MikeG]

Hi Chris, thanks for the welcome. Much appreciated. I'm just skeptical of using the Chinese products as they have produced problems in the past. Sounds like that has not been the case for you?

And yeah, the OP is no where to be found haha. Granted, this thread is pretty old. And I'm just getting into more forum discussions.

 

[CDRIVE]

Mike, the reality is that regardless of where you buy things,.. U.S., China, etc, damn near everything is manufactured in China and they're getting better at it and QC every minute of every day. Very few of the big solid state manufacturers actually make their products in the U.S. or native country any longer. I buy heaps of stuff on China's Ebay or Ebay's China clients; however you want to look at it.

Recently I purchased 100 2N2222 transistors and was amazed how closely matched their HFE's are. They're getting much better at manufacturing quality machinery too!

Chris