As part of mentoring out High School’s First Robotics Team Andromeda One I have learned Solidworks. Since we have a Jet Mill converted to CNC (running GRBL and a Chinese controller) and several of the other mentors, including myself, having CNC routers like the ShapeOKO 2 and X-carve we wanted to be able to have a one-stop shop for doing our design and CAM toolpath generation. There are some generic postprocessors for Solidworks but none seemed to support exactly the post processing options and syntax I wanted to see. As such I embarked on writing my own post for Solidworks.
When installing it is necessary to install it as Administrator. If you do not it will not install properly/fully and may not work properly. I then used this tool to edit a Postprocessor from scratch and compile it into something Solidworks understand. Note, this was not very straight forward and resulted in several iterations of trial and error until I got it close enough. I’m still getting syntax errors on comment lines. For some reason the line starts with an “*” then the line number and then the tool comment. I cannot determine where this “*” is coming from in the post or how to get rid of it. The second issue is the line numbers, These are very much a personal preference but even if they are disabled in the post configuration they still appear on the output in Solidworks. In the end the postprocessor output needs to be post processed to run on my CNC with a text editor to fix the tool comment lines.
I created this heart shaped box in November 2017 and never shared it here. This box is laser engraved on my 2.5W Laser in Meranti and CNC’d inside and out. Each side takes about 8 minutes on the CNC with 4 Minutes on the laser. This is version 1.0 of the box and I think I’ll be refining the design and possibly adding more depth to it this year. This whole design was done in Vetric Vcarve including the laser toolpaths. Finish is boiled linseed oil. Box is unlined.
I recently renovated an Iceman Clear3 Chiller I had recieved from someone who had a knee replacement. The pump no longer worked but I kept this around for the hose quick disconnects and the nice bucket. When I removed the two screws holding the pump in the nice trim plate on the back fell off. So I whipped up these retainers in Fusion 360 and printed them out on my trusty old Makerbot Thing-O-Matic and about 10 minutes later I had it back together. Works like a charm, looks nice, and as a bonus I can see the water flowing into the tank. Just drop in a couple Blue Ice to keep things chill for the long jobs and replace them later.
Fusion 360 is an awesome CAD/CAM package from Autodesk. The licensing is reasonable, the support is good, the CAD/CAM is top notch and it runs on both macOS and Windows 10. Recently I acquired a Banggood A3 2.5W Laser Engraver and decided, since I had a good tool chain for cutting on my ShapeOKO I may as well carry that over to my Laser. I started with GRBL 1.1d (edge) release which was just just came out and built it using the PlatformIO IDE. I did this on my Mac and uploaded the resultant hex file using Xloader on my PC that’s connected to the laser. The compiled hex I used for my Atmega328 Nano that was installed on my laser is below. Please note if you were not running GRBL 0.9 on your laser prior you should remove the nano and set the jumper to 0.9 on the controller board. Note if you are using a Smoothie board you can just follow along with the tool path and gcode generation portion that follows and use the Smoothie post that is already included. The GRBL post that’s included does not support the new waterjet/laser features.
I lieu of the nearly constant inexpliciple crashes I have been encountering with Slic3r I decided to try and get Cura working with my now (Ancient) Makerbot Thing-O-Matic running Sailfish. It wasn’t really terribly hard to get into Cura after the legwork with Slic3r was done. I just needed to slightly correct the Gcode coming out of cure before it was fed into the GPX post-processor to generate X3G for the printer.
In addition to this profile I made a slight tweak to the previous post-processor script I had written for Slic3r. This removes the CURA_PROFILE_STRING from the end of the code since it causes a buffer overflow in gpx. In addition it maps over the bed temperature and tool temperature settings over to compatible settings for my Thing-O-Matic. Note: This is for running Cura/GPX on a Mac.
I have a Danby DKC14SLDB 5.2 cubic Foot Single Draught Kegerator I purchased several years ago. Several times a year I find myself with two pony kegs of homebrew I want on tap. Only having a single draught faucet was really cramping my style. I decided instead of purchasing a whole new tower with two faucets ($90) or an adapter ($70), which would have required the additional faucet anyhow, I would make it work on the cheap. I set out by purchasing the following items form Beveragefactory.com (note I have been home brewing for a long time and as such I have some old Coca-Cola pin-lock kegs that I normally use – please purchase whatever keg coupling is appropriate for your application): Read more
I recently started playing around with Autodesk’s Fusion 360 3D modeling and CAM software. I managed to fumble my way through making some quick designs and setting up a simple cam job to make a tool holder. Designing the part was quick and so was setting up the CAM operation. However when exporting the G-Code through the grbl post-processor I discovered the G-code was using G28 (return to home) which isn’t supported in a stock ShapeOKO 2. Limit switches would need to be installed for this to work and for it to be turned on in grbl. The default startup G-Code using the grbl post processor looks like this:
I was cutting on my ShapeOKO 2 last weekend and having major issues with missing steps on the Z. During fast retracts the Z would just hum resulting in passes where the tool wouldn’t clear the work resulting in more or less catastrophic failure. Either the work piece was damaged or the bit from trying to be forced through way more material it should be before I hit the e-stop. After some research I came to the conclusion that the stepping was the culprit. The steppers are configured correctly, wired correctly and moving as freely as possible but the controller would step at a rate that was causing issues on the Z.
After a little research I found that there was an update to GRBL version 0.9G that in addition to having a better acceleration planner the maximum feed rates could be configured per-axis. This is a pretty big deal because in 0.8C all the axis are limited by your slowest axis – which is the Z. Because of this cutting speeds are severely limited on the axis that one spends most of the time cutting on.