G76 threading with cutviewer turn update#

Thanks Cradek for identifying the desired behaviour of motion.spindle-revs

Possibly there's a better way to achieve the same thing - I'd be interested if there are alternatives 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.

G76 threading with cutviewer turn update#

Update - I have managed to get the threading with spindle in reverse working successfully and cut a very nice test thread. 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.Р”Вo you have any idea how I can get direction for the spindle-revs signal correct?Р”Вo I have to invert the sign of encoder.position if CCW motion? Any idea the best way to do this? Net spindle-index encoder.0.phase-Z <= parport.0.pin-11-in Net spindle-phase-a encoder.0.phase-A <= parport.0.pin-10-in # connect the HAL encoder inputs to the real encoder. Net spindle-index-enable encoder.0.index-enable motion.spindle-index-enable Net spindle-velocity encoder.0.velocity => motion.spindle-speed-in Net spindle-position encoder.0.position => motion.spindle-revs # connect the HAL encoder outputs to LinuxCNC. # set the HAL encoder to non-quadrature simple counting using A only. # set the HAL encoder to 50 pulses per revolution. # add the encoder to HAL and attach it to threads.Р”Р„ddf encoder.capture-position servo-thread docs/html/examples/spindle.ynchronized_motion_a My config for this came from the LinuxCNC literature: If so this problem originates in the HAL connections for motion.spindle-revs I assume this would therefore be the reason threading remains waiting at the start point is that correct? Please Log in or Create an account to join the conversation. 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) Is this the cause? Is there any way round this or is LinuxCNC not able to cut threads on a rear toolpost lathe? I assume if I run the spindle in reverse it will actually be counting down. Searching the forum I guess this might be because LinuxCNC needs to see motion.spindle-revs counting up.

When I reverse the spindle the tool does an initial X move and then waits forever. 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.

I have a 50ppr sensor and an index pulse sensor. I seem to be having problems with this does anyone know how I can get this to work? I have a cnc lathe with rear toolpost and am trying to setup LinuxCNC for single point threading for the first time.Р”Р„s it's a rear toolpost I need to cut with spindle in reverse.