Lathe pulse input for threading (feature request)

[tklus]

Hey guys, Just wanted to get this on the list for grbl mega. Not sure how this would be done but it would be nice to have the capability to do threading with a grbl controlled lathe.

If this should be with grbl arm I can move it. Not sure what the difference is between arm and mega.

Thanks! Tim

[HuubBuis]

I have checked the GRBL-L-Mega and GRBL-L-Mega-Ramps versions. They can measure the spindle speed way above 10000 RPM.

I have decide to use the INT0 (D2) and INT1 (D3) pins for the Index and Sync pulse because:

• they are available on the RAMPS on a 4 pin header together with VCC and GND, very convenient.
• The INT0 and INT1 interrupts are not used in the GRBL-L-Mega version that reduces the side effects.

I have made a Quick and Dirty solution and tested it using the spindle index/sync simulator. I tested using UGS and your threading example and using my own CNCL software.

Pulses are detected on a negative flank for NO sensors. It should also work on NC sensors.

About the half of Mai I will make a clean version, test it an a lathe and publish it.

GRBL-L-Mega-Ramps (3).zip

[Bi7Wis3]

@HuubBuis

Tried your quick and dirty version, but i'm not getting any pulses on A12.

Error 18.

BTW i don't have a ramps board installed , so changing pins is quite easy for me.. I'm only using the ramps version because on all my other machines, i do have them installed.

P.S.

after some more testing and putting $40 to 1 i got it working. the only problem is i do have 4 magnets installed and that i can't change that easy..

[HuubBuis]

The last zip, Version (3) , 2 post before, uses the INT0 and INT1 pins for Index and Sync. These are on the SCL and SDA pins on the atmega! To use four magnets, connect the 4 magnet sensor to the SDA pin, connect the 1 magnet Index sensor to the SCL pin and set $40 to 4. Even if you have 4 sync pulses, you still need an Index pulse on INT0 (SCL), otherwise stopping the spindle to check the thread couldn't be done safely because there is no way to see in what direction the spindle is turned by hand!

[Bi7Wis3]

Just made a quick and dirty 'hotglue' fix... (LOL) Added 1 extra sensor and glued a magnet to the side of my timing ring...

I thougt in the last zip, the index pulse was on A12? not on INT0? I have tested it on A12 ..

p.s. missed the last post .. sorry .. going to check that version now ..

[Bi7Wis3]

OK ... i've been testing with some results. The result wasn't great.

Check this video: https://www.youtube.com/watch?v=i9LWLmVS_Ik

I looks like it does start at the same point, but gets lost at the end .. Also the width of the thread looks 2x too big .. i have set it at 1.25mm pitch but measure it's over 2mm.

[Bi7Wis3]

After some more testing .. thread size isn't OK. It tracks ok, BUT only at very low speeds. I have done a small test (code below). Executed it 4 times and it tracked perfectly at 130rpm.

On my lathe it's very hard set the rpm below 250.

G0 X0 Z0 ; go to start position G0 X-0.005 ; go to cutting depth, clear of workpiece G90 G33 Z-15 K0.5 ; Threading pass at a pitch of 0.5 unit per revolution G0 X0.15 ; retract at end of move Z0 ; end of pass G0 X0; end of move

thread pitch looks more like 1.0 instead of 0.5.. https://www.youtube.com/watch?v=WsOQOV--XnY

[HuubBuis]

During threading you have to keep well below the max Z speed of the lathe. That will give the stepper enough extra speed to catch up when starting the thread. The Z-axis needs time to get on speed. You can't start at the tip of the bar. When the tip of the bar is 0, I start at about Z=9. My GRBL setting for Z = max rate 500, acceleration 20, steps per mm 1600. I can make a video with my phone, have to figure out how to upload, never done that before, will try tomorrow. I run threading mostly at 300 RPM because at that speed my spindle speed is pretty stable. I do this on both lathes. I don't think the grbl settings causes the pitch problem. I suspect to much (false) synchronization pulses. Lets solve this first.

Set the synchronization pulses to 1 ($40), than only the index pulse is used. Do some threading passes at a shallow cutting depth (0.05 mm), just a scratch pass, always at the same cutting depth, just to see if the threading starts at the same place and ends at the same place. Start way beyond the bar to give the Z-axis time to get on speed and in sync. Z start at 15 mm will do. Increase the spindle speed at every pass to see at what speed the problem starts. Keep at least 10% below your max Z-speed. Set $40 to 4 and do the same test, except for starting at bit later due to the waiting of the first synchronization pulse, the results should be the same.

When the spindle starts moving, you hear the change in stepper speed to keep in sync. When the tool reaches the start of the bar, you should hear that the Z-axis is in sync, no or just very little speed changes. Have a look at the wiki GRBL-L-Mega | Threading Setup | Configuring GRBL, you can set a report option to see the actual synchronization error during threading at every index pulse. Set bit 3 in the report option ($10 add 8).

During threading on my lathes, the synchronization error is well below 0.05 mm and about 0.01 mm during the last 2 shallow cleanup passes.

Check you spindle speed reported to UGS it should be stable.

What is you z-axis setting for speed, acceleration and resolution. I will set the bigger lathe to the same value (the small one is taken apart for maintenance) and test your settings.

[HuubBuis]

I have tried to make a video but didn't succeed. Nor the (budget) smartphone or camera's (tried 2) could focus during recording. I need to get a decent camera. Tested over a threading length of 50 mm

• 0.5 mm pitch at 600 RPM, multiple passes, all lined up.
• 1.0 mm pitch at 400 RPM, multiple passes, all lined up. Results are as expected, doing this for quit some time now. Included a picture of the last test, Foto camera does focus!!!!

[Bi7Wis3]

OK.. Done the tests .. Sinds i've set $40 to 1, the pitch size is correct. I did change my Z acceleration to 40 and max feed is 700mm/m. To get up to speed i only need about 1 mm. ( did 5mm in the tests ). I can thread up to 600-700 rpm ... ( maybe faster, but i think that's fast enough :D )

Some threads get butchered tough, worse then with the 4 sync pulses. Sometimes i get an spike on my RPM's and then the thread gets F , but after the f-up, it continues tracking o.k. Isn't it possible to filter out very big spikes in the rpm's ? ( shoots over 1800rpm, just for one pulse ). Doesn't happen that often though.. can get threads without the glitch sometimes.. Going to hook up my scope and check how the rpm signal looks.

@HuubBuis P.S. .. jij bent ook al zo'n HBM klant ?! lol

[Bi7Wis3]

Check this Vid : https://www.youtube.com/watch?v=-5bh7NcSo6I here you can see that after 2 good cuts each @ 0.1 mm DOC, after the second i did ramp up the rpm's a little. from 320 to 450, the error would have occurred if i didn't change the rpm's. So, this happens when i get an RPM spike ..

[HuubBuis]

Sinds i've set $40 to 1, the pitch size is correct. That is what I expected to happen. You some times get double sync pulses. Reading your progress, you probably get some false index pulses too. When I turn up the speed for the bigger lathe some where above 1200 RPM, I often get very high RPM readings. I don't have this problem on the smaller lathe. The smaller lathe has the sensors driven by the 5V from the Arduino (cheap solution). The bigger lathe has an optocoupler board, fully isolated. I haven't done anything about it because the optocoupler board and sensors will be replaced any way. Check the pulses on your scope. If they aren't formed pretty square than you now you have something to fix. If the pulses are OK, you may pickup high frequency pulses. On the Uno and Mega version (not RAMPS) , there is some filtering (33 ms watchdog) in software that works pretty well. There is only one such filter possible and that is on the limit pins port (port B). A way to reduce high frequency spikes is by putting an optocoupler between the Arduino and the sensor. An outher way is using a low resistor pullup on then sensor input. This increases the current and makes it less sensible for high frequency spikes. Another problem could be the index/sync pulse rise and fall time, when the lathe is running at higher speeds. using a stronger magnet and/or placing the sensor closer to the magnet could solve this problem.

I'm using NO sensors too, but to make the pulse longer, i used 2 magnets next to each other on the timing ring. This could also ruin the shape of the pulse. I suspect this is also part of the problem, not the 2 magnets but the reason why you needed a longer pulse with. On the small lathe I use 8 (3 x 4) mm Neodymium magnets and 8 mm sensors (NJK-5001C). These will be fit on the larger lathe also.

You should check the polarity of the magnets using another magnet. All magnet should have the same polarity.

[Bi7Wis3]

My sensor won't pick up the magnets if they are the wrong polarity. Checked those during install.. It's a temporary fix .. i'll make a new ring soon. Also turned up sensor sensitivity so it does detect the 2 magnets as 1 without problems. I have to get my scope, i have borrowed it to a friend.

Also tried optical rpm counters, but those had very nasty pulses and i could not get high rpm's with those.

[HuubBuis]

Check this Vid : https://www.youtube.com/watch?v=-5bh7NcSo6I

I have seen the problem but can't see is the carriage to far ahead (false pulse) or you missed one pulse!

I am curious what signal you will see on the scope. Have you checked for vibration of the sensor when the lathe is running?

A picture of the sensor mount on the small lathe. The extension just fits the few threads at the back of the spindle. I see I uses 8 x 1 mm Neodimyum magnets!

@HuubBuis P.S. .. jij bent ook al zo'n HBM klant ?! lol

Goed genoeg voor mijn hobby, veel draaibank voor het geld maar je moet er ook nieuw uit de doos veel tijd in steken om het goed te krijgen. Voor mij is dat toch het leukste om te doen.

[Bi7Wis3]

I'll try to make a 'butchered thread' movie .. :rofl: But it seems to me that because of the rpm 'spike' grbl thinks the Z is behind and tries to catch up. While it hasn't missed, so it cuts up a couple of thread ahead.. I had a couple of cases where i had double fails on one go ... Going to try to film one of those..

@HuubBuis Dat heb ik dus ook, vondt HBM alleen nog te duur en ben voor een 7x14 van ebay gegaan voor 550 euries (lol), zit ondertussen al een paar duizend in ...

[Bi7Wis3]

OK .. got some errors on 'tape' https://www.youtube.com/watch?v=Edz8INdzDNc The last pass really done it .. this was @ 240 rpm.

[HuubBuis]

Clearly to see its getting false pulses and moves ahead. Because the "extra" pulse is on the index sensor, it moves a whole pitch. If it would be on the sync sensor, it would just move a partial pitch ahead. Now you have to solve the nature of this extra pulse, high frequent glitch or slow rising signals. The signal on the scope could clarify things. You could try the GRBL-L-Mega version. The 33 ms software filter (debounce) could do the trick on the index signal. I will have a look at the code tomorrow because it should limit the measured RPM to 1000/33*60 = 1818 RPM and I can run a whole lot faster and still get an accurate RPM reading. Have something to think about...

[HuubBuis]

I have a way (I think) to "debounce" all interrupts regardless of the pin that generated it. I will change the GRBL-L-Mega & RAMPS version, test it on the bench and test the GRBL-L-Mega version on the bigger lathe (small lathe still taken apart). I will make this version before the end of this week.

@crashguard If you don't change your current setup, you (and I) have a great way to test this on a real problematic setup. I will make the debounce time selectable in code to suite for different setups.

[HuubBuis]

I will have a look at the code tomorrow because it should limit the measured RPM to 1000/33*60 = 1818 RPM and I can run a whole lot faster and still get an accurate RPM reading.

On the Index and Sync pin there is no debouncing. This is why RPM speeds above 1800 can be measured.

You could try the GRBL-L-Mega version. The 33 ms software filter (debounce) could do the trick on the index signal.

No need to try this, it wouldn't make a difference for the reason above.

Currently the debouncing is done using the watchdog timer. This allows a minimum debounce time of 16 ms, to long for index or sync pulses. I need another timer, probably the timer that measures the time between index and sync pulses.

[Bi7Wis3]

Checked my rpm pulses... They are very clean.Found my portable scope. https://youtu.be/h2ijTHKiXcY

[HuubBuis]

Yes these look OK and are better than I expected. This doesn't mean you don't pickup high frequency spikes that give a false triggers. I expect that a minor debounce filter will solve this problem. I will connect my scope to my signals and check how they look. I think my logic analyzer has an option to detect missing or false pulses. Seems I have something to do...

Started on the debouncing fix and run in to severe troubles.

[HuubBuis]

I hooked up my scope to the bigger (1.5 kw DC spindle) lathe. Measured (used peak detection) at 300 and 600 RPM. The results are not what I expected, but could be the course of your problems. This lathe has optocouplers between sensor and mega board. 300 RPM 600 RPM

[HuubBuis]

Same measurements of the small lathe, 500W Servo spindle and 8 sync magnets, sensors connected without optocouplers to the arduino uno board. The RPM is less stable probably due to the "poor" regulation of the servo or the lower mass of the spindle. There are "no" spikes. 300 RPM 600 RPM

[HuubBuis]

I managed to brick 2 mega boards and one nano board today, don't know how. I can't test the ramps version any more. I will try to find a solution for the uno board that is also usable on the Mega and Ramps board. Will be continued...

[HuubBuis]

I have checked the both lathes and found a significant difference. The small lathe is finished. It has a dedicated shield on top of the Arduino Uno and all sensor wiring is done using (Foil Shielded Twisted Pair) FSTP cat 5E wiring. The bigger lathe is unfinished. All sensor wiring is done using unshielded cables. Wrapping the censor cables by a piece of aluminum foil could make a difference.

[HuubBuis]

I have added software debounce to the GRBL-L-Mega and RAMPS version. It will debounce the pulses on the Index and Sync pin. I have added a new configuration setting for the debounce time ($41) having a default value of 0 (disabled). The debounce time is in 4 us tics. The tic count ($41) is settable between 10 and 50000 tics. A setting of 0 (default) will disable this debouncing.

I added an extra check for a valid index and sync pulse in the G33 threading code processing. This will also eliminate high frequency pulses even if index and sync debouncing is disabled ($41=0).

I have tested the RAMPS version on the desktop using the Spindle index/sync simulation and the Mega version on my bigger lathe. Did a threading test at 700 RPM, 0.5 mm pitch, several passes, they all lined up (as usual). The problems in my RPM readings (onley this lathe above 1200 RPM) are now gone (debounce tics $41 = 10) using the smalles debounce filtering.

I will publish this version in a few weeks, after using it some time.

Beware, flashing this version will erase the current configuration. GRBL-L-Mega-Ramps (4).zip

[Bi7Wis3]

OK .. I'll test a.s.a.p. 2 days ago i wanted to try to do a M10 thread and stopped because my rpm's where all over the place. Hooked my scope up and checked my sync pulses this time. They looked really awful, i think i do have a grounding problem in my system and going to sort that out a.s.a.p. too.

[terjeio]

I plan to add spindle sync to the Teensy 4.x driver for grblHAL. I finally got around to install a new lead screw on my lathe, the MSP432 driver now has promising results. G76 testing next on my lathe todo list.

[HuubBuis]

I had a look on how you managed to get grblhal running on so many different boards. Really impressive. I am thinking some time about the next challenge and i am considering grblhal. The video look really well. I am however a bit concerned about PID. Tuning PID settings is not every body's cup off tee and when set wrong, do more bad than good.

[terjeio]

@HuubBuis It would be nice if you could help with testing/coding for grlbHAL.

I am however a bit concerned about PID.

And I am a bit concerned about having a feedback loop with no tuning options at all, from the posts above I guess that is how you have implemented spindle sync? So which cup of tea is preferable is a matter of taste. The good thing about open source code is that it may be changed to suit whatever preference one have. IMO grblHAL should be fairly easy to change to a different control algorithm, possibly at the driver level as I have made some motion data available to the step function. It would perhaps be nice to have some options to choose from?

A side note: my gcode sender has a PID Tuner screen to help with tuning as well as screens for lathe tasks such as threading and turning - with more in the pipeline.

[HuubBuis]

@HuubBuis It would be nice if you could help with testing/coding for grlbHAL. Yes I will help testing and coding. For coding I first need to able to test on a lathe so that is the first thing to do. This is my plan: I will modify one lathe to make it easy to change controllers. I will make an interconnection board between the controller and the lathe that uses a flat cable connector for the controller. I will use an optocoupler for each pin to make it safe to use 5V and 3.3 Volt controller boards. For each controller board I will make a shield for connecting to the interconnection board. I will make all the shields the same size and use the same mounting hole positions. I target the first week of September to have the hardware ready.

At the moment I have an ESP32 WROOM board and a STM32F103 board that could be used. I prefer a WiFi connection to the controller so my first choice would be the ESP32 WROOM board to start with. As an alternative i could order an Arduino Nano 33 IOT (don't know if there are enough pins), an Arduino Zero or Arduino Duo. Then there is a re-arm board that probably can be used to.

[terjeio]

@HuubBuis I am not too fond of ESP32, at least it should be checked for how it behaves when it does a page load of program code from flash before you start. This since there is no memory mapped flash on-chip, code runs from RAM.

I would prefer a MCU with a FPU, all you mentioned does not have that (except ESP32 which has a relatively slow one that crashes the MCU if accessed in an ISR). The STM32F103 is a bit short on timers so not a good candidate. A plus for the Re-Arm is that is possible to hack for debugging, I have done that, I use MCUExpresso for development and a J-Link for uploading code/debugging.

The MCU I would go for is the IMXRT1062 on a Teensy 4.0 or 4.1 - 4.1 has the option of adding wired Ethernet. Plenty of peripherals including two quadrature encoder interfaces - and insane speed. Downside for me is the Arduino IDE... There is a issue/discussion regarding Teensy 4.1 and grblHAL that may be of interest.

[HuubBuis]

except ESP32 which has a relatively slow one that crashes the MCU if accessed in an ISR

I had that problem some 40 years ago on intel cpu's boards ( If i remember correct, 8088 CPU) that had an (extra) FPU processor. The problem was the small (8 x) FPU stack that reached (sometimes) it's limits when Floating point calculations where done in ISR's. Disabling the FPU was the solution that time, that solved the problem.

Downside for me is the Arduino IDE.

I use the arduino IDE only for uploading and testing example sketches. For Atmel AVR development just Atmel Studio 7, AVR dragon debugger, no Git but sourcesafe (i know, don't laugh).

The MCU I would go for is the IMXRT1062 on a Teensy 4.0 or 4.1

I thought you where using a Teensy 4.0 board! I think, testing on different type of boards (at least 2), is a good test for the HAL part of grblHAL in the long term.

That Teensy board only has 23 I/O pins on the headers (if I counted right). To access the rest, you need to SMD solder a connector. Not something that most users can do.

Take your time and let me know what you prefer. In the mean time I will test on the bench using the ESP32 WROOM. Got it finally running after 2 days of struggling.

Not every application needs 6 axis. My rotary table uses 1 and maybe a second one for driving the locking system.

[terjeio]

I use the arduino IDE only for uploading and testing example sketches.

I do the same, lack of debugging is my main gripe.

I thought you where using a Teensy 4.0 board!

I only use Texas Instruments boards/MCUs for my machines - a MSP432 for the lathe. My CNC BoosterPack gives me flexibility for those. I have made prototype "motherboards" for some cards: MKRZERO, ESP32, STM32F103 Blue Pill and Teensy 4.0. This allow me to use the CNC BoosterPack for these too (for testing) - kind of similar interconnect system you described above.

Teensy 4.1 has 42 I/O pins on the headers - more than enough.

[terjeio]

@HuubBuis I have created a new issue over at my repository as a place holder for discussing spindle sync for further drivers.

[HuubBuis]

I have made 3 video's showing grbl spindle sync threading on my lathe, a line up test, threading M8 x 1.25 at low load and threading M16 x 2 under load.

Threading Lineup test Threading M8 x 1.25 at low load threading M16 x 2 under load

[hitchhiker85]

Hi, I'm using GRBL on my lathe now, and am also interested in threading/spindle synchronisation. My lathe already has an encoder on the spindle for the RPM display, and I'm hoping to be able to do threading without having to install another servo motor and clutch system. It's a mid-sized lathe, and such a conversion would be a major project.

• Does anyone know if there have been any attempts (open-source, available) to extend GRBL with spindle sync?
• If I would tackle this myself, can you give me some hints where in the overall structure would be the best place to insert it? I'm still trying to understand the detailed workings of the motion planning. My current assumption is that it would have to go into the planner. The spindle-directed speed could maybe be handled similarly to feedrate override, or by adjusting the current feed rate on the fly. The synchronisation is trickier, as it needs to plan in the lead-in and lead-out, as well as the acceleration ramp, to come out at exactly the right place once it hits the proper feed.
• is there already a fork that has a spindle encoder input for other purposes, e.g. closed-loop RPM control? If so, it would probably be a good idea to start there, so that the wiring and overall code structure is consistent.

hi! can you tell me which pin is for the spindle sync signal please?

thanks

[HuubBuis]

Have a look at the Wiki GRBL-L-Mega Threading setup and use The pins for the Arduino Uno and Arduino Mega are the same

[fschill]

Hi @hitchhiker85 , I have done a start on this a while back (see towards the top of the thread), where I did exactly what you describe: using the existing RPM encoder of my lathe. My current state of this code is here: https://github.com/fschill/grbl-Mega/tree/spindle_sync (spindle_sync branch). It is unfortunately not complete yet, and I didn't have time to work on it for a while now. Hopefully it could provide a good starting point for you though. Quick overview of what I did so far:

• added spindle_encoder to capture the speed signal from a single encoder (no quadrature, as my lathe only had a single-channel encoder).
• added spindle_sync to implement an extended "Dwell" command that waits for the spindle angle to go through zero. I also added some interpolation at some point to try and have arbitrary start angles, but can't remember now if that worked or not. So assume that part is untested. The "wait for zero" works.
• implemented a G95 "feed per revolution" mode, where the feed is proportional to spindle speed. This is woven into the existing GRBL code in a few places, to adjust the feedrate in realtime based on the encoder (a bit similar to feedrate override). Maybe do a diff to see the places.

with these parts, it's possible to do threading already, although it's a bit involved (see example GCode in the readme). As I don't have an explicit zero encoder, all passes should happen in the same operation without stopping the spindle. Also, I think you need to stay in G95 mode, as leaving the mode might reset the angle (this could probably be improved).

My next step would have been to implement a proper "canned" threading cycle, which carries out multiple passes and does the incremental depth and starting acceleration properly. And also improve the feedrate adjustment to a position-correcting mode, instead of just setting the feedrate (i.e. do some feedback to remove drift errors on long passes). I hope this makes sense, and helps in some way. I won't have time to work in this right now, but it would be great if someone wants to take it further.

[fschill]

@HuubBuis cool, seems yours is a lot further ahead, I should check that out some time.

[HuubBuis]

@fschill I have based my code on your spindle sync branch, added what was missing and did some improvements. I am/was sure this was mentioned in the WiKi, but I can't find it. I will add it now.

I am using GRBL-L (Mega) over a year now and it is working reliable.

Currently I am supporting @terjeio for the grblHAL branch. I expect that the faster ARM processors make it possible to use more complex calculations to keep the synchronization tighter. Lathes with low torque spindles (like mine) could benefit.

[terjeio]

grblHAL has an additional lathe mode that enables support for G7, G8, G33, G76, G95, G96 and G97. G33, G76 and G95 requires a driver that is capable of handling spindle sync, currently only available for the TI MSP432 processor. On my todo list is adding spindle sync capability to the iMRXT1062 (Teensy 4.x) and STM32F401/F411/F446 (Blackpill and Nucleo-64) drivers. AFAIK @HuubBuis is working on a SAMD21 implementation.

My gcode sender has a lathe mode as well, including conversational g-code generation for threading etc. A couple of videos and sender screenshots can be found here.

[hitchhiker85]

grblHAL has an additional lathe mode that enables support for G7, G8, G33, G76, G95, G96 and G97. G33, G76 and G95 requires a driver that is capable of handling spindle sync, currently only available for the TI MSP432 processor. On my todo list is adding spindle sync capability to the iMRXT1062 (Teensy 4.x) and STM32F401/F411/F446 (Blackpill and Nucleo-64) drivers. AFAIK @HuubBuis is working on a SAMD21 implementation.

My gcode sender has a lathe mode as well, including conversational g-code generation for threading etc. A couple of videos and sender screenshots can be found here.

can you sy me exactly which msp432 i need? thanks

[markotime]

GRBL L Mega on 2560. 4 pulses/rev sync, using D20 and D21 (Int 1 and int0 respectively. G33 issue, z rate goes to MAX speed configured in $112. INDX is detected, initiates start properly. Sync signal must be getting to processor, as error shown if I disable it. have tried very slow spindle speed, but same problem. Max Z rate used regardless of spindle speed. Have NOT defined rate in a g33 program, expecting it to use sync rate. I'm lost, would greatly appreciate a hint or two / thanks so much - I LOVE GRBL-L-MEGA!

[HuubBuis]

using D20 and D21 (Int 1 and int0 respectively Originally the index pin is on the Y-limit pin D12. Did you change the code?

G33 does not need a feed rate. The feed rate is calculated based on the frequency of the index pulse. The RPM is reported. Check if the reported RPM matches the actual RPM.

If you have an oscilloscope, check the signals, maybe you pickup noise.

G33 works also with only an index pulse. Try that to get started. Once that is working, it is time to add synchronization pulses.

Have you read the WiKi

[markotime]

thank you so much.

1. The Sync and Index pins are accurate, and I get errors 18 and 19 if I disable either. I wasted days on earlier pinouts, such as D12 / Ylim, which ALWAYS rendered errors, including 40. The Int0/1 pair operates error free.
2. I tried $40=1 , no help.
3. No reported rpm. The index pulse is active and proper, in that for a given spindle rpm, (Z always goes to max as defined by $112), the start point of a thread is duplicated between passes, and between runs of the code, but obviously the pitch will be wrong.
4. No feed rate is specified in my code, so yes, should be dependent on (index? not SYNC? - only for $40=1)
5. Two different mega2560 boards and Ramps 1.4 boards, same results. The scope shows clean pulses, and I've had to load up every wire with clip-on ferrites, as brush noise was killing the USB signal integrity. I also experimented with your debounce value for "probe" and presumably synch. From 0 to 2000, no change. Still wondering what I am missing / sorry for the intrusion, I do not know where else to turn / thanks / mark in canada

[markotime]

Just one other point - the X axis has some backlash. A G0 command to back off and then to take the tool tip to the surface of the workpiece does exactly that. however, during a threading pass, the same backoff and approach to the workpiece command leaves it short, by about 1mm for a 4.75mm workpiece. I began by plunging the tool to the z axis, so backlash in that direction should be taken up during the first part of the approach. Having dealt with backlash on previous machines, this should not have happened... / thanks

[markotime]

THe use of Int0 and Int1 is per your Jun 2020 note on Ramps setup.

[HuubBuis]

There is a GRBL-L-Mega RAMPS branch that is bench tested and users have reported it to work OK.

If threading synchronizes, than a lot of the code must function OK.

Backlash isn't an synchronization issue if the movement before the synchronization passes is always the same and minimal the size of the backlash.

In my CNCL software I had an issues where the decimal point (country dependent) was treated as a comma. I was unalble to reproduce it on my PC's but fixed it in the conversion from number to string. Try sending a g33 command with the k value as a whole number in the Arduino console.

In the Arduino console, you must see the measured RPM in the feed/speed section of the ? information. On my lathes, that RPM value is absolutely spot on.

[HuubBuis]

When you start a threading pass, the spindle is turning but the Z-axis not. After the Index pulse, the Z-axis start to move at max rate to catch up and slows down to the required speed once in sync. You have to start some distance from the tip so the z-axis has time to get in sync. The larger the difference in max-speed and threading speed and the lower the acceleration of the z-axis, the more travel is needed to get in sync. Test a 0.5 mm pitch at 100 RPM and position the tool 50 mm from the tip. That should give the z-axis enough time to get in sync.

[markotime]

Thank you, found my problem, syncs in about 3mm. Greatly appreciate your help!