Shapeoko Software Adventures

I finally got a little time to work on the Shapeoko V1 to V2 conversion.  I made a video to document for my future self what settings I used for things with explanations of why I used those. I hadn’t previously made many notes so I had to basically start from scratch and I lost a lot of time redoing things. I tested some software and did a quick comparison.  Details of my experience and links to the software are below. I also had a bit of trouble from the top software choice, Chilipeppr that I hope someone could shine some light on.

Software:

1.  http://chilipeppr.com/grbl

UPDATE: John Lauer, maker of Chilipeppr , showed me the error of my ways and addressed most of my concerns with it.  He made an update feedrate modification update that I have yet to test.

Chilipeppr seems to be the best interface by far with full 3D display, code simulation, and lots of neat widgets and macros.  While testing my first milling job, however, I ran into some trouble.  I haven’t really watched all the tutorials on this so it is probably something I’m doing wrong, but when I used the feedrate multiplier on the Gcode widget, I typed a value in by hand and hit “enter.”   I entered 0.15 into the feed rate window, hit the enter key, and tested it out.  This did not work at all.  You can only modify the feed rate by clicking the up and down arrow buttons on the Gcode widget in Chillipeppr. You can verify the feed rate change by watching the lines in the Gcode change when you click the buttons. I noticed that if I watched these values while typing an input, they don’t change, unless I mouse over the Gcode line.

I ran a simulation to verify it would work.  The simulation was slow as expected since I was only going 15% of the full speed. Simulations do not take into account feedrates. When I went to run the real job, I broke a bit almost immediately.  The very first line it cut was at the feed rate I specified (15% of the default speed)  but immediately on hitting the next line command in the Gcode, the speed went back to 100% breaking my bit.

Something I loved about this app was the ease of modifying the positions, zeroing and such.  A couple of improvements might be to add options to only zero one axis at a time, and to add a custom offset to each axis if needed. This can be done manually by entering the appropriate G92 code with the wanted offset, but a button similar to the “Move By” would be nice.  You can zero a single axis by clicking the little triangle next to the axis name (ie X, Y or Z) and select “Zero Out Axis”.

I would also like the “Move By” to default to 0 when you change from one axis to another. I mistakenly drove a bit 10mm into my workpiece after adjusting my Y axis first. I had used 10mm for Y, but meant to change it to 0.1mm on Z.  That was totally my fault, but a “stupid-proof” option would be nice for that.

2. Gcode-Sender Chrome plugin

This neat little app is a chrome browser plugin. It is very basic. (this link is that video cued to exactly the point I’m testing this software). It autodetects and connected to my GRBL device instantly. I didn’t have to install any executable alongside this.  An issue is that there is no visualizer for the gcode so you can’t really see what it is going to cut or graphically how far along it is in the cutting job.

3. Universal Gcode sender

You can see in the first video of this post (this link is that video cued to exactly the point I’m testing this software)that I detail this app.  I couldn’t get to display correctly. I have java 1.8 and for some reason, none of the buttons or objects display correctly. I also couldn’t get the visualizer working at all. I tried version 1.04 and 1.07 with no joy. I was able to manually move the machine, but I couldn’t trust it with a cutting job since I couldn’t really see what the button said and couldn’t get the visualizer working.

4. Grbl Controller

Here is the video cued to this software.  This is the software I ended up using in for my first mill job after I couldn’t get the chillipeppr feed rates to scale with its default Gcode.  I created my own code quickly in easel.com and threw it into GRBL Controller to mill.  I liked the simplicity of the  interface.

I have a few gripes:

The serial terminal portion is really slow on my machine and I don’t know why. it takes 5 full seconds to connect to the serial port and print the GRBL stats.  When I send commands manually, there is a definite delay of a couple of seconds before the machine moves.

The visualizer is good, and I love that it prints the extents of the design.  I dislike that it is a 2D only viewer. While it is a good viewer overall, if it was 3D, that would make this tool much better.

The GRBL Settings under the “advanced” tab really messed up my settings.  Since I am running GRBL0.9g, when I loaded this window, it populated the window with my GRBL settings, but when I changed a value ($110 for instance) in this window, it actually wrote it to the OLD GRBL setting number for that setting.  This really confused me for a while. I’m not sure why this happened.  I fixed it in a serial terminal and decided not to use that option again.

 

Other CAD/CAM tools I surveyed

Easel.com is the CAD/CAM software package from Inventables designed for their machines.  It only works with GRBL 0.8c directly, but there’s a way to export the Gcode so you can use any gcode sender.

I ran a job I created in Easel. I had to make sure I selected the correct bit size and on Machine–>advanced I created, then exported the Gcode.  I brought the Gcode into “Grbl Controller” to send the job.  Since I milled with a 0.5mm bit, and I wanted to go 1.5mm deep, that takes 3 passes (rule of thumb is to only cut as deep on a single pass as the width of your bit).  This worked pretty well because Easel generated the multiple passes without telling me anything about it.  I had manually entered 30mm/minute as a feed rate into Easel.com, but it seems to have automatically calculated the feedrates based on either the Gcode it exported, or used the GRBL defaults for each axis because it cut much faster than that.  I would have really liked to have some kind of stats or a note about the number of passes or the approximate mill time based on traveled distances and feed rates.

MakerCAM.com is kind of a precursor to easel. It allows you to import SVGs and do things like pockets or outlines. It then generates toolpaths based on your entered tool values.  It is really easy to use and what is great is that you can download the whole things so you can use it with a device not connected to the internet. There are some great tutorials here.

GRBLweb is another browser-based gcode sender. I didn’t try it out, but the video on the webpage makes it look like a good tool.

JScut is a tool that GRBLweb and Chillipeppr use. JScut is a browser-based CAD/CAM package that helps you create toolpaths. It is similar to Makercam but being JS-based, other browser-based tools can interface and use it.

 

 

Miscellaneous notes about my setup and justifications:

I’m using GRBL 0.9g as I wanted to take advantage of the 4th axis in the future. this has a different pinout than version 0.8c.  0.8c Is what Easel.com uses when you click the “Carve” button on their interface (they use a server app to send the gcode to the machine from the browser, for some reason, I couldn’t get this to register correctly, even when I had 0.8c and the website kept telling me to download and install the server app. The settings I used for the 0.9g setup and justifications for these values are at the bottom of the post.

 

Grbl 0.9g [‘$’ for help]
$0=30 (step pulse, usec)
$1=50 (step idle delay, msec)
$2=28 (step port invert mask:00011100)
$3=2 (dir port invert mask:00000010)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=3 (status report mask:00000011)
$11=0.050 (junction deviation, mm)
$12=0.100 (arc tolerance, mm)
$13=0 (report inches, bool)
$14=1 (auto start, bool)
$20=0 (soft limits, bool)
$21=0 (hard limits, bool)
$22=0 (homing cycle, bool)
$23=0 (homing dir invert mask:00000000)
$24=100.000 (homing feed, mm/min)
$25=250.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=1.000 (homing pull-off, mm)
$100=5.470 (x, step/mm)
$101=5.470 (y, step/mm)
$102=320.000 (z, step/mm)
$110=300.000 (x max rate, mm/min)
$111=300.000 (y max rate, mm/min)
$112=50.000 (z max rate, mm/min)
$120=250.000 (x accel, mm/sec^2)
$121=250.000 (y accel, mm/sec^2)
$122=50.000 (z accel, mm/sec^2)
$130=290.000 (x max travel, mm)
$131=290.000 (y max travel, mm)
$132=100.000 (z max travel, mm)

Here are the justifications for these settings:

Note: GRBL 0.9g runs at 115200 baud.

I needed to change the X and Y steps/mm based on the following:
Motors have 1.8degrees (200 steps/revolution)
MXL belt has 2.03mm pitch
My belt pulleys have 18 teeth on them
I’m single-stepping my stepper motors
I used these values in the following calculator: http://prusaprinters.org/calculator/#stepspermmbelt
= 5.470 step/mm for both X and Y

To test this, enter the following code
G01 Y-10 F300
Which means “Move Y axis -10mm at a speed of 300mm/min”
I confirmed this motion with a micrometer
My Z axis seems fine using the values from the shapeoko website (I meanured about 1mm when I sent it the command to move 1mm.)

I’ve had to invert my direction on a couple axes:
https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9 ctrl+f “$2 – Step port invert mask:binary”