Threading G76 with spindle in reverse

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

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

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.

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

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

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.

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.

Simmsey wrote:

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

Simmsey wrote:

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

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