Gantry machine
26 Jun 2013 00:28 #36044
by eslavko
Replied by eslavko on topic Gantry machine
as bigalex wrote I didn't find the best solution for gantry too.
My machine is big but it use open loop stepper.
As I know with mechanic switch I can reach 0.1mm accuracy at the best. So this may be little coarse. And in A and C axis the accuracy should be under 0.02mm.
So I need to use some index pulse scheme. The glas scale is little expensive and in reality I need just index pulse. Still need to manage that.
I look in my schematic and see that I can use my previous algorithm too.
After mesa card I have photocoupler board (my design) to avoid ground loop and protect mesa card. And I realise if I just put two photocoupler in series (emiter of one goes to other colector) and use as one I can control if step pulses goes to the driver or not. So in this way I can "disconnect" step pulse from driver with hal.
So this is my sequence for home gantry.
-move axis toward home
-when individual home switch is triggered, disconnect step signal
-when both home signals are tripped, report to emc that home is reached
-connect both step sinals back
-emc homming are directed to the opposite direction to release switch.
-when individual home (+index if anny) is released stop the motion of that motor
-when both switches are off, report emc that switch is off and connect both step signals back
-emc is finished (or does backoff from home if it's required)
This should work, and need just few line in hal.
Required extra pin
1 Enable STEP1
2 Enable STEP2
3 HomeSW1
4 HomeSW2
5 HomeIndex1 (if used)
6 HomeIndex2 (if used)
And of course have few limitations.
-As hal is executed in servo thread (no base thread on that machine) the max step rate (when releasing switch) must be under 1/2 servo thread time. (If servo thread is on 1kHz then max step rate is under 500Hz. If it's higher It may miss index pulse and wreck system.
-As step signal is just cut off (no ramp) the step rate must be low enought as if it's to fast the motor will overshot.
but that is meaningful only when motor goes to release end switch. So the total move is just sum of switch histeresys and motor runout (when motor goes to reach home switch it's probably to fast and will do few steps before stop) so the homming should be pretty fast.
Will report how it's works.
My machine is big but it use open loop stepper.
As I know with mechanic switch I can reach 0.1mm accuracy at the best. So this may be little coarse. And in A and C axis the accuracy should be under 0.02mm.
So I need to use some index pulse scheme. The glas scale is little expensive and in reality I need just index pulse. Still need to manage that.
I look in my schematic and see that I can use my previous algorithm too.
After mesa card I have photocoupler board (my design) to avoid ground loop and protect mesa card. And I realise if I just put two photocoupler in series (emiter of one goes to other colector) and use as one I can control if step pulses goes to the driver or not. So in this way I can "disconnect" step pulse from driver with hal.
So this is my sequence for home gantry.
-move axis toward home
-when individual home switch is triggered, disconnect step signal
-when both home signals are tripped, report to emc that home is reached
-connect both step sinals back
-emc homming are directed to the opposite direction to release switch.
-when individual home (+index if anny) is released stop the motion of that motor
-when both switches are off, report emc that switch is off and connect both step signals back
-emc is finished (or does backoff from home if it's required)
This should work, and need just few line in hal.
Required extra pin
1 Enable STEP1
2 Enable STEP2
3 HomeSW1
4 HomeSW2
5 HomeIndex1 (if used)
6 HomeIndex2 (if used)
And of course have few limitations.
-As hal is executed in servo thread (no base thread on that machine) the max step rate (when releasing switch) must be under 1/2 servo thread time. (If servo thread is on 1kHz then max step rate is under 500Hz. If it's higher It may miss index pulse and wreck system.
-As step signal is just cut off (no ramp) the step rate must be low enought as if it's to fast the motor will overshot.
but that is meaningful only when motor goes to release end switch. So the total move is just sum of switch histeresys and motor runout (when motor goes to reach home switch it's probably to fast and will do few steps before stop) so the homming should be pretty fast.
Will report how it's works.
Please Log in or Create an account to join the conversation.
26 Jun 2013 00:37 #36047
by andypugh
You might find it interesting to read the discussion here:
thread.gmane.org/gmane.linux.distributio...evel/9836/focus=9847
I spent last week sitting opposite cradek as he experimented with a small gantry system. He mainly found at least three ways not to do it.
Replied by andypugh on topic Gantry machine
as bigalex wrote I didn't find the best solution for gantry too.
You might find it interesting to read the discussion here:
thread.gmane.org/gmane.linux.distributio...evel/9836/focus=9847
I spent last week sitting opposite cradek as he experimented with a small gantry system. He mainly found at least three ways not to do it.
Please Log in or Create an account to join the conversation.
26 Jun 2013 02:14 #36053
by eslavko
Well that's sad. A lot of description how to not do it. But near none of how to do it.
The best idea for me seems to be the calculator variant.
If I understand correct they should work like this:
1- Both drives goes toward home position.
2- when both switches are hit , the both motors reverse
3- and both motors goes until both switches are released and got both index.
4- within all that moving the system calculate difference in position using switch and index pulse and then move one motor to square gantry
So within 1,2 and 3 the gantry can have some twist (initial) and is same all the time!
within 4 the twist is zeroed.
This should work for all configurations. But can't be done in hal. So some coding is needed.
Replied by eslavko on topic Gantry machine
as bigalex wrote I didn't find the best solution for gantry too.
You might find it interesting to read the discussion here:
thread.gmane.org/gmane.linux.distributio...evel/9836/focus=9847
I spent last week sitting opposite cradek as he experimented with a small gantry system. He mainly found at least three ways not to do it.
Well that's sad. A lot of description how to not do it. But near none of how to do it.
The best idea for me seems to be the calculator variant.
If I understand correct they should work like this:
1- Both drives goes toward home position.
2- when both switches are hit , the both motors reverse
3- and both motors goes until both switches are released and got both index.
4- within all that moving the system calculate difference in position using switch and index pulse and then move one motor to square gantry
So within 1,2 and 3 the gantry can have some twist (initial) and is same all the time!
within 4 the twist is zeroed.
This should work for all configurations. But can't be done in hal. So some coding is needed.
Please Log in or Create an account to join the conversation.
26 Jun 2013 15:12 - 26 Jun 2013 22:41 #36064
by bigalex
Replied by bigalex on topic Gantry machine
Hi.
The Siemens Gantry Homing Procedure PDF file that I previously attached is not displayed properly into the browser (I don't know why!).
So I converted it to JPG image file for a correct display.
I do believe this procedure is a good reference for the argument of this discussion.
The simulations on small machines are good for test but the situation is different on large machines and servo motor axes (closed loop).
For sure due to the gantry architecture a specific hal homing function/sequence is needed .
Today's absolute encoders/position transducers simplify the axes homing procedure.
I used many servo motors with absolute encoder and I'm forgetting about homing (after the preliminary and unique startup).
With absolute encoders on gantry machine the secondary axis have to be moved at the same position of the primary axis
after the power on if_and_only_if the misalignment is within a specific and safe value.
After that the gantry axes are synchronized and into the part program the movement is related to primary axis only
because the secondary axis is the slave in motion with the primary.
File now HERE
The Siemens Gantry Homing Procedure PDF file that I previously attached is not displayed properly into the browser (I don't know why!).
So I converted it to JPG image file for a correct display.
I do believe this procedure is a good reference for the argument of this discussion.
The simulations on small machines are good for test but the situation is different on large machines and servo motor axes (closed loop).
For sure due to the gantry architecture a specific hal homing function/sequence is needed .
Today's absolute encoders/position transducers simplify the axes homing procedure.
I used many servo motors with absolute encoder and I'm forgetting about homing (after the preliminary and unique startup).
With absolute encoders on gantry machine the secondary axis have to be moved at the same position of the primary axis
after the power on if_and_only_if the misalignment is within a specific and safe value.
After that the gantry axes are synchronized and into the part program the movement is related to primary axis only
because the secondary axis is the slave in motion with the primary.
File now HERE
Last edit: 26 Jun 2013 22:41 by andypugh. Reason: Manually added the file
Please Log in or Create an account to join the conversation.
02 Jul 2013 23:56 #36242
by tommy
Replied by tommy on topic Gantry machine
If you'r going to run Lcnc on 5axis milling machine, you will probably use 5axiskins module, because of tool length compensation ... I went through this in this thread ...
www.linuxcnc.org/index.php/english/forum...setting-up-5axiskins
And homing sequence is same as with gantrykins.
www.linuxcnc.org/index.php/english/forum...setting-up-5axiskins
And homing sequence is same as with gantrykins.
Please Log in or Create an account to join the conversation.
Time to create page: 0.067 seconds