The serial port is only a transport; the SCADA driver and the PLC must share a protocol, usually Modbus RTU. Match the driver, copy the PLC's serial settings (typically 9600 baud, 8 data bits, no parity, one stop bit, station address 1), keep an RS-232 run inside 15 m or switch to RS-485, and read one known register before building screens. An OPC server bridges a protocol neither end shares, and DDE never replaces the PLC protocol.
A SCADA package that opens the serial port and returns nothing is waiting for a protocol the PLC never speaks. The port moves bytes between two boxes; only a shared protocol turns those bytes into register values. No cable, adapter or COM number supplies one. This page names the fault, lists what each symptom points to, sets the five serial values that must match, states how far the line can run, and works one example end to end with the arithmetic on show. It covers a PC SCADA package talking straight to a legacy controller. An HMI panel already holding the port is a different fault with its own page, linked from the symptom list below.
Why will SCADA software not read a legacy PLC over a serial port?
Because the SCADA driver and the PLC do not share a protocol. A serial port carries bytes while the protocol gives them meaning, so no cable swap, adapter or COM setting fixes a driver mismatch. The two ends must run a documented protocol both can speak.
Modbus RTU is the protocol to look for first, because legacy controllers so often offer it. The match has three legal shapes, tried in this order: a driver both ends document, an OPC server that bridges when no shared driver exists, and an application bridge such as DDE when both sides document their roles. Everything else (new cables, USB adapters, a different COM number) moves bytes; none of it teaches the SCADA package the controller's language.
Start with two facts: the PLC model and the protocols enabled in its serial port configuration, and the driver list the SCADA package actually ships with. If the controller enables Modbus RTU and the package lists a Modbus RTU master driver, the protocol question is closed. The rest of this page is settings and verification.
What do the symptoms tell you before you touch the cable?
Read the failure message before the hardware. The symptoms, and what each one points to:
- A timeout or no-reply error on every poll points at the line, the serial settings or the station address.
- CRC errors on most replies point at noise or a marginal segment.
- A port that opens but returns no values points at a wrong station address, or RTU and ASCII modes mixed.
- Replies that arrive with wrong or frozen values point at a register offset or data type.
- A line that fails only when another program runs points at a port already held by an HMI panel or another master.
| Symptom in the SCADA driver | What it points to | First check |
|---|---|---|
| Timeout or no reply on every poll | Line down, or settings and station address wrong | Wiring, then the PLC's port screen |
| CRC errors on most replies | Noise or a marginal segment | Termination, routing, baud rate |
| Port opens, reads return nothing | Wrong station address, or RTU and ASCII modes mixed | Address and mode on both ends |
| Replies arrive, values wrong or frozen | Register offset or data type | Read the register the PLC displays |
| Works until a second program starts | Port already held by an HMI panel or another master | Free the port or add arbitration |
The wrong-values row has its own page of data-type traps: HMI panel shows nonsense numbers from a PLC BCD analog register. The last row is a fault this page hands off: SCADA connection to a PLC when an HMI panel holds the port covers a panel that owns the line, and two Modbus RTU masters on one RS-485 bus: why and the fix covers the shared-segment version.
Which serial settings must match at both ends?
Match five values line by line: 9600 baud, 8 data bits, no parity, one stop bit and station address 1 are the common shipping defaults. The PLC's serial port screen is the authority, and the SCADA driver must copy whatever it shows.
Copy the controller, then the driver. The Modbus serial specification allows even parity with one stop bit and asks for two stop bits when parity is off. Most legacy controllers ship parity off with one stop bit, which runs fine as long as both ends say the same thing.
Mode matters as much. RTU frames are binary with a two-byte CRC; ASCII frames are readable hex with a different check. A controller set to ASCII will not answer an RTU master. Station numbers run from 1 to 247, and the driver's device address must equal the number set in the controller. Reads use four function codes: 01 and 02 for coils and discrete inputs, 03 and 04 for holding and input registers.
When the package's driver list has no entry for the PLC's protocol at all, the ladder a panel faces applies; Connect an HMI to a PLC with Modbus RTU when no driver fits follows it. The five-value discipline here is the one that revives a stuck panel link too: HMI panel not talking to the PLC: serial settings mismatch walks those values for a panel, unchanged for a PC package.
How long can the serial cable run to the SCADA PC?
Keep an RS-232 run inside 15 m (50 ft), the length TIA/EIA-232 specifies at full speed. Beyond that, move the line to RS-485 twisted pair, where the standard carries 1200 m (4000 ft) at 100 kbit/s and Modbus RTU poll rates sit far below that.
RS-232 connects exactly two devices, so the SCADA PC and one controller own the port. An HMI panel cannot hang on the same RS-232 line; that is the contention case from the symptom list.
For longer runs or more devices, RS-485 (TIA/EIA-485) is the serial standard built for it: shielded twisted pair, daisy-chained device to device with stubs kept short, up to 32 classic unit loads on one segment. A controller that offers only RS-232 can reach past 15 m through a pair of media converters, or the link can move to the controller's RS-485 port when one is fitted. Termination and grounding for a long RS-485 segment are worked in the example below.
When does the fix need an OPC server in the path?
Install an OPC server when the SCADA package has no driver for the PLC's serial protocol but a server's driver list names that PLC. The server speaks the PLC protocol on the serial side and serves OPC to the SCADA client on the PC side.
An OPC client only asks; some server must answer. Confirm three things from the server's documentation: its driver list names the PLC model, it speaks the protocol the controller enables (Modbus RTU on the serial side is the common case), and the SCADA package can connect as a client using the OPC flavor it documents, classic OPC or OPC UA, which is standardized as IEC 62541.
Check the bridge before the SCADA package enters. OPC servers ship a built-in test client, so browse the server and read the known register there. Only then point the package at the server. A link that answers while data stays dead is a driver-layer problem, the split covered in HMI pings the PLC but reads fail: check the protocol driver. When writing code is on the table instead of a server, the tradeoff is the one panels face too: Write a Modbus client or use an OPC server for a small HMI.
Can DDE connect the SCADA package to the PLC?
DDE is the wrong first stop. It is a Windows message path between two running applications, it defines no PLC serial protocol, and it moves data only when a third program that genuinely speaks the PLC protocol publishes tags through a documented DDE server role.
DDE carries values between two Windows programs through agreed topic and item names, and it never touches the serial wire. It can move PLC data only when the program at the controller end, say the vendor's own monitoring software, documents a DDE server role and the SCADA package documents a DDE client role. Check both documentations for those two roles by name before configuring anything.
When either side lacks the role, DDE is not the branch. The choice collapses back to a Modbus RTU driver or the OPC server. Expect DDE to be the slowest of the three paths as well, because it depends on a third program staying open and publishing on the plant PC.
What does a working example look like from wire to first read?
Scenario: a legacy controller with Modbus RTU enabled sits 60 m from the SCADA PC on RS-485 twisted pair, running 9600 baud, 8 data bits, no parity, one stop bit, station address 1, a 1000 ms response timeout and a 120 Ω terminator at each end of the segment.
Timing first. The Modbus serial specification ends every frame with 3.5 character times of silence. At the specification's own framing, with parity on, a character is 11 bits, so 3.5 × 11 / 9600 = 4.0 ms of quiet, the number most handbooks print. This line runs one stop bit, a 10-bit character, so the real gap is 3.5 × 10 / 9600 = 3.6 ms. Polls are spaced at 250 ms, just over 60 times the gap, so the driver never slices a frame apart.
Wire time next. A one-register poll is an 8-byte request and a 7-byte reply, 15 bytes in all, and each RTU frame closes with a two-byte CRC the driver checks. At 10 bits a byte, that is 150 / 9600 = 15.6 ms on the wire. The 1000 ms response timeout holds roughly a 60-fold margin and absorbs a retry without pressure.
Now the first read: function code 03, one register, at reference 40001. The RTU convention maps references to protocol addresses by subtraction: 40001 - 40001 = 0, so the point asks for address 0; a tag at 40101 would be 40101 - 40001 = 100. The controller's keypad shows 137 in that register. The poll goes out, the reply passes the CRC check, and the SCADA tag reads 137, refreshing on every 250 ms poll. That closes the loop: settings, station address, register map and line all check out together, so build the screens on this register map. A different number means an offset or data-type problem. No reply means work the symptom list from the top.
How do you verify one live value before building the displays?
Read a holding register the PLC itself displays, poll it with function code 03, and accept the configuration only when the SCADA tag equals the controller's number and keeps step with every poll.
Checks, in order: watch the package's exchange counter across 10 polls, where a counter that advances beside stable values is a working line and a frozen counter is a line that stopped. Test a write only when the application is designed to write that point and the machine state makes the move safe, on a register chosen for the test, because a trial write at a wrong address can move real outputs on a live line.
Then record the configuration: driver name, port and COM number, the five serial values, station address, timeout, poll interval, register map and the known test value. The next fault now has a baseline: a timeout means the line moved, a wrong number means the map moved.
Recommendation: If the PLC enables Modbus RTU, match a documented Modbus RTU master driver, copy the five serial values from the controller's port screen, keep an RS-232 run inside its limit or move the link to RS-485 twisted pair, and hold off building screens until the known register reads correctly. If the SCADA package has no driver for the controller's protocol, put an OPC server whose driver list names that PLC in the path and verify it with the server's own test client. If both ends document DDE and a program already speaks the protocol, a DDE bridge can carry tags, treated as temporary. If the controller also offers Modbus TCP on Ethernet, test that service as the cleaner replacement for the serial line. The protocol match, never the cable, is the fix in every branch.
Questions
What port does Modbus TCP use if I move the link to Ethernet?
Modbus TCP listens on TCP port 502, the number assigned to the protocol, so the connection needs the controller's IP address, port 502 open on any firewall in the path, and the Modbus TCP service enabled in the controller. A ping reply tells you the network path works, nothing about the service, so finish with the trial read used on serial: one known register, compared against the controller's own display. Register numbering carries over unchanged between RTU and TCP.
Does station address 0 work on a single-slave line?
Never for reads. Modbus RTU reserves address 0 for broadcast, and a broadcast is a write instruction: slaves act on it but send no reply, so a master polling address 0 waits through its timeout and reports no response. Give the controller a station number from 1 to 247, start at 1, and set the same number in the driver's device address.
Why does a line with correct settings still show CRC errors?
CRC errors on a line whose settings match are noise or reflections. Terminate the two physical ends of the segment with 120 Ω resistors, keep every drop short, ground the cable shield at one point only, and route the pair away from motor and drive cables. If errors persist on a long run, lower the baud rate: going from 9600 to 4800 baud doubles the time available per bit and calms a marginal segment.
What should be recorded once the line works?
Protocol and driver name, port or adapter with its COM number, the five serial values, station address, response timeout, poll interval, and the register map with one known test value. If a temporary adapter or gateway made the trial work, mark it temporary in the record; the permanent configuration names the PLC model and the link the plant keeps.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.