Need help Homing sequence in H-bot( CoreXY) system
- Todd Zuercher
-
- Away
- Platinum Member
-
Less
More
- Posts: 4963
- Thank you received: 1369
28 Jun 2019 12:17 #138112
by Todd Zuercher
Replied by Todd Zuercher on topic Need help Homing sequence in H-bot( CoreXY) system
A better place to ask this question may be on the developers mail list.
Please Log in or Create an account to join the conversation.
28 Jun 2019 12:44 #138114
by nbremond
Replied by nbremond on topic Need help Homing sequence in H-bot( CoreXY) system
OK. Thanks
Please Log in or Create an account to join the conversation.
30 Jun 2019 13:44 - 30 Jun 2019 13:47 #138235
by andypugh
That might work, but it would involve diving in to code that is currently working well and that it is hard to test without a vast collection of real hardware. I am not saying that it couldn't be done, but it would be really hard to be confident that it hadn't broken something out there in the real world of installed machines.
If you look at the corexy sample config, that is set up for immediate homing, which gives two (not entirely elegant) solutions.
A.) Push the tool to a known position against hard-stops with the power off and home-all
B.) (After offline discussion with Dewey, this sequence can be demonstrated in the corexy sim config provided as part of the LinuxCNC installation)
The jog moves could be configured as probe moves as part of a scripted homing sequence (probably in Python). The key here is that when set for immediate homing home-all sets the current position to home and also switches immediately in to world-mode and out of joint-mode.
C.) We think that having joint.N.is-homing inputs to coreXYkins would also work. In that situation corexykins would drive the axes in the coordinated mode even though it was still in joint mode, but only if the is-homing input was set. This is actually equivalent to your suggestion of calling a different kins mode during homing, but moves the decision logic in to the kins rather than homing.c
I want to try this but would need to build a coreXY machine to test it on. This is something I have actually considered doing several times, but I don't see it happening in days, more like months-if-ever.
Replied by andypugh on topic Need help Homing sequence in H-bot( CoreXY) system
One idea I'am looking at coul be to add a configuration parameter in the INI file to choose between homing on joints, or on world XYZABCUVW.
The idea behind is to allow the homing.c code to optionally call the "InverseKinematics" function while homing in order to allow to move all joints according to the machine architecture as described in the kins files (like corexykins.c for me).
That might work, but it would involve diving in to code that is currently working well and that it is hard to test without a vast collection of real hardware. I am not saying that it couldn't be done, but it would be really hard to be confident that it hadn't broken something out there in the real world of installed machines.
If you look at the corexy sample config, that is set up for immediate homing, which gives two (not entirely elegant) solutions.
A.) Push the tool to a known position against hard-stops with the power off and home-all
B.) (After offline discussion with Dewey, this sequence can be demonstrated in the corexy sim config provided as part of the LinuxCNC installation)
The procedure is a little tricky:
1) Machine on, Estop off
2) Home-All (immediate), auto-switches to teleop mode with X=0,Y=0
3a) teleop jog X to 'X-home-switch' position (do not alter Y=0)
3b) Home All
4a) teleop jog Y to 'Y-home-switch' position (do not alter X=0)
4b) Home-All
Notes:
a) Home-All or executing distinct home joint 0, home joint 1 will work
b) the X,Y order does not matter, e.g., sequence 3a,b and 4a,b can be switched
and you could teleop jog to desired X AND Y position
and Home-All
The jog moves could be configured as probe moves as part of a scripted homing sequence (probably in Python). The key here is that when set for immediate homing home-all sets the current position to home and also switches immediately in to world-mode and out of joint-mode.
C.) We think that having joint.N.is-homing inputs to coreXYkins would also work. In that situation corexykins would drive the axes in the coordinated mode even though it was still in joint mode, but only if the is-homing input was set. This is actually equivalent to your suggestion of calling a different kins mode during homing, but moves the decision logic in to the kins rather than homing.c
I want to try this but would need to build a coreXY machine to test it on. This is something I have actually considered doing several times, but I don't see it happening in days, more like months-if-ever.
Last edit: 30 Jun 2019 13:47 by andypugh.
Please Log in or Create an account to join the conversation.
30 Jun 2019 18:20 #138245
by andypugh
Sorry, this was a misunderstanding on my part.
Kinematics is not involved in homing at all, so this is a non-starter.
A system of mux2 components driven by "is-homing" HAL pin might be a solution, or a custom HAL component to do the same thing.
Consider a HAL compionent that takes as input joint.0.motor-pos-cmd, joint.1.motor-pos-cmd and the homing state for each joint.
if homing state is 0 for both then in = out for both joints.
if J0 is homing then half the delta in J0-cmd from the point where homing started is sent to each output (one inverted) and the same (but different calcs)in the other case.
A reverse path for the feedback value would also be required to prevent f-error.
Flags on the joints (could be a hole drilled through the belt for an opto sensor) might be easier, though.
Replied by andypugh on topic Need help Homing sequence in H-bot( CoreXY) system
C.) We think that having joint.N.is-homing inputs to coreXYkins would also work.
Sorry, this was a misunderstanding on my part.
Kinematics is not involved in homing at all, so this is a non-starter.
A system of mux2 components driven by "is-homing" HAL pin might be a solution, or a custom HAL component to do the same thing.
Consider a HAL compionent that takes as input joint.0.motor-pos-cmd, joint.1.motor-pos-cmd and the homing state for each joint.
if homing state is 0 for both then in = out for both joints.
if J0 is homing then half the delta in J0-cmd from the point where homing started is sent to each output (one inverted) and the same (but different calcs)in the other case.
A reverse path for the feedback value would also be required to prevent f-error.
Flags on the joints (could be a hole drilled through the belt for an opto sensor) might be easier, though.
Please Log in or Create an account to join the conversation.
30 Jun 2019 20:19 #138254
by nbremond
Replied by nbremond on topic Need help Homing sequence in H-bot( CoreXY) system
Hello,
Thanks a lot andypugh for your proposal. I really appreciate it a lot.
Concerning modifying homing.c, I understand your concerns about fully validating any modification in this part of the code. After looking at homing.c, the idea was to keep the state machine as is, and to process the joints commands through InverseKinetics or not, depending on a new option to be added to the INI file, in the homing section. This would require to modify home_start_move and home_do_moving_checks functions, and probably a little more...
Anyway, what you proposed is much easier to manage (no linuxcnc code to compile)... I like the 2nd option C.
I'll think about it and try to make a test as soon as possible in the next few days. I'll keep you posted.
Thanks for your help.
Best regards,
Bernard
Thanks a lot andypugh for your proposal. I really appreciate it a lot.
Concerning modifying homing.c, I understand your concerns about fully validating any modification in this part of the code. After looking at homing.c, the idea was to keep the state machine as is, and to process the joints commands through InverseKinetics or not, depending on a new option to be added to the INI file, in the homing section. This would require to modify home_start_move and home_do_moving_checks functions, and probably a little more...
Anyway, what you proposed is much easier to manage (no linuxcnc code to compile)... I like the 2nd option C.
I'll think about it and try to make a test as soon as possible in the next few days. I'll keep you posted.
Thanks for your help.
Best regards,
Bernard
Please Log in or Create an account to join the conversation.
01 Jul 2019 11:44 - 01 Jul 2019 11:45 #138292
by nbremond
Replied by nbremond on topic Need help Homing sequence in H-bot( CoreXY) system
Hello,
2 Quick questions:
- Is there any drawback (issue), for a CoreYX machine, using the trivial kinematics in the INI file settings (instead of corexykins) and performing the forward and inverse required transformations (X, Y <--> joint.0, joint.1) directly in the custom.HAL file ? I this case, I'll not need the 'is-homing' signal as the required transformation will be enabled all the time.
- I have not found the "is-homing" pin or signal in the HAL documentation (linuxcnc v2.9). Does it exists or do I have to build it ? Using what existing HAL pins ?
Thanks in advance for your help.
Best regard, Bernard.
2 Quick questions:
- Is there any drawback (issue), for a CoreYX machine, using the trivial kinematics in the INI file settings (instead of corexykins) and performing the forward and inverse required transformations (X, Y <--> joint.0, joint.1) directly in the custom.HAL file ? I this case, I'll not need the 'is-homing' signal as the required transformation will be enabled all the time.
- I have not found the "is-homing" pin or signal in the HAL documentation (linuxcnc v2.9). Does it exists or do I have to build it ? Using what existing HAL pins ?
Thanks in advance for your help.
Best regard, Bernard.
Last edit: 01 Jul 2019 11:45 by nbremond.
Please Log in or Create an account to join the conversation.
01 Jul 2019 11:58 #138293
by andypugh
But then this is also the case with my suggested HAL component. In fact I think that there is a good argument that your suggestion is a simpler and better solution than my HAL-layer suggestion.
Replied by andypugh on topic Need help Homing sequence in H-bot( CoreXY) system
The main drawback is that following-error tracking is problematic, as the motor positions are not the same as the system is expecting.Is there any drawback (issue), for a CoreYX machine, using the trivial kinematics in the INI file settings (instead of corexykins) and performing the forward and inverse required transformations (X, Y <--> joint.0, joint.1) directly in the custom.HAL file
But then this is also the case with my suggested HAL component. In fact I think that there is a good argument that your suggestion is a simpler and better solution than my HAL-layer suggestion.
joint.N.homing - linuxcnc.org/docs/2.8/html/man/man9/motion.9.html (I misremembered the pin name)I have not found the "is-homing" pin or signal in the HAL documentation (linuxcnc v2.9). Does it exists or do I have to build it ? Using what existing HAL pins ?
Please Log in or Create an account to join the conversation.
01 Jul 2019 14:06 - 01 Jul 2019 14:09 #138301
by nbremond
Replied by nbremond on topic Need help Homing sequence in H-bot( CoreXY) system
OK. thanks,
I'll give it a try (maybee tonight) using the following HAL function (using comp) I wrote:
And connect it between the path calculations, and the PID that has been defined for each joint (steppers) driven by my mesa 7i96 board.
This HAL function perform the same calculation as in the corexykins (forward and inverse)
I hope this will be OK !
I'll give it a try (maybee tonight) using the following HAL function (using comp) I wrote:
component corexy;
pin out float joint0_;
pin out float joint1_;
pin out float x_;
pin out float y_;
pin in float X;
pin in float Y;
pin in float JOINT0;
pin in float JOINT1;
function _;
description """
Perform the required coreXY forward and inverse transformations in the HAL, instead of using the KINEMATICS option of the INI file.
Please set
KINEMATICS = trivkins coordinates=XYZ
in the INI file.
""";
license "GPL"; // indique la GPL v2 ou suivantes
;;
FUNCTION(_) {
joint0_ = X + Y;
joint1_ = X - Y;
x_ = 0.5*(JOINT0 + JOINT1);
y_ = 0.5*(JOINT0 - JOINT1);
}And connect it between the path calculations, and the PID that has been defined for each joint (steppers) driven by my mesa 7i96 board.
This HAL function perform the same calculation as in the corexykins (forward and inverse)
I hope this will be OK !
Last edit: 01 Jul 2019 14:09 by nbremond.
Please Log in or Create an account to join the conversation.
01 Jul 2019 18:12 #138323
by pl7i92
Replied by pl7i92 on topic Need help Homing sequence in H-bot( CoreXY) system
the Hexapot kinetics can perform a Angel move
as 0,5(joint0 "" joint1) is a angeluar movement discription
most at 45 deg calculation
so the standard g-code woudt do a great performence on a setup with hexapod kinetik
as 0,5(joint0 "" joint1) is a angeluar movement discription
most at 45 deg calculation
so the standard g-code woudt do a great performence on a setup with hexapod kinetik
Please Log in or Create an account to join the conversation.
01 Jul 2019 21:33 #138333
by nbremond
Replied by nbremond on topic Need help Homing sequence in H-bot( CoreXY) system
Hello,
@andypugh
I did some test tonight, and the HAL module I wrote with your help is working fine... at least at reasonable speed.
The homing is working also, along X and then along Y. This is a good news
I have attached to custom.hal and the corexy.comp files.
At higher speed (> 7000mm/mn), I get tracking errors on joint 0 and 1.
Do you any advise on how to investigate and fix tracking errors ? May this be due to the PID tuning ?
Thanks in advance.
@andypugh
I did some test tonight, and the HAL module I wrote with your help is working fine... at least at reasonable speed.
The homing is working also, along X and then along Y. This is a good news
I have attached to custom.hal and the corexy.comp files.
At higher speed (> 7000mm/mn), I get tracking errors on joint 0 and 1.
Do you any advise on how to investigate and fix tracking errors ? May this be due to the PID tuning ?
Thanks in advance.
Please Log in or Create an account to join the conversation.
Time to create page: 0.121 seconds