We need to make a serial link between two systems. i do not have a complete data about both systems interface. I need to send to both systems manufacturer asking about thier RS232 serial link specifications, for ex. baud rate, sync/async, parity,...
Can you list all data i have to know to decide if these two systems will communicate properly or not.

 

You need to know if the baud rate, parity, data bits, start bits, stop bits are all either selectable or if they match between the two devices.

Most important of all, you need to know if the serial ports are "protocol bound" or if you can send and receive free form ASCII to make your own simple protocol.

 

Starting with the lowest level, you need to ask about voltage levels and pin-outs. If both systems really are RS-232, then that should cover the voltage levels, but the pin-outs are not specified by the standard. Going up a little bit, you need to ask about handshaking. It is hardware (RTS/CTS/DTR) or software (XON-XOFF) or neither. Then you need to ask about baud rate, parity, stop bits. If all that checks out OK, you then have to start looking at what protocols are used. Is it proprietary? Or is is TCP/SLIP? And then you still need to ask about application level protocols. What are these two "systems" supposed to talk about with each other?

 

Mahmoud, I am no expert in this field, however I noticed nobody had replied yet and I have some advice that is helpful if you are having a hard time getting info from the manufacturer. May I ask what serial devices you are hoping to interface?

Many of the devices I have been forced to interface with, are long since obsolete, with documentation and support not available through standard support channels. An example is our 20 year old Stromberg Selma drive controller. In order to upgrade it, we needed the program. In order to get the program, we needed the programming device, which had died. Few ABB Stromberg support folks have even heard of a Selma controller.

The trick I use to determine the RS232 parameters is to grab my laptop with Windows 98 on it, and fire up Hyperterminal under "Communications", "Accessories". In order for this to work, you should know at least one command to send to the device in question. Usually this would be the same command that you issue via a terminal, front panel, or programmer. Good ones are read, query, or ID commands. Obviously, bad ones are reset, stop, edit, write, or other programming commands. For example, to check my Fluke Scopemeter, you can type "ID" and it will respond with ASCII text describing the model and firmware version. If you were testing a modem, you could issue the "AT" command and it would respond with "OK".

Next you figure out the cable to use. Normally RS232 communicates DCE device (computer) to DTE (terminal, printer, modem, etc), which requires a standard RS232 cable. However, you are likely to be interfacing two DCE devices, requiring a null modem cable or adapter. Basically, the null modem adapter swaps the "send" and "receive" signals on pins 2 and 3. It doesn't matter if the plugs are 9 pin or 25 pin, male or female, RS232 requires at most 9 signals, and some times only 2 signals (pins 2 and 3). A 9 to 25 pin adapter will connect the signals to the proper pinout for you.

Now you start systematically changing the Hyperterminal connection and port configuration parameters (usually COM1, if you have no other serial devices or ports on your computer) until you get your device to talk to you. It's easiest to use local echo (found under ASCII setup) so that you can see what you're typing into the terminal, if the device doesn't echo anything back. Once you've got comm established, you might find your commands repeated, in which case you disable local echo. Many devices will not echo your commands, even when communicating properly.

Start with XON/XOFF (software flow control) since it's common. Hardware flow control requires signals on the RTS and CTS pins at a minimum, and is typical of devices using faster baud rates. So try it after you go through the list of other parameters. Choose 8 bits, no parity, one stop bit, since it seems to be pretty common. You might guess at the baud rate by the age and sophistication of the device. But if you start at a low one, say 1200 baud, be sure to keep trying higher ones until communication fails, just in case your device negotiates a baud rate to match your laptop.

About 80% of the time, I am talking to a device within 30 minutes by varying only 1) straight RS232 cable or null modem cable 2) Hdwr/Sftwr flow control 3) baud rate. Sometimes you will be able to vary partiy and stop bits on the device by the use of dip switches or jumpers.

For further help, contact me at [email protected].

 

- Pinout (DTE/DCE, 9 or 25, male or female)
- Handshaking (Hardware and/or Software or none)
- Baud, Bits per word, Parity, Stop Bits
- Protocol (e.g. Modbus ASCII, Modbus RTU, DF1) and protocol-specific addressing information

The last item, protocol, is the most significant one. Some people make careers out of developing gateway hardware or software for integrating dissimilar devices. Check out http://www.mysst.com/xlink/content.asp

Ted

 

Hi Bob,

I wonder if you can give a hand for the SELMA protocol. If you could send a list of the protocol or anything. We are in the same situation as you 13 years ago!

YOU WROTE:

> An example is our 20 year old Stromberg Selma drive controller. In order to upgrade it, we needed the
> program. In order to get the program, we needed the programming device, which had died. Few ABB
> Stromberg support folks have even heard of a Selma controller.