PLC-011, invalid value in function code, is the operator panel rejecting one read or write on its Ethernet driver. Read the panel's fault entries, test the path with a timed ping run and the switch port counters, take the maker's Ethernet software update, and verify under production load before closing commissioning.
PLC-011 on an Ethernet operator panel looks like a controller fault, and it rarely is. The alarm says the panel rejected a read or write on its Ethernet driver. The causes documented behind this code are packet loss on the network plus the panel software's own timeout handling. The order of work is fixed: read the fault entries to learn which operation failed, test the link for lost frames, then take the software's Ethernet update from the maker's own site and rerun the production conditions. This article carries the numbers for each step, including the pass mark that closes commissioning.
What does PLC-011 invalid value in function code mean?
PLC-011, invalid value in function code, means the panel rejected one read or write on its Ethernet driver. Packet loss with mishandled timeouts produces this exact text while the PLC program sits untouched.
The text names the field the driver checks on every incoming transaction. Noise on the network and a timeout setting the software mishandled were the two causes documented behind this code. That is why the work starts at the fault entries and the link, with the PLC logic last. The alarm tells you a transaction failed; the entries tell you which one, and that difference is the whole diagnosis.
How do I find which read or write triggered PLC-011?
Open the fault entries on the panel's setup screen. Each one shows the read or write the panel attempted when PLC-011 fired, which is the detail the alarm banner leaves out.
Every operator panel family keeps a fault list in its setup screens, and this code is exactly the case where the list earns its keep. Work it in order:
- Open the fault entries and find the PLC-011 records.
- Record each one: the timestamp, the attempted read or write, and the screen object or tag behind it. A photo of the panel screen is enough on the floor.
- Match the named operation to the object and the data item in the panel project.
- Record the next occurrence too. Two entries naming one operation move the job to that object's mapping; entries naming different operations move it to the link test below.
Decision: the entries either repeat one operation, and you repair that mapping, or they scatter, and you repair the path.
Why does PLC-011 come and go while the screens work?
An intermittent PLC-011 across different reads and writes points at the Ethernet path. Packet loss interrupts whichever transaction happens to be in flight when a frame is lost.
The other screens keep updating because most transactions arrive intact; the rejected ones are the ones a lost or late frame caught. The panel software's timeout handling was the second documented half of the cause, corrected in a later software release. A software fix only changes how the panel reports a noisy link, so the link test comes first. Match your case against these patterns:
- Every entry names the same screen object. Repair that object's read or write mapping first and check its tag address against the controller's data map.
- Entries name different objects while the rest of the screens keep updating. Packet loss caught whatever was in flight; run the link test in the next section.
- The fault returns on a fixed cadence. A repeating cycle points at polling and retry timing; the fix for an HMI protocol error that pops up every 30 seconds walks one such pattern.
- The entries carry a plain communication timeout with no function-code wording. The same path is failing more gently; why an HMI shows an intermittent PLC communication timeout covers the timeout-only form.
- The panel's port LEDs drop and relight during production. A physical fault in the patch cable, a connector or the switch port; replace the lead, move to a spare port and retest.
Decision: scattered entries plus any link event is a path repair; one repeating object is a mapping repair.
How do I test the Ethernet path for packet loss?
Run a ping from a laptop on the same switch to the panel and to the PLC at the 1-second interval for at least 2 hours under production load, then read the switch port counters. On a clean two-device wired link the pass mark is zero lost requests.
Set the run up in this order:
- Addresses. The panel, the PLC and the laptop need unique, valid IP addresses on one subnet. Check each address against the device's own setup screen before anything else, and note them in the commissioning log.
- Cable and port. Swap the panel's patch lead for a known-good one, reseat the connectors and move the panel to a spare switch port. Note the port's error and link-change counters before you start.
- Speed and duplex. Set both ends the same: auto on both or 100 Mbit/s full duplex on both. One end forced and the other on auto corrupts frames under load and shows up as intermittent loss.
- Timed ping. One request per second, from the laptop to the panel and to the PLC, for at least 2 hours while the line runs the operations that produced the fault.
- Counters and correlation. Read the counters again after the run. CRC errors or link changes gained during the window should line up with PLC-011 timestamps in the fault entries.
- Discovery failures. A panel that never appears in the node list on the commissioning laptop usually has the laptop's firewall in the way. Check the firewall first, then the panel's own network settings.
Decision: one lost request or one incrementing error counter inside the window sends the repair to the path; a fully clean run with entries still naming one object sends it to that object's mapping.
Worked example: what does a 2-hour ping run with 3 lost requests show?
A small line network with one switch, an operator panel, a PLC and a laptop loses 3 of 7200 ping requests in 2 hours. The three timeouts land on the same minutes as three PLC-011 entries, which convicts the path.
Scenario: a packaging line in commissioning. One small switch carries the operator panel, the PLC and a laptop. The panel, on software version 2.6, raises PLC-011 a few times per shift and the fault entries name different objects. The crew starts a ping at 1 request per second to both devices and leaves the line running for 2 hours.
- Requests sent: 2 h × 60 min/h × 60 s/h = 7200 per target.
- Lost: 3 to the panel, 0 to the PLC.
- Delivered to the panel: 7200 - 3 = 7197, a loss of 3 / 7200 = 0.04%.
- Timing: the 3 ping timeouts fall at minutes 47, 72 and 118, and the fault list carries PLC-011 at those same minutes.
- Counters: the panel port's CRC error counter gains 3 during the run; the PLC port's stays at 0.
The repair follows the verdict: the crew swaps the panel's patch lead and sets both ports to 100 Mbit/s full duplex. The rerun delivers 7200 of 7200 to the panel, the counter stays flat and no new entry appears.
Decision: 3 lost requests at 0.04% with matching timestamps is a path repair, and even 1 lost request fails the pass mark. The numbers here are illustrative; the pass mark and the timestamp match are the parts that transfer.
Should I update the panel software first?
Record the baseline first, then take the panel software's Ethernet update from the maker's own support site. Release 2.71 listed improved tolerance of Ethernet packet loss across all Ethernet drivers and corrected timeout handling.
A panel still on release 2.6 sits below both fixes. The update changes the symptom as much as the cause, because better timeout handling makes a link that still loses frames show its trouble faster. Rerun the ping test after updating and let the lost-request count and the counters decide. Check the controller side too: read the controller's own release notes when the entries blame its station, because firmware updates have cleared Ethernet communication faults before.
The baseline is three things: the saved project file, the installed version in writing, and photos of the fault entries. With that recorded, the update becomes a step with a before and after.
Update in a planned window: the panel drops its screens while it restarts, so agree the window with production and make sure nobody acts on a frozen display.
Decision: take the update to correct the timeout handling, then let the rerun's entries, counters and ping count say whether the path still needs repair.
Recommendation: when PLC-011 scatters across different reads and writes, repair the path first, record the baseline, then take the panel software's Ethernet update from the maker's own site in a planned window, and hold the rerun to the same test window that convicted the path before anyone signs off commissioning.
How do I verify the fix before closing commissioning?
Close commissioning only after the operations named in the fault entries run for the same window length with zero new PLC-011 entries, a clean ping run and flat switch counters.
Run the screens and the operations the entries named, under the same production conditions that produced the originals. If the project includes writes, test them in the safe order the operator-panel link setup that tests writes before motion follows, so the first test of the repaired link never moves anything. Keep a live exchange check running: the PLC heartbeat counter method gives you a value to watch in place of waiting for an alarm banner.
The repair holds when no new PLC-011 entry appears across the same window length that produced the originals, the ping run delivers every request and the switch counters stay flat. If PLC-011 returns, read the new entries against the baseline. The same object again narrows the job to that mapping, and a fresh scatter sends you back to the path with new timestamps to correlate.
Close on that comparison, never on a quiet alarm banner right after the update.
Questions
Can PLC-011 come from the PLC program logic?
Yes, and the fault entries tell you. If every occurrence names the same screen object and the same read or write, and a clean ping run finds zero lost requests, inspect that object's tag mapping in the project and the data item the controller serves for it. The alarm text names a field; the entries name the operation.
Two controllers hang off the panel: which one raised PLC-011?
The fault entries separate the failed transactions by the connection they belonged to. A burst of PLC-011 records from one connection points at that connection's patch cable and switch port; records spread across both connections point at the shared switch or the panel's Ethernet handling, and the ping test in the article covers either leg.
Does a 2-hour ping run disturb production traffic?
No. One request per second is a negligible frame rate for a 100 Mbit/s industrial link carrying an operator panel's polling, and the panel keeps updating its screens normally through the run. Run it during the operations that produced PLC-011, because the loss that triggers the code only appears under that traffic.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.