Homing sequence inside .comp
14 May 2021 14:08 - 14 May 2021 14:14 #208807
by gcardinal
Homing sequence inside .comp was created by gcardinal
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
Axis A is not defined, only stepgen parameters are configured inside .hal and passed to toolchanger.comp
net apos-cmd toolchanger.position-cmd => hm2_7i76e.0.stepgen.02.position-cmd
net toolchanger-stepgen-fb <= hm2_7i76e.0.stepgen.02.position-fb => toolchanger.stepgen-pos-fbLimit switch on A:
net home-a <= hm2_7i76e.0.7i76.0.0.input-02Since 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
Last edit: 14 May 2021 14:14 by gcardinal.
Please Log in or Create an account to join the conversation.
14 May 2021 15:12 #208810
by andypugh
Replied by andypugh on topic Homing sequence inside .comp
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
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
The following user(s) said Thank You: gcardinal
Please Log in or Create an account to join the conversation.
14 May 2021 16:36 - 14 May 2021 16:37 #208818
by gcardinal
Part of the problem that A is not an axis at all.
Quote from original post :
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?
Replied by gcardinal on topic Homing sequence inside .comp
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?
Last edit: 14 May 2021 16:37 by gcardinal.
Please Log in or Create an account to join the conversation.
14 May 2021 17:12 #208825
by andypugh
No, in fact I don't think that that will work.
Just have a homing state inside your .comp
Replied by andypugh on topic Homing sequence inside .comp
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
Please Log in or Create an account to join the conversation.
14 May 2021 17:50 #208829
by gcardinal
So just home it manually? move the axis until I get a hit on the limit switch and latch it etc?
Replied by gcardinal on topic Homing sequence inside .comp
...
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?
Please Log in or Create an account to join the conversation.
14 May 2021 18:07 #208832
by andypugh
Replied by andypugh on topic Homing sequence inside .comp
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}
Please Log in or Create an account to join the conversation.
15 May 2021 12:13 #208907
by gcardinal
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.
Replied by gcardinal on topic Homing sequence inside .comp
... 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.
Please Log in or Create an account to join the conversation.
15 May 2021 12:36 - 15 May 2021 12:37 #208908
by andypugh
Replied by andypugh on topic Homing sequence inside .comp
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)
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:
component state;
param r signed state = 0;
pin in bit trigger;
;;
static bool old_trigger = 0;
static float timer;
switch (state){
case 0: // waiting
if (trigger && trigger != old_trigger){
timer = 1.2;
state = 1;
}
break;
case 1: // doing thing
timer -= fperiod;
if (timer <= 0){
state = 0;
}
break;
default:
rtapi_print_msg(RTAPI_MSG_ERR, "Ooops!");
}
old_trigger = triggerTake a look at the HAL "carousel" component for an example if this structure in the context of a toolchanger (and including homing)
Last edit: 15 May 2021 12:37 by andypugh.
The following user(s) said Thank You: gcardinal
Please Log in or Create an account to join the conversation.
17 May 2021 10:23 #209207
by gcardinal
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?
Replied by gcardinal on topic Homing sequence inside .comp
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?
Please Log in or Create an account to join the conversation.
17 May 2021 14:35 #209229
by andypugh
Replied by andypugh on topic Homing sequence inside .comp
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:
More conventional would be to increment the position command at a fixed velocity:
Something like:
case HOMING_LATCH:
if (atc_limit) {
position_cmd += 1;
} else {
if (position_cmd < target_pos){
position_cmd += latch_velocity * fperiod;
} else {
position_cmd = target_pos;
if (delay == false) {
timer = LOCKING_DELAY;
delay = true;
}
event = HOMING_FINISH;
}
}
break;
The following user(s) said Thank You: gcardinal
Please Log in or Create an account to join the conversation.
Time to create page: 0.089 seconds