Configuring Mitsubishi FX2N STL in GX Developer Safely

After the project target and editor representation are corrected, the FX2N step sequence appears as executable step-ladder logic in GX Developer and passes the software syntax check. On the programming screen, the problem looks like missing or unusable STL code: the manual shows a sequence, but you cannot reproduce the same display in the editor.

Start here. Confirm what STL means, then check the PLC target, the editor representation, instruction entry, and sequence structure in that order. Reinstalling GX Developer or changing unrelated PLC settings wastes time until those checks identify a software fault.

Identify the STL language first

For an FX2N project, STL refers to step-ladder/state-transition programming. It does not mean the text-based Statement List language that some other PLC platforms abbreviate as STL. Searching for a free-form text editor or trying to enter an entire textual program therefore sends you down the wrong branch.

• If you want a machine sequence divided into active steps and transition conditions, continue with the FX step-ladder checks below.
• If you want a general textual instruction language, stop. You are asking GX Developer for a different representation, not building an FX2N STL sequence.

The mechanism matters: a step sequence activates one state at a time, executes the logic associated with that active state, and advances only when its transition condition becomes true. The editor may render that structure as ladder elements rather than as the printed diagram or textual layout shown in an older manual.

Check the project target before entering logic

Read the configured PLC type in the open project. It must identify the intended FX2N target. GX Developer uses the selected PLC family to determine which instructions, operands, and editing rules it accepts.

• Target is FX2N: Keep the project and check the editor representation next.
• Target is another PLC family: Create or open the correct FX2N project before entering the sequence. Do not try to repair target-related rejection by rewriting the transitions.
• Target cannot be identified: Do not download. Read the project properties and compare them with the controller identification first.

A project can look like ordinary ladder and still have the wrong processor selected. That error appears later as rejected instructions, invalid operands, or a download mismatch, so settle it before debugging the sequence.

Separate display differences from program errors

Compare function, not page layout. Manual JY992D88101D contains an FX STL section, but printed examples may not look exactly like the representation produced by GX Developer. A different symbol shape or screen arrangement is not a PLC fault.

Screen symptom	Likely cause
The manual looks like a flow sequence, while GX Developer shows ladder elements	The manual and editor use different representations of the same step logic
The editor rejects the entry immediately	The selected entry method, instruction syntax, or operand is invalid for the project target
The sequence converts, but never leaves its first active step	The initialization path or first transition condition is missing or false
Several steps appear active unexpectedly	The transition structure or state activation logic does not enforce the intended sequence
The offline check passes, but the controller behaves differently	The downloaded project, operating state, or live input conditions do not match the offline test

Run the GX Developer syntax or conversion check. If it passes, stop treating the visual mismatch as the fault and inspect sequence behavior. If it reports an error, record the exact rejected instruction and operand, then correct that entry before adding more steps.

Build one minimal sequence branch

Do not begin with the full machine cycle. Prove the editor and execution model with an initial state, one transition, and one following state.

1. Create a new test project with FX2N selected, or make a backed-up test copy of the existing project.
2. Define the condition that establishes the initial step after startup or reset. A sequence without a deterministic entry state can remain inactive even when every transition is written correctly.
3. Enter the first step using GX Developer's FX step-ladder representation.
4. Place only the outputs or internal actions that belong to that active step beneath it.
5. Add one Boolean transition condition. Use a condition you can observe and control during the test.
6. Connect that transition to the next step. Keep the second step free of unrelated machine logic.
7. Close the sequence using the structure required by the FX STL editor, then run conversion or syntax checking.

The functional pattern is:

INITIAL STEP
  actions while initial step is active
  transition condition to following step

FOLLOWING STEP
  actions while following step is active
  next transition or defined hold condition

This is a sequence outline, not literal GX Developer instruction syntax. Assign operands that are valid for the configured FX2N project and use the editor representation shown by the installed software.

Trace the active step and transition reading

Monitor the sequence online only after the offline check passes and the correct project is in the controller. Watch the active-state indication, the transition condition, and one action associated with each step.

• No step becomes active: Return to the initialization logic. Forcing later transitions will not repair a missing entry state.
• The initial step is active and the transition stays false: Trace the contacts that form that transition. Read their live states; do not infer them from the machine's physical appearance.
• The transition becomes true but the next step does not activate: Recheck the transition placement and destination step, then rerun conversion.
• The next step activates correctly: The STL mechanism works. Add one step and one transition at a time.
• The offline and online programs differ: Stop diagnosing the logic until the intended compiled project is downloaded and verified.

Do not use output forcing as the first test. It bypasses the state mechanism and can make faulty transition logic appear correct. Monitor internal state and transition truth first; operate real outputs only under the site's normal commissioning controls.

Complete the sequence and verify the fix

1. Remove temporary forces and test-only overrides.
2. Convert or compile the complete project with no unresolved instruction or operand errors.
3. Verify that startup or reset selects the intended initial step.
4. Trigger each transition separately and confirm that the current step relinquishes control as the following step activates.
5. Confirm that actions associated with an inactive step are no longer commanded unless separate logic intentionally controls them.
6. Test false transitions, interrupted cycles, and the defined restart path. The sequence must not advance merely because it was previously partway through a test.
7. Compare the online project with the saved project so the verified logic is the logic retained for maintenance.

A successful test proves three things independently: GX Developer accepts the FX2N syntax, the sequence always acquires a known initial state, and every step change follows an observable transition condition.

FAQ