Moving digital input tags about ten channels in Productivity Suite caused ladder logic to show the wrong tags, so a wiring cleanup can change which physical input a rung represents. Restore a deliberate channel-to-tag mapping first; then put a stable program mapping layer between hardware channels and machine logic before the next I/O rearrangement.
Stop blind ten-channel shifts before changing hardware tags
Do not drag or reassign a block of DI names and trust the ladder display to preserve the intended signal. In the reported project, moving the channels made the wrong tags appear in ladder logic. That is a production risk because a rung can look valid while its contact now represents a different field input.
Renaming tags in place is also not a safe shortcut until you know how the installed Productivity Suite revision handles hardware-tag edits and ladder references. An earlier project revision was described as requiring STOP mode for I/O renaming, but that behavior was qualified as version dependent. Check the installed release’s edit requirements before changing the live project; do not assume an old mode requirement applies to every revision.
For recovery, use a controlled, one-tag-at-a-time reassignment and check every affected rung. If the mapping is unclear, stop before downloading or returning the machine to automatic operation. A correct-looking tag name is not proof that the rung is reading the intended terminal.
Separate physical channel identity from ladder meaning
A hardware configuration associates a tag with a physical I/O point. Ladder logic then uses that tag as the program reference for the signal. When the hardware association changes, the tag shown in a rung can no longer match the field device or wire the maintainer expects. Treat these as two separate records: the physical terminal assignment and the logical machine signal.
Before editing, make a simple cross-reference for each moved input: current module and channel, current tag, intended module and channel, and the rung or logic function that uses it. Record the intended device name as well, such as a limit switch or pressure switch, using the project’s actual signal names. This list gives the shift a way to detect a swapped, missing, or duplicated assignment rather than relying on channel order.
Keep the difference clear when reviewing the ladder:
- The module and channel identify where the electrical input enters the controller.
- The tag identifies what the logic reads at that point in the project.
- The rung’s function identifies what that input is supposed to do in the machine sequence.
All three must agree after a move. If the ladder shows a familiar tag but the module channel now lands on another wire, the program can execute without an obvious syntax error while acting on the wrong device.
Choose a mapping pattern before editing
Use direct hardware-tag reassignment when the project is small and the physical I/O arrangement is the intended program interface. Use a program mapping layer when you expect hardware layouts to change, want the same logic to run on different base or I/O configurations, or need a consistent naming scheme across repeated components.
| Pattern | How it works | Tradeoff |
|---|---|---|
| Direct hardware tags | Move the tag to the intended input in Hardware Config, then confirm every ladder use. | Fast for a limited change, but the hardware map and logic references require careful joint review. |
| Stable tags plus mapping logic | Leave hardware I/O at its default names and copy input states into internal program tags; map internal output commands to physical outputs. | Adds a mapping task, but separates the machine logic from a particular I/O layout. |
| Array-based processing | Copy raw input values into indexed arrays and process or scale them in loops. | Efficient for repeated devices, but element documentation and index-to-device correspondence need deliberate management. |
The program-mapping approach described for this software uses CPD to copy an input to an internal bit or an internal bit to an output. Keep the direction explicit: an input mapping supplies the logic with a stable internal signal, while an output mapping transfers the logic’s command to the assigned physical output. Do not mix up the two when creating the task.
Move each tag through Hardware Config
For a direct reassignment, use the reported Hardware Config cut-and-paste method and verify each transfer before moving on. Do not make a large set of changes without checking the resulting channel map and ladder references.
- Save a separate working copy of the project. Record the old and intended module/channel assignment for every DI tag being moved.
- In Hardware Config, select the module that currently contains the tag. Cut the tag from its present input.
- Open the module that will receive the tag, select the intended input, and paste the tag there.
- Check that the source input is no longer assigned that tag and that the destination input now has it. Update the cross-reference list before continuing to the next tag.
- Review every ladder use of the moved tag. Confirm that the contact or instruction still represents the intended field device, not merely the expected text label.
- Run the project’s normal validation or build checks, then compare the final hardware assignments against the cross-reference list.
A cut-and-paste transfer changes the assignment in the hardware configuration; the project still needs a logic review. If a name appears on an unexpected rung, stop and resolve the mapping before downloading. Confirm the STOP or other operating-mode requirement in the documentation or edit prompts for the installed revision, since the historical report does not establish the requirement for every release.
Keep future I/O changes behind stable program tags
For a permanent repair, leave the DI, DO, AI, and AO hardware tags at their default names and put the meaning of each signal in the program layer. Then a physical channel move changes the mapping task while the rest of the machine logic continues to read the same internal tags. This also supports using one program across different base and I/O configurations.
For repeated components, arrays can reduce duplicated logic. One described pattern copies analog raw readings into temporary S32 arrays named with a raw-count convention, then loops through the values to scale them into engineering-unit arrays. The array index can stand for the component number only when the machine’s numbering and array positions are intentionally aligned; an example application numbered capacitors from 1 to 25 or 1 to 100 and used that index as the identity.
Array documentation is a design constraint. Individual elements could not be uniquely documented in an earlier revision, while unique element comments down to the bit level were reported starting with 2.2.0(12). Check the installed revision and document the index-to-device map where maintainers can find it. Example names discussed for voltage and pressure arrays include Ai_vlt_array and Ai_psi_array; choose project names that distinguish raw counts, intermediate voltage, and final engineering units.
For the described voltage example, the first linear scaling was from raw counts 0–65535 to 0–10 V, followed by a second scale from 0.5–5 V to either 0–200 PSI or 0–500 PSI. If both stages are linear and those endpoints match the module and transmitter configuration, calculate:
V = raw_count * 10 / 65535
PSI = (V - 0.5) * full_scale_PSI / (5.0 - 0.5)
Set full_scale_PSI to 200 or 500 for the applicable signal. Use the actual configured raw range and transmitter endpoints if they differ. A separate example used voltage tags ending in _Vlt and pressure tags ending in _PSI, keeping intermediate and engineering values distinct.
Integer scaling can also be appropriate when the application does not use, calculate, display, or log floating-point resolution. One described machine multiplied milliamp readings to remove the decimal and assumed the decimal position at the HMI. Keep that multiplier and HMI decimal convention consistent. A reported loop scaled 100 voltage and 100 milliamp values on a 0.5-second interval without significant impact in that application; measure task execution and update behavior on the target project before adopting the same interval.
Prove each input through the ladder before release
Verify the signal path from terminal to program meaning, not just the tag list. With the machine in an approved condition for input testing, operate or otherwise stimulate one field input at a time and observe the corresponding module channel, tag, and ladder state. Compare the result with the cross-reference list. This catches a correct-looking tag assigned to the wrong physical point as well as a wiring or labeling mismatch.
For each moved DI, record a pass only when the intended channel changes, the intended tag follows it, and the expected ladder reference responds. Check neighboring channels too, especially where the move was made to group similar input types. If the observed state differs from the intended device, restore the known mapping from the saved project or correct the assignment before returning logic to service.
For an array mapping, verify several known component indices, including the first and last used positions, so an index offset does not shift every device by one. Confirm raw count, scaled intermediate value, final engineering value, and HMI presentation for representative signals. For the two-stage voltage-to-pressure example, check both the voltage and PSI result against the configured endpoints. Do not sign off solely because the loop executes or values appear plausible.
Finally compare the validated hardware map and program references with the saved cross-reference. Keep the temporary direct reassignment documented if it is restoring operation while a mapping-layer redesign remains scheduled. If the installed revision’s edit behavior, channel association, or task execution cannot be established from the project and official documentation, stop and contact the software’s official support channel before downloading or resuming automatic operation.
Frequently asked questions
What happens if I move a DI tag to another channel?
The hardware assignment changes, and ladder logic can show a tag that no longer represents the physical input you expect. Review each affected rung and verify the terminal-to-tag-to-logic path before release.
What happens if I cut a tag from one module and paste it to another?
The tag is reassigned in Hardware Config using the reported method. Check that the source is cleared, the destination is correct, and every ladder use still represents the intended field signal.
What happens if I leave default I/O tags in place?
You can map hardware inputs and outputs to stable internal program tags, for example with CPD. The machine logic can then remain independent of the particular I/O configuration.
What happens if array elements are hard to identify?
Maintain an index-to-device map and check comment support in the installed revision. Unique array element comments were reported starting with Productivity Suite revision 2.2.0(12).
When should I stop and contact official support?
Stop before downloading if the channel-to-tag assignment or ladder reference remains ambiguous, or if the installed revision’s edit-mode behavior is unclear. Contact the official software support channel with the project revision and the affected module/channel map.