Connecting DirectSOFT to DL06 Via a Serial Device Server

Check the Direct Cable First

Every minute spent inside the device server web page is wasted if the plain serial link was never proven on this laptop. Pull the D2-DSCBL off the converter, plug it into the PC, and build a link in the DirectSOFT Link Editor at 9600, 8, odd, 1, no flow control, K-sequence, station address 1. Those are the fixed settings of DL06 Port 1 — the baud rate is not adjustable there, so the on-wire time of every K-sequence frame is a constant you design around rather than tune.

No connect means the fault is upstream of the network and nothing downstream matters yet. If the PC has no DB-9 and the baseline test runs through a USB-serial adapter, note it: a marginal adapter adds its own latency and will confuse the later timing work. If you need more throughput than Port 1 gives, Port 2 is the configurable port — read its setup values out of the DL06 user manual before changing anything.

Find Out Which End Drives Pin 3

The D2-DSCBL is built to hang off a PC's DB-9. Its shell behaves like the DCE end: it listens on pin 3 and drives pin 2. Plug that into a device server whose DB-9 is wired the same way as a PC and both ends drive pin 2 into each other. Nothing moves, the transmit LED still flickers, and the fault survives an hour of settings changes because it looks like traffic.

Measure it instead of assuming it. Power the converter, leave the serial side unplugged, and read DC volts from pin 3 to pin 5 (signal ground), then pin 2 to pin 5.

• Pin 3 sitting at a negative idle mark (roughly -5 to -12 V), pin 2 near 0 V: the server port is wired like a PC and the D2-DSCBL plugs straight in.
• Pin 2 negative, pin 3 floating near 0 V: the server port is the opposite sex electrically. Insert a null-modem adapter, or use the server's DTE/DCE jumper or software swap if it has one.

Flow control kills the same link a different way. A device server configured for hardware flow control waits for CTS that never arrives and transmits nothing. Set flow control to none in the server, in the virtual COM driver, and in the DirectSOFT link. If the firmware refuses a none setting, jumper pin 7 to pin 8 at the server's DB-9.

Prove the Tunnel Passes Binary

Before chasing the PLC, verify the socket carries bytes end to end and returns them unaltered.

1. Jumper pin 2 to pin 3 at the device server's DB-9, serial side otherwise empty.
2. Open the mapped virtual COM port in a terminal such as PuTTY at 9600, 8, odd, 1, flow control none, local echo off.
3. Type. Characters that come back have crossed the LAN twice and passed through the server's UART.
4. Remove the jumper. Typing must now produce nothing — that confirms you were seeing the loopback and not the terminal's own echo.

Echo proves the path exists; it does not prove transparency. Two modes mangle binary traffic. Telnet option negotiation treats as IAC and will escape or consume it. ASCII or CR/LF translation rewrites and . K-sequence frames are binary and any byte value can appear inside one, so run the server in raw TCP socket mode, or run RFC2217 on both the server and the virtual COM driver — never one flavor on each side. One more habit: close the terminal before DirectSOFT opens the port. Single-socket servers refuse the second connection, and an abandoned telnet session holds the port until its idle timer expires.

Read the Bytes Before You Blame the Converter

Put a port monitor or Wireshark on the link and look at the actual exchange. A healthy start looks like the Link Editor sending 4b 21 05 and the PLC answering with short frames — 21 05, 21, 06, 04. In ASCII control terms is ACK and is EOT. The PLC received a well-formed request and replied, which retires wiring polarity, baud, parity, and byte transparency in one observation.

What remains is time. The DirectSOFT serial driver expects the response inside a fixed window, and that window is not exposed to you — the timeout fields in the Host Engineering utilities belong to the ECOM Ethernet driver, not to the serial link. Stack a device server's packing timer, TCP's Nagle delay, and a Wi-Fi or cellular round trip on top of a 9600-baud ping-pong and a three-byte exchange can take several hundred milliseconds. The driver retries, gives up, and reports no PLC while the port LEDs cheerfully blink.

Cut the Round-Trip Latency

Get it running on a clean LAN, then put the wireless or cellular leg back and re-test. Work down this list in order.

1. Wire the PC directly to the device server, static IP, same subnet. Take Wi-Fi and cellular out of the path for the first successful link.
2. Raw TCP socket mode, single connection, no Telnet negotiation — or RFC2217 on both server and driver if the vendor's virtual COM port requires it.
3. Disable Nagle (, "low latency", or "send immediately", depending on firmware). Short K-sequence frames otherwise sit in the stack waiting for a piggyback ACK.
4. Drop the packing and forwarding controls to their floor: forward on one character, or the shortest inter-character gap the firmware allows.
5. Set the virtual COM driver's latency or read timer to its minimum.
6. Flow control none at the server, the driver, and the DirectSOFT link.
7. Map the virtual port to a free low number, COM1 through COM4. Numbers like 254 or 16 are legal for the OS and still invisible to the Link Editor; add the entry to DS500.INI if DirectSOFT will not list the port.
8. Confirm the serial parameters on the server read exactly 9600, 8, odd, 1, none.

If the link comes up on the wired LAN and dies over the carrier link, the converter is doing its job and path round-trip time is the limit. Fixed driver timeouts and hundreds of milliseconds of carrier latency do not co-exist.

Verify, and Stop If It Still Drops

1. Connect from the Link Editor and confirm the PLC type and firmware read back.
2. Read the program out of the PLC and compare it against the offline project. A full upload is the sustained transfer that exposes marginal timing; a successful connect alone proves very little.
3. Write a value, read it back, verify at the PLC.
4. Power-cycle the device server and reconnect without changing anything — that proves the settings are in flash and the address did not move.

Stop here if the PLC returns well-formed bytes, the server is in raw mode with Nagle off and the gap timer at its floor, and DirectSOFT still refuses the link. That is a driver interaction, not a configuration error, and rolling settings past this point burns shift time. Capture the byte exchange and export the server's saved configuration, then take the DirectSOFT side to AutomationDirect technical support and the virtual COM driver side to the converter vendor; the production fix in the meantime is a known-good path — free an option slot for an ECOM100, or swap in a device server whose virtual COM driver is already proven against DirectLOGIC, such as the Lantronix UDS series.

FAQ