Productivity Suite Empty Sub-Rung Corruption: Field Fix

Identify which fault is on the screen

Two different failures show up while editing ladder in Productivity Suite. One changes the project content. The other, as far as it was observed, changes only what the editor draws. They need different handling, so sort them out before you touch another rung.

The quick fixes that come to mind first, and why they don't restore production:

• Compile again to clean it up. On the empty sub-rung fault, compile is what causes the damage. A second compile does not bring the pasted rung back.
• Hit Undo. After a compile has rebuilt the rung list, you don't know what the undo history holds. Undo is not a recovery plan.
• Download and see if it runs. This pushes suspect logic to the CPU.
• Ignore the drawing glitch. You can't verify a branch you can't see correctly.

Check: Note the rung count in the affected task. Note which rung numbers look wrong. Write down which of the two rows above matches what you see.

Save a fallback copy before editing further

1. Use Save As to write the current project to a new file with the date and time in the name. Do not overwrite the last good project.
2. Keep the project file that matches the logic running in the controller untouched. That file is your recovery point.
3. Read the exact software version and build from the About dialog and write it down. You need it to compare against release notes and for a support case.
4. If the fault is the empty sub-rung type, keep the damaged file as a separate diagnostic copy. Do not repair it.

Check: Close and reopen the fallback file. Confirm it opens, and confirm the rung count matches your note from before the problem started.

Clear empty sub-rungs before you copy

An empty sub-rung is a branch leg with no instructions on it. In V1.4.1(1) the fault showed up every time with one sequence: copy a rung carrying an empty sub-rung, paste it a few rungs lower, compile. After the compile:

• The pasted rung was gone.
• A duplicate of the rung directly above the paste point sat in its place.
• The duplicate was identical in every way, and it stayed linked. Changing a contact or output on either rung changed the same element on the other.

The editor behaves as though both rung positions point at one rung object instead of two. That explains the linked edits, and it explains why pasting the same source again gives the same result. The empty leg is the common factor, so remove it from the source rung before you copy.

1. Open the source rung and look for any branch leg with nothing on it. This includes legs left behind after you deleted an instruction.
2. Delete the empty leg, or finish it with the instruction it was meant to hold.
3. Compile with only that change made. Confirm the source rung still reads correctly.
4. Copy the rung, paste it at the target position, and compile.

To find out whether your build is affected, test on a scratch project only. Build a small project with a rung containing an empty sub-rung at rung 2. Copy rung 2 to rung 4 and compile. Never run this test in a production file.

Check: After the compile, the pasted rung is at the position you pasted it. Its contents match the source rung, and the rung above it is unchanged.

Test every pasted rung for a hidden link

A linked duplicate looks like normal code. If the rung above happens to be similar to the one you pasted, you will not catch it by reading. Linked edits are the giveaway, so test for them directly.

1. Pick one contact on the pasted rung.
2. Temporarily change its tag to a spare or unused tag.
3. Look at the rung directly above the paste point, and at the source rung.
4. If the same contact changed anywhere else, the rungs are linked. Stop and go to the rebuild procedure below.
5. If nothing else changed, restore the original tag.
6. Repeat the test with one output coil on the same rung.

Check: An edit on the pasted rung affects that rung only, for both a contact and a coil.

Rebuild a linked rung by hand

Don't try to repair a linked pair inside the damaged file. If you delete one rung of the pair, you cannot predict whether the other goes with it, or whether an edit to what remains carries over. Work from the fallback copy instead.

1. Stop editing the damaged file. Save it under a diagnostic name for the support case.
2. Open the fallback copy from before the paste.
3. Remove any empty sub-rungs from the source rung, as described above.
4. Enter the new rung by drawing the instructions, not by pasting. Once the empty legs are gone, pasting is acceptable, but drawing it by hand takes the paste path out of the problem entirely.
5. Compile.
6. Run the link test on the new rung.

Stop here if the new rung fails the link test even though you drew it by hand from a clean source. That result is outside the known trigger. Hand it to official support with the diagnostic file.

Check: The link test passes. The task rung count equals the original count plus the rungs you added. The rung above the new one is unchanged.

Redraw a misattached parallel branch

This was the V1.6.0(19) behaviour. While a parallel output was being added:

• The vertical bar did not attach to the intended rung.
• Every other rung in that task showed the same unattached bar.
• Tag names were drawn over the output coils.

A compile put the screen layout right. The software had been running continuously since the previous day. After a restart, the condition could not be reproduced. The pattern points to the editor's display state going stale over a long session, not to changed logic. Still, prove that before you download.

1. Stop drawing. Don't add or move anything while the screen is inconsistent.
2. Compile and let the editor redraw.
3. Inspect the rung you were working on. Confirm the parallel output sits on the intended rung and the branch closes where you meant it to.
4. Scroll through every other rung in the task. Look for leftover vertical bars or branches you didn't draw.
5. Save, close Productivity Suite completely, and reopen the project.
6. Inspect the same rungs again in the fresh session.

If the stray branches or misplaced outputs are still there after the restart, they are in the saved logic, not just on the screen. Treat that as corruption: go back to the fallback copy and rebuild. Make it a habit to close and reopen the software at the start of a shift instead of leaving one session open for days.

Check: After the restart, the parallel output is on the intended rung. No other rung has a branch you didn't draw. Every tag label is readable and clear of its coil.

Verify the whole project before download

Get it running, then fix it properly. Running still means proving the file first.

1. Compare the rung count for each task against your notes.
2. Read every rung you touched, plus the rung directly above each paste point.
3. Run the link test on every rung that came from a paste.
4. Check the tag usage or cross-reference view for every output a pasted rung writes. Each output should appear where you expect it and nowhere new.
5. Compare the edited project against the fallback copy. Use the version's project comparison tool if it has one; otherwise compare exported or printed ladder side by side. Every difference should be one you intended.
6. Download during a window when the machine can be stopped.
7. Monitor online. Confirm each pasted rung shows power flow from its own contacts, not a mirror of the rung above.

Check: The online status of every edited rung follows its own inputs through at least one full machine cycle. The comparison against the fallback shows only intended changes.

FAQ