|
Connecting to a PC's RS232 (com) port can be a tricky business. Hopefully the following explanations will iron out a few mistakes and have you communicating smoothly. Before we start a brief explanation of the standard used pins. 9 pin 25 pin name description 3 2 Tx Transmit Data 2 3 Rx Receive Data 7 4 RTS Request To Send 8 5 CTS Clear To Send 6 6 DSR Data Set Ready 5 7 GND Signal Ground 1 8 DCD Data Carrier Detect 4 20 DTR Data Terminal Ready 9 22 RI Ring Indicator Transmit Data, the pin from which data is sent to the device connected to the port. Receive Data, the pin in to which data is sent from the device connected to the port. Request To Send, the pin on which the port requests that it wishes to transmit data to the device connected to the port. Clear To Send, the pin on which the device connected to the port grants permission to the port to transmit it's data. Data Set Ready, the pin on which the device connected to the port states it has data for the port. Data Terminal Ready, the pin on which the port states it is ready to receive data from the device connected to the port. Data Carrier Detect, this pin is used only by modems stating the modem link is ready to transfer data (and should be held at 'on' if not used). Signal Ground, this pin is probably the most important. It is the pin to which all signals are referenced as well as carrying the return current of any signal. A full description of each pin can be found at this web page. Now I am going to be a little blunt here and if I step on toes, move them! If the software does not use the pins as described above the software has been badly written and you are at the mercy of the supplier of it. Hopefully they have included a description of what each pin does in their manuals, just to make your life a little less hell.
IBM (in their wisdom) decided that the standard 25-pin port was too large as well as most of the pins were not used. This is fair comment, as will be shown below. However,..... There was already a 9-pin standard being adopted by industry using exactly the same pin numbers as a 25-pin with the only exception being pin 9 now did the function of pin 20. It had a fairly logical layout being frame ground, tx, rx, transmit control pins, receive control pins, ground, and carrier detect (i.e. link ok). IBM wanted to be different (so what else is new!?) and created a totally illogical layout of pins. They've bunched the tx and transmit control pins in the middle (pin 3, 7, & 8 form a triangle). Rx, carrier detect and DSR are bunched (1, 3, & 6 form another triangle) with DTR (which is truly a receive control pin) found at the opposite end (pin 4). The actual signals are exactly the same between all the styles.
Some devices (and there are a lot) do not use all the control signals but "jumper" or link the pins such that the PC port is 'fooled' into thinking all the required signals are present and correct. There are, however, other devices that do not even link the pins and it is up to the interconnecting cable to do this.
Further to this there are some devices that do no use connectors but screw terminals that require that the installer use a cable with the required connector between the PC and the device. Often such connections use the bare minimum of Tx, Rx and Gnd.
To make matters even worse there are two 'standards' (meaning there is actually no standard) of how pins or connection points are named. If everyone used the descriptions as detailed above then life would be simple but, alas, this is not so. Some designers tell you the pin's use or function but others decide they should inform you what pin of the PC port should be connected to a point thus Tx could mean it is the device's Transmit Data (the proper way), or, that the PC's transmit data should be connected to that point meaning it is actually the device's Rx or Receive Data (ugh! as you can gather, not the proper way). To add insult to injury, they never appear to tell you which 'standard' they have adopted. With this confusion reigning it is now up to the installer to determine, before constructing a cable, which 'standard' is adopted. The primary method is to determine if the Tx pin is actually the Transmit Data or Receive Data, this being done through either voltage or impedance.
When no voltage is found it is either that the port is specially controlled i.e. voltage only appears when the port is required, or, the port does not conform to the CCITT specification and is relying on using 0 and 5 volts as 'off' and 'on' voltages respectively. This is often done on devices that are run from batteries and where the designer is trying to save power by using a typical logic output (usually CMOS) to drive a RS232 port. Using a Digital Multi Meter set to 2kΩ (2000 ohms) measure the 'resistance' of the pin marked as the Tx pin. Do this with the device on and also in both polarities of the meter i.e. first with the black (-) probe to Ground and the the Red (+) to Ground. Make a note of these readings. Now turn the device off. Measure the pin again also doing this in both polarities. There should be a marked difference in the readings and if this is the device's Transmit Data pin the 'resistances' should rise with the device off. Do this same test in the Receive Data pin except the meter should now be set to the lowest resistance range where a reading appears, this being on average the 20k or 200k range. The 'resistance', if it is the Rx pin, should drop when the device is off. The reasons for these strange behaviours is the Tx pin, being an output, will have a low impedance when the device is on (as the output transistors are conducting) but a higher impedance when the device is off (there is no current to make the output transistors conduct). The opposite is true for the input, as the power is removed the input has no voltage on it's input circuitry resulting in an apparent 'reduction' of the input impedance (often seen by the protection diodes of the input conducting in this state). Hopefully this has helped in trying to suss out what pin is meant to do what.
However, there is one thing that needs to be considered in the hot-swap. It will rest on the application of the hardware. Although no physical damage will occur when the hardware is disconnected, the applications running on each piece of hardware may suffer "damage" (i.e. crash). An example is a process control system which would come to a grinding halt if the connection between the controller PC and the main PLC interface is broken. A similar issue could result from a modem being disconnected from a PC and then reconnected - the PC may think there is a new modem and cause another one to be installed. I have seen this happen! In short; You are perfectly allowed to disconnect and reconnect RS232 ports at will with no damage to hardware. The only 'danger' of this action may be to break a process that relies on this connection being available at all times. As more questions come forward this paper will expand. Connecting to remote sites using modems (including radio modems) is covered in another paper.
© 03.10.00 / 26.05.03 |
Using
