Once the magic smoke comes out, it won't work any more.
John Kasunich
jmkasunich@fastmail.fm
GPG Key
Postings:
Index (titles only):
If you are into RSS, you can Subscribe to a syndicated feed.
Links
Friends
I Support
Powered by
Sat, 19 Jul 2008
Surface grinder into the basement
One unfortunate fact about where I live is that my shop isn't limited by what machinery I can afford - it is limited by what machinery I can find room for. My garage is detached and unheated, and in Cleveland's climate, that means I have to fight rust, especially in the spring. My Van Norman #12 mill is out there, but I'm not willing to put any other machines in the garage. So any new tools not only have to be small enough to fit in my rather cramped basement, but they also have to be light enough to move down the steps.
Today was the "Saturday Sidewalk Sale" at HGR Surplus (they're only open one Saturday a month). After spending a few minutes looking at a reasonably affordable and very nice Mitsui surface grinder, sanity kicked in and I walked away - it probably weighed over a ton. But a little later I found a nice benchtop 6x12 grinder. "Targa" brand, made in Tiawan (a bit better than made in China), it seems to be identical to this Enco one - 3/4HP, single phase 120V motor, 451 lbs. But it was a LOT cheaper at HGR - I paid about one-tenth the Enco price.
HGR's forklift easily loaded it into my truck, but the hard work started when I got home. Before I even unloaded it I started taking it apart to reduce weight. The table lifts right off - 65 pounds. The "saddle" (dunno what the proper term is) slid off after I unscrewed it all the way to the front and loosened the gibs - 74 lbs. Four socket head capscrews and some disconnected wires let me remove the motor/spindle assembly - 48 pounds. And finally, screwing the vertical slide all the way up and loosening the gib allowed it to be removed - 33 lbs. The remaining base casting is about 225 lbs - still too much to move by brute force.
Step 1 was sliding it from the truck tailgate onto a rolling cart. That wasn't too hard - the cart is only a few inches higher than the tailgate, and the machine was on a small pallet.
Step 2 was getting it onto the back porch. The cart is about level with the porch, so I moved it to the foot of the porch steps and spanned the gap between cart and top porch step with a seven foot piece of 2x8. I carefully slid the machine along the 2x8 until it was setting safely on the porch.
Step 3 was getting it into the kitchen. I left it on the 2x8 - it made a handy lever. By pushing the casting to one end of the board, I could lift the other end, and stick a moving dolly under the middle. Then I slid the casting back to the middle over the dolly. The 2x8 very nicely bridged the threshold of the sliding glass door, and a bit of sliding and levering was all it took to get the casting in the house with the dolly once again under it. (See first picture below.)
Step 4 is the biggie - getting it down the steps. There is a bathroom directly across from the top of the steps, and I braced a piece of 2x6 across the inside of the bathroom doorway. That served as an anchor for a block-and-tackle that allowed me to ease the casting down the steps, still sitting on the long 2x8. The rigging allowed me to have total control of the casting during what would otherwise have been some very hairy moments. The second picture below shows it just about to go "over the edge", as the 2x8 tilts from level on the floor, to sliding on the steps. The third photo shows it about half way down - note the superviser at the top of the stairs, making sure I'm doing it right.
Step 5 was getting it from the basement floor up onto the bench. I used a few deck screws to fasten a short piece of 2x8 across three joists. Then I wedged uprights on both ends, so the screws and joists wouldn't need to carry the weight. Rigged the block and tackle again, this time to lift the casting straight up. The next-to-last photo below shows it half-way up, and the last photo shows it sitting on the bench.
Tomorrow I'll bring in the rest of the pieces, clean everything, and put it back together. It still needs a magnetic chuck, but Small Tools Inc. has some used ones in the $100-125 price range that look promising.
(posted: 19 Jul 2008 23:21) (permalink)
Tue, 15 Apr 2008
More Production - Tecumsah Intake Manifolds
A friend of mine is very into minibikes. These bikes use a Tecumsah engine that is identical in most respects to a snowthrower engine. However. the engine is mounted on an angle, and needs a non-standard intake manifold to keep the carb level. My friend had patterns made and got 18 manifolds from an aluminum foundry, and then came to me for machining.
Holding the raw casting was a bit tricky, but eventually I came up with a setup that located the part using some features at the carb end flange. The photo below shows the setup I used to machine the carb end. One program with one tool change, to mill the end flat, clean up the inside of the manifold to make the opening round and concentric, and drill the screw holes. The second pic shows 11 of the 18 parts after the first program. The final step at the carb end was to thread the holes. That went rather quickly with a tapping head on the drill press.
The block end had a lot of material to be removed. Instead of nibbling at it with the Shoptask, I screwed each manifold to a steel block, clamped the block in a tilt vise at the proper angle, and let my Van Norman make a single pass with my 5-1/2" face mill. A slow shutter blurred the cutter - it is only doing 140 RPM or about 200 SFPM.
The cores were pretty far away from the desired shape at the block end, so the ports needed a lot of work. I used the same steel block and angle vise to mount the parts with the port facing straight up on the Shoptask. Jeff Epler let me use some alpha-stage offsetting software that he has been working on. The resulting g-code matches the port in the manifold to the one in the engine block, and blends that profile down into the as-cast interior of the manifold. The program used a 5/16" end mill for roughing, a 1/8" mill for finishing, and a drill to make the mounting holes. Because of machining time, most of them were done with a 0.050 stepdown. But I did a few with a much smaller step size, and they came out very nice.
Both ends of the manifold needed tool changes during the program run. My machine has totally manual toolchanging. However, I'm using the "Tormach Tooling System". which works quite nicely. Each tool has a 3/4" straight shank that goes up into a collet in the spindle. As the collet draws tight, it pulls a 1-1/2" diameter shoulder up against the spindle nose for a very repeatable Z position. It is quite fast and easy to change tools - I was getting 30 to 40 seconds chip-to-chip, with very repeatable results.
Tormach sells a variety of tooling for the system, but it is really pretty simple to convert other tools. For example, I'm too cheap to buy the Tormach collet chucks at about $80 each. But I found some very nicely made 3/4" straight shank ER20 chucks from MariTool Inc. for about $45 each. I made 1-1/2" diameter rings with a 0.749 bore and shrunk them on to the 3/4" straight shanks, and they work perfectly. The photo below shows my current collection of spindle tooling - the collet chucks with the homemade rings are on the right.
(posted: 15 Apr 2008 22:15) (permalink)
Tue, 01 Apr 2008
Most of the CNC work I've done so far has been one or two pieces. But this job is different. I have a friend who works in a lab where they sometimes need the odd bit of metal. I've done jobs for her before, but this is the first one since I got the CNC working.
They needed 20 'pull blocks'. These blocks get glued to samples of tile, then they use a tensile tester to pull the blocks and tiles off of a substrate - it tests the strength of the tile cement.
The parts are made from 2" square steel bar, one inch long. Face one end, then face, drill, and thread the other end for a pull stud. I've been learning more about how to use EMC, and for this job I learned all about lathe tool offsets.
The above photo (blurry, sorry) shows the setup for the second operation. The facing tool is in the toolpost (on the left), the drill is in the tailstock, and the threading tool is clamped down with a couple step blocks on the right. I'm using tool offsets when I switch from one tool to the next.
The program first faces the block. Then it prompts me to drill the hole. It positions the table so a strap clamp bolted to the table lets me know where to position the tailstock, and I stop drilling when the nose of the chuck hits the clamp holding the threading tool. Then I retract the tailstock and hit 'Resume'. The program switches to the threading tool and makes a couple of boring passes first, to make sure the drilled hole is on center. Then it threads the hole M12-1.75. While it is threading, I debur the previous part.
The finished parts:
(posted: 01 Apr 2008 20:07) (permalink)
Mon, 31 Mar 2008
Variable-pitch, variable-diameter threadcutting
In this post I mentioned making a 'fusee', as part of a rat-trap powered vehicle. The trap pulls a wire, which unwinds off of a threaded spool. The spool starts out large, to provide a lot of torque, then as the vehicle gets moving, the diameter drops to get more distance. The idea is the same as shifting gears in a car. The picture below shows the spool with the wire wound up, ready to go.
I promised a post and maybe a video about how that part was made, so here it is. First the video (on YouTube):
Below is the G-code that was used to cut the spool. I've broken it up into chunks so that I can explain what is going on.
Comments in g-code are in parenthesis. I tend to use a lot of comments - it's not the most transparent language, and I sometimes can't even read my own code a few weeks or months after I wrote it. I added even more comments when writing this post.
The lines after the comments are the data that defines the shape of the spool. I used a spreadsheet to calculate the shape I needed, based on how much wire I had, how far the vehicle had to go, and so on. Every project will need something different. When I was done, I had three columns with the Z (length), X (radius) and K (pitch) values. I exported that chunk of the spreadsheet to a text file, and massaged it into what you see below.
EMC2s g-code has a bit of a split-personality as programming languages go. It is a complete programming language, with flow control, variables, etc. In some ways it is quite high-level. You can cut a circle with a single line of code, the flow control is structured (no GOTO), etc. But there are no data structures, there are no arrays, in fact, there aren't even named variables. The statement '#1100 = 0.3200' assigns the value 0.3200 to the variable at location 1100. There 5000 possible variables, plus some dedicated ones above 5000. So what I'm doing here is making three "arrays", each with 28 entries. I'm wasting a bunch of variable space, from 1028 through 1099, 1128 thru 1199, etc, but it doesn't matter.
(program to cut a variable-pitch, variable-diameter threaded pulley)
(the profile - each segment is defined by its ending Z,X coordinates)
(and by the distance per rev along that path - the pitch)
(note that even though the profile is defined from left to right, )
(the part will be cut from right to left)
(Z values stored in #1000 and up)
(X values stored in #1100 and up)
(K values - pitch - stored in #1200 and up)
#1000 = 0.0000 #1100 = 0.3200 #1200 = 0.0450
#1001 = 0.0450 #1101 = 0.2560 #1201 = 0.0450
#1002 = 0.1530 #1102 = 0.2560 #1202 = 0.0450
#1003 = 0.2190 #1103 = 0.2406 #1203 = 0.0440
#1004 = 0.2620 #1104 = 0.2189 #1204 = 0.0430
#1005 = 0.3040 #1105 = 0.1920 #1205 = 0.0420
#1006 = 0.3450 #1106 = 0.1651 #1206 = 0.0410
#1007 = 0.3850 #1107 = 0.1480 #1207 = 0.0400
#1008 = 0.4240 #1108 = 0.1390 #1208 = 0.0390
#1009 = 0.4620 #1109 = 0.1330 #1209 = 0.0380
#1010 = 0.4990 #1110 = 0.1280 #1210 = 0.0370
#1011 = 0.5350 #1111 = 0.1280 #1211 = 0.0360
#1012 = 0.5700 #1112 = 0.1280 #1212 = 0.0350
#1013 = 0.6040 #1113 = 0.1280 #1213 = 0.0340
#1014 = 0.7294 #1114 = 0.1280 #1214 = 0.0330
#1015 = 0.7644 #1115 = 0.1219 #1215 = 0.0350
#1016 = 0.7994 #1116 = 0.1132 #1216 = 0.0350
#1017 = 0.8324 #1117 = 0.1025 #1217 = 0.0330
#1018 = 0.8634 #1118 = 0.0918 #1218 = 0.0310
#1019 = 0.8924 #1119 = 0.0831 #1219 = 0.0290
#1020 = 0.9194 #1120 = 0.0790 #1220 = 0.0270
#1021 = 0.9584 #1121 = 0.0770 #1221 = 0.0260
#1022 = 1.4334 #1122 = 0.0770 #1222 = 0.0250
#1023 = 1.4604 #1123 = 0.0770 #1223 = 0.0260
#1024 = 1.4894 #1124 = 0.0770 #1224 = 0.0280
#1025 = 1.5204 #1125 = 0.0770 #1225 = 0.0300
#1026 = 1.6854 #1126 = 0.0770 #1226 = 0.0320
#1027 = 1.7154 #1127 = 0.0770 #1227 = 0.0320
Now that I have my profile, there is some preamble code - every program needs to start off with a few lines of this. Select the units to be used, set blending mode, turn off tool length offsets and tool shape compensation, etc. See the EMC2 G-code documentation for the details of these commands. Finally, start the spindle, at a speed of 580 RPM.
G20 (inches)
G64 P0.002 (round corners with tolerance)
G18 (XZ plane)
G40 G49 (cancel compensation)
G92.1 (cancel offsets)
M3 S580 (start spindle)
The first step is to rough out the part from a solid cylinder to the tapered shape. The traditional way to do this is a CAM (Computer Aided Machining) program, but those are expensive. EMC2's 'O-word' extensions make g-code into a complete programming language, and it can do a lot of things that would normally be considered CAM. I was able to write code that roughs out the shape using the profile data stored in variables #1000-1027 and #1100-1127. The following code was written by a programmer who happens to be a hobby machinist. It will probably make more sense to programmers (even those who have never seen g-code) than it will to a machinist who isn't a programmer. This ain't your father's g-code.
A key thing to remember when looking at the rest of the g-code - this is generic code to rough and thread a part, based only on the profile data above, and on a few control variables. If you have a different profile, this code would be able to cut it with minimal changes. I've basically embedded the CAM right into the part program.
First, I set a number of variables to tell the code what it is supposed to do:
#100 = 0.330 (initial blank radius)
#101 = 0.050 (material to leave during roughing)
#102 = 0.075 (depth per pass during roughing)
#106 = 0.500 (Z offset, per inch of X offset - sets infeed angle)
#107 = 0.400 (safe X - beyond OD of workpiece)
#108 = 1.900 (safe Z - beyond end of workpiece)
#109 = 6.0 (roughing feed)
The first step is to find out what part of the profile is the deepest. In my case, it is the first part to be cut (last entry in the profile data), but the program doesn't know that, or care. If the shape was an hourglass, this loop would find the skinniest part. The radius (X coordinate) of the skinniest part is stored in variable #103.
(find #103 = X coordinate of deepest part of profile)
#200 = 26 (loop counter)
#103 = 100 (this will be the deepest cut)
O100 while [ #200 GE 0 ] (loop through all segments of the profile)
O101 if [#[#200+1100] LT #103]
#103 = #[#200+1100]
O101 endif
#200 = [#200-1] (decrease loop counter by 1)
O100 endwhile
The code above includes two of EMC2's 'O-word' extensions, a while loop and an if statement. The while loop starts at "O100 while" and ends at "O100 endwhile". I indented the loop body to make it easier to read, EMC2 ignores indenting. The if statement starts at "O101 if" and ends at "O101 endif". O-numbers must be unique - they are used by the interpreter to match up the beginning and ends of statements. The while loop starts at segment 26, and loops until it get to zero. "GE" means "greater than or equal".
"#[#200+1100]" might need some explaining. #200 is the loop variable - it starts at 26 and counts down to zero. 1100 is the location of the first X value. "[#200+1100]" adds the loop counter to 1100 to get the location of a specific X value, and the outer "#" looks at that location to get the actual X value. So in the first pass, when #200 is 26, [#200+1100] is 1126, and #[#200+1100] is the same as #1126, which is 0.0770.
The next step is to figure out how many roughing passes are needed. The code below does that by adding #102 (the depth per pass) and checking to see if the skinniest spot is still inside the diameter of the blank. If it is, it adds another pass.
(find #104 = offset for first pass, and #105 pass count)
#104 = [#101+#102]
#105 = 1
O102 while [[#103+#104] LT #100]
#104 = [#104+#102]
#105 = [#105+1]
O102 endwhile
Now that those preliminary calculations are out of the way, its time to cut some metal. This next chunk of code is pretty complex. When I started writing this post, I was planning on explaining everything in lots of detail. That was an hour ago, and its getting late. So instead, I'm going to rely on the comments in the g-code. If anyone has any questions, please email me. If people want it, I'll come back and add more details later.
I will mention one detail here: the "if" statements at O105 and O106 are used to speed up the program by rapiding though any segements that are outside the blank. If you watch the first and second roughing passes in the video you will see the tool speed up. Those rapids were computed automatically by the g-code - there was no CAM involved, and no manual conversion of slow moves to rapids.
(go to safe start point)
G0X#107Z#108
#104 = [#104-#102] (move in by one step, so first pass will remove some metal)
(loop through roughing passes)
O103 while [#105 GT 0] (#105 is the number of passes, it counts down)
#200 = 26 (loop counter - counts through the segments on each pass)
#110 = [#[#200+1100]+#104] (X at start of first segment)
#112 = [#[#200+1000]+[#104*#106]] (Z at start of first segment)
(rapid to #102 outside start of pass)
G0X[#110+#102]Z[#112+#102]
(is start of segment inside the blank?)
O105 if [#110 LE #100]
(yes, cut to that point)
G1F#109X#110Z#112
O105 else
(no, rapid to that point)
G0X#110Z#112
O105 endif
(loop thru rest of segments)
#200 = [#200-1]
O104 while [ #200 GE 0 ]
#111 = [#[#200+1100]+#104] (X at end of segment)
#113 = [#[#200+1000]+[#104*#106]] (Z at start of segment)
(is either start or end of segment inside the blank?)
O106 if [[#110 LE #100] OR [#111 LE #100]]
(yes, cut to the end)
G1F#109X#111Z#113
O106 else
(no, rapid to the end)
G0X#111Z#113
O106 endif
(previous end becomes next start)
#110 = #111
#112 = #113
(next segment)
#200 = [#200-1]
O104 endwhile
(move out to safe X if not already out)
O107 if [#111 LT #107]
G0X#107
O107 endif
(move over to safe Z)
G0X#107Z#108
(next pass)
#104 = [#104-#102]
#105 = [#105-1]
O103 endwhile
(roughing complete)
After roughing out the part, the next step is the threading. The code to do the threading looks very similar to the roughing code, except that it uses G33 spindle-synchronized moves instead of ordinary G1 linear moves.
Another detail: the code after the comment "(next pass)" is designed to reduce the depth of cut as it gets closer to the finished size, so the final cuts will be very light and avoid tool deflection. Once the amount of metal to be removed is less than the initial depth per pass, the O118 and O119 "if" statements reduce the depth of cut in half every time, until it reaches the minimum that was specified in #116.
#101 = 0.100 (space to allow for accel)
#104 = [#104+#102] (reset to offset of last pass)
#102 = 0.007 (depth per pass during threading)
#116 = 0.0004 (smallest finish pass)
#105 = 1 (pass counter)
(loop through threading passes)
O113 while [#104 GE 0]
#200 = 26 (loop counter)
#110 = [#[#200+1100]+#104] (X at start of first segment)
#112 = [#[#200+1000]+[#104*#106]] (Z at start of first segment)
#114 = [#[#200+1200]] (K value for first segment)
(rapid start of pass)
G0X[#110]Z[#112+#101]
(start sync move to segment start)
G33K#114X#110Z#112
(loop thru rest of segments)
#200 = [#200-1]
O114 while [ #200 GE 0 ]
#111 = [#[#200+1100]+#104] (X at end of this segment, start of next)
#113 = [#[#200+1000]+[#104*#106]] (Z at end of this segment, start of next)
#115 = [#[#200+1200]] (K value for next segment)
(cut this segment)
G33K#114X#111Z#113
(previous end becomes next start)
#110 = #111
#112 = #113
#114 = #115
(next segment)
#200 = [#200-1]
O114 endwhile
(move out to safe X if not already out)
O117 if [#111 LT #107]
G0X#107
O117 endif
(move over to safe Z)
G0X#107Z#108
(next pass)
O118 if [#104 LE [2*#102]]
O119 if [#102 GT #116]
#102 = [#104/2]
O119 endif
O118 endif
#104 = [#104-#102]
#105 = [#105+1]
O113 endwhile
M5 (stop spindle)
G0X1Z3 (move clear of work)
M2 (end program)
%
(posted: 31 Mar 2008 00:27) (permalink)
Fri, 22 Feb 2008
Every year, my employer holds a contest as part of National Engineers Week. Teams of employees design and build contraptions to complete some task, and on Friday of Engineers Week, we have a competition to see which one works best. As in prior years, I teamed up with a co-worker for the contest.
The task is different every year. This year, we needed to build a vehicle powered by the classic Victor rat-trap. The vehicle had several tasks to perform:
- Pop a balloon on the right edge of the 8 foot wide course, 15 feet from the start
- Pick up a 1-1/2" diameter steel washer one foot right of center, 24 feet from the start
- Pick up another washer at the center of the course, 30 feet from the start
- Pick up third washer one foot left of center, 36 feet from the start
- Pop a second balloon on the right edge of the course, 45 feet from the start
- Stop with all wheels on a 24 inch square of sheet steel, centered in the course, 55 feet from the start
We quickly decided that we wanted to go for the autonomous bonus. If it wasn't for the strict weight constraints implied by rat-trap power, I would have used a laptop running EMC2's Hardware Abstraction Layer (HAL), which provides functional blocks such as encoder counters, etc. But we needed something lighter, so I ordered an inexpensive AVR microcontrollerboard. I also got some optical sensors that I hoped would be able to sense the black electrical tape that was going to outline the course. My plan was to make a tricycle shaped vehicle, with the front wheel powered by the rat trap, and the rear wheels turning encoders (made from old mice). The wide spacing of the rear wheels would allow fairly accurate navigation, and the optical sensors would provide additional guidance. The AVR would provide a control signal to a standard RC servo for steering.
My first mistake was not starting on the software side right away. Instead, I had fun with my newly CNC'ed Shoptask working on the rat-trap powered "engine". After the first week or so, I had the engine nearly complete, but work on the rest of the vehicle was had barely started. We had a frame but not much else.
About half of the allotted time had passed before we did the first tests. We improvised a pair of rear wheels, and tested the "engine". It managed to travel an underwhelming 25 feet before stopping. We knew that the improvised wheels had a lot of friction and the real ones would be better, but we had no idea how much better. We immediately started focusing on "less weight, less friction". The same day I tested the optical sensors. Although they do a fine job of differentiating between "something" and "nothing", they could not tell apart different kinds of "something". In particular, the difference between "floor" and "black electrical tape on the floor" was virtually non-existant.
With half the time gone, my trip to Wichita looming, the software not even started, and faced with much mechanical work to get the weight and friction down, I recuited another team member, a software engineer. Instead of using the AVR board with its learning curve, he planned to use a small board from one of our products, with his existing development environment. He began coding, while I worked on the rear wheels and encoders, and my other teammate worked on the frame, magnet assembly (for picking up washers), and other parts.
By Wednesday of E-Week, we had rear wheels with encoders. Test runs showed that the rat-trap could move the vehicle at least 60 feet at a nice pace. But time simply ran out to get the software working. By mid-day Thursday we all had to admit that autonomous wasn't going to happen, and drop back to radio control. The encoders came off to save weight and drag, and we concentrated on finishing up.
The Vehicle
First an overall view, as seen from behind at the starting line (click on pic to enlarge):
Across the back is a row of six magnets taken from scrapped hard-disks, to pick up the washers. On the right rear corner is the balloon popper - pushpins pressed into an upright strip of aluminum, and sharpened. The rear wheels are small and have O-ring "tires" because we thought we were going to be driving encoders from them. We needed many counts per inch and no slippage. If we had been doing RC control from the beginning I would have probably used CD-ROMs as wheels, they are light and have very low rolling resistance. In the center of the rear "axle" is a lever, connected to a tube running forward. The rule for awarding points for "all wheels on the metal plate" at the end of the course actually can be read as "nothing touching the floor outside the plate". So the RC servo on the left pulls a pin, the tube slides forward, and the rear wheels pop up off the floor. If we don't hit the plate centered, it won't matter - the magnets that are on the plate will hold the vehicle, and the ones hanging off the plate will be above the ground by the thickness of the plate.
Now a front right view, showing the rat-trap "engine".
The trap drives the large aluminum arm on top, which turns the large black (metal) gear through slightly less than half a revolution. The two stages of gears (salvaged from old printers) make the 3.3" diameter pulley at the front bottom turn about 3-1/2 revolutions. That winds up about 33" of 30AWG wire, which unwinds from the tapered threaded spool that drives the main wheel. The spool starts out large for good starting torque, like low gear in a car. Then it tapers to a smaller diameter, like upshifting for higher speed and better economy. The thread on the spool changes both diameter and pitch - cutting it was a fun exercise of EMC's G33 spindle synchronized motion. I'm planning a separate post about that, and maybe a video. I clearly had lots of fun with CNC - the trap arm, the wheel, the wire pulley, the bearing brackets, the cutouts in the plate that the trap is screwed to, the cutouts in the main frame rails, and the rear wheel mounts, were all done on my Shoptask in mill mode. The wire spool, several shafts and bushings, the groove in the wire pulley, and the rear wheels were also done on the Shoptask in lathe mode.
The Competition
I believe there were twelve teams signed up, but a couple dropped out. That left ten entries. We got photos of seven besides our own, here they are (click to enlarge):
Several competitors took advantage of a loophole in the rules that allowed you to recharge the rat-trap, using things like windshield wiper motors to pull a wire attached to the trap arm, etc. Not exactly the "green", energy efficient way to do things, but anticipated and allowed by the rulemakers. I was pleased to observe that our vehicle with its single "trap load" of energy was faster than all of the ones that recharged the trap.
The Results
We lost. Badly. Simple human error, based on a lack of practice runs. When you are driving a radio control vehicle that is coming towards you, the steering works one way. When the same vehicle is going away from you, the steering is reversed, because you are seeing it from the back instead of the front. My teammate was driving, and stood about two-thirds of the way down the course. He did great as the vehicle approached him - popped the first balloon, and got all three washers. But when it got close to him, instead of backing up as he did during practice, he stood still and turned around to track it. Turning around reversed the direction of the steering, and at a critical moment a few inches short of the second balloon, he turned right instead of left. The vehicle crashed into the balloon support, and we were out of the running.
Based on the performance of the other vehicles, we would have definitely been near the top if we had autonomous control - software simply doesn't make that kind of mistake. But we had too little time. I should have recruited the software guy a couple of weeks earlier. Oh well, that's how things go. It was still a lot of fun.
(posted: 22 Feb 2008 23:05) (permalink)
Wed, 20 Feb 2008
This isn't strictly a Shoptask related post, but it is CNC and EMC2 related.
Last weekend I joined three other EMC2 developers for a "mini EMC workshop". Chris Radek, Jeff Epler, Steven Wille Padnos, and I all met at Machining, Programming, Manufacturing, Inc. in Wichita Kansas. Stuart Stevenson, one of the owners and an active EMC2 user, invited us to "come and play for a few days". Thanks Stuart!
MPM does a lot of multi-axis work, mostly for aircraft makers. Of the 13 or 14 CNC mills in the shop, well over half are four- or five-axis machines, with a variety of controls. Some of the pictures below I took while I was there, others I shamelessly lifted from the MPM website (with Stuart's permission of course).
Fadal with tilting rotary table for 5-axis work
Mazak and Haas 5-axis with A and B axes on the head.
Cincinatti 5 axis, also A and B at the head (there are three of these, two working, one waiting for a rebuild/retrofit).
Viper bridgemill, with B and C axis head.
All machinists know that you can never have too many vises. (No, I didn't say vices.)
The Project
Over the summer Stuart converted a Dah Lih 3-axis knee mill to use EMC2. Some photos and info about that project can be seen here. Now he is working on something a bit bigger - a Giddings and Lewis horizontal boring mill, with a 100 x 106 x 72 inch working volume. The machine has been inoperative for several years, ever since the old control died.
Stuart invited us because this machine makes a good test case for something that is often discussed on the emc-users mailing list - taking feedback from linear scales on the table in addition to (or instead of) encoders on the screws. Often when it comes up, it is in the context of someone wanting to use less expensive rolled ballscrews and correct their inherent errors using a linear scale. Sometimes people want to use scales to correct for or at least detect lost steps on a stepper motor machine. In Stuart's case, he wants to correct for thermal expansion of the screw - on one of his other large machines, a single rapid from one end of travel to the other caused a change of a couple thousandths of an inch because the screw warmed up.
The G&L already has 1 micron resolution scales on X, Y, and Z (table motion). There is a fourth axis, W, which controls the quill, but I don't believe it has a scale. All four axes are driven by AC servomotors, with Allen-Bradley 1391 servodrives. The motors have resolvers, not encoders, and the resolver signals go back to the drives only. We were pretty sure that using ONLY the linear scales wouldn't work, so Stuart bought and installed an encoder on the X axis motor before we arrived.
Other than the Mazak at the CNC workshop, none of the four of us has ever worked on anything larger than a Bridgeport. When we walked out into the shop, we immediately got a new sense of scale. The photo below shows Steven (left) and Stuart standing next to the table of the G&L. The large angle plate is one of TWO that were on the table. Stuart guesses that they weigh close to a ton each. The second photo shows the head and spindle just left of Jeff, and the 106" travel Y axis towering above his head. That ballscrew is about 3" in diameter. The heavy chain behind Jeff's head goes to a hydraulic counterbalance in the column. The white box to the right of Jeff contains the computer, monitor, and operators controls. Between Jeff's arm and the box you can see the fins on the 20HP spindle motor, and to the right of the box is half of the large gray cabinet that contains the axis drives and other control equipment.
The Results
We were able to get the X axis working nicely, without hacking any of the EMC code. We used two PID loops, and summed their outputs together in HAL. Both loops get position commands from EMC. One of them gets its feedback from the encoder on the motor, and the other one gets its feedback from the linear scale. The Proportional and Derivative gains, and the FeedForward term, are set for the loop that uses motor feedback. That loop has no Integral gain. The other loop, using the scale for feedback, has Integral gain and nothing else, to correct for the steady state error between screw and scale.
As always, it took some trial and error to get things tuned properly. The P gain was a lot lower than I expected, probably as a result of the huge mass of the table and the two angle plates. After everything was working with both feedback devices, we started experimenting with gains in an attempt to use only the scale. We didn't really think it would work, but if it did it would save Stuart the expense and hassle of mounting encoders on the other motors. (The Y axis motor is fifteen feet up, on top of the column.) We were right - it didn't work. When we reduced the effect of the motor encoder feedback, the axis went unstable. We got to hear what it sounds like when a multi-ton table starts to oscillate at 5-10 cycles per second, pushed by a 45 amp servo drive. Fortunately we didn't break anything.
(posted: 20 Feb 2008 20:45) (permalink)
Fri, 11 Jan 2008
Another "back-dated" post - I've been too busy to post things lately.
With the spindle encoder mounted, I wanted to cut some threads. I wired the encoder to my last two parallel port input pins. I could only use one of the quadrature phases, plus the index, because I'm out of pins. One of these days I'll install the Mesa 5i20 board that I bought last year, and have plenty of I/O, but for now this works.
After wiring up the encoder, I added a few lines to my .hal and .ini files to configure it. Then I needed a threading tool. I have a nice carbide inserted threading tool that my dad gave me. He was a machinist for over 40 years, but he worked on machines a lot bigger than my shoptask. The tool has a 1" square shank! My toolpost can accept a maximum of about 1/2". So I got out some step blocks and clamps and improvised:
The first thing I threaded was some 3/8" aluminum rod. It took a few trials to get the pitch diameter right, but then I moved on to drill rod. Below is the first real threaded part - O1 drill rod, threaded 3/8-16 on both ends.
(posted: 11 Jan 2008 22:34) (permalink)
Mon, 07 Jan 2008
To do CNC threading you need a spindle encoder. I dug up one this week, and figured out how to mount it. I had a couple timing belt pulleys and a belt, pulled from an old printer. It isn't really practical to belt directly to the spindle. The diameter is quite large, and there is very little depth behind the main pulley. But the stud gear that used to drive the change gears can be used instead.
Modifying one of the pulleys to fit on the stud was straighforward. Mounting the encoder is a little more complex. I decided to copy the method used to adjust the change gears - a bracket that pivots on a stud and is locked in place by a bolt in a curved slot. I drew up the bracket in EasyCad, then manually picked off the critical coordinates and wrote a g-code program to mill it. Again O-word loops and subroutines eliminated a lot of duplication.
The bracket was specifically designed to use a piece of scrap aluminum that I already had. I managed to work around 5 holes and a large notch in the side of the stock. The notch is in the upper left of the photo below, one of the holes is in the upper right, and a several small holes are on the bottom edge, below the left hold-down bolt. Another hole was inside the large hole at the right end of the part, where it will pivot.
The strange arrangement holding the part is a consequence of the short Z travel of the Shoptask. Just about every milling job needs to be blocked up in order for the quill to be able to reach it. In this case I have a couple pieces of 2" diameter steel about 3" long, topped with 1" long 1" diameter sections. The 3/8-16 hold-down studs go through everything and into the t-nuts.
The finished part, with both holes and the curved slot milled, outside profile milled, and encoder mounting holes spot drilled. I finished drilling and countersinking them on the drill press.
And finally, the bracket mounted in the machine, with the encoder, pulleys, and belt (orange). The Z axis stepper motor, belt, and leadscrew pulley are in the lower right corner, and the larger pulleys are the spindle drivetrain - v-belts and step pulleys.
Next step - wiring it, and configuring everything so I can do threading.
(posted: 07 Jan 2008 23:15) (permalink)
Tue, 01 Jan 2008
My stepson was in town for the holidays, on leave from the Navy. Before he left to go back, I gave him this plate, with his ship's name, number, and motto engraved on it. It was my first non-trivial CNC project.
I used Chris Radek's TrueType Tracer to generate the g-code for each line of text. Scaling them and centering them was tricky because I didn't know exactly how big each line was. Fortunately TrueType Tracer is GPL software. I got the source and made a few tweaks. My hacked version generates comments in the g-code that show the x and y extents of each character, as well as the overall line. I also added two additional parameters for x and y offsets, so it is easy to move a line of text around. (I submitted my changes to Chris, and he's planning on including them in the next release of TTT.)
I ran the patched version of TTT once for each line, and concatenated the output into one long g-code file. The size info embedded in the comments allowed me to calculate the scales and offsets needed to match the lengths of the first and last line, and to have all three lines centered horizontally and nicely spaced.
When I did my first CNC engraving I used a 1/8" ball end mill because that was the smallest thing I had. But a ball end mill is bad for engraving - the line width is very sensitive to depth. A moderate V-bit is better. For this project that is what I wanted, but I didn't have one. I did have a number of surplus 3/16" square ended HSS end mills. I carefully ground one of them into a shallow V cutter.
I am pleasantly surprised at how well that hand-ground cutter works. The V angle allows me to vary the cut width by varying the depth, which lead directly to the idea for the stars. Each star is five straight cuts that get deeper as they approach the center. I did a layout in EasyCad to work out the geometry, then wrote a g-code subroutine to make stars of any size. It only works with the particular V angle of my cutter, although it could be modified to work with other cutters. If you would like a copy contact me.
(posted: 01 Jan 2008 12:45) (permalink)
Fri, 28 Dec 2007
I've been doing lots of stuff with the Shoptask, but haven't posted in a while. I'm going to cheat and back-date some posts showing what I've been up to.
Cutting keyways on the lathe is a trick that is probably as old as lathes. You mount a cutter so that what will be the top of the keyway points straight forward (or back). Cuts are made by using the lathe carriage as the "ram" of a hand-powered shaper. The cross-slide is used to advance after each stroke.
It's not something you want to do often, or for heavy work, but for the occasional keyway in aluminum it works. However, doing it by hand is a nuisance. A single keyway might need a hundred or more cuts, advancing 0.0005" or less after each one. That gets old fast, and it is also all too easy to accidentally take a heavier cut.
CNC makes it a lot easier. A CNC program can rapid the carriage left to make a cut, then back to clear, rapid right, advance a very small amount, and make another cut, without getting bored or accidently cutting too deep. EMC's dialect of G-code has O-word loops which make it even easier to do highly repetitive work like this.
The first photo below shows it just about to begin a cut. The cutting edge is on the left in the photo (closest to the operator). The end of the cutter facing the chuck has a positive rake, and the cutter is as sharp as I could get it so it could take a fine chip.
Below is the finished part, alone, and installed. This piece replaces the Y-axis handwheel - I don't want a big wheel with a crank handle on it spinning around in the vicinity of my stomach when the machine is running as a CNC. Replacing the handwheel also significantly reduces the inertia that the motor has to accelerate and decelerate.
(posted: 28 Dec 2007 22:15) (permalink)