Axis cannot be put into modeAH after resetting the error

[AndroidzZ]

Axis cannot be put into modeAH after resetting the error

I have a program where the axis sometimes goes into error. After the axis is in error state I want to reset the axis and then put it back in ModeAH and continue the program where it left off.

What is now the case, after resetting the error the error disappears but the axis remains in ModeAB despite that I try to put it directly in ModeAH with a command. Also the forcing of the ModeAH the axis does not respond. This problem occurs in VIRTUAL but also on the CORE. Is there something i am missing or is there another explanation? 

See pic for command i am sending to the axis after resetting.

P.S. the error that occurs is the same as i explained in this topic: https://developer.community.boschrexroth.com/t5/ctrlX-MOTION/Motion-error-when-y-axis-follows-x-axis... but this time i'am not using a virtual machine.

[CodeShepherd]

Does your program try to switch to AH already when the axis is still in error? Or other way around after your error is the axis command already AH? The motion interface will only do a new commanding when there is a change in the command or you set the retriggeropmode to true.

Is there an error in the diagnostic log when you try to switch the state?

Please contact me directly so we can have a look on your program.

[AndroidzZ]

No i dont switch to AH when in error or the other way around. And no ,there is no log of trying to change state.

I send logs with trace active. One log is without dev info and without system-messages

[CodeShepherd]

Please also add a system report of your ctrlX CORE:

I will get in contact with you.

[AndroidzZ]

Here you go. 

[CodeShepherd]

Sorry for the late reply. We did some investigations and improved the motion interface (axis and kinematics interface) to be more robust on customer usage. This update will release in the RM21.07 (version 1.10) end of July.

I will get in contact with you to get a test version.

[CodeShepherd · Accepted solution]

After some more joint investigation with the test version of the motion interface we found that the problem seems to be caused by a commanding with a too high velocity that was then limited by the set motion limits and resulted in a too low speed. So the axes couldn't quite following the commands.

EDIT: I also want to add the note, that this application can/will lead to strange movement. The motion command always plan with an end velocity of 0 mm/s (full stop at the target position). This means, when a motion with a length of 15 µm is commanded and the acceleration is 25 mm/s², it will only get to a velocity of ~0,875 mm/s. When you have a higher initial velocity (because its a non-buffered command), this will lead to an overshoot. This means, the ctrlX MOTION breaks with the allowed limit deceleration, changes the direction and moves back to the target position.

Currently, there is no way implemented to command cyclic set points to the ctrlX MOTION.