Homing and limits with X axis 2 joints
04 Oct 2013 19:22 #39541
by Clive S
Homing and limits with X axis 2 joints was created by Clive S
Hi all.
I have been a lurker here for some time
Now I am in need of some TLC with a homing and gantry squaring problem.
I have a router type gantry machine with 3 axis but on the X axis I have 2 motors (joints) with prox.switches 1 on Z, 2 on Y and 4 on X.
I have got all this to home and limit using just 1 pin on the bob but only driving the x with one motor (the other with the belt off and switches not connected)
This all works fine.
Now comes the problem how do I connect the other x motor (joint ) so that the x axis will home together and square the gantry.
Also be able to jog the axis.
I have read everything I can find on this and I suspect I will have to use GANTRYKINS etc but I am lost here.
Can anybody help me with a simple step by step order of what I need to do to achieve it.
I am using linuxcnc 2.5.2 with stepper motors.
Thanks Clive
I have been a lurker here for some time
Now I am in need of some TLC with a homing and gantry squaring problem.I have a router type gantry machine with 3 axis but on the X axis I have 2 motors (joints) with prox.switches 1 on Z, 2 on Y and 4 on X.
I have got all this to home and limit using just 1 pin on the bob but only driving the x with one motor (the other with the belt off and switches not connected)
This all works fine.
Now comes the problem how do I connect the other x motor (joint ) so that the x axis will home together and square the gantry.
Also be able to jog the axis.
I have read everything I can find on this and I suspect I will have to use GANTRYKINS etc but I am lost here.
Can anybody help me with a simple step by step order of what I need to do to achieve it.
I am using linuxcnc 2.5.2 with stepper motors.
Thanks Clive
Please Log in or Create an account to join the conversation.
04 Oct 2013 21:00 #39547
by Clive S
Replied by Clive S on topic Homing and limits with X axis 2 joints
The simple answer is to push the gantry up to stops that makes the gantry square, turn on power in LinuxCNC and home both joints where they are.
A more complex and elegant answer is sure to arrive...
Thanks for the reply. Not very high tech though
Only kidding I wait in hope!! ..Clive
A more complex and elegant answer is sure to arrive...
Thanks for the reply. Not very high tech though
Only kidding I wait in hope!! ..Clive Please Log in or Create an account to join the conversation.
06 Oct 2013 02:09 - 06 Oct 2013 15:28 #39591
by Clive S
Replied by Clive S on topic Homing and limits with X axis 2 joints
Andy. It loads the first configuration screen that lets you pick a machine config. then it locks up the VB (and you have to reset the VB) if you start it from within a terminal it show the errors about halui pins not found etc. then the terminal closes.
The VB works fine with V2.5.3 but does show something about a real time error. but it runs ok.
Thanks for getting back to me.
A bit of rambling. Would this sort of thing be feasible re homing
First lets call the motors x1 and x2
Homing would start with x1 being run to the home switch position with x2 powered (slaved) with it then x1 would do its stuff i.e. run to the switch at some set speed back off then run back at a slow speed then when the switch has been hit the second time x1 knows where it is (referenced). It now backs off say 25mm (all this time both motors are powered being controlled by x1)
At this point control is passed over to x2 motor (with x1 being slaved to it). x2 motor goes through the same routine as x1 did.
Now both x1 and x2 motors have been referenced without any racking of the gantry.
Fine adjustment to get the gantry square could be done in software by changing the offset value of one of the switches or perhaps physical adjustment of one of the switches.
..Clive
The VB works fine with V2.5.3 but does show something about a real time error. but it runs ok.
Thanks for getting back to me.
A bit of rambling. Would this sort of thing be feasible re homing
First lets call the motors x1 and x2
Homing would start with x1 being run to the home switch position with x2 powered (slaved) with it then x1 would do its stuff i.e. run to the switch at some set speed back off then run back at a slow speed then when the switch has been hit the second time x1 knows where it is (referenced). It now backs off say 25mm (all this time both motors are powered being controlled by x1)
At this point control is passed over to x2 motor (with x1 being slaved to it). x2 motor goes through the same routine as x1 did.
Now both x1 and x2 motors have been referenced without any racking of the gantry.
Fine adjustment to get the gantry square could be done in software by changing the offset value of one of the switches or perhaps physical adjustment of one of the switches.
..Clive
Please Log in or Create an account to join the conversation.
09 Oct 2013 22:39 #39699
by Clive S
By the lack of response I take it that it can't be solved, not by me anyway, it's a shame really that nobody has been able to come up with an answer to what I thought should have been have been implemented in linuxcnc a long time ago.
It looks like I will just have to slave the two motors and put some sort of reference mark on one of the screws to know when the gantry is square as JT suggested above.
..Clive
Replied by Clive S on topic Homing and limits with X axis 2 joints
Andy. It loads the first configuration screen that lets you pick a machine config. then it locks up the VB (and you have to reset the VB) if you start it from within a terminal it show the errors about halui pins not found etc. then the terminal closes.
The VB works fine with V2.5.3 but does show something about a real time error. but it runs ok.
Thanks for getting back to me.
A bit of rambling. Would this sort of thing be feasible re homing
First lets call the motors x1 and x2
Homing would start with x1 being run to the home switch position with x2 powered (slaved) with it then x1 would do its stuff i.e. run to the switch at some set speed back off then run back at a slow speed then when the switch has been hit the second time x1 knows where it is (referenced). It now backs off say 25mm (all this time both motors are powered being controlled by x1)
At this point control is passed over to x2 motor (with x1 being slaved to it). x2 motor goes through the same routine as x1 did.
Now both x1 and x2 motors have been referenced without any racking of the gantry.
Fine adjustment to get the gantry square could be done in software by changing the offset value of one of the switches or perhaps physical adjustment of one of the switches.
..Clive
By the lack of response I take it that it can't be solved, not by me anyway, it's a shame really that nobody has been able to come up with an answer to what I thought should have been have been implemented in linuxcnc a long time ago.
It looks like I will just have to slave the two motors and put some sort of reference mark on one of the screws to know when the gantry is square as JT suggested above.
..Clive
Please Log in or Create an account to join the conversation.
09 Oct 2013 23:19 #39701
by andypugh
For some reason I didn't see this.
What you describe might be plausible, but I am not sure how it would work inside the way that LinuxCNC currently works.
At the moment there is no such thing as a slaved axis as far as the controller is "aware". You either have two motors sharing the same joint position command, or two joints sharing the same axis position command. (I am using "joint" here to mean either a sliding or rotating physical element, and "axis" to mean one of XYZABCUVW as commanded from G-code.)
Using gantrkins or gentrivkins you define which joints share an axis command:
This is trivkins, where axes X to W map directly to joints 0 to 8.
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...ads/joints_axes3#l24
Which you can compare to gentrivkins, where it is possible to re-define the mapping:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...ads/joints_axes3#l24
And (for fun, not really relevant) this is for a heaxpod platform where things are a whole lot more complicated:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...ds/joints_axes3#l324
However, homing bypasses this code completely, and drives the joints directly. I think that this means that at the moment it has no real idea which joints are paired. You can't necessarily work on the assumption that sharing a homing sequence is a good clue, as it is common to home X and Y at the same time.
I have wondered if it would suffice to simply have each joint wait at the end of each phase for any other joints that share a homing sequence number.
There are 26 states in the homing state machine:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...41588496c423d12#l236
Replied by andypugh on topic Homing and limits with X axis 2 joints
A bit of rambling. Would this sort of thing be feasible re homing
First lets call the motors x1 and x2
Homing would start with x1 being run to the home switch position with x2 powered (slaved) with it then x1 would do its stuff i.e. run to the switch at some set speed back off then run back at a slow speed then when the switch has been hit the second time x1 knows where it is (referenced). It now backs off say 25mm (all this time both motors are powered being controlled by x1)
At this point control is passed over to x2 motor (with x1 being slaved to it). x2 motor goes through the same routine as x1 did.
For some reason I didn't see this.
What you describe might be plausible, but I am not sure how it would work inside the way that LinuxCNC currently works.
At the moment there is no such thing as a slaved axis as far as the controller is "aware". You either have two motors sharing the same joint position command, or two joints sharing the same axis position command. (I am using "joint" here to mean either a sliding or rotating physical element, and "axis" to mean one of XYZABCUVW as commanded from G-code.)
Using gantrkins or gentrivkins you define which joints share an axis command:
This is trivkins, where axes X to W map directly to joints 0 to 8.
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...ads/joints_axes3#l24
Which you can compare to gentrivkins, where it is possible to re-define the mapping:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...ads/joints_axes3#l24
And (for fun, not really relevant) this is for a heaxpod platform where things are a whole lot more complicated:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...ds/joints_axes3#l324
However, homing bypasses this code completely, and drives the joints directly. I think that this means that at the moment it has no real idea which joints are paired. You can't necessarily work on the assumption that sharing a homing sequence is a good clue, as it is common to home X and Y at the same time.
I have wondered if it would suffice to simply have each joint wait at the end of each phase for any other joints that share a homing sequence number.
There are 26 states in the homing state machine:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...41588496c423d12#l236
Please Log in or Create an account to join the conversation.
Time to create page: 0.160 seconds