Threading G76 with spindle in reverse
09 Jun 2015 00:18 #59633
by Simmsey
Threading G76 with spindle in reverse was created by Simmsey
I have a cnc lathe with rear toolpost and am trying to setup LinuxCNC for single point threading for the first time.
As it's a rear toolpost I need to cut with spindle in reverse.
I seem to be having problems with this does anyone know how I can get this to work?
I have a 50ppr sensor and an index pulse sensor. These appear to be working fine and I get spindle speed and appear to get a threading cycle being run if I run the spindle forwards. When I reverse the spindle the tool does an initial X move and then waits forever. It never starts the Z thread move.
Searching the forum I guess this might be because LinuxCNC needs to see motion.spindle-revs counting up. I assume if I run the spindle in reverse it will actually be counting down.
Is this the cause? Is there any way round this or is LinuxCNC not able to cut threads on a rear toolpost lathe?
It's a ratchet and pawl autochange toolpost so I don't think I can turn the tool upside down and run spindle forwards (besides I would have tool height problems requiring a new special toolholder)
Thanks Simmsey
As it's a rear toolpost I need to cut with spindle in reverse.
I seem to be having problems with this does anyone know how I can get this to work?
I have a 50ppr sensor and an index pulse sensor. These appear to be working fine and I get spindle speed and appear to get a threading cycle being run if I run the spindle forwards. When I reverse the spindle the tool does an initial X move and then waits forever. It never starts the Z thread move.
Searching the forum I guess this might be because LinuxCNC needs to see motion.spindle-revs counting up. I assume if I run the spindle in reverse it will actually be counting down.
Is this the cause? Is there any way round this or is LinuxCNC not able to cut threads on a rear toolpost lathe?
It's a ratchet and pawl autochange toolpost so I don't think I can turn the tool upside down and run spindle forwards (besides I would have tool height problems requiring a new special toolholder)
Thanks Simmsey
Please Log in or Create an account to join the conversation.
09 Jun 2015 00:44 #59635
by Simmsey
Replied by Simmsey on topic Threading G76 with spindle in reverse
Update:
Checking HAL meter shows that motion.spindle-revs does actually count up despite spindle running in reverse.
Spindle at speed is also True.
So does anyone else have any idea why threading doesn't start when spindle is running in reverse?
Thanks Simmsey
Checking HAL meter shows that motion.spindle-revs does actually count up despite spindle running in reverse.
Spindle at speed is also True.
So does anyone else have any idea why threading doesn't start when spindle is running in reverse?
Thanks Simmsey
Please Log in or Create an account to join the conversation.
09 Jun 2015 01:55 #59638
by cradek
Good troubleshooting! This is wrong. If in M3 mode, motion.spindle-revs should increase by 1.0 per turn of the spindle. If in M4 motion.spindle-revs should decrease.
Replied by cradek on topic Threading G76 with spindle in reverse
Checking HAL meter shows that motion.spindle-revs does actually count up despite spindle running in reverse.
Thanks Simmsey
Good troubleshooting! This is wrong. If in M3 mode, motion.spindle-revs should increase by 1.0 per turn of the spindle. If in M4 motion.spindle-revs should decrease.
The following user(s) said Thank You: Simmsey
Please Log in or Create an account to join the conversation.
09 Jun 2015 02:34 #59639
by Simmsey
Replied by Simmsey on topic Threading G76 with spindle in reverse
Thanks Cradek.
I assume this would therefore be the reason threading remains waiting at the start point is that correct?
If so this problem originates in the HAL connections for motion.spindle-revs
My config for this came from the LinuxCNC literature:
linuxcnc.org/docs/html/examples/spindle....ynchronized_motion_a
Details below:
# add the encoder to HAL and attach it to threads.
loadrt encoder num_chan=1
addf encoder.update-counters base-thread
addf encoder.capture-position servo-thread
# set the HAL encoder to 50 pulses per revolution.
setp encoder.3.position-scale 50
# set the HAL encoder to non-quadrature simple counting using A only.
setp encoder.3.counter-mode true
# connect the HAL encoder outputs to LinuxCNC.
net spindle-position encoder.0.position => motion.spindle-revs
net spindle-velocity encoder.0.velocity => motion.spindle-speed-in
net spindle-index-enable encoder.0.index-enable <=> motion.spindle-index-enable
# connect the HAL encoder inputs to the real encoder.
net spindle-phase-a encoder.0.phase-A <= parport.0.pin-10-in
net spindle-phase-b encoder.0.phase-B
net spindle-index encoder.0.phase-Z <= parport.0.pin-11-in
Looking at this I assume the issue is that the motion.spindle-revs comes from encoder.position and because the encoder setup in counter mode it does not track direction.
Do you have any idea how I can get direction for the spindle-revs signal correct?
Do I have to invert the sign of encoder.position if CCW motion? Any idea the best way to do this?
Thanks Simmsey.
I assume this would therefore be the reason threading remains waiting at the start point is that correct?
If so this problem originates in the HAL connections for motion.spindle-revs
My config for this came from the LinuxCNC literature:
linuxcnc.org/docs/html/examples/spindle....ynchronized_motion_a
Details below:
# add the encoder to HAL and attach it to threads.
loadrt encoder num_chan=1
addf encoder.update-counters base-thread
addf encoder.capture-position servo-thread
# set the HAL encoder to 50 pulses per revolution.
setp encoder.3.position-scale 50
# set the HAL encoder to non-quadrature simple counting using A only.
setp encoder.3.counter-mode true
# connect the HAL encoder outputs to LinuxCNC.
net spindle-position encoder.0.position => motion.spindle-revs
net spindle-velocity encoder.0.velocity => motion.spindle-speed-in
net spindle-index-enable encoder.0.index-enable <=> motion.spindle-index-enable
# connect the HAL encoder inputs to the real encoder.
net spindle-phase-a encoder.0.phase-A <= parport.0.pin-10-in
net spindle-phase-b encoder.0.phase-B
net spindle-index encoder.0.phase-Z <= parport.0.pin-11-in
Looking at this I assume the issue is that the motion.spindle-revs comes from encoder.position and because the encoder setup in counter mode it does not track direction.
Do you have any idea how I can get direction for the spindle-revs signal correct?
Do I have to invert the sign of encoder.position if CCW motion? Any idea the best way to do this?
Thanks Simmsey.
Please Log in or Create an account to join the conversation.
09 Jun 2015 02:36 #59640
by Simmsey
Replied by Simmsey on topic Threading G76 with spindle in reverse
Sorry some typos in encoder numbers - hopefully corrected here:
# add the encoder to HAL and attach it to threads.
loadrt encoder num_chan=1
addf encoder.update-counters base-thread
addf encoder.capture-position servo-thread
# set the HAL encoder to 50 pulses per revolution.
setp encoder.0.position-scale 50
# set the HAL encoder to non-quadrature simple counting using A only.
setp encoder.0.counter-mode true
# connect the HAL encoder outputs to LinuxCNC.
net spindle-position encoder.0.position => motion.spindle-revs
net spindle-velocity encoder.0.velocity => motion.spindle-speed-in
net spindle-index-enable encoder.0.index-enable <=> motion.spindle-index-enable
# connect the HAL encoder inputs to the real encoder.
net spindle-phase-a encoder.0.phase-A <= parport.0.pin-10-in
net spindle-phase-b encoder.0.phase-B
net spindle-index encoder.0.phase-Z <= parport.0.pin-11-in
# add the encoder to HAL and attach it to threads.
loadrt encoder num_chan=1
addf encoder.update-counters base-thread
addf encoder.capture-position servo-thread
# set the HAL encoder to 50 pulses per revolution.
setp encoder.0.position-scale 50
# set the HAL encoder to non-quadrature simple counting using A only.
setp encoder.0.counter-mode true
# connect the HAL encoder outputs to LinuxCNC.
net spindle-position encoder.0.position => motion.spindle-revs
net spindle-velocity encoder.0.velocity => motion.spindle-speed-in
net spindle-index-enable encoder.0.index-enable <=> motion.spindle-index-enable
# connect the HAL encoder inputs to the real encoder.
net spindle-phase-a encoder.0.phase-A <= parport.0.pin-10-in
net spindle-phase-b encoder.0.phase-B
net spindle-index encoder.0.phase-Z <= parport.0.pin-11-in
Please Log in or Create an account to join the conversation.
09 Jun 2015 13:44 #59644
by ArcEye
Replied by ArcEye on topic Threading G76 with spindle in reverse
You haven't actually said what 'reverse' is.
That would be M3 on a back tool / slant bed lathe and you can't cut anything with an upright tool, so I am confused.
If it was M4, which isn't reverse, you would always be cutting left hand threads, unless you work from negative to positive values.
I use a special toolholder to get the tooltip onto the centreline and cut threads in M3.
A fringe benefit is that all the swarf drops away instead of potentially jamming the cut.
www.linuxcnc.org/index.php/english/forum...-250b?start=20#44003
regards
That would be M3 on a back tool / slant bed lathe and you can't cut anything with an upright tool, so I am confused.
If it was M4, which isn't reverse, you would always be cutting left hand threads, unless you work from negative to positive values.
I use a special toolholder to get the tooltip onto the centreline and cut threads in M3.
A fringe benefit is that all the swarf drops away instead of potentially jamming the cut.
www.linuxcnc.org/index.php/english/forum...-250b?start=20#44003
regards
Please Log in or Create an account to join the conversation.
10 Jun 2015 05:55 #59660
by Simmsey
Replied by Simmsey on topic Threading G76 with spindle in reverse
Update - I have managed to get the threading with spindle in reverse working successfully and cut a very nice test thread. ![:) :)](/media/kunena/emoticons/smile.png)
The way I have done it is to connect standard HAL Mux2, Mult2 and Constant components so that depending on the direction of the spindle the sign of encoder.0.position is inverted (or not) to provide a motion.spindle-revs counting up/down in the correct way.
Possibly there's a better way to achieve the same thing - I'd be interested if there are alternatives
Anyway it works at present.
Thanks Cradek for identifying the desired behaviour of motion.spindle-revs
Hello ArcEye
I have the Lathe setup looking towards the chuck, M03 counterclockwise.M04 clockwise.
For my lathe and rear turret cutting needs spindle running M04 (clockwise) for turning tools.
As I already have toolholders making a special offset one to invert the insert and put the edge at centre height isn't particularly attractive. I am also not sure the ratchet & pawl toolpost can take cutting loads in reverse direction. - Does anyone know?
All my issues are resolved anyway by getting a suitable motion.spindle-revs signal.
![:) :)](/media/kunena/emoticons/smile.png)
The way I have done it is to connect standard HAL Mux2, Mult2 and Constant components so that depending on the direction of the spindle the sign of encoder.0.position is inverted (or not) to provide a motion.spindle-revs counting up/down in the correct way.
Possibly there's a better way to achieve the same thing - I'd be interested if there are alternatives
Anyway it works at present.
Thanks Cradek for identifying the desired behaviour of motion.spindle-revs
Hello ArcEye
I have the Lathe setup looking towards the chuck, M03 counterclockwise.M04 clockwise.
For my lathe and rear turret cutting needs spindle running M04 (clockwise) for turning tools.
As I already have toolholders making a special offset one to invert the insert and put the edge at centre height isn't particularly attractive. I am also not sure the ratchet & pawl toolpost can take cutting loads in reverse direction. - Does anyone know?
All my issues are resolved anyway by getting a suitable motion.spindle-revs signal.
Please Log in or Create an account to join the conversation.
06 Jul 2015 07:35 #60457
by tome
Can you post your hal config related to this? Or have you found another way?
Thanks,
-Tom
Replied by tome on topic Threading G76 with spindle in reverse
Update - I have managed to get the threading with spindle in reverse working successfully and cut a very nice test thread.
The way I have done it is to connect standard HAL Mux2, Mult2 and Constant components so that depending on the direction of the spindle the sign of encoder.0.position is inverted (or not) to provide a motion.spindle-revs counting up/down in the correct way.
Possibly there's a better way to achieve the same thing - I'd be interested if there are alternatives
Anyway it works at present.
Can you post your hal config related to this? Or have you found another way?
Thanks,
-Tom
Please Log in or Create an account to join the conversation.
07 Jul 2015 10:20 #60495
by tome
You didn't say what kind of lathe this is (I didn't see that anyway) but on my Emco 120P the holding forces are very strong in the opposite direction. I talked with a tech from Emco and he said it isn't really a problem to cut especially the lighter cutting forces of threading. Someone in the Yahoo forum for Emco lathes said he calculated 12Nm between the worm gear in the turret and the holding torque of the motor. The Emco tech didn't have the exact number but said that sounded reasonable, that the machine was designed to cut in either spindle direction or tool orientation.
The Yahoo group thread is: groups.yahoo.com/neo/groups/emco_turn_12...sations/messages/832
-Tom
Replied by tome on topic Threading G76 with spindle in reverse
I am also not sure the ratchet & pawl toolpost can take cutting loads in reverse direction. - Does anyone know?
You didn't say what kind of lathe this is (I didn't see that anyway) but on my Emco 120P the holding forces are very strong in the opposite direction. I talked with a tech from Emco and he said it isn't really a problem to cut especially the lighter cutting forces of threading. Someone in the Yahoo forum for Emco lathes said he calculated 12Nm between the worm gear in the turret and the holding torque of the motor. The Emco tech didn't have the exact number but said that sounded reasonable, that the machine was designed to cut in either spindle direction or tool orientation.
The Yahoo group thread is: groups.yahoo.com/neo/groups/emco_turn_12...sations/messages/832
-Tom
Please Log in or Create an account to join the conversation.
09 Jul 2015 10:22 #60534
by tome
Replied by tome on topic Threading G76 with spindle in reverse
This is one method that works:
loadrt mux2 count=1
loadrt abs count=1
loadrt mult2 count=1
addf mux2.0 servo-thread
addf abs.0 servo-thread
addf mult2.0 servo-thread
setp hm2_5i25.0.encoder.00.counter-mode 1
setp hm2_5i25.0.encoder.00.index-invert 0
setp hm2_5i25.0.encoder.00.index-mask 0
setp hm2_5i25.0.encoder.00.index-mask-invert 0
setp hm2_5i25.0.encoder.00.scale [SPINDLE_9]ENCODER_SCALE #set to scale for your encoder
setp mux2.0.in0 1
setp mux2.0.in1 -1
# spindle rotating in reverse will pick -1, otherwise 1
net spindle-reversed <= motion.spindle-reverse => mux2.0.sel
# send mux output (1 or -1) to a multiplier
net spindle-revs-multiplier <= mux2.0.out => mult2.0.in0
# compute ABS(encoder position) in case it is negative
net spindle-revs-raw <= hm2_5i25.0.encoder.00.position => abs.0.in
# take ABS(encoder position) and multiply it by mux output above
# position is now negative for reverse, positive otherwise
net spindle-revs-abs <= abs.0.out => mult2.0.in1
# send recomputed position to motion component
net spindle-revs-signed <= mult2.0.out => motion.spindle-revs
loadrt mux2 count=1
loadrt abs count=1
loadrt mult2 count=1
addf mux2.0 servo-thread
addf abs.0 servo-thread
addf mult2.0 servo-thread
setp hm2_5i25.0.encoder.00.counter-mode 1
setp hm2_5i25.0.encoder.00.index-invert 0
setp hm2_5i25.0.encoder.00.index-mask 0
setp hm2_5i25.0.encoder.00.index-mask-invert 0
setp hm2_5i25.0.encoder.00.scale [SPINDLE_9]ENCODER_SCALE #set to scale for your encoder
setp mux2.0.in0 1
setp mux2.0.in1 -1
# spindle rotating in reverse will pick -1, otherwise 1
net spindle-reversed <= motion.spindle-reverse => mux2.0.sel
# send mux output (1 or -1) to a multiplier
net spindle-revs-multiplier <= mux2.0.out => mult2.0.in0
# compute ABS(encoder position) in case it is negative
net spindle-revs-raw <= hm2_5i25.0.encoder.00.position => abs.0.in
# take ABS(encoder position) and multiply it by mux output above
# position is now negative for reverse, positive otherwise
net spindle-revs-abs <= abs.0.out => mult2.0.in1
# send recomputed position to motion component
net spindle-revs-signed <= mult2.0.out => motion.spindle-revs
Please Log in or Create an account to join the conversation.
Time to create page: 0.093 seconds