If the panel's driver list has no entry for your exact PLC, the nearest family name will not communicate: a driver speaks one protocol and a different family speaks a different one. The fix is a documented driver or a protocol gateway, five matching serial settings, the wiring diagram both manuals print, and one known value updating before any tag changes.
Your panel's driver list has no entry for your PLC, so you picked the closest family name, and now the screen shows an error on every read. That error is the expected result. A driver speaks one protocol, and a different PLC family speaks a different one, so no serial setting and no cable repair turns one protocol into another. The working path is short: identify the exact CPU family, find a driver documented for it or add a protocol gateway, match the serial settings both manuals print, check the three conductors the link needs, and read one known value before you touch a single tag. This article walks through the failure, the checks in order and the decision at each step.
Why the nearest family name cannot work
A driver is a translator for exactly one protocol. It writes every read as a request frame in that protocol's format, sends it, and waits for a reply in the same format. Your PLC's serial port answers only in its own protocol. When the two differ, the port never returns a frame the panel can parse, so the panel reports a failed read on every object on every screen.
A shared maker tells you nothing about the frame format. Frame layout, addressing and timing all define a protocol, and two families from one maker can differ in all three. The point count on the CPU label sizes the inputs and outputs; a 23-point label names no protocol. That is why the driver list is the first document you open, not the last. Panel makers publish which protocols each driver speaks, and your panel's documentation carries that list. If your CPU family is absent from the list, a direct serial link is not available on that panel, and the choices that work are a protocol gateway or a panel whose list names your CPU.
Order matters as much as content: check the panel driver list before tuning serial settings, because settings can only be matched once both ends name the same protocol.
What the error points to
Where the error appears tells you which layer to work. Sort the symptoms by scope:
- An error on every screen and every value. The link itself: the driver, the protocol, the settings or the cable. Start at the driver list; nothing downstream matters until a documented protocol pair exists.
- An error on one value only. That tag: its address, its data type or the driver's address rules. The link is up, so compare the one failing tag against the manual.
- An error that appeared after a change. The change: a new baud rate, a new cable, a new driver selection. Put the previous value back and change one item at a time, recording the result each time.
- A value sitting at 0x0000 alongside the error. The panel's report of a failed read. Wire nothing to that object and build no logic on it until the same register updates on its own.
The scope rule keeps the work short. When every read fails, tag edits are wasted effort until the link carries one known value; when one tag alone fails, the link is already working and the tag is the suspect.
Match the serial settings on both ends
Once the driver names your CPU's protocol, five items must match across the link: the protocol, the baud rate, the data bits, the parity and the stop bits, plus the station or unit address when the protocol uses one. The driver's manual prints what the panel sends. Many industrial serial ports default to 9600 baud with 8 data bits, no parity and 1 stop bit, but defaults differ between families, so copy the values from the two manuals rather than assuming either side's default. The PLC side sits in the PLC programming software, which shows what the port receives; where a port has been set to the wrong protocol entirely, the repair lives in the PLC's setup and program, as in this documented fix for a PLC serial port that will not communicate.
The two failure modes have different signatures, and telling them apart saves hours. A serial settings mismatch shows up as both ends speaking the same protocol with different numbers, so reads come back wrong or drop out. A protocol mismatch shows up as no valid reply ever arriving, with the error on every read. If you see the second signature, the baud rate is the wrong lever; the protocol has to match first.
Check the cable against both wiring diagrams
An RJ45 plug gives you 8 positions, and an RS-232 serial link needs 3 of them: transmit, receive and signal common. Which pin carries which signal is printed in each device's manual, and the two manuals can assign pins differently, which is why an RJ45-to-RS232 cable built for one device pair can be wrong for another. With power off, beep the three conductors end to end against the wiring diagram in both manuals. The fit of the plug tells you the mechanical shape; the diagrams tell you the signals. If any conductor is wrong, fit a cable documented for your exact device pair, and change nothing else until you retest. Keep the run short while you commission: an RS-232 link is normally reliable to about 15 m at 9600 baud, and long unshielded runs pick up noise before they fail outright.
Example: a 23-point VersaMax CPU, the 90-30 driver, and PLC-499 with code 0x0000
Inputs. The CPU is a VersaMax unit, labeled by point count: 23 points, which sizes the inputs and outputs and names no protocol (CPU label). The panel software's driver list carries the 90-30 family and has no VersaMax entry (driver list in the panel programming software). The project selected the 90-30 driver as the nearest name (project configuration). The cable in hand is RJ45-to-RS232 from the panel to the CPU's RJ45 serial port, about 2 m long (bench setup). The screen reports PLC-499 error code 0x0000 returned from PLC on reads (panel display).
The rule in words. A read succeeds only when four checks pass: 1, the driver's protocol names the CPU's protocol; 2, the five serial items match; 3, the three conductors beep through end to end; 4, one known value updates on the panel. A substitute driver fails check 1, and checks 2 to 4 cannot repair a protocol mismatch.
The arithmetic. Driver-list entries matching the exact CPU family: 0. Protocol pairs formed by the 90-30 driver against the VersaMax port: 1 required, 0 present. Serial items with a documented value on both ends: 0 of 5, because the driver names the wrong protocol first and no matching pair of manuals exists to copy values from. Valid replies per read: 0, so the panel reports PLC-499 with code 0x0000 on every read. Known values updating with the substitute in place: 0, against the pass threshold of 1.
The result. The link fails at check 1 of 4. With 0 protocol matches and 0 of 5 settings items documentable, every tuning effort starts from 0 and cannot reach the threshold of 1 updating value. At a typical 9600 baud poll cycle of 1 second per read, that is 86,400 failed reads across a 24-hour run, and not one of them carries data.
The decision. Stop polling through the 90-30 driver. The working options are two: a panel whose driver list names the VersaMax CPU and its port, or a protocol gateway whose documentation names the panel-side protocol and the VersaMax protocol on the PLC side. Fit one of the two, then rerun the four checks to 1 updating value before any tag is edited.
The fix, in order
- Identify the CPU. Read the exact family and the port you are using from the PLC documentation or its programming software. Keep the point count as an input and output figure; the family and the port decide the protocol.
- Search the driver list. Look for that family and the port type. Found: continue at step 3. Missing: go to step 6.
- Match the five settings. Protocol, baud rate, data bits, parity, stop bits, plus the station address if the protocol uses one: take the values from the driver's manual, enter them in the panel project, and set the PLC port to the same values, one side at a time.
- Verify the cable. Beep transmit, receive and signal common end to end against both manuals' wiring diagrams, 3 conductors in all. If any pin is wrong, fit a cable documented for the device pair.
- Prove the link with one value. Set a spare register to a number you chose in the PLC program, point one panel object at it, download the project, and confirm the number appears and holds. Bring the remaining tags across and confirm the error stays gone.
- Close the protocol gap. With no driver for your CPU, fit a gateway documented on both sides or a panel whose list names your CPU. Give the gateway the same proof: test a gateway with one known value before you trust its data. And when the panel itself is up for replacement, check the PLC serial protocol before replacing a legacy HMI.
If the link still fails after step 6, write down the CPU family, the port configuration, the driver selected, the five setting values, the cable's wiring diagram and the exact error text, then recheck that list in order, one item at a time.
The decision
With zero protocol matches between the selected driver and the port, no settings change and no cable repair can reach one updating value. The count decides the case, and it decides it at check 1, before any hour is spent on settings or wiring.
Recommendation: never poll through the nearest family name, not even once as a test. If the panel's driver list names your exact CPU, match its five serial settings against the PLC port and confirm one known value updates before any tag is written or rewritten. If the list has no entry, choose between a protocol gateway documented on both sides and a panel whose list names your CPU, then bring the link up on one known value before the remaining screens are converted.
Questions
Is a driver from the same PLC maker ever close enough?
Only when the panel's compatibility list names your exact CPU family for the port you are using. Two families from one maker can differ in frame layout, addressing and timing, so the list is the evidence, not the name. If the list covers your CPU, use that driver; if it does not, the fix is a gateway documented on both sides or a panel whose list names your CPU.
What do I do with the 0x0000 value on the screen?
Treat it as part of the error message and keep it out of your logic. The pair PLC-499 with code 0x0000 is the panel reporting a failed read, and the exact wording for that code lives in the panel manual's error list. Note which screen and which object raised it, then work the checks from the driver list down; the value stops appearing once real reads succeed.
Which value should I test first once the link is up?
One you can drive yourself. Set a spare register or bit to a value you chose in the PLC program, point a single panel object at it, and watch several updates in a row. When your chosen value appears and holds, the round trip is working, and the remaining tags can move across one screen at a time while you confirm the error stays gone.
Can one cable suit every RJ45 serial port?
No. RJ45 names the 8-position connector; the RS-232 signal assignment belongs to each device's manual, and two devices can use different pins for transmit, receive and signal common. Build or buy the cable against both manuals' wiring diagrams, beep the three conductors end to end, and keep a cable documented for the device pair as the standard for that link.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.