OK, so, I’ve been very busy with work and other projects lately, but in the past week or two the traffic here has picked up and a bunch of new people have asked about boards and project files. So, I am going to try and get some things wrapped up and ready for release. Among other things, I want to address a few nagging issues in the firmware, and get the project files up on Github. I also want to write up a proper BOM to make it easy for people to buy parts.
Anyway, this project/blog are definitely not dead, and for those of you who’ve asked about getting a board, I will definitely be getting things together over the next few weeks. In the meantime I appreciate your patience and happy machining!
OK. So, I have been using my pendant for a couple weeks now with both my mill and lathe. There are a few significant things still to do, but the basics have all held together very well so I think it’s time to move things forward. To that end, I’m going to offer the prototype PCBs I have left for sale, for those of you who don’t mind the alpha-ness of this.
The big things which are still open:
- Make DRO use current work-system coordinates rather than machine coordinates
- Implement the Pause and Block mode buttons
- Implement spindle control
- Implement adjustable speed setting for continuous-feed buttons
None of these are hardware questions, nor particularly difficult. This was really meant to be a platform for people to build what they wanted in a pendant anyway, so hacking your own is integral.
At this time I don’t have any plans to sell kits. I will provide a BOM and all parts are very common items available from the usual suppliers. I’ve thought about commercializing this more aggressively, but I’m not sure if the demand is there to justify it right now. The messiest part of this project is the enclosure. The approach I’ve taken works, but it’s a bit demanding on the builder. I can’t machine the enclosures myself at a reasonable cost, and sending them out would add a lot of cost unless I did a lot of them. A membrane keypad would be much better in the long run, but also has a large upfront engineering cost.
At some point I might try getting this to work with Mach 3, since the user base for that seems much larger, and more inclined to spend money on things. If I could get that to work, then I might look into doing a Kickstarter project to get some membrane keypads made. Price estimates for those range from $500-$2000 in tooling plus $5-$20 per keypad in quantities of 100. The low end is a shady supplier in some back alley in Shenzhen and the top end is a company in Peabody, Mass. Draw your own conclusions.
Anyway, here’s the deal: boards are $20 each including USPS shipping anywhere in the US. I’ll take international orders, but the postage will be extra, and you’ll have to send me a money order. I’ve just read too many horror stories about PayPal scams and international shipping and don’t want to deal with it. I will provide a BOM and suppliers list and do my best to help build it and get it running. THIS WHOLE THING IS BETA.
If you’ve never used the Arduino or edited a HAL file by hand, you will need to learn a few things to get this to work. I originally spent $130 for 13 boards. Shipping will cost five bucks, and going to the Post Office and back will take me twenty minutes during my lunch break. If these sell out quickly, I might order more, or I might not. I’ll provide the Eagle files to anyone who wants them and you can make your own. I’ll provide the Arduino and Python EMC code too.
Anyway, if you’re interested, just leave a comment and I’ll mail you a PayPal invoice.
In case anyone out there is looking for an automatic tapping head, I am selling Procunier 1E on eBay:
The head itself works great, it just has a little bit of cosmetic wear. It comes with a full set of collets for #6-1/4″ and a replacement clutch set. Selling because it got almost no use and I’m hoping I can get at least a good part of the way to the cost of a rotary table for my mill.
A few months ago I was over on the CNCZone and found myself reading the roughly 10,000th post asking the same dozen questions about how to do a CNC conversion on one of the ubiquitous Sieg X2 mini-mills. Discussion boards like the ‘Zone are wonderful resources for many things, but for a newbie looking for a roadmap, they stink*. Hundreds of good ideas lie buried deep in threads with dozens or hundreds of posts, often on unrelated subjects, and with no particular system of organization. Part numbers, preferred suppliers, and recommended approaches likewise change over time, while forum posts remain frozen in amber. What people really need is a wiki, so a few months back I decided to set one up:
My goal for this site is to serve as an index of links to the great sites and info sources out there, as much as a source of original content. I’m not looking to steal anyone’s thunder, but rather to give newbies a single place from which to start their exploration. Anyone who’d like to help fill out the content is welcome; all you need to do is register to be able to add or edit pages.
* If discussion boards are problematic for long-term knowledge transfer, mailing lists and IRC channels are vastly worse. IRC has its place as exactly what it is–a real-time chat system–but the lack of any thread-type organization greatly reduces the findability of knowledge that changes hands over it. Likewise, there is nothing that mailing lists are good for that a discussion board doesn’t do better.
Yesterday I took a few hours to go over to the Artisan’s Asylum, a “hackerspace” just outside Boston proper, to get checked out on their 2-axis Sharp CNC mill. If you live anywhere near Somerville, it’s a seriously cool place, and for $75 a month, you get access to a full shop with the aforementioned mill, a 13″ Clausing Colchester lathe, woodworking shop, and welding shop with 220V MIG and TIG machines.
My main reason to be there was that every so often, I have a part I can’t quite fit on my benchtop machines, but I was also interested to get a chance to work with a “real” CNC control, in this case, an Acu-Rite MILLPWR of early 90s vintage. Compared to a VMC, which is designed mainly for production, 2-axis knee mills like this are used to assist the machinist in making one-offs or very short runs, rather than replacing him completely. As such, they’re probably the closest “serious” industrial equivalent of what we do with little “toy” machines like mine.
While the control was organized differently than EMC or Mach, I found it very user-friendly and efficient to work with. After the jump, a few more detailed observations on what I really liked about it…
Read more of this post
Following on the previous post, I shot a quick video showing some of the new firmware features in action. Most importantly, my suspicion that it was a serial buffer overflow problem seems to have panned out. As this video shows, I can spin the encoder as hard as I can, and nothing weird happens. A more technical explanation after the jump…
Since switching to the 128-cpr encoder I’ve been having a slightly peculiar problem and I think I may have found the cause: serial buffer overflow.
What’s happening is that during program operation, when the DRO is receiving updates, if I spin the encoder very fast, the LCD display would lock up and refuse to display any values. Originally, the only way to recover was to reset the Arduino, but I made some improvements that allowed for a softer recovery. Basically, if it froze, you had to wait a second, then jiggle the encoder a little, and the display would come back. It still wasn’t robust, though, and I couldn’t see what was going on.
Well, it turns out that the Arduino’s serial buffer is a whopping 128 bytes, which isn’t very much. With 6-byte messages streaming in and 3-byte messages going out, it seems very possible that I’m getting buffer overruns. If this is in fact the problem, there are a bunch of different possible solutions, but they all basically come down to reducing the amount of data moving over the wire, particularly the update rate of the encoder.
On the incoming side, I’ve already made a major change in ditching the DRO display during program operation. Instead, I created a different page which displays the spindle and feed rate override percentage values, which are what you’d actually control in that setting. Next, I’m changing the way updates are sent so that only the “hot” parameter gets updated more than twice per second. In other words, if you’re manually jogging the X axis, then the X axis DRO will update ten times a second, but everything else will only update twice. Likewise, in program operation, if you’re tweaking the FRO, then the FRO% and velocity will update fast, but the spindle RPM will go in the slow lane. Taken together, this will reduce the number of updates without, I think, reducing any utility.
On the encoder side, there are a few possibilities. I didn’t have this problem with my old encoder, which was I think due to (1) it being only 32 CPR, so you’d have to spin it 4x faster to get the same amount of data output; and (2), it had detents, which slowed down the spin rate even further. All told, I think I liked the feel of the old encoder better. I *really* like the detents, because they allow for precise positioning. The lower pulse rate does make it less nice to use for long jogs, but since the pendant has continuous-jog buttons for both X and Y, I think the main use of the handwheel is primarily for nudging, where 32 CPR is plenty.
A true CNC MPG wheel like this one might be the best of both worlds, but it adds a lot of expense ($60-$80 vs $20-$30). I also picked up some really basic encoders of the type used in consumer audio/video equipment which I’m interested to try. They’re 24-count, detent type, and cost under $5 each. I previously tried some Panasonic encoders like this and they failed, because the output was unreliable for steady rotation, but maybe these will work better. If they do, it could trim $30 or more from the price of a finished pendant.
After a good 10 hours of knocking around and around a yard of double-sided tape, I finally have everything inside the enclosure!
The good news is that everything fits. Other than that it’s kind of a mess, which is probably to be expected from Serial #000001. The jog wheel was pulled off the shaft of a stepper, so it’s not as big or pretty as I’d want. The keypad works, but the cutout is major-league ugly, and the overlay doesn’t fit it well. And the labels don’t align as well with the buttons beneath as they should. Mounting the LCD was also a PITA as it required making a mount to fit the studs inside the enclosure. And, just when I thought I had everything ready, I realized the USB socket needs to have clearance milled out of both the top and bottom halves of the enclosure.
Nonetheless, I’m feeling pretty happy about seeing it all inside the enclosure for the first time. I had an epiphany and realized that the outlines for the cutouts for the keypad and LCD unit could be marked by printing outlines on sticker paper and sticking them right on the top of the case. All you’d have to do is clamp the case down and mill right through.
I also have an idea for improving the feel of the keypad. Tomorrow I’m going to hit the hardware store to see if I can get some 3/16″ weather stripping. The tops of the buttons are 0.167″ above the PCB, so if the weather stripping is 0.1875″ of foam, that might strike a good balance of firmness and give. I’ll keep my fingers crossed because if that doesn’t work, I’m probably going to have to go back to the drawing board. My goal has been to make this something that’s relatively easy for someone to assemble. Right now, I’m starting to push those limits a bit.
I’ve also started to go back and nibble more on the software. When I swapped in the new 128PPR encoder, I noticed a problem. Basically, if you gave the wheel a really good spin, it caused the Arduino to become unstable, and the only way to get it working properly was to reset it. The old, 32PPR encoder didn’t seem to cause this problem, but it may also have been that with detents, it simply couldn’t be spun as fast without really trying. More testing will be necessary. This is why the encoder is connected via a header, not soldered on!
In the meantime, I did some tweaking to the data input-handling routine in the Arduino, and the result is some improvement in the stability of it. Basically, I added some exception-handling code that tries to recover if the serial communications get out of whack. So far, it’s not preventing errors completely, but interestingly, if you spin the encoder and the display locks up, if you wait a second and just jiggle the wheel a little, it will “wake back up,” for lack of a better term. This makes me hopeful that there’s a specific condition or bug down there causing this that I can handle and make this really solid. As it is now, I think it’s quite usable, but it’s a long way from industrial quality. Though, it’s also a long way from industrial price….
I’m coming around to thinking that the 3-axis DRO page might only make sense when running in manual mode. Instead, I think I’m going to have a Program Run mode page that displays the FRO and SRO percentages, the spindle speed, and the velocity. That will be more useful, and, in practice, likely a lot less data coming down, which might make lockups even less likely.
Have you ever heard the expression “yak shaving” before? Allegedly invented at the MIT AI lab a decade or so ago, it’s what you call all the stupid, annoying work you have to do first in order to be able to do what you’re trying to get done. When you find yourself looking for a tool to make a tool that you can use to make the tool you need (and which you could buy from Enco for $25), you’re shaving a yak.
Anyway, I spent a good six hours today trying to figure out the best way to cut a hole in a piece of plastic. To be specific, to cut out two holes in the face of the enclosure for the keypad and the LCD display. In order to do this, I need a way to clamp the enclosure securely. Neither a vise or double-sided tape would work, and there’s not enough room to get step clamps snug enough. So, it was going to require a fixture.
The enclosure front panel luckily has a bunch of holes with threaded inserts (to hold the two halves together), so I figured I could just use these to screw it down to a piece of tooling plate. So, all I had to do was precisely drill 12 holes (4 for dowel pins to locate the fixture, 4 1/4″ holes for screws that hold the fixture to the mating plate on the mill, and 4 for the screws that would hold the enclosure to the fixture). As this was one of those cases where every .001″ counted, it was slow work.
Nonetheless, I happily test-fitted the hold-down screws for the fixture (spot on), the hold-down screws for the enclosure (3 perfect, one hole needed to be drilled .010″ oversize), and the dowel pins (one came out oversize due to cheap drill bit, but 3 pins should be plenty). The screws that hold the fixture to the mill come down from the top. The screws that hold the enclosure come up from the bottom. So, you need to screw the enclosure to the fixture, then screw the fixture down onto the mill. Easy enough, if time-consuming.
Can you see what’s coming? When I tried to actually put it all together, I realized that once I screwed in the workpiece, it covered the holes where the hold-down screws for the fixture went. If I screwed the fixture down to the table first, there’d be no way to attach the workpiece. So, this would be me:
So, long story short, I’m going to have to make some clamps to go around the edges that can be secured from the top. The earlier efforts weren’t entirely in vain as they’ll make it easier to attach straightedges to locate the workpiece properly, and the end result will be a fixture that’s easier to use as I’ll be able to swap workpieces without having to unmount the fixture. Still, I’ve probably got another 4-5 hours of work ahead before I can even *try* the CAM program I wrote to mill out the two holes. Anybody need some extra yak hair?