Motion functions like Axis::MoveSCurve execute asynchronously, with the MOTION_DONE event generated on their completion, which works well in event-driven architectures. But Axis::Home executes synchronously, blocking the thread from which it’s called until homing has completed. Why is there that difference in behavior?
The MotionDoneWait function enables blocking on motions, for cases in which that behavior is desired. Why doesn’t homing offer both options as well?
Home() is a collection of moves, checking state, waiting for motion done, and configuration of limits rather than a single motion profile kick off. Depending on the home method selected, we will move 0-3 times. All of which could be duplicated yourself using our API. If you’d like a different homing behavior set than those provided, we can help you setup a custom homing routine.
And yet, you’ve (thankfully) hidden all of that complexity under the hood of the single call to Home(), much as you’ve hidden the complexity of the acceleration, deceleration, and constant velocity phases of MoveSCurve().
Clearly your underlying code knows when all the phases of a particular homing operation are completed (else it couldn’t be wrapped up so neatly in a single API call) and could generate a single event to mark that. If you still wanted to provide separate MOTION_DONE events for each homing phase, then that could be a new “HOMING_DONE” event. (Or better yet, use a new “HOMING_PHASE_DONE” event for each homing phase, with the same MOTION_DONE event used to indicate the completion of the entire homing operation.)
That would make the API more consistent and relieve its consumers of the responsibility to create their own separate threads, and separate events, etc., just to make homing as non-blocking as other motions.
It is possible but fairly involved given the way some of the underlying code works. I’d like to see some sort of blocking feature in which gave a warning while Home() was in process if we removed to asynq Home().
What you are asking for is possible with the existing api. I can help you get with the necessary changes. Here is our Custom Homing example. We can use it and a variety of options to signal and execute whatever behavior you are looking for.
Can you describe the behavior sets you are looking for?
That approach in the Custom Homing example looks nice and also completes after a single MOTION_DONE event. Does that mean that to handle asynchronously a single homing in that way, via a homing method that uses “a collection of moves…”, one would need a collection of MoveVelocity() calls and a collection of waits for MOTION_DONE events with specific handling?
As far as the behavior set we’re looking for, it’s basically just to be able to call Home() and immediately return, in order to handle other events that may come in while awaiting the completion of homing, just as we can do with the other motion commands.
To retain the synchronous option, the API could provide a “HomingDoneWait()”, again consistent with the way moves work.
I know we can do almost anything (with more or less work 
via your API – I’m just suggesting that it could be made more symmetric and thereby easier to use, for all of us lazy consumers.
The collection of moves comes from the following.
Some of the Homing Methods require that your final approach of the limit is from the positive or negative direction.
Some of them require seeking an index pulse after finding the limit switch.
Sometimes might you hit a POT or NOT and need to turn around to find the limit.