PLC-010, code 1010, means the reply to a read carried the wrong number of bytes. During a program transfer the controller stops answering polls normally, so the alarm hits every tag at once and clears once it returns to run. One tag still failing afterward is an address or data-type mismatch to correct, not a network fault.
Short answer: yes, in the case you describe. PLC-010 that appears while a program transfers to the controller and clears once the controller is back in run, with every value updating again, is the transfer interrupting the reads. The panel project needs no change. The documented meaning is narrow: an incorrect number of bytes in the data returned from the PLC. While the controller takes the new program it stops serving its normal reads, so every tag on the screen reports at once. The pattern that deserves work is the other one: a single tag that keeps raising the alarm after the transfer ends, because that points at its address or its data type. A three-window count, before, during and after the transfer, separates the two in one pass.
What the alarm reports
The error-code appendix in the panel's manual lists PLC-010 with the numeric value 1010 and the text "There is an incorrect number of bytes found in the Data returned from the PLC." Read plainly: the panel asked for a block of data whose length the tag's data type sets, 2 bytes for a 16-bit integer and 4 bytes for a 32-bit value, and the reply came back a different length. The next entry in the same table, PLC-011, is a different complaint about the same exchange, an invalid value in the function code; see what PLC-011 invalid function code means on an Ethernet link.
The text stops at the byte count. It names no tag and no cause, so the diagnostic work is scope: everything failing at once, or a few tags failing on a cycle.
Symptoms and what each one points to
- Every value on the screen fails together, only while a program transfers, then recovers. The controller stops serving its normal reads while it takes the new program, so the alarm covers the whole screen at once and leaves when the controller returns to run. This is the artifact you suspected. Nothing to fix.
- One tag, or a few at fixed addresses, fails on every poll while their neighbors update. Those tag definitions disagree with the data table in the loaded program. Integration guides name this class directly: the data type in the controller has to match the type the panel expects, and the data allocated has to match the size configured. A 32-bit tag pointed at 16-bit data asks for double the bytes the table holds.
- The message clears in 1 to 2 seconds and returns every 10 to 20 seconds. A field report of this same alarm watched exactly that rhythm. The cause repeats with the poll cycle, so find the failing tag; the rhythm holds until the definition or the interruption is gone.
- PLC-010 arrives mixed with a lost-connection alarm such as PLC-015. Two separate failures. PLC-015 means no device answered within the timeout, so settle the link first; a dropping link fails reads for its own reason. Start with why an HMI shows PLC-015 no device found after a timeout.
- The alarm began right after a program change and never left. Compare the panel project's tags against the data table in the program now loaded before you touch anything else. The change is the leading suspect, and the comparison usually closes the job in one pass.
The three-window check
- Before the transfer, open the affected screen, list the values that update, and satisfy yourself that PLC-010 is absent. Thirty seconds of watching is enough; call it a 30-second window.
- During the transfer, note which values freeze and whether the alarm covers all of them or only some.
- After the controller returns to run, count the tags still failing or stuck on stale values. Give this window 1 to 2 minutes so several poll cycles pass.
Zero failing after the controller is back: that closes it, walk away. A handful still failing: for each one, write down its configured address and data type, compare it with the data table in the loaded program, and note the byte width its data type implies.
If many unrelated tags keep failing outside any transfer while the link stays up, the next check is the protocol driver match, which is its own job; see an HMI that pings the PLC but reads still fail.
Worked example: PLC-010 during a program transfer on an Ethernet link
Inputs:
- Alarm and code: PLC-010, value 1010 in the panel's error table, "an incorrect number of bytes found in the Data returned from the PLC", from the manual's error-code appendix.
- Trigger: the alarm shows while a program transfers to the controller over Ethernet. This is the case in question.
- Cadence from a field report of this alarm: it clears within 1 to 2 seconds and returns every 10 to 20 seconds while the cause is active.
- Data widths: a 16-bit integer is 2 bytes, a 32-bit value is 4 bytes.
Rule in words: count failing tags in three windows, before the transfer, during it, and after the controller is back in run. Whatever still fails in the last window is the worklist; everything that recovered was the interruption.
The pass:
- Window 1, before: 0 tags failing, values updating.
- Window 2, during the transfer: every value on the screen raises the alarm together.
- Window 3, after the controller returns to run: all values recover except one counter tag, which raises PLC-010 on the repeating cadence above.
Arithmetic on the survivor: the tag is configured as a 32-bit value, so the panel expects 4 bytes in each reply. The data table in the new program holds that counter as a 16-bit integer, 2 bytes. 4 expected minus 2 returned leaves 2 bytes short, on every poll.
Result: the storm during the transfer was the artifact; one real mismatch survived it.
Decision: zero failing tags in window 3 means the project stands as loaded. One or more failing tags means fix those definitions; here the correction is the tag's data type, 32-bit down to 16-bit, or moving the counter into a 32-bit register in the controller program.
Fix the tag, or fix nothing
Artifact case: write the observation in the log, "PLC-010 during program transfer, clears on return to run", so the next shift reloads nothing over it.
Tag case:
- Back up the panel project before editing.
- Correct the failing tag's address or data type to match the data table in the loaded program. When the edit touches a type that several objects share, change a tag's data type without rebuilding every object keeps the job contained.
- Load the revised project in an agreed maintenance window.
- Watch the repaired tag through several poll cycles, 1 to 2 minutes, and confirm the value updates and the alarm stays away.
One safety note: if the failing tag feeds an interlock or any safety-related function, stop and use the site's approved change process before editing, because a wrong data type can read a tripped condition as a normal value.
Recommendation: treat PLC-010 that appears only during a program transfer and clears when the controller returns to run as an artifact: change nothing, and log the behavior. Correct a tag only when it still fails after the controller is back, and fix its data type or address before touching the cable, the driver or the network settings.
When to escalate
If the tag definitions match the loaded program, the link holds, and the alarm still recurs after 60 seconds or more of clean observation, take it to the panel manufacturer's support with the notes from all three windows. That is the point where repeating the transfer or editing tags by guesswork costs more than it can return.
Questions
How is PLC-010 different from PLC-015?
PLC-015 means no device answered within the timeout: no reply arrived, so the checks are the link, the node address and the cable. PLC-010 means a reply did arrive and its byte count was wrong, so the tag definitions come first and the connection checks second. When both alarms appear together, settle the link before judging any byte count.
Will PLC-010 clear on its own?
Only the transfer-time form does. That one clears when the controller returns to run and the values update again. A tag mismatch keeps firing on every poll of that tag; a field report watched this alarm clear within 1 to 2 seconds and return every 10 to 20 seconds until the cause was fixed. Use that cadence as your confirmation window and watch a repaired tag for at least 60 seconds.
Can a single wrong data type cause PLC-010?
Yes. A tag configured as a 32-bit value expects 4 bytes in each reply; a 16-bit integer in the controller's data table is 2 bytes, so every poll of that tag comes back short. The neighboring tags keep updating because their byte counts still agree. One tag failing while the rest of the screen stays live is the signature of a definition mismatch.
What should I include when I escalate a PLC-010 case?
The numeric code 1010 and the alarm text, the failing tag list with each address and configured data type, the panel and controller project versions, and your notes from before, during and after the transfer. Add the poll cadence you observed, since a repeating fault and a one-off glitch point support down different paths.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.