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
Thu, 08 May 2008
I went to the park Sunday. Spring is finally here to stay I think. There were lots of small flowers (most less than 3/4" across) and I had fun with my 70-300mm macro lens.
One of the neatest sights was leaves just getting ready to explode out of their buds. This is one of my favorite photos - the fine silky fibers make the leaf seem almost like a butterfly trying to break out of its cocoon.
On another branch I got several leaves in various stages of blossoming.
A little way down the path I was surprised by a large dragonfly - I think of them summer insects. It settled on a plant just long enough for me to grab a quick shot, then went flying again. Another one joined it, a mating dance maybe? In any case they never stayed in one place long enough for me to get another shot.
After a couple hours I wound up beside a pond not far from where I parked. I noticed a turtle had climbed out of the pond onto a log to bake in the sun:
While I was taking its picture, another one climbed out:
And then a third (the first one is out of the picture to the left).
Turtle number three hadn't even made it out of the water when number four showed up:
And then there were five:
Still an empty spot on the log, so turtle number six made himself comfortable:
I like this shot - I'm not sure why they are sticking their necks out and up, but it looks funny.
(posted: 08 May 2008 23:19) (permalink)
Thu, 01 May 2008
All the real welders can start laughing now
I went to the NAMES (North American Model Engineering) show a couple weeks ago. I've been wanting to learn to weld for several years now. There was a salesman doing demos of the Cobra 2000 (aka Henrob 2000) Torch. Of course the salesman makes it look easy. I succumbed to the demo, and bought a torch. Today I finally got all the other bits and pieces, and started playing with it.
The "starter kit" comes with a few pieces of steel for you to practice welding on. My first attempt at welding two of them together resulted in one piece of steel, but it wasn't very pretty. For real practice I'd probably need about 50 pieces. But since I only had three, I spent the next hour or so abusing the piece that I welded together - just running beads every which way, melting holes in it and then trying to fix them, etc.
When that got old, I started looking around for things to weld. They say when the only tool you have is a hammer, everything looks like a nail. Well, when you have a brand new torch, everything wants to get welded. But I didn't really find much. I did find a pair of brackets, I think they once held reflectors on a bicycle. So I welded them together:
The brackets were fairly thin - 0.040 by my calipers. I looked around and found some thicker stuff. A couple of pieces of 1/8" x 3/4" flat steel. So I butt welded them together. The first pass didn't quite get complete penetration, but it stood up pretty well when I tried bending it. I flipped it over and did the back just to make sure.
I soon got tired of looking for pieces of metal to abuse, when I thought of nails. My stock of 2-1/2" finishing nails is a bit depleted now - it took three tries (at six nails each) before I got this:
More practice is clearly needed - this weekend I'm gonna go digging through the scrap metal pile and see what I can come up with.
(posted: 01 May 2008 21:08) (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
March in northern Ohio is still winter, but bird activity is starting to pick up. I took a couple walks in the woods over the weekend and got some nice pictures.
One tree was very popular with woodpeckers. Both male and female Hairy and Downy woodpeckers. I don't know which these are - I got photos of both but the others didn't come out so nice.
In addition to birds, I saw some ferns clinging to a steep hillside, and some kind of seeds left over from fall.
I think the last photo is my favorite
(posted: 31 Mar 2008 21:40) (permalink)
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)
Sun, 09 Mar 2008
I'm really glad I have a snowblower. We had snow starting Friday morning and running nonstop until late Saturday night, along with plenty of wind to spread it around. I cleared the driveway Saturday morning, but within hours you couldn't even tell. Today it is nice and sunny, and I spent a couple hours this morning digging out. I'm VERY glad this didn't happen on a work day.
Pet peeve: snowplow guys who clear people's driveways and pile the snow on the sidewalk. Hey guys, some people still like to walk places. Common courtesy and local ordinances both say not to block the sidewalk. This guy came along after I had cleared the sidewalks in front of my house and a couple of the neighbors.
My dog Buddy doesn't seem to mind the snow.
When it gets deep, he stops walking through it and starts bouncing over it to get from place to place.
(posted: 09 Mar 2008 16:19) (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)