General Design:
The CNC conversion of my Grizzly 10x22 G0752 (G0602) Lathe will be composed of two completely independent control systems. First, and simplest, I want to be able to perform CNC machining on the lathe using Mach4 software. Second, I want to retain all manual lathe functionality. Why? Well this lathe is used for hobby use and although I want CNC occasionally, 75% of the work I do will be simple one off parts and quick fixes which would become more time consuming to use CAM/CNC. In addition, it's just a fun challenge and I think it will be kinda cool. The 'manual' design aspect of this conversion could also be useful to anyone wanting to try there hand at CNC without compromising the existing functionality of their lathe and then take their time learning the ins and outs of CNC and CAM programming. Not to mention the added benefit of having a DRO, improved accuracy, and most importantly never dealing with gear changes again.
Below I’ll list my requirements of this conversion; first as a list for the reader to determine interest in adapting this design, and second for my benefit to clarify my goals as I write this post along with my design process. It's a bit wordy..... ok, you can skip ahead if you like.
Requirements:
Overview:
First a simple picture of the overall mechanical design - I'll then dig down into the details.
Note: All machining modifications required to original parts are indicated with a red colored face throughout the CAD files and images.
The CNC conversion of my Grizzly 10x22 G0752 (G0602) Lathe will be composed of two completely independent control systems. First, and simplest, I want to be able to perform CNC machining on the lathe using Mach4 software. Second, I want to retain all manual lathe functionality. Why? Well this lathe is used for hobby use and although I want CNC occasionally, 75% of the work I do will be simple one off parts and quick fixes which would become more time consuming to use CAM/CNC. In addition, it's just a fun challenge and I think it will be kinda cool. The 'manual' design aspect of this conversion could also be useful to anyone wanting to try there hand at CNC without compromising the existing functionality of their lathe and then take their time learning the ins and outs of CNC and CAM programming. Not to mention the added benefit of having a DRO, improved accuracy, and most importantly never dealing with gear changes again.
Below I’ll list my requirements of this conversion; first as a list for the reader to determine interest in adapting this design, and second for my benefit to clarify my goals as I write this post along with my design process. It's a bit wordy..... ok, you can skip ahead if you like.
Requirements:
- Operator controls: This is my biggest requirement guiding the design - In NO way should the manual lathe operations be negatively influenced by this conversion! I want to walk up to the lathe, chuck a part, hit pwr button, and simply start turning the hand wheels in a traditional way.
- Accuracy / Repeatability: I want to improve on the existing accuracy and repeatability of the original G0602/0752 lathe. The z-axis has absolutely horrible control and backlash is enormous – I would like to control cutoff and length position to +/-0.010”. The x-axis, although it does have backlash, I’ve found usable as it’s always “measure, cut, measure, cut” but nonetheless it would be nice to have <0.001” accuracy with <0.0005” repeatability without the concern of backlash.
- Resolution: In general I like the resolution of the existing graduated dials so won't mess with that. Z-Axis = 0.950"/rev, X-Axis = 0.060”/rev.
- Locking: The original z-axis is easily driven back away from the cut and requires the lock engaged for facing. I believe the stepper motors will hold both axis well enough to eliminate the need to lock the axis in place. I hope this is a benefit of the “manual” design.
- Aesthetics: I like the current look and feel of the lathe and will retain as much as possible the hand wheels & there location. In addition, I don’t want to see the motors, or worse, have them moving around the operator area. With this in mind I will not follow the traditional motor locations of the x-axis on the front of the apron and z-axis at the right end of the lead screw. Hidden from view is the name of the game.
- Measurement feedback: Add DRO display (without computer) and still retaining use of the original graduated dial indicators for both axis. The DRO should have at a minimum a zero buttons, and inch/mm toggle buttons.
- Modularity: I want the “manual” conversion of the lathe to be “stand alone” as a complete project. This will allow others interested in adapting this design to separate out the project into two phases and have a fully functioning lathe while they take the sometimes extended time to figure out the electronics, software communication, and CAM challenges.
- Tooling: As the lathe will be CNC I’ll have no need for the compound assembly so will replace this with a standoff and quick change tool post. This also eliminates a significant weak point for the 10x22 bench top lathes as the compound connection to the cross slide is not well designed.
- Feed functionality: Again I want to retain all the original manual control “feel” so I’ll still use the half nut engagement lever but replace the components with a simple switch to engage the feed. In addition, as the entire gear box is removed, I’ll add a speed dial to vary the feed rate. I also want to add the functionality to disengage the feed at adjustable positions.
- Threading: At this time I’ll defer all threading operations to the CNC and simply give up this functionality for manual control. My end goal will be to use the ‘manual’ electronics to control threading and simply have the operator dial in the TPI or pitch with the feed dial and have this information displayed on the DRO.
- X Axis feed rate: The fastest I can manually turn the X axis handwheel is about 5 rev/sec at a 0.06"/rev yields about 18 IPM which although extremely slow is fine for cutting feed. I'll estimate about 5x that amount for rapids during CNC work for about 90 IPM.
- Z Axis feed rate: Again estimating feed based off the original grizzly handwheel on the z-axis (5 rev/sec @ 0.95"/rev) yields 285 IPM which will be the target for rapids. All recommended cutting feed rates fall well below this value.
Overview:
First a simple picture of the overall mechanical design - I'll then dig down into the details.
Note: All machining modifications required to original parts are indicated with a red colored face throughout the CAD files and images.
In general you'll see that the basic operator functionality is completely intact and the CNC hardware (motors for X & Z axis) is tucked away from the operator area. Originally I tried to minimize the rework to the original parts in my design and replacing with new design component but quickly found that approach, although nice for promoting "easy conversion", was too restrictive and wasteful by not utilizing existing parts. In the end I changed that approach to utilize as many original parts when appropriate and was happy I was able to retain the nice steel castings of the apron and gearbox case by simply incorporating new functionality with minimal rework. The design became an effort to merge the new functionality seamlessly into the original design. All modified parts are removable with no modification to the lathe bed. Beyond the drive hardware you'll notice a spindle sensor with disc, some operator buttons inside the gearbox, a DRO on top of the electrical box, cable routing along & down the saddle extending out to a cable carrier on the backside of the splash guard, and the electrical enclosure mounted behind the back splash. I'll walk thru each aspect with some more detail and in process pictures along the way.
X-Axis Drive:
Typical conversions of this lathe place the x-axis motor in the apron area which in my case would interfere with the desire to retain the manual hand wheel locations and simply not retain the original look and feel of the lathe. Therefore I positioned the x motor and pulley drive at the rear of the cross slide. This location has some obstacles which must be accounted for: 1) the Nema23 triple stack motor size extends to interfere with the splash guard. This is easily solved by repositioning the splash guard in +x about 30 mm with simply standoffs, 2) The cross slide X movement needs to extend over top of all the drive hardware which simply requires the design to be below the dovetail profile, and 3) when the carriage is moved to its maximum Z location into the spindle the new hardware must avoid hitting the spindle drive motor and guard created by the splash guard. This again is only a design consideration and requires the motor to be offset in -z (toward the tailstock) to avoid the interference - easily done due to the flexibility of location afforded by using pulleys. 4) There is very limited volume available inside the saddle lead screw pocket.
Typical conversions of this lathe place the x-axis motor in the apron area which in my case would interfere with the desire to retain the manual hand wheel locations and simply not retain the original look and feel of the lathe. Therefore I positioned the x motor and pulley drive at the rear of the cross slide. This location has some obstacles which must be accounted for: 1) the Nema23 triple stack motor size extends to interfere with the splash guard. This is easily solved by repositioning the splash guard in +x about 30 mm with simply standoffs, 2) The cross slide X movement needs to extend over top of all the drive hardware which simply requires the design to be below the dovetail profile, and 3) when the carriage is moved to its maximum Z location into the spindle the new hardware must avoid hitting the spindle drive motor and guard created by the splash guard. This again is only a design consideration and requires the motor to be offset in -z (toward the tailstock) to avoid the interference - easily done due to the flexibility of location afforded by using pulleys. 4) There is very limited volume available inside the saddle lead screw pocket.
|
|
|
The x-axis drive uses a 10 mm diameter by 2 mm pitch ball screw from Misumi. I've used a C6 class screw with a near anti backlash nut (10 micron) which is priced at $260 but they also have a lower class (c10) version available for $150 (see parts list). The fixed end side uses ABEC-5 angular contact bearings with the support end using a simple roller bearing into the custom end mount (purple) - both bearings from Misumi. The fixed end bearing block and the ball nut both need to be modified with flats to fit into the existing saddle - It's a very tight fit. In addition the saddle will need to machine flat parallel surfaces on each end to insure the ball screw runs true to the dovetail slide. The design of the two motor mounting plates pack a lot of functionality into them (pulley tension, protection from chips, Nema mounting, Ball Screw end support) and therefore became a bit complex for manual machining - I used my CNC router for these two plates (Video Link). Pulley ratio is 1:1 and I expect to have a rapids of 70 IPM (900 RPM) and max cutting speed of 30 IPM (400 RPM). There's only 3 new manufactured parts involved in mounting the stepper to the x-axis with modifications to the saddle and cross slide.
Z-Axis Drive:
The Z-Axis motor placement wasn't obvious at first but once I started to disassemble and document the lathe components in CAD it was a pleasant surprise to learn the gearbox housing was completely removable and not part of the bed casting. This location, as CNC conversion obsoletes all gear hardware, is the perfect spot to hide the z motor.
The Z-Axis motor placement wasn't obvious at first but once I started to disassemble and document the lathe components in CAD it was a pleasant surprise to learn the gearbox housing was completely removable and not part of the bed casting. This location, as CNC conversion obsoletes all gear hardware, is the perfect spot to hide the z motor.
|
|
|
As you can see in the above picture I took this one step further and simply modified the gearbox housing to accommodate the ball screw fixed bearing and Nema23 mounting bracket. You could simply replace the housing with new plates to mount the motor but I'm a bit in the recycle mood and like the idea of having this lathe conversion fool the operator into not actually knowing it's CNC. The motor is the same as the X-Axis and uses a Nema23 stepper with a pulley setup. The pulley ratio here is 1:1 but can also accommodate a speed reduction (torque increase) setup which I'll explain in a bit. I've popped a couple air flow holes into the left and bottom to facilitate some air flow and cable routing. The fixed bearing is again an ABEC-5 angular contact bearing from Misumi with the support a simple roller bearing in custom mount (green) which reuses the existing threaded holes from the original lead screw end mount. The ball screw is an SFU2005-C7-900 Chinese mfg screw (Dia 20 x 5 pitch) which I purchased from Automation Technologies at 975mm and re-machined the support end down to length. Lastly the apron is machined to accept the ball nut mounting bracket with some slotted mounting screws to allow adjustment in the Y axis and X adjustment allowed in the variation of the connection of the apron to the saddle. Again we have only 3 new manufactured parts in the design of the Z-axis with modifications to the apron and gearbox castings.
|
Half Nut (for manual control):
Needless to say, by removing all the gears and changing the original z-axis lead screw for a ball screw, we must find an alternative solution for the half nut function. In this design I've retained the original operator handle, added a screw to the internal actuated lever, and mounted a miniature D2HW series limit switch from Omron. The half nut lever now simply toggles the switch and the Arduino code tells the z-axis motor to move. Two more components are required which together set the speed of the motor; one is a potentiometer which is mounted into the gearbox cover plate and the second is a C3 Index Pulse Card to capture the spindle RPM. I'll cover the mounting of these two components in additional to explaining the Arduino code later; although, it's worth noting now that in addition to simply moving the motor I've allowed the operator to set a stop point along the z axis with the DRO which the motor will then automatically "disengage" at - this works real slick! In the picture gallery you'll notice I'm wiring up the switch together with both x & z encoders all into an RJ45 ethernet breakout board so that one cable (8 pin) is all I need to wire back to the control box. Further on you'll see I've used this approach in 2 other sub-modules (worked very well). |
|
Encoders & Hand Wheels (for manual control):
The design solution I've implemented to satisfy the requirement to retain all manual control is to attach incremental rotary encoders to the original hand wheel shafts of the lathe. Both X and Z axis hand wheels are no longer attached to the mechanical drive system of the axis and therefore are "dead" motion wrt the drive system. When you turn these dials the signal from the encoder is sent to an Arduino controller which in turn tells the motors how far and fast to travel. The distance to travel per hand wheel revolution is matched to the dial graduation marks resulting in 0.95" per revolution on the z-axis and 0.06" on the x-axis. This can easily be changed in the code if we want to make new dials or the conversion is not this specific lathe and has different graduation marks on the dials.... or it's a mill conversion! - This manual design can be modified to work with any machine requiring operator input via a dial. Of course we'll also send the motion information from the Arduino to an LCD screen - see section on DRO.
The x-axis hand wheel design replaces the original single housing used to offset the hand wheel with two separate housings (yellow & pink) and a new independent shaft (green) which will only function to transmit the hand wheel rotary motion to the encoder.
The design solution I've implemented to satisfy the requirement to retain all manual control is to attach incremental rotary encoders to the original hand wheel shafts of the lathe. Both X and Z axis hand wheels are no longer attached to the mechanical drive system of the axis and therefore are "dead" motion wrt the drive system. When you turn these dials the signal from the encoder is sent to an Arduino controller which in turn tells the motors how far and fast to travel. The distance to travel per hand wheel revolution is matched to the dial graduation marks resulting in 0.95" per revolution on the z-axis and 0.06" on the x-axis. This can easily be changed in the code if we want to make new dials or the conversion is not this specific lathe and has different graduation marks on the dials.... or it's a mill conversion! - This manual design can be modified to work with any machine requiring operator input via a dial. Of course we'll also send the motion information from the Arduino to an LCD screen - see section on DRO.
The x-axis hand wheel design replaces the original single housing used to offset the hand wheel with two separate housings (yellow & pink) and a new independent shaft (green) which will only function to transmit the hand wheel rotary motion to the encoder.
|
|
The inner (Yellow) housing holds an IGUS split bushing with a split hub and adjustment screw used to vary the friction of the shaft which prevents free motion of the hand wheel and fools us into thinking it's connected to the drive. The outer (pink) housing holds the outer bushing and provides a mounting interface to the rotary encoder which places it between the bushings. The original hand wheel and graduated dial is then simply mounted to the shaft (Green) via some set screws and the shaft is retained within the inner housing with the original nut and screw. The assembly uses the original mounting position to the housing but locates the dial just slightly lower than the original due to the encoder size and the fact that the cross slide must ride over top this assembly. Overall it's a lot of detail in a small package.
|
|
The Z axis hand wheel utilizes the exact same design concept but forgoes the outer bearing by utilizing the original hole of the apron (pink). The inner split bushing is again housed into a split hub (blue) with an adjustment screw and this housing also mounts the rotary encoder. Of course the original gear pinion is completely removed so the z-axis is no longer actuated with connection to the geared rack. The apron requires a number of modifications for various functions and this design aspect simply requiring some new mounting holes and a flat mounting face for the inner bushing mount. |
|
Some in process pictures of the drive & hand wheel assemblies.
DRO:
Now I know... the most accurate way to report linear position is to measure .... well, to be precise, it's to measure the actual tool location relative to the part being worked. Normally this is implemented by attaching a linear encoder to the slide motion of the lathe (saddle to bed (Z), or saddle to cross slide (X)) and although this is a bit removed from the 'best' tool to part relative position it nonetheless gives us good results. My implementation will report to the DRO only where it 'thinks' the motion should have gone - the Arduino receives the rotary encoder counts, sends a calculated set of counts along to the motor to drive the ballscrew, and in addition sends a calculated set of counts to the LCD display in real time. Through this process nothing actually looks at the motion. This allows inaccuracies including encoder error, backlash, and any skipped steps to be unaccounted for (one reason I moved to Clearpath servos). Although, when you think of it, this is exactly how the Mach4 CNC software reports position (unless you close the loop).
Now on to the design.
Now I know... the most accurate way to report linear position is to measure .... well, to be precise, it's to measure the actual tool location relative to the part being worked. Normally this is implemented by attaching a linear encoder to the slide motion of the lathe (saddle to bed (Z), or saddle to cross slide (X)) and although this is a bit removed from the 'best' tool to part relative position it nonetheless gives us good results. My implementation will report to the DRO only where it 'thinks' the motion should have gone - the Arduino receives the rotary encoder counts, sends a calculated set of counts along to the motor to drive the ballscrew, and in addition sends a calculated set of counts to the LCD display in real time. Through this process nothing actually looks at the motion. This allows inaccuracies including encoder error, backlash, and any skipped steps to be unaccounted for (one reason I moved to Clearpath servos). Although, when you think of it, this is exactly how the Mach4 CNC software reports position (unless you close the loop).
Now on to the design.
|
|
The digital readout assembly is composed of a 4 row x 20 column LCD display and 3 momentary push button switches both by Frentaly. These components get mounted into a 150x70x47 project box by Uxcell along with an RJ45 breakout board (I also add a terminal box to make wiring and attaching the resistors easier). All three switches use a 10kohm resister bridged to ground as you can see in the gallery pictures. The design of the box is simple enough and self explanatory with the pictures and it is finished off with a simple printed sticker over the top to hide the mounting holes and label the buttons. As to the functions: We have one button each for the X & Y axis which first will switch between 3 memory locations with a momentary push and second will zero out the currently displayed memory value by holding the button. The third button functions to toggle inch/mm with a momentary push and by holding this button we can set the current z axis location as the half nut disengage position. The box is simply mounted with 2 tapped holes into the existing sheet metal enclosure box.
|
Electronic Gear Box & Power Distribution:
The gear box cover is converted into the operator control for the CNC conversion. It contains a 3 position changeover switch, a potentiometer, C3 Index Pulse card, and an ethernet breakout board. Additionally we have an index dial to mount to the spindle shaft, a mounting block for the C3 sensor head, and an EStop module. Let's get to it.
The gear box cover is converted into the operator control for the CNC conversion. It contains a 3 position changeover switch, a potentiometer, C3 Index Pulse card, and an ethernet breakout board. Additionally we have an index dial to mount to the spindle shaft, a mounting block for the C3 sensor head, and an EStop module. Let's get to it.
|
|
The C3 board operates in both manual and CNC mode to send one pulse/rev to either the ESS or the Arduino to determine RPM of the spindle. A 1-to-2 terminal module (see Controller section) is used to distribute this signal to both controllers. As shown below, it's mounted to the outer edge of the gear box cover and the sensor head routes up to the spindle and mounts with a new bracket to an existing hole in the original bracket plate. This new mounting bracket is slotted to allow some adjustment of the sensor head to accurately read the index dial. The dial is a simple disk with one cutout at the perimeter and is mounted by removing the spindle shaft nuts and sandwiching the disc before the pulley.
The 3 turn potentiometer is only active in manual mode and allows the operator to set the z axis feed rate during half nut engagement. As the unit, together with the changeover switch, is panel mount; the gear box cover plate must be machined down to ~6mm in the mounting area (I machined this area larger to accommodate cable routing). |
The dual controller power distribution is controlled by a 3 position changeover switch to provide CNC, MAN, and OFF. We need a total of 4 independent dc voltage supplies for this conversion. 1) The 75v+ supply to the motors 75v is wired into both CNC & MAN contacts. 2) 9v+ is connected to only the MAN contacts and supplies the Arduino Uno. 3) 5v is routed first through both the CNC & MAN contacts to supply the C3 board and then continues on to only a CNC contact to supply the ESS. 4) A separate 5v supply for the buttons, LCD, & potentiometer come from the Arduino Uno and although it does not use the changeover switch, this supply is brought back into the gear box assembly from the main controller through the ethernet breakout board to supply the potentiometer. An electrical schematic is posted in the "Documentation" section.
I simply cut off the original operator panel sheet metal portion which extended below the gear box and added a printed sticker to cover the outside with indicator marks as shown in the photo gallery.
I've also wired the 110v AC power for the motors through the existing EStop button of the lathe by simply adding an additional circuit module to the existing button. This ensures when the original EStop is pressed motor power along with the spindle are killed - separate circuit but same button.
The last picture in the photo gallery above you can see the holes drilled thru the drip pan to allow the wires from the power strip to pass into the gearbox. I've also mounted the 75v supply under the drip pan in this area and route the motor pwr and control lines thru holes placed here.
I simply cut off the original operator panel sheet metal portion which extended below the gear box and added a printed sticker to cover the outside with indicator marks as shown in the photo gallery.
I've also wired the 110v AC power for the motors through the existing EStop button of the lathe by simply adding an additional circuit module to the existing button. This ensures when the original EStop is pressed motor power along with the spindle are killed - separate circuit but same button.
The last picture in the photo gallery above you can see the holes drilled thru the drip pan to allow the wires from the power strip to pass into the gearbox. I've also mounted the 75v supply under the drip pan in this area and route the motor pwr and control lines thru holes placed here.
Controller Assembly:
Ohhh the main control box!! I must have rewired this thing 10 times and I have 14 versions of the electrical schematics! Although it was a challenge I'm pleased with the results. First off we have another Uxcell project box (320x240x60) which needs to accept 4 Ethernet cables connected via RJ45 bulkhead connectors (from Gearbox, Apron, DRO, & ESS), a USB-B cable for downloading the program to Arduino also via a bulkhead, and 2 motor signal cables which are passed through PG9 cable glands. Mounting of the control box is onto the rear of the back splash where cable routing from the x-axis and apron come in from the cable carrier and motor signals drop down from a cable tray tube as shown in the photo gallery. When connecting the cables to the external bulkhead connections of the enclosure I made sure to leave some extra length to allow the controller to be temporarily positioned onto the bed of the lathe for easy routing at the machine (also see pictures).
Motor step, direction, and enable signals are passed thru six 2-position terminal blocks mounted onto a din rail to distribute the signals to both the ESS and the Arduino simultaneously. Three additional terminal blocks are then used to gather up all 6 of the motor ground signals into a single output to send off the the relay.
Ohhh the main control box!! I must have rewired this thing 10 times and I have 14 versions of the electrical schematics! Although it was a challenge I'm pleased with the results. First off we have another Uxcell project box (320x240x60) which needs to accept 4 Ethernet cables connected via RJ45 bulkhead connectors (from Gearbox, Apron, DRO, & ESS), a USB-B cable for downloading the program to Arduino also via a bulkhead, and 2 motor signal cables which are passed through PG9 cable glands. Mounting of the control box is onto the rear of the back splash where cable routing from the x-axis and apron come in from the cable carrier and motor signals drop down from a cable tray tube as shown in the photo gallery. When connecting the cables to the external bulkhead connections of the enclosure I made sure to leave some extra length to allow the controller to be temporarily positioned onto the bed of the lathe for easy routing at the machine (also see pictures).
Motor step, direction, and enable signals are passed thru six 2-position terminal blocks mounted onto a din rail to distribute the signals to both the ESS and the Arduino simultaneously. Three additional terminal blocks are then used to gather up all 6 of the motor ground signals into a single output to send off the the relay.
|
|
Although all the power to the control box is received from the Gearbox ethernet cable, there is a separate internal 5v loop created from the Arduino which uses a terminal rail to distribute to switches, buttons, and LCD for the manual control side of things. Separating this 5v loop from the main ESS 5v supply was one of the key aspects to avoid all kinds of grounding issues between the two controllers. This was one of the painful learning experiences.
And finally a relay is added to distribute the motor ground signals independently to the ESS or Arduino. This is a bit different than the motor signals which are simply split and wired to both controllers. The reason... well it's "above my pay grade" as they say, but the bottom line is... when the motor ground wires were simply connected to both ESS and Arduino without a relay the motion of the motors under manual/Arduino control was erratic - I did notice that although the ESS was not receiving power, a small LED on the board would light dimly when the relay was not in place... using the relay resolved this issue. This was the second painfully time consuming key component needed to get everything working correctly. You can grab a copy of the electrical schematic in the "Download" section under 'Docs'. |
Here's a youtube video showing a simple overview of the completed lathe and some video footage of disassembly and assembly.
Arduino Program:
Well it's been over 20 years since I took a Fortran programming class in college and I've only dabbled in Java about 7 years ago.... needless to say the C code was the biggest challenge of the project; but I must admit, also the most enjoyable. As of this writing the program is fully operational and starting my 'bonus' attempt to add threading functionality. I'll run through each of the major functions of the code with some explanation of how it works.
Clearpath Servos (Step/Dir):
The text below is an explanation of how the Clearpath motors can be driven by the Arduino controller and the critical limits considered in code architecture.
The Clearpath SD (step/dir) servo motor has Arduino libraries available which allow 2 different ways to move the motor...
Encoders on X & Z hand wheels:
I'm using a CUI Incremental Rotary Encoder set at 500 cnts/rev for both the X & Z axis handwheels which results in 2000 cnts/rev in the code. The Arduino code handles these encoders by using an existing library by PaulStoffregen (https://www.pjrc.com/teensy/td_libs_Encoder.html) which uses Arduino pin interrupts to count the steps. The encoders two signal pins can be connected to non-interrupt pins which results in sporadic readings, to one interrupt and one normal pin which improves the performance to "good", or to two interrupt pins which results in "best performance". Unfortunately the UNO only has two interrupt pins available so I was limited to using only one interrupt pin per encoder for "good" performance. This results in solid performance when the encoder wheels are rotated with normal speed (captures all the encoder counts) but when turning the wheel with unusual gusto the program will miss some encoder readings. Although, a missed encoder count is ok with respect to the lathe position and DRO because if the program does not see a count it simply will not send it to the motor for motion. What does happen when an encoder count is missed is it creates an error between the graduated dial of the handwheel to the actual motion & LCD display. For this reason I'd like to move to an Arduino Mega or Duo or possibly a Teensy controller in the future which will have more interrupt pins available.
X & Z axis motor drive by Encoders:
The handwheel motion is a bit tricky as we must accommodate a broad range of input from the operator. The way the program handles this is to first read the encoder counts into a buffer and this buffer is then evaluated within a 'motion' loop which makes decisions on how fast the motor must be driven. I spent a lot of time calculating and testing this motion to develop a simple set of buffer ranges to provide smooth motion; which, although I won't detail here, I will give a walk through of the operation. The first buffer range is 1-50 encoder counts which will send a single step/pulse (1 motor count per program cycle) by starting off at the minimum velocity at a buffer of 1 (max delay of 10,000 us) and ramp the velocity up to max when the buffer is 50 encoder counts (min delay of 500 us). Once the buffer exceeds this first range (1-50) I say, "Hey this guy wants to go faster but I've reached my maximum velocity when sending only a single motor count per program cycle", so I change the number of motor counts sent per cycle to 2. This then allows us to double the velocity of the motor within the next encoder buffer range of 51-100, again ramping up the velocity from min to max within the range of 51-100. And so on until the operator is frantically rotating the handwheel and the program is simply keeping up. I'm sure there are more elegant ways to handle this type of motion but this simple approach works out rather well.
Z axis motor drive by half nut:
As mentioned previously the half nut motion is driven by the "PulseClearpath" mode which sends a step and delay per program cycle. This allows us to monitor the exact motion traveled and can accept the operator disengagement action at any time. Inputs are taken from the potentiometer (inch/rev) and Index Pulse Card (RPM) to calculate the velocity required for feed and then simply calculates the delay required per cycle. The half nut lever remains unchanged from the operator perspective but the mechanical linkage is replaced by a simple switch.
A bonus feature of this conversion is the use of the DRO to set a predefined half nut disengagement position. The operator need only to move the z axis tool to the point along the bed which he wants the half nut to disengage and set this position with a button press. When this position is defined the program simply calculates the required number of steps to reach that position and automatically disengages. Having the value set however does not prevent the operator from stopping prior to that location (for emergency etc).
LCD Display with Buttons:
The LCD operation is listed below.
________________
X = +00.0000 in M1
Z = +000.000 mm M3
RPM = 0000 Z-STOP
IPM = 00.0 ******
________________
The Z-Stop setting has three display modes. "Not Set"=Not Set, Numeric Value = Set and ready to go, +++>>> = Set but carriage is past set point (must move +Z).
Potentiometer (Feed Rate adjustment):
The Arduino code assigns a minimum to maximum rev/inch value based on the analog input from the potentiometer and together with the spindle RPM calculates the feed rate in IPM and displays this on the LCD.
Well it's been over 20 years since I took a Fortran programming class in college and I've only dabbled in Java about 7 years ago.... needless to say the C code was the biggest challenge of the project; but I must admit, also the most enjoyable. As of this writing the program is fully operational and starting my 'bonus' attempt to add threading functionality. I'll run through each of the major functions of the code with some explanation of how it works.
Clearpath Servos (Step/Dir):
The text below is an explanation of how the Clearpath motors can be driven by the Arduino controller and the critical limits considered in code architecture.
The Clearpath SD (step/dir) servo motor has Arduino libraries available which allow 2 different ways to move the motor...
- The first mode is "StepClearpath" which moves to a defined position at a set velocity and acceleration. As this mode requires prior knowledge of the motion parameters, it is poorly suited for use to execute the handwheel motion as the input is infinitely variable by operator input. The halfnut operation could use this mode to run at a constant velocity (feed rate) but as the operator can disengage the halfnut at anytime, we don't always know the end location, and therefore would have issues keeping track of the motor position in this mode. "StepClearpath" mode is not used in the program.
- The second mode is "PulseClearpath" which requires a frequency (delay in code) and step size (number of steps per pulse) to be sent to motor. This mode is used for the handwheel motion as it allows us to change the velocity 'on the fly' without a predefined travel distance. (actual distance traveled is one step at a time and we can vary the velocity dependent on the speed the operator moved the handwheel). In addition, even though we need a constant velocity for feeding the halfnut, using this mode allows us to keep track of the motor position within the code (# of steps/pulse) and therefore whenever the operator decides to disengage the halfnut we know the exact position to write to the DRO.
- 1st, is the maximum frequency (minimum delay) at which pulses can be sent; which, although specified as 500 KHz (2us) for this motor, the Clearpath Arduino libraries restrict to a 500us delay (likely due to the slow processor speed). This value will set our maximum frequency allowed to send a pulse (resulting in a max velocity limit) ..... Although, we can simply send multiple steps per pulse at that max frequency so this timing limit is not a real restriction and only becomes something to adjust in the code to obtain higher speeds up to the motor rated maximum velocity.
- 2nd, is the minimum frequency (maximum delay) at which pulses can be sent to allow the motor to stay within a single smooth motion profile. This value is simply stated as a maximum delay time of 10,000us (10ms). If we send pulses at a delay value higher than 10ms the motor will set the velocity to zero between pulses and treat each pulse as a single command move. This will be fine when the handwheel is being operated at very slow speeds for fine adjustment but will create an unacceptable choppy motion once the motor increases the volocity to any appreciable amount. We need to carefully evaluate when it's acceptable to transition from choppy single pulse fine adjustmenet motion and smooth velocity. This is all about how the operator interacts with the machine - the goal is to make it feed as thought the handwheel is still connected to a mechanical linkage.
- An additional consideration for timing is the amount to time required to update the DRO LCD display with the linear position. If you think the Arduino 16 MHz processor is slow, watch out.... my original code required nearly 9,000 us to send an LCD update which is a direct delay before we can send the next pulse command. I was able to fine tune the data and limit how many characters are updated based on speed of handwheel (ie - no need to have tenth resolution when the operator is turning the handwheel as fast as possible); yet it still takes nearly 3,000 us even for small data packets sent. In the end, the handwheel LCD update works well but I'm simply not able to do live updates during halfnut motion and simply send the update once after halfnut stops.
Encoders on X & Z hand wheels:
I'm using a CUI Incremental Rotary Encoder set at 500 cnts/rev for both the X & Z axis handwheels which results in 2000 cnts/rev in the code. The Arduino code handles these encoders by using an existing library by PaulStoffregen (https://www.pjrc.com/teensy/td_libs_Encoder.html) which uses Arduino pin interrupts to count the steps. The encoders two signal pins can be connected to non-interrupt pins which results in sporadic readings, to one interrupt and one normal pin which improves the performance to "good", or to two interrupt pins which results in "best performance". Unfortunately the UNO only has two interrupt pins available so I was limited to using only one interrupt pin per encoder for "good" performance. This results in solid performance when the encoder wheels are rotated with normal speed (captures all the encoder counts) but when turning the wheel with unusual gusto the program will miss some encoder readings. Although, a missed encoder count is ok with respect to the lathe position and DRO because if the program does not see a count it simply will not send it to the motor for motion. What does happen when an encoder count is missed is it creates an error between the graduated dial of the handwheel to the actual motion & LCD display. For this reason I'd like to move to an Arduino Mega or Duo or possibly a Teensy controller in the future which will have more interrupt pins available.
X & Z axis motor drive by Encoders:
The handwheel motion is a bit tricky as we must accommodate a broad range of input from the operator. The way the program handles this is to first read the encoder counts into a buffer and this buffer is then evaluated within a 'motion' loop which makes decisions on how fast the motor must be driven. I spent a lot of time calculating and testing this motion to develop a simple set of buffer ranges to provide smooth motion; which, although I won't detail here, I will give a walk through of the operation. The first buffer range is 1-50 encoder counts which will send a single step/pulse (1 motor count per program cycle) by starting off at the minimum velocity at a buffer of 1 (max delay of 10,000 us) and ramp the velocity up to max when the buffer is 50 encoder counts (min delay of 500 us). Once the buffer exceeds this first range (1-50) I say, "Hey this guy wants to go faster but I've reached my maximum velocity when sending only a single motor count per program cycle", so I change the number of motor counts sent per cycle to 2. This then allows us to double the velocity of the motor within the next encoder buffer range of 51-100, again ramping up the velocity from min to max within the range of 51-100. And so on until the operator is frantically rotating the handwheel and the program is simply keeping up. I'm sure there are more elegant ways to handle this type of motion but this simple approach works out rather well.
Z axis motor drive by half nut:
As mentioned previously the half nut motion is driven by the "PulseClearpath" mode which sends a step and delay per program cycle. This allows us to monitor the exact motion traveled and can accept the operator disengagement action at any time. Inputs are taken from the potentiometer (inch/rev) and Index Pulse Card (RPM) to calculate the velocity required for feed and then simply calculates the delay required per cycle. The half nut lever remains unchanged from the operator perspective but the mechanical linkage is replaced by a simple switch.
A bonus feature of this conversion is the use of the DRO to set a predefined half nut disengagement position. The operator need only to move the z axis tool to the point along the bed which he wants the half nut to disengage and set this position with a button press. When this position is defined the program simply calculates the required number of steps to reach that position and automatically disengages. Having the value set however does not prevent the operator from stopping prior to that location (for emergency etc).
LCD Display with Buttons:
The LCD operation is listed below.
- Buttons 1&2: Push= Toggle X & Z readout between 3 stored memory fields (M1,M2,M3).
- Buttons 1&2: Hold= Zero X & Z display value for current memory being displayed.
- Button 3: Push= Change units mm<-->inch.
- Button 3: Hold (0.4 to 0.8 sec) = Store current Z axis position to use as half nut feed automatic disengagement
- Button 3: Hold (1.0 to 3.0 sec) = Recently added to enter "Mode" selection which allows threading and profiling (see "Special Topics blog")
________________
X = +00.0000 in M1
Z = +000.000 mm M3
RPM = 0000 Z-STOP
IPM = 00.0 ******
________________
The Z-Stop setting has three display modes. "Not Set"=Not Set, Numeric Value = Set and ready to go, +++>>> = Set but carriage is past set point (must move +Z).
Potentiometer (Feed Rate adjustment):
The Arduino code assigns a minimum to maximum rev/inch value based on the analog input from the potentiometer and together with the spindle RPM calculates the feed rate in IPM and displays this on the LCD.
Cost - Parts List:
Well this surprised me a bit... I just finished up compiling my parts list into excel (will post to the "Documentation" section in a minute) and my total cost to convert this machine was .... wait for it.... $2,050 bucks! And this total is not including Mach4 software and a computer as I already had these with my CNC router. Some quick thoughts....
Well this surprised me a bit... I just finished up compiling my parts list into excel (will post to the "Documentation" section in a minute) and my total cost to convert this machine was .... wait for it.... $2,050 bucks! And this total is not including Mach4 software and a computer as I already had these with my CNC router. Some quick thoughts....
- My fixed bearings and x ball screw have alternatives listed in the parts list which gives a savings of $200.
- I moved to Clearpath servos mid way through the project because I was having trouble getting the steppers to work with Arduino. There is likely about $400 savings in this area if moving to steppers (yet the code would need to be modified)
- The ESS is likely overkill so there might be savings here.
- As opposed to my CNC Router build I didn't look for any special deals so there might me some savings there.
|
I've followed the typical CNC conversion breakdown by separating the mechanical, motors, and control aspects.
|
The mechanical cost of $785 can be compared to other "for sale" conversion kits for this type lathe you may find on ebay. Although my mechanical cost is slightly lower for my conversion you're getting higher quality components in the x-axis ball screw and fixed bearings on both axis (z-axis ball screw still cheap). This higher quality component is balanced by the fact we're reusing some main original parts (gearbox & apron) which requires much more machining than online kits. Of note, is a potential cost reduction for this conversion by choosing the alternative fixed bearing and x-axis ball screw in the parts list which will cut the cost from $785 to a cool $576.
The motor cost coming in at $683 is a bit steep but you're getting high quality without potential missed steps (extra important when implementing DRO). Keep in mind that the Arduino program can only use these Clearpath motors as of this writing. I'd like to try to modify the program to accept steppers but likely this will not be done.
And now you need to choose a controller (one of the orange columns)..... or use both as I did. I can't imagine not having full up CNC/CAM capability after doing all this work but it's absolutely a possibility to choose the mCNC option (micro-controller NC) and have a full working lathe for the $291 and simply keep the $701 for a future upgrade (BTW - $701 includes an estimate for a computer, monitor, Mach4, and ESS which you could arguably reduce cost here).
Summing the total soup to nuts cost options.... (subtract $209 as cheaper alternative)
Using mCNC only = $1,759
Using full CNC only = $2,169
Using BOTH mCNC/CNC = $2,460
The motor cost coming in at $683 is a bit steep but you're getting high quality without potential missed steps (extra important when implementing DRO). Keep in mind that the Arduino program can only use these Clearpath motors as of this writing. I'd like to try to modify the program to accept steppers but likely this will not be done.
And now you need to choose a controller (one of the orange columns)..... or use both as I did. I can't imagine not having full up CNC/CAM capability after doing all this work but it's absolutely a possibility to choose the mCNC option (micro-controller NC) and have a full working lathe for the $291 and simply keep the $701 for a future upgrade (BTW - $701 includes an estimate for a computer, monitor, Mach4, and ESS which you could arguably reduce cost here).
Summing the total soup to nuts cost options.... (subtract $209 as cheaper alternative)
Using mCNC only = $1,759
Using full CNC only = $2,169
Using BOTH mCNC/CNC = $2,460
Special Topics Blog:
Done.... we'll kind of. I certainly will continue to tinker with this conversion and will now need to test all my motion, etc. From this point on I'll add separate articles about this build in the Special Topics Blog - Article links are below.
Threading on the Arduino - Can it be done!
Done.... we'll kind of. I certainly will continue to tinker with this conversion and will now need to test all my motion, etc. From this point on I'll add separate articles about this build in the Special Topics Blog - Article links are below.
Threading on the Arduino - Can it be done!
Consider donating if you like the content - thanks!