SComm32 Communications OCX



. Break
. CDHolding
. Commevent
. CommName
. CommPort
. CTSHolding
. DSRHolding
. DTREnable
. EOFChar
. EOFEnable
. EvtChar
. EvtCharEnable
. Handshaking
. InBufferCount
. InBufferSize
. Input
. InputLen
. InputMode
. NullDiscard
. OutBufferCount
. OutBufferSize
. Output
. OverlappedIO
. ParityReplace
. PortOpen
. Read
. RThreshold
. RTSEnable
. Settings
. SThreshold

OnComm Event
Hardware/Cables etc
Loopback Test Plug

RS232 TestPlug (Loopback)

An RS232 test plug simply loops back all the signal lines so that any output can be seen on the corresponding input. For example the transmit pin is connected to the receive pin (Pins 2 and 3 linked together) so that any transmitted data is immediately received. The same goes for the control lines. RTS and CTS are linked together - Any test application would set the RTS line on or off and that should instantly change the state of the CTSHolding property.


9pin Test Plug

25pin Test Plug

In the above diagrams you'll see that we've connected the CD pin to DTR.

It is common to connect DTR and DSR together - DTR is an output and DSR is the opposite Input - They are a signal pair just like TxD-to-RxD and RTS-to-CTS.

But CD (DCD) is a modem signal. It's rarely used when connecting two computers or other end devices so you might never need to use the CD pin. But, in order for us to test the CD input we've connected it to DTR. This means that if your test application toggles DTR you will see both DSR and CD change state at the same time.

In the diagrams you'll also see a dotted line to RI. Again, this is a modem signal (Ring Indicator) in fact it's hardly ever used on modems either. So, unless your application involves modems and you know that you are going to use the RI signal you may as well not bother making/testing that connection. It's not a very reliable signal anyway - MS Windows can usually detect the RI transition to ON but then can't detect it going off again so it's not much use for anything.

Making a Test Application

Depending on your version of SComm32 you may find that we've added a test application as one of our samples. But if you intend making your own test application we'd like to give you a couple of tips..... Well, maybe just one tip. From a computer point of view RS232 is slow. Very slow. If you connect your test plug and transmit some data and then instantly read the input buffer to see your data you're not going to see anything. Your application executes the transmit and receive functions so quickly that you'd be reading the input buffer long before the data even reached the com port. So, in the case of a loopback test, Send your data and then wait a moment - only a fraction of a second - before reading the input buffer. Or, better still, use the OnComm event.