Why the stepper advanced function block will not enable

Why does the basic block move the motor while the advanced block will not enable?

Because they are two separate programs. The two block instances share an 11-byte axis array that passes position data between them, so the basic block's motion shows up in the advanced block's position output while the advanced block never issues an enable to the drive stage.

Both instances reach the card through a shared axis array, 11 bytes in the common stepper libraries. It carries command bytes from the block to the card and status bytes back. When the basic block commands motion, the card's position counter runs, and the advanced block reading the same array reports the moving position. That is observation. Control of the card belongs to whichever instance writes the command bytes, and with both instances running, that is a race the basic block usually wins. A moving position readout in the advanced block is expected in this state. It says nothing about its own outputs ever reaching the card.

What does each symptom point to?

Each symptom points at one of three paths: the enable chain, the command chain or the feedback chain. The list below pairs the six symptoms you will actually see with the single check that resolves each.

• No power on the motor line. The enable chain never closed. The drive stage gates power on the block's enabled state, so read the state word before you touch the motor wiring.
• Position updates in the advanced block while the basic block jogs. The feedback path works. The command path is still untested; run the advanced block alone.
• State word sits in Disabled with error code 0. No error happened; an enable input is false or miswired. Check the enable pins against the declaration.
• State jumps to ErrorStop on the first move command. A move was commanded on an axis that was never enabled, or a real fault latched. Acknowledge the error, re-enable, then command again.
• Advanced block works only after the basic instances are deleted. Two instances were fighting over one axis array, and the fix is ownership.
• Error output true, nonzero code, motor dead. The block attempted an action and the controller refused it. Decode the code before changing any wiring.

Which inputs must be true before the enable will latch?

Two, on the standard pattern: a master enable and a direction enable, both triggered after download, with any earlier error acknowledged. IEC 61131-3 compliant motion blocks run the same axis state machine, and an axis sits in Disabled until those conditions hold.

The motion blocks in IEC 61131-3 drive an axis through a state machine of nine states, from Disabled and Standstill through Homing, Discrete Motion and Continuous Motion to ErrorStop. During commissioning you live in three of them: Disabled, with the drive stage off; Standstill, powered and waiting for a command; and ErrorStop, latched after any error until an acknowledge input clears it. The master enable moves the axis from Disabled to Standstill when no error is pending, and the direction enables gate which way it may run. When the block's status output stays false the drive stage stays off, which is exactly the dead line you measured. One trap catches most first attempts: command inputs in these blocks trigger on a rising edge, so an input wired TRUE since download never fires. Set the command after the state word reads Standstill.

How do you read the block's actual state and error code?

From the block's own outputs, not from the motor's behavior. Expose the state word, the error flag and the error code as variables and log all three every scan, because the transition between scans is the diagnostic.

A state word still reading Disabled after 100 scans of a 10 ms task, one full second, is a wiring fault. A state that left Standstill for ErrorStop the moment you commanded tells you the command arrived and was refused. Decode any nonzero code against the vendor's code list for that library revision, the same method as PLC fault code decoding for drive diagnostics. A small screen at the machine showing the three values saves the walk back to the laptop: a read-only process display is the pattern, and shop-floor display options cover the hardware.

Why must only one block own the axis during the test?

Because both instances write the same 11-byte axis array every scan and the last writer wins. With a 10 ms task, a typical motion task period, the basic block overwrites the advanced block's command bytes 100 times per second, so the card never sees a valid advanced command.

Which instance wins comes down to PLC execution order across task layers: the block that runs last in the scan owns the card. Disable or delete the basic instances in the test program and declare a fresh axis array for the advanced block, so a working basic command can no longer mask a dead advanced one. Reading position through a second instance is harmless; two instances commanding one array is the fault.

How do you verify the wiring against the installed library?

Pin by pin, in the declaration of the exact library revision installed. Every connected variable checked against the formal parameter name, type and direction, because advanced blocks add inputs over their basic versions and a copied wire lands on the wrong pin.

Open the block's declaration in the development environment and work the pin list top to bottom. The advanced block carries more inputs than the basic block, and the exact count and meaning live in your declaration; a wire copied from the basic block will land on a pin with a similar name and a different job. Guessing a pin's meaning from its name is how the enable ends up dead. A screenshot from another project helps only when its controller, card, library revision and block name all match yours, and the block name itself has variants across revisions, so the declaration on your disk is the authority. Where a pin stays unclear, the vendor's function block manual and sample projects for that exact revision are the supported source; request them from the vendor's support line if the documentation portal is thin.

What does an example single-axis enable test look like?

Axis 3 of 4, one advanced block instance, one fresh 11-byte array, a 10 ms task: trigger the enable, watch the state word for one second, jog at 200 pulses per second for 5 seconds, and expect the position counter to read 1000 pulses.

Uncouple the load if the mechanics allow it, then work the sequence:

1. Disable or delete the other three motion instances in the test program.
2. Declare one fresh 11-byte axis array and bind the advanced block to it.
3. Wire the enable inputs from the declaration and trigger them after download, so the block sees a rising edge.
4. Watch the state word: it should leave Disabled for Standstill within one or two scans of the enable, and the drive stage puts power on the line.
5. Jog at 200 pulses per second for 5 seconds: 200 × 5 = 1000 pulses, and the position counter should read 1000.

Pick the jog value at about 10 percent of working speed if you know it, slow enough to stop a small axis by hand. If the counter reads 1000, the command path is closed and you scale back to all four axes. If the state word shows a motion state but the counter stays at 0, the fault is downstream of the block: the card's output stage or the wiring between card and drive. If the state never leaves Disabled, go back to the enable pins.

One safety point: the shaft can turn the moment the state leaves Disabled, so keep hands, fixtures and product out of the travel before you trigger the enable.

What if the advanced block still will not enable?

Then the cause sits outside your wiring: a library revision whose signature differs from the documentation you wired against, an error latched on the card itself, or a controller and card pairing the block was never written for, in that order of likelihood.

Confirm the library revision and re-check the wiring against its declaration. Clear errors on the card if it exposes its own status words. Confirm the controller and card pairing is on the block's supported list in the manual, and request the function block manual plus a sample project for your exact revision from the vendor's support line; suppliers provide both, and the sample is a wiring reference you can compare line by line against your own declaration. After any library update, repeat the single-axis jog test before the machine goes back to work.

Recommendation: Commission the advanced block on one axis with its own 11-byte array and every other motion instance disabled, wire only from the installed declaration, and treat a state word stuck in Disabled with error code 0 as a wiring fault and any nonzero code as a decode-first item. Scale to all four axes only after the single-axis jog counts out.

Questions