[gnea/grbl-Mega Issue#26] Lathe pulse input for threading (feature request)

#1 – HuubBuis 于 2018-04-02

I do threading on my lathe using GRBL and a stepper (Nema 23) on the spindle controlled by the GRBL Y-axis. It works using unmodified GRBL V1.1.

#2 – X3msnake 于 2018-04-02

Can you share some pics?

What sw are you using for lathe?

No dia segunda-feira, 2 de abril de 2018, Huub Buis < notifications@github.com> escreveu:

> I do threading on my lathe using GRBL and a stepper (Nema 23) on the
> spindle controlled by the GRBL Y-axis. It works using unmodified GRBL V1.1.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/gnea/grbl-Mega/issues/26#issuecomment-378063078>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AKke-lrhAfEbn6obUiSO6V3H7jkoCOS_ks5tkqKegaJpZM4N1dzH>
> .
>

—
Com os melhores cumprimentos,
Vinicius Silva

#3 – HuubBuis 于 2018-04-03

Here you find all drawings, pictures, electronic designs and documentation for all my lathe modifications:
My Lathe

For software I use (my own) CNCL

Any question please ask

#4 – X3msnake 于 2018-04-03

Cool mod. Thanks for sharing.

Do you know of any open source lathe controller?

I rather use open source software only whenever i can, even more if it is
for non comercial use

No dia terça-feira, 3 de abril de 2018, Huub Buis
escreveu:

> Here you find all drawings, pictures, electronic designs and documentation
> for all my lathe modifications:
> http://www.mwt.messageboard.nl/forum/viewforum.php?f=6&sid=
> de7d4c9bb90499dcd929779c5766f05b
>
> For software I use (my own) CNCL https://www.microsoft.com/
> store/apps/9P42TB5T697H
>
> Any question please ask
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/gnea/grbl-Mega/issues/26#issuecomment-378182358>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AKke-rGsjR66Ey89XZ2mOYbsA7DqZaiBks5tkzx7gaJpZM4N1dzH>
> .
>

—
Com os melhores cumprimentos,
Vinicius Silva

#5 – HuubBuis 于 2018-04-03

There are a few GCode senders (https://github.com/gnea/grbl/wiki/Using-Grbl) together with a cam program that supports GRBL, you are ready to start, but no threading. All other software i have found are based on their own (some times GRBL based) hardware solutions. That makes CNC on the lathe a bit expensive for most of us.
For mach3 there are lathe extensions, but they also are expensive. Then there is the printer port that is not supported under windows 10.
Linux CNC is also a way to go, but i didn’t find good support for the lathe and they also need a printer port.
There is an opensource controller (http://smoothieware.org/) i looked at. I could make the board my self but it would be more expensive than the arduino boards and it needs a gcode generator/sender.

I now have a small tablet, wireless connected to the lathe, can do treading and lot of cool stuff and can still uses any other GRBL compatible software, hard to beat! Nevertheless, I check weekly the internet for affordable CNC lathe solutions but until today without success.

#6 – fschill 于 2018-06-21

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.

#7 – HuubBuis 于 2018-06-21

I use GRBL and do threading by adding a stepper on the spindle axis. It is controlled by the GRBL y-axis. Now threading is just adding some rotation when the Z-moves and that is handled by GRBL. Until now I used a Nema 23 , 2 Nm stepper. Recently I upgraded (for the wrong reasons) to a Nema 24, 4 Nm stepper. This way i have no synchronization problems and it a lot more accurate than using a single pulse synchronization.
I think 2Nm is enough because i mostly make small parts. For the larger threads, is just takes a bit more time, but it’s runs automatically so who cares.
Besides threading i know can also do knurling using a cutting tool, grinding (drills, mills, slit saw disks, etc) broaching and more.
The stepper is engaged by a lever. For normal turning I still use the original spindle motor.
For drawings, pictures and documentation look at: My Lathe
Your encoder for the spindle probably only has one pulse. You could consider adding a separate encoder and closed loop controller (depends on the motor). Then it would just look like a stepper to GRBL. I considered doing this, but the cost would be high and the gain just more torque during threading. Most of the time I can’t even run the 2 Nm stepper at higher speeds due to the deflection of the small parts I make.

#8 – fschill 于 2018-06-21

Hi HuubBuis,
I’ve read your comments above. It is certainly a way to do it, and has additional advantages if one wanted to go further (mill-turning, indexing, etc.). But for now I’m looking for a software solution: essentially, implementing the tapping cycle as it is defined in GCode. My spindle encoder has 4 pulses per revolution, and as it’s a fairly heavy spindle, and RPM-controlled motor, the speed is pretty constant. I think it will be ok to interpolate the speed and spindle position in software. And if not, it’s relatively easy to mount a higher resolution encoder. I don’t want to mess with the existing motor (230V 1.5 kW), so doing closed-loop with that is not so easy. Also, it’s a V-Belt so it won’t keep good sync for very long I’d think. I could mount a separate motor and a clutch system, but that’s a major hassle. Also, I’d like to run automated repeat cycles, so having to manually switch over for threading would be annoying.

Regarding a software solution, the nice thing is that it’s only some work to do once, and then anybody can use it immediately. Mounting an encoder is easy (maybe it’s already there anyway), and threading is a super useful feature. It’s also a major reason to convert a lathe to CNC, because it’s then easy to do any thread with out having to change gears. And it’s even possible to cut conical gears, e.g. pipe threads.
I had a closer look at the code, and my current best approach angle is to tap into the “plancomputeprofilenominalspeed” method in planner.c. It already gets called by stprepbuffer regularly from what I can tell, and testing the feedrate override, it gets applied fairly instantly within line segments. The comments say that the segment buffer holds 40-50msec of steps, so one would have to take some latency into account. For adjusting the feed, it might be ok, assuming that the speed is fairly constant, and that threading is done at fairly low RPMs normally. Syncing could maybe also be done there. It would require taking time into account, and explicitly predicting ahead and aligning the execution of line segments with the spindle position (closed loop speeding up/slowing down the feed to get into sync during lead-in). As the acceleration limits have to be observed, it would have to be done at some planning stage before the actual stepper loop I think, as sudden jumps in the stepper outputs would be problematic.
My current thought is that the motion primitive to aim for is “reach a certain position with a certain speed at a given point in time in the near future”. The tapping cycle could then be built on top of it.
I’d appreciate further ideas or suggestions where the best place would be for this, or any other ideas that would help.

#9 – fschill 于 2018-06-21

FWIW, I also have a clone of grbl-Mega on my github account: https://github.com/fschill/
I extended it to 5 axis control, and made the tool offsets work for all axes, not just Z (on lathes I need offsets for X and Z). Also working on a simple, real-time GUI for semi-manual operation, running on a raspberry with touch screen – haven’t published it yet, but planning to do so soon.

#10 – tklus 于 2018-06-21

That is great news! I have been patiently waiting for this…

I have an extra pi that I could use for testing this out once it’s published

Thanks for all the hard work…

I am hoping to start converting my lathe soon

#11 – HuubBuis 于 2018-06-21

I use tool offsets on all axes but don’t have a tool changer. So for me, engaging the stepper by the leaver isn’t a problem. If it was, i would put an actuator on it.
If GRBL has to synchronize, it would not only cost more programming power put also additional code. And there is no room for extra code on the Arduino. The atmega port, i think, is also maintainded by Chamnit. There you have more memory and pins. I think that is a better to start with. Chamnit, the developer is busy changing the code so porting GRBL to other hardware will be easier. After that he will probably port GRBL to arm.
There are more open source stepper controllers that have support for threading and spindle synchronization. The problem is their boards are “expensive”, but maybe, like me, you can build your own boards. Having a look at their code could also bring up some ideas.
My lathe as a variable speed spindle. Due to its low torque, synchronizing with only a single pulse would definitely give bad threads at the first rotations. I would definitely need more synchronization pulses. I think 100 will do!
You are building a gui on a raspberry. I considered a raspberry also, but decided for a 7″ tablet. I now have a small screen, touch control, WiFi and Bluetooth connection for 70$. I can’t build this, that cheap, based on a raspberry. And the software on the tablet (windows 10 App) also runs on a PC without modification.

#12 – X3msnake 于 2018-06-21

Other open source stepper controllers as alternatives can you name them
please?

No dia quinta-feira, 21 de junho de 2018, Huub Buis < notifications@github.com> escreveu:

> I use tool offsets on all axes but don’t have a tool changer. So for me,
> engaging the stepper by the leaver isn’t a problem. If it was, i would put
> an actuator on it.
> If GRBL has to synchronize, it would not only cost more programming power
> put also additional code. And there is no room for extra code on the
> Arduino. The atmega port, i think, is also maintainded by Chamnit. There
> you have more memory and pins. I think that is a better to start with.
> Chamnit, the developer is busy changing the code so porting GRBL to other
> hardware will be easier. After that he will probably port GRBL to arm.
> There are more open source stepper controllers that have support for
> threading and spindle synchronization. The problem is their boards are
> “expensive”, but maybe, like me, you can build your own boards. Having a
> look at their code could also bring up some ideas.
> My lathe as a variable speed spindle. Due to its low torque, synchronizing
> with only a single pulse would definitely give bad threads at the first
> rotations. I would definitely need more synchronization pulses. I think 100
> will do!
> You are building a gui on a raspberry. I considered a raspberry also, but
> decided for a 7″ tablet. I now have a small screen, touch control, WiFi and
> Bluetooth connection for 70$. I can’t build this, that cheap, based on a
> raspberry. And the software on the tablet (windows 10 App) also runs on a
> PC without modification.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/gnea/grbl-Mega/issues/26#issuecomment-399254131>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AKke-tgvU93vdwaD2s0IiOpzd35-HaQks5tBR5gaJpZM4N1dzH>
> .
>

—
Com os melhores cumprimentos,
Vinicius Silva

#13 – HuubBuis 于 2018-06-21

Google on “open source CNC controller”
https://buildbotics.com/
http://smoothieware.org/
https://www.thunderclap.it/projects/60431-open-source-cnc-controller
https://openbuilds.com/threads/openbuilds-apex-controller.9186/

and there are more!

#14 – fschill 于 2018-06-21

Before this thread derails too much, I’d like to keep it focused on the original topic: Lathe pulse input for threading, i.e. software sync of an open-loop spindle, for grbl-Mega (as this is a thread on the grbl-Mega repository). (Also, I’m not going to buy your software, and I’m not a windows user…)

Any suggestions by the maintainers would be much appreciated, particularly to avoid integration issues later. @chamnit if you have time, can you give me some pointers about the bigger picture?

Regarding encoder ticks/rev, it remains to be seen what the minimum is to get good results, and it will obviously vary depending on the lathe and RPM stability. The easiest would probably be a super-high res encoder (>500-1000 ticks), so that it’s enough to keep track of the spindle position with an interrupt, and just query the position and speed at any update step. To make it work with lower-res encoders, and at slow RPM, interpolation is required to fill the gaps between ticks. This is more work on the software side, but would make it more flexible. It may require two different versions, as the interpolation method might be too slow for a 1000-tick encoder signal. I think it’s a matter of getting started somewhere, and testing what works, and what precision is achievable. 1 tick/rev is most likely not enough. 4 ticks/rev as on my machine is probably borderline – I think on my machine the speed variations within a quarter revolution are fairly small, but smaller machines might have more trouble. But given that 20-30 step/rev are fairly easy to do with a variety of methods (magnets+hall sensor, DIY optical encoder with lasercut or hand-cut wheel, etc.), it would be worth trying to get an interpolation method to work.

In any case, I see three separate functions:
1) a module to measure and report spindle position and speed at any time (either interpolated or direct),
2) extending the motion planning to execute precisely timed motion segments,
3) a higher-level canned cycle for threading, that breaks down the gcode into lead-in, feed and lead-out segments.

I think 1) is completely independent of everything else. 2) would probably have to go either into the stepper update interrupt (if fast enough), or one layer above into the “stprepbuffer”.
3) is at the same level as arc interpolation in the planner, and fairly straight forward once 2) works, I think. Any opinions/feedback on these thoughts?

#15 – fschill 于 2018-06-21

silly question (maybe): I will need a way to measure elapsed time accurately (at least relative to the stepper ISR). I can’t find any way to get current microseconds or anything like that. Does that exist already, or do I have to add it? I’d add a counter to the stepper ISR. Just realised though that the refresh rate of this may change (at least if AMASS is disabled). Any easy way to find out the current ISR rate, or alternatively, is AMASS ever turned off, and can I just assume a constant update rate?

#16 – 109JB 于 2018-06-21

@HuubBuis Good luck with your software, but it is not a viable solution at least for me to use a stepper to power the spindle. I have a lathe that threads with a single pulse input per rev already using LinuxCNC, but would love to use Grbl on my lathe. A stepper powered spindle also requires using a separate control scheme for cutting and for threading and a change between stepper power and whatever the other spindle drive is. An pulse input for threading eliminates the need for 2 different control schemes and all the switching and has been proven to work on countless installations of other machine control software (LinuxCNC, Mach 3, Turbo CNC, etc.)

I also have my doubts as to whether a stepper powered spindle can have enough torque. Sure you have been able to cut threads, but how big, and even the lightest threading cuts on a large diameter will require a good amount of torque. For a stepper based solution that would require multiple gear ratios between stepper and spindle.

as far as:

> If GRBL has to synchronize, it would not only cost more programming power put also additional code. And there is no room for extra code on the Arduino.

You do realize this is posted in the Grbl-mega issues forum and the mega has plenty of room for additional code and plenty of pins. Also, another user is already working on an encoder based solution that I think has great promise. Instead of using the arduino clock to time the step signals, it uses the interrupt from the encoder to do it. A wonderfully simple concept. I’m hoping he’s still working it.
https://github.com/gnea/grbl-Mega/issues/58

#17 – fschill 于 2018-06-21

@109JB thanks for the link to the other thread – was not aware of it (which is why I asked if anyone is already working on it). Will read and see how to proceed.

#18 – HuubBuis 于 2018-06-21

@109JB @fschill

No i was not aware this is the xmega thread.
With a stepper on the spindle, any cnc software can do threading.
I do Cr42Mo4 M40 with 2Nm stepper.
Thanks for the encoder/interrupt solution, great idea.
I get the impression my contribution is not appreciated. I will unsubscribe.

#19 – bsherman100 于 2018-06-22

I’m very excited that work is being done on this, I am looking to adapt a AS5147 to my lathe.

https://www.mouser.com/ProductDetail/ams/AS5147-EK-AB?qs=sGAEpiMZZMvxVoyCXc2K7r%2f0QHff57jdQtyR0Erk%252brE%3d

#20 – X3msnake 于 2018-06-22

@HuubBuis that’s just your impression your input is welcome.

#21 – 109JB 于 2018-06-22

@HuubBuis It is not that your contribution isn’t appreciated, It is just that not everyone agrees with your approach. If it works for you that is great, and if it even works for someone else, that is great too. Not everyone is going to agree with you all of the time. Don’t take it as that your contribution is not appreciated. Not everyone has to agree all the time. Do you ever disagree with your friends, or family?

#22 – fschill 于 2018-06-22

@109JB looking at the other thread by @shooter64738, I think it’s an interesting approach, but will be limited to high-res encoders to work. For rigid tapping quite interesting, as the spindle needs to accelerate anyway, and then reverse, but for threading there remains the problem of accelerating the Z axis for repeat cycles, to hit the thread start again. Not an easy problem. It’s one of those features that seems simple at first, until you start looking into the details
There were also some good ideas regarding encoders. I was going to simply keep count of the encoder ticks to maintain absolute spindle position, but an index pulse would be useful too. While running, counting would be enough, but when stopping and restarting, turning the spindle by hand, etc. it might lose track with a single pin low res encoder. For rigid tapping, we’d need quadrature encoding too, to detect reversal, but for the lathe it’s not needed I think. Also an interesting idea from that thread was to have a special tooth on the wheel for index, that way only one sensor/one pin is needed. I’m considering to modify my magnetic encoder by putting two magnets next to each other for a longer index pulse. But for now I think I’ll start with single-pin input, everything else can be added later.

@HuubBuis everyone’s contribution is appreciated. You already described your approach, and it’s great, but not for everyone. I had some specific questions, regarding the topic of this thread, and just repeating what you already wrote earlier didn’t add additional information. I also found it strange that when someone is attempting to implement a new feature for this open source project, that it seemed like you are trying to argue against having this feature at all, while pushing your own solution that you sell as non-open source (nothing against doing that, software is work that should be paid). But there’s a time and a place for marketing, and these issues/threads here are the time and place for questions regarding this project (as indicated at the top of the page), not other projects.
Btw. I was also wondering where the place would be for collecting information about related projects that don’t really fit into “Issues”, like other GUIs, hardware, etc. related to GRBL. Are there lists in the wiki? Couldn’t find it.

#23 – X3msnake 于 2018-06-22

I would say the wiki yes. But i think we need to create it. Similar to the
listing of the senders sw

No dia sexta-feira, 22 de junho de 2018, fschill
escreveu:

> @109JB <https://github.com/109JB> looking at the other thread by
> @shooter64738 <https://github.com/shooter64738>, I think it’s an
> interesting approach, but will be limited to high-res encoders to work. For
> rigid tapping quite interesting, as the spindle needs to accelerate anyway,
> and then reverse, but for threading there remains the problem of
> accelerating the Z axis for repeat cycles, to hit the thread start again.
> Not an easy problem. It’s one of those features that seems simple at first,
> until you start looking into the details
> There were also some good ideas regarding encoders. I was going to simply
> keep count of the encoder ticks to maintain absolute spindle position, but
> an index pulse would be useful too. While running, counting would be
> enough, but when stopping and restarting, turning the spindle by hand, etc.
> it might lose track with a single pin low res encoder. For rigid tapping,
> we’d need quadrature encoding too, to detect reversal, but for the lathe
> it’s not needed I think. Also an interesting idea from that thread was to
> have a special tooth on the wheel for index, that way only one sensor/one
> pin is needed. I’m considering to modify my magnetic encoder by putting two
> magnets next to each other for a longer index pulse. But for now I think
> I’ll start with single-pin input, everything else can be added later.
>
> @HuubBuis <https://github.com/HuubBuis> everyone’s contribution is
> appreciated. You already described your approach, and it’s great, but not
> for everyone. I had some specific questions, regarding the topic of this
> thread, and just repeating what you already wrote earlier didn’t add
> additional information. I also found it strange that when someone is
> attempting to implement a new feature for this open source project, that it
> seemed like you are trying to argue against having this feature at all,
> while pushing your own solution that you sell as non-open source (nothing
> against doing that, software is work that should be paid). But there’s a
> time and a place for marketing, and these issues/threads here are the time
> and place for questions regarding this project (as indicated at the top of
> the page), not other projects.
> Btw. I was also wondering where the place would be for collecting
> information about related projects that don’t really fit into “Issues”,
> like other GUIs, hardware, etc. related to GRBL. Are there lists in the
> wiki? Couldn’t find it.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/gnea/grbl-Mega/issues/26#issuecomment-399331405>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AKke-i6xcT48AjDCgIyTxtxaricnAeyAks5t_IqhgaJpZM4N1dzH>
> .
>

—
Com os melhores cumprimentos,
Vinicius Silva

#24 – fschill 于 2018-06-24

Ok, I made some progress (still some way to go though). For those who are interested, my current state is in https://github.com/fschill/grbl-Mega (spindle_sync branch).

– I added an extra module for reading the spindle encoder, measuring speed and current spindle position. Still to do: interpolated position. At the moment I’m only using the current speed.
– added timekeeper.c/h for measuring time, using HW timer 5, with 4 us resolution. Used for spindle speed measurements
– added support for G95 (feedrate per revolution mode). This set an extra flag in planlinedatat and planblockt (had to change the condition variable to uint16t, as it was fully used already). The flag is evaluated in plancomputeprofilenominalspeed to compute the actual feed rate based on spindle speed. The initial value for spindle speed is taken from the gcode (M3, etc.). During execution, protocolexecuterealtime calls spindlesyncupdate from spindlesync.c, which updates the spindlespeed in the planner blocks with the actual measured spindle speed, and re-plans.

I’ve only tested it on my desk so far, with an encoder handwheel, watching the outputs on the screen. It seems to work, insofar the reported feedrate and the coordinates correspond in speed to the handwheel. I’ll still need to test on the lathe to see how well it tracks. I do not expect it to be perfect, and I’m planning to do closed-loop feedback with the feedrate to keep it in sync with the motion progress.

What is also still missing is a synchronisation to the absolute spindle angle, to be able to do multiple passes and hit the start of the thread. I think this should go into a G33 cycle that flushes the queue and waits for the right moment to start. Reading the LinuxCNC documentation, it seems that G33 always hits the start at the zero angle (index position of spindle). I don’t know if it’s possible to define an angle offset directly – it could be done by moving the start position if there is enough space for lead-in.

Potential issues:
– due to the minimum feedrate requirement, it still moves (slowly, at minimum speed) even if the spindle is stopped. This can be dangerous. During a G33 cycle, we can check at the start if the spindle has the right speed (close to the last M3 S— command), and throw an error if the speed is wrong. If speed drops too much during execution, or gets too fast to keep up, aborting is tricky, if the spindle is not controlled by GRBL, as simply stopping can be disastrous too. Checking at the start should be sufficient though.
Another approach would be to issue a hold command if the speed drops below the minimum speed, and resume if it speeds up again. Being able to completely stop and resume could be useful for manual thread chasing, or for rigid tapping in the future, but it’s not so easy to do it precisely.

#25 – shooter64738 于 2018-06-24

Hey all! I meant to get back to this a couple days ago and comment, but just didn’t get a chance.

Couple of things I have ran into that might help others (to not make the same mistakes)
1. High resolution encoders seemed like the way to go. Lower priced encoders are pretty small making the optical slots close together. Vibration on high res encoders cause a tremendous amount of erroneous ‘bouncing’ This causes the angle to eventually get completely lost. The controller thinks the spindle has moved but its just picking up signals caused from the encoders internal wheel bouncing. On a lathe with a heavy chuck and spindle, this may be less of an issue, but its really been a killer on a mill spindle, even if its mounted to the drive motor.
2. High resolution encoders suck the life out of the avr running grbl. A 600 ppr encoder running quadrature mode produces 2400cpr. Somewhere around 3000rpm grbl spends more time trying to handle the interrupts from the encoder than it does in motion. So in general, using either one channel from the quadrature, or just a lower res encoder would actually work better to some degree.

I was never able to completely solve issue 2, and I was pretty bummed by the 4th or 5th time working through it on the bench only to have it fail in practice. So I went with a separate board (a nano) to control my spindle. Since it has very little to do, it can handle a pretty high count rate from the encoder. A simple formula translates encoder ticks per rev into a step pulse value. So for example every 7.2 encoder ticks, I need to send a pulse to the grbl system pin, which causes grbl to run through the motion code one time. This did create the need a gcode parser on the nano to get the programmed feed rate and mode, along with spindle speed and direction.

I do think an index is going to be needed so that if the encoder position does get lost at some point, it would never be in error more than one revolution. This could go beyond the scope of a hobby cnc system though.

I’ll get the changes I made to grbl up, and you can see how it worked better. The majority of the work I did was on a separate controller, and I haven’t gotten to work on it much since April. I have written so much code trying to get this to work, I’ve pretty much ported the entire grbl project to c++ in fragments. @fschill the only concern I would have with your approach is overloading the avr with other ISR tasks. There probably is a way to keep it all on the grbl board but I was never satisfied with the methods I tried. If you have it working pretty well on a bench, put your encoder on a drill and run it at 2000 rpm and see how it does. I know some systems use only the programmed spindle speed to set the feed rate (assuming the spindle is right) and others read the spindle rpm at motion start (and assume it stays there). Obviously the best approach is reading it constantly and adjusting as needed.. Its a simple and complex problem all at the same time!

My upload of grbl is here: grbl 6 axis synch. Its far from done for sure. Most of my changes are in planner,stepper,system, and I added rtc.h and rtc.c Hopefully it will be useful to other people, this is by no means the only way to do it..

#26 – fschill 于 2018-06-25

thanks for your comments! On my lathe I actually only have 4 ticks/rev (magnetic sensor, 4 little magnets in a ring on the shaft sensed by a hall effect sensor). This was already built-in for the RPM display that came with the machine. I checked with the oscilloscope, and it gives a clean, stable output. It’s not a symmetric signal though, it is normally high with short low pulses when a magnet goes by. So I think this will be ok regarding signal quality and interrupt load. For getting the exact spindle position, it will require time-based interpolation though, and it is less quick to pick up spindle speed variations. I was planning to do closed-loop progress tracking, and fine-tune the feedrate to keep the tool in sync. At the moment I only adjust the speed, which could accumulate drift over longer distances. We’ll see how well it works – I think for short threads with a constant spindle speed it might already be enough, but would be nicer to guarantee good tracking. Directly coupling the steppers to the spindle encoder would be more precise, but then we have to worry about obeying acceleration limits, and would need a high-res encoder.

Regarding index pin, my thought is to keep it as flexible as possible. If there is no index pin, it will just keep counting. I see the biggest risk here when using only a single-channel encoder without index or quadrature, and stopping the spindle, e.g. to check the thread. Maybe it’s a matter of documenting clearly what the limitations are for single-channel encoder w/o index, with index, with or w/o quadrature, and regarding number of ticks/rev.

The ISR load on the AVR is a good point. For testing, I actually also have a 600 line encoder on my desk, but no motors attached so I can’t really see how smooth the motion output is, and if there is any stuttering. And of course no vibrations. I only use the falling edge in the interrupt, so that can help to reduce the interrupts/second, and I’m only using one of the channels for now. Instead of having both channels on interrupt, you could also get the direction with one interrupt and simply reading the other channel. If that is not enough, we could also consider to impose an RPM limit for threading (I thought that mostly this is done at a few 100 RPM at most), and refuse a G33 command if the RPM is too high. Any other time the interrupt could be turned off, or we could only use the index pin interrupt at high speeds for RPM control.
I was actually thinking of taking a second arduino to count the stepper pulses and encoder ticks, and forward this to my PC for plotting, as a debugging tool. Just reading off coordinates doesn’t really show any potential issues.

#27 – shooter64738 于 2018-06-25

(I edited this because I think I have a better idea than when I first wrote it:))
Ok at 4 ticks per rev, that would be kind of low resolution, but honestly I think that could be plenty. What if we took your idea and my idea and we mash them together.
1. Use a separate control for the spindle. It reads the pulses from your encoder, and determines rpm of the spindle. Since you have 4 sensors you have 4 reads per rev.
2. After one rev on the spindle control, send the rpm to grbl via a serial connection. Use an upper end character like char 254 to precede the rpm. grbl would know when it picks this up its an rpm from a spindle control. In G95 mode, grbl will not start motion until it gets this rpm value from the spindle control. The spindle control can have a set rate of updating the rpm, of say 10hz. Regardless of the encoder being used, it will send the rpm at 10hz to grbl. It wont send the first one until its made a complete revolution to get its first rpm, and then when it either rolls to spindle angle 0, or the index pulse is hit. This should keep thread starts pretty consistent. And if we need more than 10 updates a second, I’m pretty sure we could go to 100 pretty easily without loading grbl much.
3. Low res encoders wont/shouldn’t be an issue because grbl is interpolating/predicting the feed rate based on the rpm at a frequency of 10 times per second. Even a 100cpr encoder would be plenty because the feed rate would get adjusted 10 times per second. That seems plenty to keep up with a threading operation.

You could scale down the encoder outputs so that even a 2400cpr encoder wont send a pulse from the controller to grbl more than 10 times per second. The way I’ve been going about it, I was driving grbl with encoder pulses instead of timer ticks. Which may work eventually, but a low res encoder would give threads on a lathe that look like tiny stair steps. If we interpolate as your are planning, low res encoders wont be an issue.

#28 – fschill 于 2018-06-25

Hi,
just a quick update – I had a chance to test it on the lathe just now, with a sharpie drawing “threads” on bar stock. It looks pretty good already, even though it’s just trying to match the speed without closed-loop position tracking. It even keeps up while changing the spindle RPM from 100RPM to 500RPM and back, drawing a fairly regular looking “thread” (although I saw a little bit of unevenness when changing the RPM too quickly, and also was hitting the max feed of 800mm/min on my Z with a 2mm pitch). But the principle is sound, it works. During real thread cutting the RPM changes won’t be that big anyway. I’ll try to post a video soon, but I’m quite busy this week.
I think once I add a synchronisation point for the lead-in (within a G33 cycle), it might already be usable if precision is not that important, and if the spindle speed is fairly slow and constant.

@shooter64738 : I’m not sure if I fully understand your suggestion. I think with low-res encoders such as mine, there is no problem measuring the spindle speed in GRBL directly (as it’s working pretty well already). For high-res encoders I can see a use for an intermediate controller that downsamples the encoder (although one might also just get another encoder with less ticks). I’m not sure if sending additional things through the UART is going to help – it will introduce additional latencies if trying to adjust to varying spindle speeds during the cycle. As it will need an electrical pin anyway for the start synchronisation, it seems overly complicated to me.

#29 – 109JB 于 2018-06-25

I am only a rank amateur when it comes to programming, and you guys are obviously much better than I, but I would like to contribute as this spindle sync issue is the biggest thing preventing me from converting over to Grbl completely. That said, I have a few comments:

1. in regard to spindle rpm, whether using a separate MCU to read RPM or not, I think you need to program in a comparison between successive RPM readings before and sync move is made. The reason I say this is because you need to make sure the RPM has stabilized before starting a sync move for many reasons. As one example, my lathe spindle uses a treadmill motor and controller and has a soft start feature where the motor ramps up to speed. From a dead stop to full speed can take several seconds. Obviously spindle sync for threading isn’t going to be at full speed, but the slow accel is still there.

2. As for counts per rev. I’m not at all sure about the intricacies of it, but can say that LinuxCNC can do threading with only 1 count per rev (index). https://www.youtube.com/watch?v=jHKmcjoCyLg and the same is true for the older DOS based turboCNC http://www.dakeng.com/threading.html , and also Mach3. I am not opposed to anything that works, just wanted to point this out. The one reason I can see for trying to get this working on a single pulse per rev is because there are those out there that already have a 1ppr setup working on other control software and if they want to try it with Grbl, then Grbl would have to support this if possible, or they would have to change their encoder setup.

3. as far as encoders, many LinuxCNC, Mach3, TurboCNC users have made their own encoders
http://7xcnc.com/hardware/encoder/
https://www.homemodelenginemachinist.com/threads/mach-3-spindle-encoder.15226/

#30 – fschill 于 2018-06-25

@109JB
thanks for your input. Regarding your points:
1) I agree. I’m coming from computer science and self-taught machinist, so I’m learning how “pro” machines do it from others, and from youtube videos… For now I only implemented G95 mode, which simply adjusts the feedrate based on spindle speed to do constant-width cuts. By itself it is not enough for threading, unless you do it in one pass. For a proper threading cycle (G76), as far as I understand, the sequence would be:
– bring spindle up to speed (if it isn’t running already)
– go to a “waiting position”, far enough away from the thread start to give the machine time to accelerate to the right cutting speed
– check spindle speed, and verify that the cut parameters are within the acceleration limits and speed limits of the machine. Abort and throw error if not.
– execute lead-in move, accelerating the axes to the right speed. This should be planned carefully, so that the tool will reach the start of the thread, going at the correct speed, just as the spindle hits the “zero” mark. This is probably the hardest part. As a fallback, it might be enough to just start with the zero pulse, and always use a constant-length lead-in so that it’s at least repeatable throughout the multiple passes, even if the thread would not start at the zero angle in this case.
– execute the actual cut segment, while actively adjusting the feedrate to always match the spindle. It might be necessary to also track the progress through the cut vs. the revolutions of the spindle, as it might drift apart over long cuts due to slight speed mismatches and rounding errors
– execute a lead-out move to get the tool out of the thread at the end
– return to start position, repeat for n cycles with increasing depth, and finishing passes.
Repeat passes could be explicitly coded in GCode, it would be enough if GRBL supports a single pass as long as it can reliably hit the start point.

2. I wasn’t sure what the minimum pulses per rev are to make this work, but good to know that it’s in principle possible with just one. I can confirm it’s working with 4 pulses. As long as the spindle speed is nice and steady, it shouldn’t be a problem – the main issue is at the start of a cut, when the spindle is suddenly loaded down and might slow down significantly within one revolution. Taking light cuts can help here. I’m certainly in favour of making this feature work with as many setups as possible, and keeping the conversion work as simple as possible.
An advantage of a single pulse per rev is that it’s also the index pulse. With more ticks comes more ambiguity, but I’m hoping that it’s possible to keep count at least during a single run. Doing re-cuts after a spindle stop or end of program could be more tricky without an index pulse.

3. thanks for the links.