HuubBuis
commented
6 years ago 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.
Open tklus opened 7 years ago
HuubBuis
commented
6 years ago 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.
X3msnake
commented
6 years ago 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
HuubBuis
commented
6 years ago X3msnake
commented
6 years ago 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 notifications@github.com 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
HuubBuis
commented
6 years ago 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.
fschill
commented
6 years ago 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.
HuubBuis
commented
6 years ago 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.
fschill
commented
6 years ago 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 "plan_compute_profile_nominal_speed" method in planner.c. It already gets called by st_prep_buffer 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.
fschill
commented
6 years ago 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.
tklus
commented
6 years ago 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
HuubBuis
commented
6 years ago 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.
X3msnake
commented
6 years ago 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-tgvU93vdwaD2s0IiOpz_d35-HaQks5t_BR5gaJpZM4N1dzH .
-- Com os melhores cumprimentos, Vinicius Silva
HuubBuis
commented
6 years ago 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!
fschill
commented
6 years ago 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 "st_prep_buffer". 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?
fschill
commented
6 years ago 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?
109JB
commented
6 years ago @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
fschill
commented
6 years ago @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.
HuubBuis
commented
6 years ago @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.
bsherman100
commented
6 years ago I'm very excited that work is being done on this, I am looking to adapt a AS5147 to my lathe.
X3msnake
commented
6 years ago @HuubBuis that's just your impression your input is welcome.
109JB
commented
6 years ago @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?
fschill
commented
6 years ago @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.
X3msnake
commented
6 years ago 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 notifications@github.com 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
fschill
commented
6 years ago 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).
plan_line_data_t and plan_block_t (had to change the condition variable to uint16_t, as it was fully used already). The flag is evaluated in plan_compute_profile_nominal_speed 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, protocol_execute_realtime calls spindle_sync_update from spindle_sync.c, which updates the spindle_speed 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:
shooter64738
commented
6 years ago 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)
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..
fschill
commented
6 years ago 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.
shooter64738
commented
6 years ago (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.
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.
fschill
commented
6 years ago 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.
109JB
commented
6 years ago 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:
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.
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.
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/
fschill
commented
6 years ago @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:
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.
thanks for the links.
fschill
commented
6 years ago Maybe a stupid question: For G33, (basic threading command), is the pitch parameter (K) always relative to the Z-axis, or to all axes/total distance traveled? It doesn't say clearly in the LinuxCNC docs, but it seems to me that it's always relative to Z. For example, when turning a tapered thread, the pitch would be the same as for a non-tapered thread, even though the tool moves further. This would be slightly different to G95 mode, where the 3D feedrate is proportional to the spinde, so the z-pitch would decrease on a tapered cut.
Does anyone know how this works? What happens if someone would issue multiple moves in G33 mode? It appears to be a modal command, so it should be possible. Can I assume that for every line with a G33 ... K... on it, the machine waits for the zero sync and "engages the nut", i.e. locks the Z-axis to the spindle? And if it's additional moves in G33 mode, but without a new G33 on the line, it just maintains that virtual lock, as if it was mechanically still coupled? What happens if the second move is in the opposite z direction than the first move (reversal)? Is this an error?
fschill
commented
6 years ago Success! I wanted to get something going first before starting to overcomplicate things. The feedrate control was already working quite well even across varying spindle speeds. So to synchronize the start, I simply added an extra bit of code to the Dwell command (G4): if in G95 mode (feed in units per rev), execute the dwell, and then also wait for the spindle to cross zero before proceeding. With this it's now possible to write threading GCode, eg.:
G0 X1 Z0 ; go to start position
G95 ; Feed per revolution mode
G0 X-0.5 ; go to cutting depth, clear of workpiece
G4 P1 ; Dwell and wait for spindle sync (in G95 mode)
G1 F1 Z-20 ; start threading pass
G0X1 ; retract at end of move
Z0 ; end of passDoing repeat passes lines up pretty well with the previous cuts. It's best though to keep the spindle speed the same - it still works with different speeds, but due to the acceleration ramp in the beginning, they don't line up quite as well. I took some videos, will upload them as soon as I have time.
The current state is in my fork in branch "spindle_sync". I think it's a good basis, already does something useful. Further modes can be built on top. Beware, it's still early beta, doesn't do any safety checking (e.g. if spindle speed or resulting feedrate is too high), and may damage your equipment. Feel free to test it, but at your own risk :) Be careful. (edited - sorry, was logged in with another account...)
tklus
commented
6 years ago Great work! This will push me to get my lathe converted :D
fschill
commented
6 years ago uploaded a video showing the various stages of progress: https://youtu.be/Ia_g6kpPqtE
109JB
commented
6 years ago Absolutely awesome!!!! I do have one complaint though. Where the heck were you the past several years. I have been waiting for someone to tackle this to make Grbl useful on a lathe for some time but I unfortunately didn't and still don't have the skills to do it myself. Thank you, thank you thank you. I'm sure there will need to be more testing, but this is very exciting. I sold my 7x10 CNC'd lathe, and acquired a 9x20. I guess I need to get it cnc'd now ;)
Again, fantastic work, but I do have a few questions.
109JB
commented
6 years ago Also, do you feel that once flushed out a bit more that this is something that could be added to the mainstream branch?
fschill
commented
6 years ago @109JB yeah, I know the feeling ;) I only just converted my lathe to CNC. My milling machines were CNC converted from the start, but for the lathe it wasn't that pressing, as most parts can also be machined by hand. For me it was actually the real-time jogging feature in GRBL that I was waiting for, as I still want to use it in "semi-manual", using the steppers as motordrive and DRO. I'm also working on a hand-wheel based on a high-res encoder (600 lines) for "fly-by-wire" manual machining - I like the analog feel of hand wheels. Funny thing is, I never actually cut a thread on my lathe, as I was always too lazy to change the gears. Now that it's CNC, I figured that this should be a thing of the past now...
Regarding the current version: Yes, it absolutely needs more testing, and there could still be some surprises and bugs. Caveats I know about:
Regarding your questions:
Things still to do:
terjeio
commented
6 years ago Interesting "thread" - I have started work on spindle sync as well and plan to continue my work on that soon. I too have started with G33, I calculate the angular position from encoder input and use that in a PID-loop to adjust the segment timing. This is a test result from 15 passes or so:
Also, I want to control my lathe (an old Emco 5) from a MPG pendant so I am currently working on that - I want to use it in "standalone" mode - without firing up a PC. I am going to implement some basic operations, such as threading, by entering data in on-screen dialogs and then let the pendant control the lathe:
shooter64738
commented
6 years ago @fschill I think if you just had an index pulse, you could turn the timer on in g95, and turn it off when in g93 or g94. The ext interrupt could also be turned off unless in g95. grbl could run as 'normal' even at high feed rates pretty easily even with a high res encoder. I still dont think a high res encoder is needed. :) What you have there looks pretty good for threading. I haven't gotten to take much of a look at your code yet, but all the 'issues' listed previously could be over come fairly easy. I also don't think a quadrature encoder is needed. In G95 mode any rotation of the spindle regardless of direction should cause the controller to move towards its end point. The program would know the direction of the spindle based on the m3/m4 code. If you were to turn it by hand some amount, when you started the spindle again and went to cut another thread pass, if it didn't start motion until it hit the index, it would still start cutting at the same place.
With a low pulse rate (say something below 64 because its a nices 2's comp value) the pin change interrupt might work just as well and you could assign the encoder pulse and index pins all over the board instead of the ext interrupt. I think pin 2 on the uno is taken up for a stepper pulse pin, but I could be mistaken. There is also the issue of needing another timer, which I think is used in the uno version as a step pulse delay option. I moved to the mega board for other reasons, but there are a lot of uno board users out there as @109JB stated.
Also I believe Mach3 is known to have issues on threading passes if the spindle speed is changed due to its acceleration of the axis motion too. One way around it is to have enough lead room that by the time the thread starts to cut, the axis is beyond accelerating and is in it full speed stage. You might be able to shorten that time up by changing the acceleration rate in g95 mode to a higher value. That would limit the take off velocity of the axis because it has less time to accelerate.
All in all, it works. It may have some limitations, and if that stops someone from using it, well they can thread with a die and a T handle :) I like it. Makes me wanna build a lathe.
109JB
commented
6 years ago I like the idea of having an index pulse even if it means needing another pin interrupt. As @shooter64738 said, when not threading there really isn't a need to keep the interrupt going. I'm sure it running slows the rest of grbl down, so shutting off the interrupt while still being able to turn it back on would be nice to have.
As for the UNO vs Mega, I don't care that much really. More curious than anything. I do have more nanos and Unos lying around than Megas, but I have a couple of those too, so not a big deal to me. Just thought that since there are fewer axes that it could possibly work.
Jimbobfrank0
commented
6 years ago Even on a lot of professional cnc machines changing the spindle speed after a cut will result in a different thread being cut. This is very good work it seems I have started to build my lathe at about the right time.
terjeio that is a very nice looking pendant and dro.
terjeio
commented
6 years ago @Jimbobfrank0 : Thanks, nice looks does not compensate for a working brain - giving it one is hard work as I aim for a completely event driven GUI.
A few observations:
Feed hold should be postponed until a threading movement is complete, stopping in the middle of a pass is bad/dangerous? Even wait until retract is complete? This needs to be handled in grbl as it is a signal input as well as a real-time command. I am a newbie when it comes to lathe work so I might be wrong, anyway I am bit scared of the lathe...
I miss a real-time command for cancelling a job gracefully when holding - I like the way I can do that in Mach 3. I think a reset is a bit over the top.
Any views on this?
fschill
commented
6 years ago @terjeio Good point about feed hold. I already set the flag for "no feed override" for commands in G95 mode, as that is equally dangerous, but have not done anything about feed hold. Not sure at the moment how realtime commands could be queued - one could completely ignore it, but I do like having feed-hold always working as a safety feature. Obviously during threading it would ruin the piece, and maybe the cutting tool as well. For now, and for myself, I'm happy to just not trigger feedhold at such times. Waiting until after retract would not be possible in G33 I think, as it doesn't define a retract position. In G76 it's possible to do a "retract and hold", maybe even in the middle of the thread. Resuming from hold would be trickier - safest would probably be to repeat that pass from the start. It would get pretty complicated though.
Regarding cancelling during hold - that would definitely be good. Not sure, i thought it's possible but need to check. I also had some issues recently where it got stuck in hold during a jog that should already have been terminated, and resuming resulted in unintended motions. I do need to check my GUI though as well, could be a problem on the PC side. The current jogging mode with realtime-abort does have some issues, it's not easily possible to cancel and override current jogging motions, as would be nice for cursor-key based realtime jogging like in linuxCNC. I got it working pretty well, but there are very rare glitches, and it's not possible to transition from an active jog on one axis into a diagonal jog on multiple axes. Minor quibbles though.
109JB
commented
6 years ago Feed Hold - One could argue either way. Sure it is bad if the axes stop moving during a sync move. It will ruin the cut at a minimum, probably scrapping the part However, what if the axes don't stop until a sync move is complete? Maybe the sync move has the Z axis running right into the lathe chuck. Maybe the operator is hitting feed hold during a portion of the move where no material is being cut. One can think of a whole slew of possibilities either way.
In any case, what occurs on other machines must be weighed carefully when talking about Grbl. The way that Grbl operates with GUIs and the streaming protocols means things can happen in unconventional or unexpected ways. For example, on most machines, a "feed hold" will not stop a sync move, but a "program stop" will. Grbl has no program stop command or pin, but it does have a "reset/abort" command and pin. However, invoking it while the machine is in motion results in an alarm, and a loss of position. So, many GUIs first invoke a feed hold, wait for the machine to stop, and then reset as a work-around. Works great, but if feed-hold is disabled during a sync move, then the machine never stops, and the reset never happens. I can't see a way around this. If the machine doesn't stop when the operator expects, this could be more dangerous than a ruined part or broken tool.
Bottom line, I would vote to leave feed-hold active during synced moves.
@terjeio Why would you consider a soft-reset "over the top"? A soft-reset is no big deal on Grbl. It isn't like re-booting a computer, machine position isn't lost as long as it doesn't happen during motion, takes just a second, and flushes the buffer and any other stagnant stuff. Really just think of it a a "return to defaults" command rather than a reset, because that is essentially what is happening. Easy peasy.
terjeio
commented
6 years ago @109JB : I consider a soft reset "over the top" when holding for the reasons you give. Why should I have to cancel the resulting alarm and worry about the position beeing lost? When I do a feed hold followed by a stop in Mach 3 neither does the computer or Mach 3 restart ( a bad analogy, I know). And there is no alarm to cancel. Smooth.
Wanting to use feed hold to stop the z-axis from hitting the chuck is perhaps indicative of something amiss in the protocol? I would hit the eStop button when something is about to badly wrong, using feed hold should not be they way my brain should get trained to react in such scenarios (because I want to avoid a reset?).
@fschill : I have modified handling of jog cancel so that it flushes the serial and input buffers, this to ensure jogging motion reliably stops. I have no jogging buttons in my gcode sender GUI, I use the keyboard - and have successfully coded for 3-key rollover support. No glitches so far, even when abusing the navigation buttons, touch wood. Similar to Mach 3 jogging action can be modified by \<Ctrl> and \<Shift>, this for step and fast mode.
Feed hold during jogging is for what? I think it should be ignored or result in jogging beeing cancelled. Or is jogging regulary used for movements doing cutting actions? IMO as one famous person puts it: "Bad".
I think cancelling during hold can be done safely in a similar way to how my jog cancel behaves, flush the serial buffer, the input buffer and the motion buffer(s). I will at least try to implement such a feature for myself. I will also try to implement a delayed feed hold when executing spindle synchronized motions, I am not going to be the only user of the lathe so dangerous actions has to be blocked. It believe it should be fairly easy to implement - ignore the status flag until it is safe to act upon it.
I have forked grbl-mega and backported the changes I have done to jog cancel, I have also added code to support a secondary input stream - this to allow use of MPGs like the one I am working on. Available from my github account. Be aware that I have not subjected this to the same stress tests as my ARM port.
109JB
commented
6 years ago @terjeio -
Why should I have to cancel the resulting alarm and worry about the position beeing lost?
I am not sure what you are talking about. My implementation of Grbl does NOT alarm, and does NOT lose position if a soft reset is invoked when the machine is not moving. If the machine is in motion when reset is invoked then yes it triggers an alarm due to possible loss of position, but not if care is taken to stop motion first.
You say you have implemented a routine to flush the input and planner buffers. If this accomplishes what you want then all is good.
Wanting to use feed hold to stop the z-axis from hitting the chuck is perhaps indicative of something amiss in the protocol?
No, you miss my point. There is not "program stop" in Grbl, so Grbl's feed hold is used by GUIs for implementing one, but if you disable the feed hold for sync moves you will essentially disable the "program stop" implementations as well. This could be far worse than the benefits of disabling feed hold during sync moves as program stop should work regardless of what the machine is doing. This is what operators expect.
I would hit the eStop button when something is about to badly wrong, using feed hold should not be they way my brain should get trained to react in such scenarios (because I want to avoid a reset?).
It depends. The emergency stop is for just that, an emergency. If it isn't an emergency then there is no need to use the emergency stop. Just because a tool is heading toward the chuck doesn't mean that it constitutes an immediate emergency. It may be several seconds before it gets there and a program stop would be more than appropriate. However, if disabling feed hold has disabled program stop, instead of a simple matter of having to invoke a program stop you are now forced to use an e-stop for what was not an emergency. That is what I am opposed to. This has to do with how Grbl interaction takes place.
My emergency stop is implemented so that power is cut to the entire machine requiring re-powering, homing, possibly re-zeroing, etc. All of this because the only way to stop during a sync move would be to e-stop.
I am not going to be the only user of the lathe so dangerous actions has to be blocked.
I agree that dangerous actions need to be blocked, and if you feel what you propose is better for your situation, with your GUI and your custom Grbl, then all is well, but you are assuming that is the case for everyone and that cancelling motion during a threading cut is a dangerous enough situation to warrant disabling feed hold. I contend that not being able to cancel motion during a threading cut could be even more dangerous.
In my opinion the danger of stopping motion during threading is almost exclusively to the part and the cutting tool. Whereas, disabling a method of stopping motion could create more danger to the machine in general and to the operator as a result. There is no reason that existing GUIs can't use this newly created sync move right now because it is simply a matter of streaming the code. However, depending on how the GUI is written, this proposed disabling of the feed hold could break what is supposed to happen because of how the GUI is written. In the current release version of Grbl, feed hold works all the time no matter what, regardless of what the machine is doing, and GUIs have come to expect this behavior. Changing this expectation could have more disastrous effects than a broken threading tool or scrapped part.
Also, consider a machine with a safety door. The operation of the safety door has to stop the machine. In many cases, this is a regulation requirement. The way the safety door is implemented in Grbl is to tie the safety door switch to the feed hold pin of Grbl. Therefore, disabling feed hold during any move will disable the function of the safety door. Now I don't have safety doors on my machines, but this is an example of how a seemingly innocuous change can have unexpected results.
All I am saying is that while there may be benefits of disabling the feed hold during a sync move, it is not simply a matter of doing it without considering all of the ramifications. Perhaps what needs to be done is create another parallel realtime function that essentially does what feed hold does, but cannot be disabled. Maybe call it a "persistent feed hold" or something. Then one could be disabled during sync moves to satisfy those that need it, while maintaining one that stops no matter what. Or maybe a define in config.h so the user can select how he wants feed hold to function. I just don't think it would be a good idea to implement disabling it during sync moves as a default behavior without a way to override that selection.
Jimbobfrank0
commented
6 years ago On a normal cnc lathe feed hold while threading retracts in X out of the threads then returns to thread start point in Z. When start is hit again it will recut the last thread.
109JB
commented
6 years ago On a normal cnc lathe feed hold while threading retracts in X out of the threads then returns to thread start point in Z. When start is hit again it will recut the last thread.
I would be all for this type of feed hold implementation during thread cutting. It would still be necessary to investigation what ramifications making a change like this would have overall, and might not be trivial.
fschill
commented
6 years ago On a normal cnc lathe feed hold while threading retracts in X out of the threads then returns to thread start point in Z. When start is hit again it will recut the last thread.
I think this is the best option. All the GRBL realtime commands should always be active, and for consistency always do the same thing. We could consider adding a non-realtime "program hold" that will finish the current command and then stop, if we really want such a thing.
Some things to consider though: G95 isn't really a threading command, it's simply a mode to specify feedrate in units per revolution. This is quite common for lathes it seems, also for normal cuts, as one can simply enter the desired chip thickness. Considering this, feed hold should just do feed hold, as it would be quite reasonable to do all normal cutting in G95 mode.
G33 is a bit more closely related to threading - it locks the axis to the spindle at all time, and guarantees synchronisation at the start. Note that for now I haven't implemented this yet, and cheated a bit by simply adding a "spindle sync wait" to the Dwell command as a workaround. However, G33 would still not be enough to implement a "smart feed hold" with a retract and repeat, as the command has no clue if it's an internal or external thread, how much it can retract, etc. For that we need to implement the G76 canned cycle, which has all those parameters, and takes care of multiple repeat cycles, retracting, etc. Internally, G76 is translated into a series of G33 and G0 commands.
I think for now we can consider the current state as "beta - usable, but beware, and don't press hold". I think Fusion uses G33 (need to check), or maybe depending on the post processor also G76, so in the long run we should aim to make GRBL compatible with this, to have a seamless workflow (I assume by now Fusion is the go-to for almost every hobbyist - not aware of any free open-source alternative at the moment, and other CAM packages are quite expensive).
shooter64738
commented
6 years ago This might be better handled as a canned cycle, but further it might also need to be split up. If one were to retract and move the Z to a home position for threading on a lathe, that would be ideal. But on a mill, I would prefer it not move the X axis if I hit feed hold on a boring/tapping cycle. :) In a mills case, it would just need to stop, a lathe would be slightly different it seems. Perhaps its time to add a setting for turning vs. milling and allow them to behave as they should for their respective machine.
I could use what @fschill has right now as a means to create a canned cycle for rigid tap. The G95 ability is what would give me that. On the mill I would want to slow/stop the spindle as I approach and reach the Z target. Then set the Z target to the retract height of R or old Z and start the spindle in reverse.
I'm not as familiar with the lathe operation, but I believe in that case you would thread to the appropriate Z target, then retract X and return Z to home.
One fadal machine i used will perform a feed hold with the tap halfway in a hole. One of the others I used will not. There is no feed hold on that machine during a rigid tap, but there was on drill cycles. My guess is, it gets complicated in there trying to keep all of that in synch and some control firmware can, and some firmware cannot, depending on its age and the hardware it runs on.
If one were running plane jane G95 a feed hold would be a feed hold. and if you were using that to cut threads on a lathe, yea it would ruin your threads. Same as it would if I were using G95 to thread a hole with a tap. If I hit feed hold on a mill with a tap in it, the spindle would keep rotating and strip my threads or pull my part out of the holder. I would think the canned cycle or G code given would dictate what its actual operation is, and what it could/could not do during a feed hold.
Ok I took too long responding, so basically, what @fschill, @109JB all said. 👍
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