Homing sequence inside .comp

Code is available on GitHub

Axis A is not defined, only stepgen parameters are configured inside .hal and passed to toolchanger.comp
Limit switch on A:
Since axis A is not part of joint 3 and is only accessible inside .comp - I also need to find a way to run a homing sequence from inside of toolchanger.comp. All proper speed, offset etc. are configured inside .ini and homing squence has been tested on this axis in a separate configuration.

Is there an easy way to maybe import homing.c ?
Or maybe it is possible to setup A axis as a joint ? and then maybe call homing with something like set_home_start(...) ?

This post originated in general question, where it as partially solved:
forum.linuxcnc.org/38-general-linuxcnc-q...0-atc-problem#208806

Is the axis in question stepper-controlled? What does it home to?

You can add a pin to your component "homing command" and do something appropriate when the system sets it high. If the toolchanger isn't itself a joint then you could simply choose to home it at the same time as Z, or maybe trigger from the Z "is-homed" pin to do it after Z is finished.

You can either keep a home-offset as a static variable inside the component, or (if using a recent Mesa stepgen) zero the stepgen feedback at the current position.

For reference, homing is implemented in the latest version of the press.comp in this thread: forum.linuxcnc.org/30-cnc-machines/42100...ions?start=60#208433

andypugh wrote: Is the axis in question stepper-controlled? What does it home to?

Part of the problem that A is not an axis at all.

Quote from original post :

This does not need an A axis it is all done in the toolchanger.comp. But it does require stepgens so will need an extra set in the hal file. The ATC stuff is at the bottom of the hal file

And original .comp is written for "position control" - but actual axis / joint requires it to be velocity control.

So from what I can see, I should re-write component in order to have A as an regular axis. Then I can just home it as part of the regular homing sequence and control it from .comp using axis_pos_cmd_out(0)

Dose it sounds like a right path to take?

gcardinal wrote: So from what I can see, I should re-write component in order to have A as an regular axis. Then I can just home it as part of the regular homing sequence and control it from .comp using axis_pos_cmd_out(0)
Dose it sounds like a right path to take?

No, in fact I don't think that that will work.

Just have a homing state inside your .comp

andypugh wrote: ...
Just have a homing state inside your .comp

So just home it manually? move the axis until I get a hit on the limit switch and latch it etc?

What do you mean by "Manually"? Just have the .comp respond to a "home-now" pin then when that pin changes from low to high it can output a constant homing velocity output until it sees {whatever tells it that it is homed}

andypugh wrote: ... Just have the .comp respond to a "home-now" pin then when that pin changes from low to high it can output a constant homing velocity output until it sees {whatever tells it that it is homed}

New attempt - I did the following:
HAL
- Signal for when X or Z axis are homing (axis-homing)
- Signal for when X and Z axis are homed (axis-homed)

.comp
- Monitor change to axis-homing and invalidate previous ATC homing state
- Monitor change to axis-homed, wait a few seconds and start ATC homing

Next step would be:
- Link pin for limit switch on ATC
- Write code to move ATC to the limit switch, latch, back-it off.
- etc.

Does it looks like the right path?

PS: Sorry for me being thickheaded and thank you for helping.

A few pointers:

1) A realtime comp is passed a variable "fperiod" which is the time elapsed since it last ran.

2) Realtime comps are often best written as a state-machine. This just means that there is a variable that determines the current state, and various rules for changing state.

A (very) simple state-machine with a timeout might look like this:
Take a look at the HAL "carousel" component for an example if this structure in the context of a toolchanger (and including homing)

andypugh wrote: A few pointers:
1) A realtime comp is passed a variable "fperiod" which is the time elapsed since it last ran.
2) Realtime comps are often best written as a state-machine. This just means that there is a variable that determines the current state, and various rules for changing state.
...

Thank you for the help and feedback. I have switched to state-machine and implemented delay using fperiod. Also homing sequence is now working and locking tool in nearest position.

There just a few issues left:
- I would like to slow down during home latching and turret locking sequence. I can't figure out how to move at different speeds.
- Since after homing and locking the tool, actual position of the turret and logical are out of sync (due to lost steps when moving into locking position and hitting "stop"). Is it okay to take value of .stepgen.02.position-fb as an starting point / zero and move tools from it?

I can think of a couple of ways to alter the speed. You could add a pin that connects to the stepgen velocity limit pin, and change the value of that.

More conventional would be to increment the position command at a fixed velocity:

Something like: