GX Works2 reports “invalid argument” when the FX3 simulator is asked to force X17, even though other input devices can be forced. Check the FX device-addressing convention first; X17 is a valid FX address, so changing it to another input only hides the symptom.
Stop changing X17 to another input
- Changing X17 to an input that works: This avoids the failing address without explaining it. X17 is within the FX input sequence described for this PLC family.
- Rebuilding the project immediately: The same failure occurred in a project recreated from scratch, so project recreation alone is not a useful first fix.
- Reinstalling GX Works2 as the first move: A damaged installation was suggested, but it was not demonstrated. Check device syntax, the selected PLC type, and simulator state before spending time on reinstallation.
Record the exact error text and check whether the simulator is running. Do not treat “invalid argument” as proof that X17 is an invalid device.
Check the FX3 address convention and project target
FX input numbering uses octal-style device progression: X0 through X7, then X10 through X17. Therefore, X17 is a valid FX input address; the transition after X7 is not decimal X8 or X9. A project configured for a different PLC family can use a different I/O convention, so verify the selected PLC type rather than applying another family’s address assumptions.
- Open the project’s PLC type/settings and confirm that the target matches the FX3 being programmed.
- Inspect the X17 references in the ladder and confirm the device is entered as X17, without a typo or a different character.
- If the project uses configured I/O or module settings, compare them with the actual target configuration. The required settings depend on the selected PLC and its I/O arrangement.
Do not transfer Q-series hexadecimal-style examples such as X0F or X10-X2F into an FX project. Those examples describe a different address convention, not a correction for FX3 X17.
Separate an address problem from a simulator problem
Because other inputs work while X17 fails, test the device in isolation. Create a minimal test using X17, then compare it with adjacent devices that the simulator accepts. Keep the PLC target and simulator configuration unchanged during the comparison; changing several settings at once makes the result inconclusive.
| Observation | What to check next |
|---|---|
| X17 fails, but X15, X16, or X18 works | Confirm the exact X17 entry, target PLC type, and whether the error occurs only in the force/debug operation. |
| Several inputs fail | Check that the simulator is started and the project target and I/O configuration match the intended PLC family. |
| The same X17 test works in a fresh minimal project | Compare the original project’s PLC type and I/O settings with the minimal project. |
| X17 fails in a fresh project as well | Use the alternate watch/register test and capture the exact message and steps for escalation. |
The reported GX Works2 version was 1.662Y. Another installation at 1.620 did not reproduce the failure, but that comparison does not establish a version defect or a reliable downgrade fix.
Test X17 through a watch or register view
If the debug force command still returns the error, use the software’s online watch/register method as a diagnostic alternative. The reported workaround was to enter the relevant I/O device and try writing 1 or 0 rather than using the debug force control.
- Start or connect to the intended simulator session and open the watch/register view.
- Enter the device as
X17and attempt the needed 1 or 0 test value using that view’s supported operation. - Observe whether the monitored state changes and whether the same invalid-argument message appears.
- Repeat with a neighboring input that already works, using the same view and session.
This test distinguishes a failure in the debug-force path from a broader device or simulator issue. Do not assume that an online write to a real physical input can override the electrical signal at the terminal; this procedure is for diagnosing the simulator workflow.
Verify the fix before using the simulation
- Confirm X17 can be monitored and operated through the chosen simulator method without the invalid-argument message.
- Check that the ladder logic using X17 responds as intended when the simulated state changes.
- Confirm adjacent input addresses still behave as expected and that no PLC type or I/O settings were changed merely to bypass X17.
- Keep the project target and simulator configuration consistent with the FX3 before relying on the test results.
If the watch/register test works but debug force continues to fail, use the working test path for simulation and document the debug-force limitation. If both paths fail on X17 in a minimal project, preserve the exact error text and project target details before escalating.
GX Works2 X17 simulator questions
Can I force X17 on an FX3 in GX Works2?
X17 is a valid FX input address in the sequence X0-X7, then X10-X17. If debug force returns “invalid argument,” verify the project target and try the watch/register diagnostic path.
Does X17 mean a decimal input number?
No. FX input numbering follows the stated octal-style progression, so X17 follows X16 and precedes X20. Do not interpret the address using another PLC family’s convention.
Can I use a watch register if debug force fails?
Yes, as a simulator diagnostic: select the intended session, enter X17, and test 1 or 0, then compare with a neighboring working input. If both methods fail in a minimal project, stop changing settings blindly and escalate to Mitsubishi support with the exact error, PLC target, GX Works2 version, and reproduction steps.