Installing the communications hardware and LayGO software is just the first step. Getting the hardware to connect to another system and transfer data is the next. Success in this step sometimes does not come on the first try. This section of the manual is designed to explain how to diagnose and resolve some common problems.
The primary tool for testing the hardware and software is the Tdrv test program. Tdrv is a GUI-based LayGO test program available for all platforms which support GUIs. Testing with Tdrv explains how the program works.
The first question which needs to be answered is:
Running Tdrv with a hardware loopback configuration tests the internal integrity of the hardware and the correctness of the installation. If Tdrv does not work in hardware loopback mode, nothing else will work either!
The LayGO distribution contains 2 configuration files necessary to run the hardware loopback test:
For instance, the Win32 version of Tdrv is WinTdrv. To run the test for board ID A under Windows, you would start WinTdrv with the following command line:
> wintdrv stacka.cfg x21loop.cfg
When WinTdrv starts, press , then . When the Flags indicator turns green and WinTdrv enters data transfer state, press . Since x21loop.cfg puts the hardware into internal loopback mode, the frame should be immediately received and displayed in the window. Press to toggle simultaneous sending and receiving on and off. (To exit WinTdrv, press to stop data transfer, then , and .)
By default, Tdrv uses Verified Transmission Mode (VTX). When VTX is enabled, sender and receiver exchange a known set of frames so that the receiver can verify that the exact frame contents transmitted by the sender were received. The loopback test is successful only when there are no VTX errors reported.
If the Tdrv test works in internal loopback mode, you can go on to Establishing a Physical Connection. Otherwise, what went wrong? Here are some common problems:
Once the hardware has passed the loopback test, it is time to try connecting to the target device. This means connecting a cable from the communication board to the target device and, using an appropriate configuration, getting Tdrv to enter data transfer state. Only when Tdrv enters data transfer state can you move on to Transferring Data.
LayGO software has been used to connect to an astonishing variety of devices, some standard, some totally non-standard. However, there are always 2 basic issues to resolve:
The physical signals generally available are:
| Signal | Direction |
|---|---|
| DTR | output |
| RTS | output |
| DSR | input |
| DCD | input |
| CTS | input |
| External Clock | output |
| Transmit Clock | input |
| Receive Clock | input |
| Transmit Data | output |
| Receive Data | input |
Where differential signaling is used (V.35, EIA-530), some or all of the signals are mapped to a pair of pins.
The LayGO hardware vendor's documentation should show the pinout of the board's physical connector and the supplied cable. The documentation for the target device should specify the details of it's physical interface. Some adjustment is often required to map the output signals of each side onto the corresponding input signals of the other. In many cases, this is merely a null-modem cable. The LayGO Hardware Guide shows some common null-modem cable layouts. In some cases, the mapping is not symmetrical. In addition, the correct cable layout may depend on which side is expected to generate the clock signal.
The LayGO X.21 bis configuration profile allows you to specify which physical signals to output, which to expect as input and whether the RTS/CTS pair, if available, should be used for hardware flow control. The LayGO Configuration Manual explains how to configure the signals.
Running Tdrv with the X.21 bis configuration profile you expect to use for your device can help diagnose connection problems. Tdrv will not enter data transfer state until all signals configured as input signals go high. If a signal stays red, Tdrv is not detecting a change in that signal. There are 2 possible explanations:
You can check whether the target device has actually raised the signal by probing the output pin with an oscilloscope or other device.
Once Tdrv enters data transfer state, you can attempt to exchange data with the target device.
Running Tdrv with the X.21 bis configuration profile you expect to use for your device can help diagnose data transfer problems. Testing with Tdrv explains how to use test data frames. You can create some frames to which the target device will respond and send them using Tdrv. Tdrv will display any responses received from the device. For instance, if the target device uses HDLC LAPB, you can create SABM and DISC test data frames which will let you use Tdrv to test whether you can bring up and take down the LAPB link.
The most frequent problem encountered in transferring data is configuring the correct clock mode. Synchronous communication requires a reference clock signal which is used to encode and decode the data bits. Most communication boards can be configured to use a number of different clock modes. Typically, one side provides the clock signal for both sides to transmit data with. If neither side provides the clock, data cannot be transmitted by either side. If both sides provide the clock, the result is totally unpredictable. If the cable does not route the clock signals correctly, either side may be able to send data but not receive it or vice versa.
There is no general rule about the correct clock mode for a particular target device. The correct clock mode is the one the device expects! The LayGO Configuration Manual explains how to configure the clock mode.
Even when everything is configured correctly, special problems may prevent successful data transfer: