Motion callable has not reached "RUN"

[DdG]

Hi,

I'm having the same issue as listed above. I followed the links to the threads/topics you mentioned but it didn't solve my problem.

When i boot the CORE, the motion app is stuck in Configurating/Running and the axis states are OUTDATED. Setting the Motion app to Running doesn't work. The state changes to Booting but after a couple of minutes an error pops up and the state goes back to Configuration/Running.

When I set the main operating mode from partially operating to Operating the motion app does start and the state changes to Running (both the motion app and the main operating mode of the CORE)

The help provided says it could heve to do something with the scheduler, but i don't see any differences between the partially operating state and the running state of the core.

[CodeShepherd]

Moved to own topic from this one.

Could please check the "Configuration" tab of the scheduler and add a picture? Especially check the priority of the "motionHighPrep" task. it should be different e.g. 24 to the one of "ctrlXAutomation" e.g. 23.

See also our online documentation for the error 090F0053 Error in system configuration/0C56020D Motion callable has not reached "RUN" state during bootup.

Best case would be to switch on traces of the motion core and the axisprofile via the data layer (see e.g. here how to do so) and create a system report directly after the error occurred, that would be quite helpful. It can be found via the question mark symbol in the ctrlX CORE web UI.

[DdG]

Update:

This only happens when I switch on the mains on the whole cabinet CtrlX CORE + 2 Ctrlx Drives. If i just power up the CORE when the drives are already powered and ready, the motion app is started correctly.

Is it possible to delay the starting of the motion app or something like that?

[CodeShepherd]

ctrlX Motion app booting cannot be delayed. But to understand what really happens please give us some more information like mentioned in my post above.

[DdG]

The task have different priorities.

I've added a system report, I hope this helps.

[CodeShepherd]

We could not find problems in your system setup but as the report seems to created to long after the error occurred we cannot see anything about it in the logbook.

Could you please:

1. switch on the traces like mentioned above
2. save your active configuration (app data)
3. generate error
4. download all logbook messages directly afterwards, including system messages and developer information

[DdG]

I have uploaded a new system report (of the last 6 hours). can you find soething in this?

[CodeShepherd]

There is only one motion error present in the logbook but not the one we are looking for:

motion/axs/X_axis

091F2002

0C550101

General axis command error

Device error - power failed

AddInfo: error result of setPowerMode(): 0xF000000F

The earliest entry is 2023-05-24 06:15:31 and latest 2023-05-24 06:23:07. Please keep in mind that the logbook is designed as a ring buffer and is by standard setting cleared while bootup.

[DdG]

My, bad. let's try this again

[CodeShepherd]

Let us have a try together. Please send me a private message with your contact data so we can arrange an online meeting.

[CodeShepherd]

After an online investigation some information:

• Main topic seems to be that axisprofile needs quite a long time to boot up because of waiting for EtherCat going to OP.
• The PLC also did a lot of asynchronous access to some slaves, this behavior may block axisprofile for a while. Because fieldbus async assess is limited by mailbox (3 mailbox same time). Best would be to delay PLC start to do such accesses.
• We will implement some improvements to better handle your case. This patched version of 1.20 will release end of July and we recommend to use this version.

[DdG]

So if I understand it correctly:

I need to delay/disable the ethercat connection from the plc until the ethercat becomes operational? can this be done in the CORE with the scheduler e.g. or do i need to do this from the PLC app itself?

[CodeShepherd · Accepted solution]

It seems that your application code in the PLC is doing that requests. Do you use any EtherCat based drive access function blocks like IL_ECATSoeRead? These could be delayed to improve the behaviour.