Hi Jacob, maybe a clean shop is unused shop and mine has been filthy for the past month. I've started using TAS aluminum roughing end mills. Instead of long slivers, lots of tiny little chips, easy to vacuum up.
I am glad we got here to your channel we only have 1 TAIG CNC 4 axis mill table top. I like your machine as looks to be bigger. Your videos will be nice to watch. Our bigger lathe here is a Precision Mathews so I know the mill type you have as a base machine to start with and that helps me. Personal note we like you screw and various drivers on the wooden racks.
Thank you, I enjoyed your letter. When I set up the mill, it was a rush because I needed parts for work. I'm embarrassed by the ratrod like wiring, but let's say it's for teaching. I have a couple more drives to test yet and then maybe box all up.
Oh that's COOL! I've been experimenting with a Hall Effect sensor on my spindle for a similar operation, haven't gotten very far with it yet but I hadn't even considered using an encoder. Super awesome stuff!
Thank you! You might check the Dyn encoder... I only looked at it briefly, but you may be able to add a magnet to the opposite side of the spindle drive and then mount the encoder on top of the spindle motor completely out of the way. The Dyn encoder is 14 or 16 bit and far higher resolution than needed.
Kent VanderVelden I will write that down and check those out! This is something I’ve been kinda just wondering about, as to whether or not it was even remotely possible, so seeing you accomplish it fills my head with ideas! Thank you and once again, great job!
Here is a sensor that may work and it has quadrature output. Attaching the magnet may be tricky since the stock motor has no protruding shaft, however maybe it could be epoxied into place? Should then use a timing belt between the motor and spindle. Just an idea to add the encoder while preserving access to the drawbar. Will probably need to have a hardware decode because of the sampling rate required. See my reply to Steven Kirby about this. This is cool stuff for sure. Let me know what you decide to try and how it goes. www.dmm-tech.com/Files/dmmdsn05_inmt_a14_en.pdf
I have installed a stepper motor next to the machine and drive the spindle via a belt. Additionally I have added G83.1 to linuxcnc to sync the B Axis (which is used for the stepper) with the Z axis, and I also support pecking. It's really nice. Also the torque of the stepper (and 1:5 ratio) is quite good.
Thank you Steven, glad the video was useful. Once past their cost, thread mills are a great choice on a smaller cnc machine that may not have the torque for reliable tapping.
Which is precisely why I found it interesting! :) It's about the only way I could cut a thread on my machine. It has an inexpensive air cooled spindle motor which I can't run below 8000 rpm lest it melt. Most likely that would be too fast for any kind of rigid tapping. I'm guessing a small thread mill for the types of threads I'd be cutting would have to be run pretty fast anyway. I'm in the midst of a Linux CNC lathe conversion at the moment and I actually came here looking for some clues on how you hooked up your spindle encoder. I'm concerned about software decoding of the encoder pulses not being adequate for the types of frequencies my spindle will create (2500rpm spindle 1000ppr encoder). I'm guessing this is the purpose of your differential receiver in the above setup? Could it's output be fed to Linux CNC via a standard breakout board? (i.e. straight down the parallel port? Or is the Pico Systems stepper controller doing some magic too? Do you have an encoder on your CNC lathe conversion by the way, if so how did you implement it there? I've watched a few of your videos now including the lathe conversion. All very informative and concise. All killer no filler as they say. Keep it coming! :)
My lathe still needs a spindle encoder. The plan is to use the same encoder. I considered Mesa hardware but had trouble deciding on what would work so I went with an identical setup as on the mill. The differential receiver may not be required. If not using a differential receiver just ignore the /A, /B, /Z signals and it may be necessary to bias the A, B, Z signals with pull up or pull down resisters depending on your input. I used the differential receiver just to be sure about noise, but the encoder did work OK without it for short tests. The Pico System USC is an hardware (FPGA) board, and compared to software, that's the source of its magic. The USC works by reporting position to LinuxCNC, and LinuxCNC uses a servo loop to send velocities to the USC and the USC creates the step pulses. By exchanging position and velocity information the parallel port is exchanging denser information than steps. There are quadrature encoder inputs for each axis on the USC or if none is available its assumed the motor is in the correct location, this can be aided by using servos or closed-loop stepper motors. I used the fourth axis input to read the encoder. The important part is that the encoder is sampled by hardware at, I think, 10MHz. Things are not quite as good as they sound because the duty cycle of the encoder waveforms is not 50/50. This evening I've been testing a different BLDC drive that runs the stock mill motor faster. The encoder that I have is 2500 ppr and is quadrature output with index pulse, and all signals are differential. At about 3000RPM, the encoder reading is no longer reliable. This would require ~1MHz sampling if all was perfect, particularly if the encoder waveforms had 50/50 duty cycle. Your 1000 ppr encoder is would probably be good to about 2.5*3000 = 7500RPM if using the USC or something similar. The RPM limit would be substantially lower if using the parallel port. I think people are using 100-200ppr encoders at low RPM with the parallel port. You would need to check on the LinuxCNC forum to be sure. A 200ppr encoder is probably sufficient resolution as well. I hope this was helpful. Please ask if something comes up. Feel free to use email too. And thank you for the support!
Very helpful thanks, Kent! After posting last night, I did some further googling and surmised that the differential receiver's purpose in your setup was to act as a noise gate for the encoder's output. Whilst both the Mesa and Pico boards are fantastic solutions to the real-time interface of external hardware with linux cnc, both are somewhat pricey. I already have a BoB which will suit my needs for everything aside from the encoder so I was hoping I could find a hardware implementation for reading the the encoder pulses and reporting the information via the parallel port input pins on the BoB I already have. I've found some inexpensive stand alone FPGA boards (for hobby model railways I believe) that would read encoder outputs but precisely how I would interface them with my BoB is still a mystery to me. I'm guessing this kind of arrangement is not possible or more people would be doing it and I'd have found documentation of such a setup online. Any clues the on feasibility of that yourself? The encoder I already bought wasn't especially expensive so buying another with a lower resolution is certainly an option. Provided I can cut a half decent thread and get constant surface speed going then i'm happy. I may well get in touch via email to pick your brains further down the line. Thanks again for all your help! :)
The parallel port breakout should work fine especially on a lathe where you will only need pins for two motor drives. Keep the spindle speed low while threading and consider a lower resolution encoder if needing to thread faster. I would guess 200ppr is about as low as one should go. You'll need three inputs. Read the encoder module section of the LinuxCNC manual, and place the encoder into the fastest thread that's practical. I don't remember their names, but the servo thread is 1 to 4 kHz or so because it has floating point operations. The encoder module should be in a faster thread so not too miss pulses. I hope this helps :)
@@kentvandervelden At least someone is watching. Views seem to be down for everyone. I did sixty five videos of various lengths and subjects over thirty days and my channel traffic actually went down 25%. So much for posting daily. It seems TH-cam has decided it only wants me making Solidworks videos, so that is what I will do until I get to 25,000 subscribers. If you can't beat them......
Check out my most recent video: goo.gl/Jj7cU1 Here is a nice and short summary of the advantages of thread milling: th-cam.com/video/b1CG2NB8Wko/w-d-xo.html
I don't remember... Since this videos, I now use a Mesa 7i76e, so no more trouble with lost pulses at high speeds. Also, with a 1kW servo driving the spindle there's more power available. Now, I'm limited by the NEMA23 Z-axis motor. In aluminum, 500RPM should be pretty reliable up to 6mm. Larger than that I would thread mill. Faster than that and the Z-axis would stall. Hope this helps.
Great Video Kent. Two questions - I'm considering how to tap NPT (tapered pipe thread) holes and get consistent accuracy for good sealing. My CNC conversion of a mill is still in planning and I have configuration decisions to make. Single point threadmilling would be nice since it doesn't require a spindle encoder (and can be re-run to adjust the fit plus carbide threadmills are much more economical than carbide NPT taps), but my concern is the precision required and the effects of motion accuracy, interpolation and mechanical hysteresis on the thread's ability to seal. What do you think? Also have you considered using the single point threadmill to chamfer the hole (both top and bottom sides)?
Hi Alan, I've never tried NPT but believe that threadmilling would be perfect (especially given the cost of taps.) I would start by measuring circular interpolation by measuring consistency of a milled cylindrical boss. My mill has about 1.5 thou backlash in all axes which is sort of corrected in software. A bit of an oval still remains, but except for small NPT threads, I doubt it'll matter. (Ballscrew error contributes as well.) Some of the plugs at the hardware store look pretty crude and NPT requires sealant. Maybe NPTF would be less forgiving. I've not used the threadmills for chamfering, but I'm working on a program calculating parameters, and chamfering would would be a great feature to add. Sorry, I don't have the definitive answer, but it's a great idea.
Nicely done! Are you using a VFD to power the motor? My milling machine has a gear box between the motor and the spindle with a small amount of backlash, depending on the set ratio. Does backlash pose a problem in the synchronisation, specifically at the reversing stage of the process?
The motor in this video is the stock BLDC motor, it has a slow reversal time, but inertia is low. Backlash in the spindle does not matter, because the spindle position is monitored, but backlash in Z-axis is possible because the encoder is mounted to the motor instead of the axis. However, so far, all has worked well. The BLDC motor is being replaced with a servo motor, and I put up a video of the initial steps of this. Timing belts and pulleys will ultimately be used and rigid tapping tested.
Great video Kent! Do you know if there is a canned cycle for thread milling in Linux CNC? Is it possible to manually write code for thread milling or is it to hard?
Hello and thank you. I don't know of a canned cycle in LinuxCNC, but you could implement thread milling with G02 or G03 (helical motion = circular motion in XY and linear motion in Z.) Probably best to do this with a program variables and a few loops. Here's an online calculator that may help and it does use G03 (for right-hand threads and I assume G02 for left-hand threads.) sct-usa.com/thread-mill-code-generator/ Best of success to you!
That was spot on, I tried the calculator and this is exactly what I need for the moment. And Yes, it uses G02 as well. Many thanks for taking your time to answer Kent!
Thanks Dylan. The part number is TRDA-2E2500VD from Automation Direct. www.automationdirect.com/adc/Shopping/Catalog/Sensors_-z-_Encoders/Optical_Rotary_Encoders/Light_Duty_Incremental_Encoders_(Quadrature)/1-z-4_inch_Solid_Shaft_Line_Driver_(TRDA-2E_Series)/TRDA-2E2500VD
Instead of using the differential decoder? Yes, that should work, but without the noise rejection of differential signaling. Will probably need pull-up resisters on the inputs as the encoder is not a strong driver.
Your shop is clean as a whistle! Pan over to mine when I'm trying to get something done and its like the inside of a metal flake snow globe.
Hi Jacob, maybe a clean shop is unused shop and mine has been filthy for the past month. I've started using TAS aluminum roughing end mills. Instead of long slivers, lots of tiny little chips, easy to vacuum up.
really nice video Kent! thanks to post it... I'm building my cnc ... I hope I can do tapping as you .. . :)
I am glad we got here to your channel we only have 1 TAIG CNC 4 axis mill table top. I like your machine as looks to be bigger. Your videos will be nice to watch. Our bigger lathe here is a Precision Mathews so I know the mill type you have as a base machine to start with and that helps me. Personal note we like you screw and various drivers on the wooden racks.
Thank you, I enjoyed your letter. When I set up the mill, it was a rush because I needed parts for work. I'm embarrassed by the ratrod like wiring, but let's say it's for teaching. I have a couple more drives to test yet and then maybe box all up.
Oh that's COOL! I've been experimenting with a Hall Effect sensor on my spindle for a similar operation, haven't gotten very far with it yet but I hadn't even considered using an encoder. Super awesome stuff!
Thank you! You might check the Dyn encoder... I only looked at it briefly, but you may be able to add a magnet to the opposite side of the spindle drive and then mount the encoder on top of the spindle motor completely out of the way. The Dyn encoder is 14 or 16 bit and far higher resolution than needed.
Kent VanderVelden I will write that down and check those out! This is something I’ve been kinda just wondering about, as to whether or not it was even remotely possible, so seeing you accomplish it fills my head with ideas! Thank you and once again, great job!
Here is a sensor that may work and it has quadrature output. Attaching the magnet may be tricky since the stock motor has no protruding shaft, however maybe it could be epoxied into place? Should then use a timing belt between the motor and spindle. Just an idea to add the encoder while preserving access to the drawbar. Will probably need to have a hardware decode because of the sampling rate required. See my reply to Steven Kirby about this. This is cool stuff for sure. Let me know what you decide to try and how it goes.
www.dmm-tech.com/Files/dmmdsn05_inmt_a14_en.pdf
I have installed a stepper motor next to the machine and drive the spindle via a belt.
Additionally I have added G83.1 to linuxcnc to sync the B Axis (which is used for the stepper) with the Z axis, and I also support pecking. It's really nice. Also the torque of the stepper (and 1:5 ratio) is quite good.
Very interesting video. I'd never come across thread mills before.
Thank you Steven, glad the video was useful. Once past their cost, thread mills are a great choice on a smaller cnc machine that may not have the torque for reliable tapping.
Which is precisely why I found it interesting! :) It's about the only way I could cut a thread on my machine. It has an inexpensive air cooled spindle motor which I can't run below 8000 rpm lest it melt. Most likely that would be too fast for any kind of rigid tapping. I'm guessing a small thread mill for the types of threads I'd be cutting would have to be run pretty fast anyway.
I'm in the midst of a Linux CNC lathe conversion at the moment and I actually came here looking for some clues on how you hooked up your spindle encoder. I'm concerned about software decoding of the encoder pulses not being adequate for the types of frequencies my spindle will create (2500rpm spindle 1000ppr encoder). I'm guessing this is the purpose of your differential receiver in the above setup? Could it's output be fed to Linux CNC via a standard breakout board? (i.e. straight down the parallel port? Or is the Pico Systems stepper controller doing some magic too? Do you have an encoder on your CNC lathe conversion by the way, if so how did you implement it there?
I've watched a few of your videos now including the lathe conversion. All very informative and concise. All killer no filler as they say. Keep it coming! :)
My lathe still needs a spindle encoder. The plan is to use the same encoder. I considered Mesa hardware but had trouble deciding on what would work so I went with an identical setup as on the mill.
The differential receiver may not be required. If not using a differential receiver just ignore the /A, /B, /Z signals and it may be necessary to bias the A, B, Z signals with pull up or pull down resisters depending on your input. I used the differential receiver just to be sure about noise, but the encoder did work OK without it for short tests.
The Pico System USC is an hardware (FPGA) board, and compared to software, that's the source of its magic. The USC works by reporting position to LinuxCNC, and LinuxCNC uses a servo loop to send velocities to the USC and the USC creates the step pulses. By exchanging position and velocity information the parallel port is exchanging denser information than steps. There are quadrature encoder inputs for each axis on the USC or if none is available its assumed the motor is in the correct location, this can be aided by using servos or closed-loop stepper motors. I used the fourth axis input to read the encoder. The important part is that the encoder is sampled by hardware at, I think, 10MHz. Things are not quite as good as they sound because the duty cycle of the encoder waveforms is not 50/50.
This evening I've been testing a different BLDC drive that runs the stock mill motor faster. The encoder that I have is 2500 ppr and is quadrature output with index pulse, and all signals are differential. At about 3000RPM, the encoder reading is no longer reliable. This would require ~1MHz sampling if all was perfect, particularly if the encoder waveforms had 50/50 duty cycle. Your 1000 ppr encoder is would probably be good to about 2.5*3000 = 7500RPM if using the USC or something similar. The RPM limit would be substantially lower if using the parallel port. I think people are using 100-200ppr encoders at low RPM with the parallel port. You would need to check on the LinuxCNC forum to be sure. A 200ppr encoder is probably sufficient resolution as well.
I hope this was helpful. Please ask if something comes up. Feel free to use email too. And thank you for the support!
Very helpful thanks, Kent!
After posting last night, I did some further googling and surmised that the differential receiver's purpose in your setup was to act as a noise gate for the encoder's output.
Whilst both the Mesa and Pico boards are fantastic solutions to the real-time interface of external hardware with linux cnc, both are somewhat pricey. I already have a BoB which will suit my needs for everything aside from the encoder so I was hoping I could find a hardware implementation for reading the the encoder pulses and reporting the information via the parallel port input pins on the BoB I already have. I've found some inexpensive stand alone FPGA boards (for hobby model railways I believe) that would read encoder outputs but precisely how I would interface them with my BoB is still a mystery to me. I'm guessing this kind of arrangement is not possible or more people would be doing it and I'd have found documentation of such a setup online. Any clues the on feasibility of that yourself?
The encoder I already bought wasn't especially expensive so buying another with a lower resolution is certainly an option. Provided I can cut a half decent thread and get constant surface speed going then i'm happy. I may well get in touch via email to pick your brains further down the line. Thanks again for all your help! :)
The parallel port breakout should work fine especially on a lathe where you will only need pins for two motor drives. Keep the spindle speed low while threading and consider a lower resolution encoder if needing to thread faster. I would guess 200ppr is about as low as one should go. You'll need three inputs. Read the encoder module section of the LinuxCNC manual, and place the encoder into the fastest thread that's practical. I don't remember their names, but the servo thread is 1 to 4 kHz or so because it has floating point operations. The encoder module should be in a faster thread so not too miss pulses. I hope this helps :)
Great video
Thank you for the support. BTW I love your videos. Best wishes
Glad to see you working so hard.
Thank you Richard. When I worked at the University, a co-worker would ask everyday... "Working hard or hardly working?" :)
@@kentvandervelden I need to stop making videos and assemble some inventory!
You're on a roll! Actually watched your latest in the parking lot while waiting for my son to wake up :)
@@kentvandervelden At least someone is watching. Views seem to be down for everyone. I did sixty five videos of various lengths and subjects over thirty days and my channel traffic actually went down 25%. So much for posting daily. It seems TH-cam has decided it only wants me making Solidworks videos, so that is what I will do until I get to 25,000 subscribers. If you can't beat them......
And I'm supposed be making saw videos :)
well.... thats pretty cool !!!
Check out my most recent video: goo.gl/Jj7cU1
Here is a nice and short summary of the advantages of thread milling: th-cam.com/video/b1CG2NB8Wko/w-d-xo.html
What RPM were you using to tap hole with?
I don't remember... Since this videos, I now use a Mesa 7i76e, so no more trouble with lost pulses at high speeds. Also, with a 1kW servo driving the spindle there's more power available. Now, I'm limited by the NEMA23 Z-axis motor. In aluminum, 500RPM should be pretty reliable up to 6mm. Larger than that I would thread mill. Faster than that and the Z-axis would stall. Hope this helps.
How do you reverse the spindle motor? With VFD?
The BLDC drive has a reverse control. I'm redoing with a servo motor which has better torque at lower tapping speeds.
Great Video Kent. Two questions - I'm considering how to tap NPT (tapered pipe thread) holes and get consistent accuracy for good sealing. My CNC conversion of a mill is still in planning and I have configuration decisions to make. Single point threadmilling would be nice since it doesn't require a spindle encoder (and can be re-run to adjust the fit plus carbide threadmills are much more economical than carbide NPT taps), but my concern is the precision required and the effects of motion accuracy, interpolation and mechanical hysteresis on the thread's ability to seal. What do you think? Also have you considered using the single point threadmill to chamfer the hole (both top and bottom sides)?
Hi Alan, I've never tried NPT but believe that threadmilling would be perfect (especially given the cost of taps.) I would start by measuring circular interpolation by measuring consistency of a milled cylindrical boss. My mill has about 1.5 thou backlash in all axes which is sort of corrected in software. A bit of an oval still remains, but except for small NPT threads, I doubt it'll matter. (Ballscrew error contributes as well.) Some of the plugs at the hardware store look pretty crude and NPT requires sealant. Maybe NPTF would be less forgiving. I've not used the threadmills for chamfering, but I'm working on a program calculating parameters, and chamfering would would be a great feature to add. Sorry, I don't have the definitive answer, but it's a great idea.
@@kentvandervelden Thanks for your thoughts!
Very nice , sir what are the size of motor you are using for the axis ? And how can i get fusion 360 freely ?
The spindle is a 750W BLDC and the axes have 0.9Nm ES-M32320 motors. One way to get Fusion free today is the entrepreneur program. Thank you
Nicely done! Are you using a VFD to power the motor? My milling machine has a gear box between the motor and the spindle with a small amount of backlash, depending on the set ratio. Does backlash pose a problem in the synchronisation, specifically at the reversing stage of the process?
The motor in this video is the stock BLDC motor, it has a slow reversal time, but inertia is low. Backlash in the spindle does not matter, because the spindle position is monitored, but backlash in Z-axis is possible because the encoder is mounted to the motor instead of the axis. However, so far, all has worked well. The BLDC motor is being replaced with a servo motor, and I put up a video of the initial steps of this. Timing belts and pulleys will ultimately be used and rigid tapping tested.
Great video Kent!
Do you know if there is a canned cycle for thread milling in Linux CNC?
Is it possible to manually write code for thread milling or is it to hard?
Hello and thank you. I don't know of a canned cycle in LinuxCNC, but you could implement thread milling with G02 or G03 (helical motion = circular motion in XY and linear motion in Z.) Probably best to do this with a program variables and a few loops. Here's an online calculator that may help and it does use G03 (for right-hand threads and I assume G02 for left-hand threads.) sct-usa.com/thread-mill-code-generator/
Best of success to you!
That was spot on, I tried the calculator and this is exactly what I need for the moment. And Yes, it uses G02 as well. Many thanks for taking your time to answer Kent!
Awesome job om getting the ridgid tapping working. What encoder are you using?
Thanks Dylan. The part number is TRDA-2E2500VD from Automation Direct.
www.automationdirect.com/adc/Shopping/Catalog/Sensors_-z-_Encoders/Optical_Rotary_Encoders/Light_Duty_Incremental_Encoders_(Quadrature)/1-z-4_inch_Solid_Shaft_Line_Driver_(TRDA-2E_Series)/TRDA-2E2500VD
couldnt you just have wired the encoder to your Linuxcnc hardware?
Instead of using the differential decoder? Yes, that should work, but without the noise rejection of differential signaling. Will probably need pull-up resisters on the inputs as the encoder is not a strong driver.