Configuring Mitsubishi FX3G MOV Bit Groups Correctly

After the fix, all 16 inputs land in predictable internal-relay positions. On the GX Works device monitor, the fault looks like a broken address sequence: X27 is present, X28 and X29 are missing, and the next input is X30. A MOV K4X020 K4M020 can then appear to shift bits even though the instruction is working correctly.

Start here: separate the address numbering from the transferred bit positions. FX3G input addresses use octal digits. The M devices in the destination use decimal numbering. MOV packs consecutive source bits into consecutive destination bits; it does not preserve matching printed address suffixes.

Check the device list first

Open the GX Works device list or monitor and inspect the input addresses around the reported gap. This check comes first because it distinguishes invalid address notation from missing hardware or failed logic.

Do not spend time searching for X28 and X29. They are not input devices in this numbering sequence. Also do not replace X30 with X28 to make the labels look continuous; that creates an invalid address rather than correcting the transfer.

Count FX3G input addresses in octal

Octal addresses contain only the digits 0 through 7. After the final digit reaches 7, increment the next position and return the final digit to 0:

X20, X21, X22, X23, X24, X25, X26, X27,
X30, X31, X32, X33, X34, X35, X36, X37

The jump from X27 to X30 is an address-format rule. It does not represent two unused inputs, two missing bits, or a gap in the transferred word. Sixteen consecutive input bits still exist across that boundary.

Internal relays use a different device-number sequence. Starting at M20, sixteen consecutive relays are M20 through M35. This difference matters whenever one instruction groups X devices and M devices.

Expand the K4 group before changing logic

For this bit-device form of the instruction, K4 specifies four groups of four bits: 16 bits total. Expand both operands before diagnosing the result:

MOV transfers bit significance in order. It treats the input group as one packed 16-bit value and writes that value into the 16-bit destination group. The resulting correspondence is:

X20 -> M20    X24 -> M24    X30 -> M28    X34 -> M32
X21 -> M21    X25 -> M25    X31 -> M29    X35 -> M33
X22 -> M22    X26 -> M26    X32 -> M30    X36 -> M34
X23 -> M23    X27 -> M27    X33 -> M31    X37 -> M35

The apparent mismatch starts at the octal boundary. X30 is the ninth source bit, so it lands in the ninth destination position, M28. That is not a corrupt value or an off-by-two execution fault.

Choose MOV or PRUN by the required mapping

Keep MOV when downstream logic needs a packed 16-bit image of the inputs. Read the destination by position, not by matching the decimal suffix of each M device to the octal suffix of each X device.

Use (D)PRUN, instruction FNC 81, when the design requires an octal run of bits to retain matching displayed suffixes across the transfer. The documented example PRUN K3X16 K3M16 copies:

X16 -> M16
X17 -> M17
X20 -> M20
X21 -> M21
X22 -> M22
X23 -> M23
X24 -> M24
X25 -> M25
X26 -> M26
X27 -> M27
X30 -> M30
X31 -> M31

This is a different mapping objective. Changing from MOV to PRUN only makes sense when the consuming logic expects those matching suffixes. If the program treats the destination as a packed word, replacing MOV wastes time and can move signals away from the positions that existing logic expects.

Apply the correction in a controlled sequence

1. Record which physical inputs the machine options use and read their actual X addresses from the device list.
2. Confirm that the sequence crosses from X27 directly to X30. Remove any worksheet or comment references to nonexistent X28 and X29.
3. Expand K4X020 into its 16 source positions and K4M020 into its 16 destination positions.
4. Choose the required result. Retain MOV for a packed input image. Select the documented PRUN behavior only when matching octal-style suffixes are part of the program interface.
5. Update symbol comments and I/O documentation with explicit source-to-destination mappings. A comment such as X30 -> M28 prevents the next technician from diagnosing normal packing as a fault.
6. Check every consumer of the destination group before downloading a logic change. Blade-deviation detection, mist spray, laser control, or other option logic may already reference the packed M positions.

Verify the boundary bits individually

Test one input at a time while monitoring both device ranges. Use the machine's approved test state and observe the real input indication; do not infer the input state from the destination alone.

1. Change X20 and confirm that M20 follows when the MOV rung executes.
2. Test the last input before the octal boundary: X27 must correspond to M27.
3. Test the first input after the boundary: X30 must correspond to M28 under MOV.
4. Test the final grouped input: X37 must correspond to M35.
5. Monitor the instruction condition. If the source changes but the destination does not, confirm that the rung executes and that later logic does not overwrite the same M range.

Those four boundary checks prove the group width, octal transition, destination start, and final position without testing every bit. If one boundary fails, trace that exact input and destination before changing the instruction type.

FAQ