Configuring SoftMotion Axis Tasks to Prevent FB Aborts

After the axis objects were assigned explicitly to MainTask, the motion function blocks stopped aborting. The commissioning rule is direct: the EtherCAT master, each real axis, its linked virtual axis, and the motion logic must execute in one coherent task context. A correct axis tag does not compensate for a mismatched cycle assignment.

What is the screen telling you?

The operator sees motion function blocks abort even though the axes can move and the virtual-to-real links appear correct. Treat that combination as a scheduling problem before changing motion parameters. An abort indicates that a command was accepted or evaluated but could not continue under the active execution conditions; it does not automatically identify a drive, scaling, or trajectory fault.

Keep the existing motion profile unchanged during this check. Changing acceleration, velocity, or command sequencing at the same time can conceal the scheduling fault. The first proof is that the abort correlates with different task identities, not with a particular move value.

Which task is running the EtherCAT master?

Start at the driver layer. The EtherCAT master was assigned to MainTask. That assignment establishes the controller task responsible for the master's cyclic processing in this configuration. Axis objects that inherit a different effective cycle will not share the same execution context merely because they are located below the master in the device tree.

1. Open the EtherCAT master configuration.
2. Record its assigned task; for this configuration, it is MainTask.
3. Run the motion program and evaluate IecTaskGetCurrent() from the code that calls the motion FBs.
4. Confirm that the current task is the intended MainTask, rather than a different application task.

The checkpoint is a single named task for both master processing and motion-FB calls. If the calls run elsewhere, move the program call or revise the task architecture before changing any axis object.

How should each axis cycle be assigned?

The failing configuration used Use parent bus cycle on the axis objects while the EtherCAT master was set to MainTask. Debug inspection showed that the axis hTask differed from the result returned by IecTaskGetCurrent() in MainTask. Assigning every axis explicitly to MainTask removed the aborts.

Two scheduling patterns can be valid in a cyclic motion architecture. All motion objects can inherit a common parent cycle when the inheritance chain resolves to the task that runs the motion logic, or all relevant objects can be assigned explicitly to that task. For this configuration, explicit MainTask assignment is the better choice because it matches the EtherCAT master, matches the calling program, and avoids an inherited task identity that already proved different.

1. Open the configuration for the first real axis.
2. Replace Use parent bus cycle with MainTask.
3. Repeat the change for every other real axis.
4. Inspect every linked virtual axis separately and assign MainTask where its cycle is configurable.
5. Rebuild and download the changed configuration using the normal project workflow.

Do not stop after correcting the axis that first reported an abort. One object left on an inherited cycle can make the failure appear command-dependent. The checkpoint is a complete axis inventory with no unintended inherited assignments.

Why must virtual and real axes be checked separately?

A virtual axis supplies a motion state and command path; a linked real axis connects that motion model to physical cyclic processing. The object link describes their functional relationship, not necessarily their task ownership. The tag is right; the binding is wrong when the application references the intended object but that object executes under a different cycle.

Check the entire chain in that order. If an object has no explicit task selector, trace the parent-cycle inheritance until it resolves to a configured task. The proof before running motion is that every configurable object names MainTask, and every inherited object resolves to that same task.

How can the program detect a forgotten task setting?

IecTaskGetCurrent() identifies the task executing the checking code; it does not identify the task owned by an arbitrary axis object. The observed axis task value, hTask, is private, so application logic should not bind to it as though it were a public axis property. Private implementation fields can be useful in a debug window but are not a stable commissioning interface.

Build the safeguard around configuration control and observable behavior:

1. Place all motion-FB calls in the intended motion program under MainTask.
2. At startup or during commissioning, call IecTaskGetCurrent() from that program and compare the result with the stored identity captured for the intended task.
3. Treat a mismatch as an application scheduling fault and inhibit new motion commands.
4. Maintain a commissioning checklist covering the EtherCAT master, every real axis, and every virtual axis.
5. Use the debug view to compare each axis hTask with the IecTaskGetCurrent() result after configuration changes.

This runtime check proves where the motion code is executing, while the configuration review proves where the axes are assigned. It cannot replace axis-side inspection because the program has no stated public accessor for the private hTask member. The checkpoint is a passing current-task comparison plus matching axis task values in the debug view.

How do you verify the complete motion path?

Verify one layer at a time so an abort cannot be mistaken for a command-profile problem.

1. Confirm the EtherCAT master remains assigned to MainTask.
2. Confirm the motion program reports the expected task through IecTaskGetCurrent().
3. Inspect the debug hTask value for each real and virtual axis; compare each value with the current-task result.
4. Issue the same motion command that previously aborted.
5. Observe the motion FB state through acceptance, execution, and completion. Record any abort indication before issuing another command.
6. Repeat the test for every virtual-to-real axis pairing, not just the first corrected axis.
7. Restart the application through the normal commissioning sequence and repeat the command to prove that the assignment survives initialization.

The final verification passes when the master, motion logic, real axes, and virtual axes share MainTask, their task identities agree during debugging, and the previously failing motion FB completes without aborting.

FAQ