We had a few final bits of goofing off without a Z-axis before starting to build a real one. Two beams available for construction were found to be exactly the same length as the width of our table, so they were natural candidates as the main horizontal gantry structure. Now we could use arbitrary lengths for the vertical support beams bolted to either side, because they could drape past the edge and below the table surface. Not only does it give us complete flexibility on what height to mount our main horizontal beam, we also gain the option to reinforce the beam with brackets bolted to the bottom of the table.

Once the drilling and bolting started, however we found a few unexpected problems.

A small problem was that while our horizontal beam is exactly the width of the table, we also had a black plastic moulding surrounding the edge of the table. Actually dropping the beam below the table surface meant cutting interfering pieces of plastic away. Which we could do, but we don’t need to do so just yet so that’s been deferred.

A more significant problem was that one of the two holes of a bracket overlapped with the existing metal structure of this printer table. If it lined up exactly with the horizontal parts of the metal, we could drill a hole through it just as we did the wooden parts. Unfortunately it partially overlapped with some vertical members of the support structure, which would severely weaken the table if we drilled into it. We chose not to drill, but it also meant there were only two bolts instead of four fastening our gantry to the table.

This meant we ended with a less rigid gantry than we had originally hoped. It is pretty good left-right (parallel to machine X axis) but front-back (machine Y axis) is weak. We’ll have to add more reinforcements before we get serious about cutting material, but in the meantime it is the best Z-axis yet for pen plotting.

So Emily created a program that draws a gift for our enthusiastic supportive online cheerleader. This was the machine’s first run with nontrivial G-code, and its success cleared the way to further refinement of this machine.

After some debugging and re-awakening, I brought the laptop running UGS back to the workshop and this time it mostly worked. There were still a few unexplained system freeze-ups early in the work session but it was stable afterwards. Was there something weird with Java runtime settling down? I’m not sure, but I’ll have to keep an eye out to see if this recurs upon every system bootup.

Having a computer running UGS proved useful because we now have a 3D visualization of G-code tool path. It allowed us to see where a particular program declared its origin, so we could set work coordinate zero accordingly. It also allowed us to debug a few problems with the G-code we’ve randomly found online. The smiley face, for example, issued a G54 command early in the program but Grbl didn’t like that upon rerun and demanded a G0 before it.

Running G-code programs repeatedly to debug UGS settings meant we had ample opportunity to goof around with more drawings.

While fun, this “let’s act like a crappy Z-axis” game is not the point of the project. We know we need some sort of structure to fasten a Z-axis mechanism to. We hunted around the workshop for items collecting dust and found a set of 40mm x 40mm aluminum extrusion beams along with associated hardware. Formerly some sort of display for trade shows, it has been retired and available for use.

For the first draft we just want something better than holding the pen by hand, so we weren’t picky. Not really understanding what we wanted also meant we were reluctant to cut into these beams destructively until we know better. This meant using the lengths as-is and playing with various arrangements. C-clamps were very useful to temporarily hold pieces in place! Eventually we had enough of a plan and the clamps were replaced with bolts.

One thing that didn’t go quite according to plan during our first system test was how we sent our G-code file to the controller. I had planned to dedicate my Dell Inspiron 11 (3180) to the task of CNC control console, but it didn’t turn on at the workshop.

This was a problem, because I had hoped the G-code sender program I had installed on that laptop would help us understand what’s going on as we drive the machine. While CNC G-code is officially standardized, the standards still left a lot to the individual machine makers to define. Grbl (mostly) follows example set by LinuxCNC, so for the most part I can use LinuxCNC reference guide. I doubt I could memorize everything immediately, so a little software help might have been nice.

Grbl ESP32 is capable of operating completely independently using web interface. This is a basic interface which is extremely streamlined and missing some of the luxury features of other control interfaces. Furthermore, there is not enough onboard storage for CNC programs. To address the latter, there’s provision for attaching a SD card for storage via four pins on the ESP32. This is great for building small self-contained (maybe even portable!) machines.

But since our project is not very easily portable, I thought it’d be better to have a more full featured control console for this CNC. Grbl project wiki included a list of popular G-code senders, after reading that list I decided to try UGS and installed it on the little Dell. Since it was written for Grbl, it understands the Grbl-specific subset of G-code and also has a visualization module so we know what to expect when we run a program. All of these would have been useful in an initial system run.

At the workshop I pulled the Dell out of my backpack, pushed the power button, and nothing happened. After a few failed efforts to wake the machine, I resorted to using simple_stream.py from the Grbl site, a flat Python script with absolutely no user friendly features whatsoever.

I brought the little Dell home in order to debug the problem. Once I got home, I determined the machine is running but stuck. I held the power button for longer than 4 seconds, which per ACPI spec will power down the machine regardless of state. I thought I had tried that at the workshop but I guess I didn’t quite hold it long enough? In any case the computer is ready for another attempt.

[Update: UGS didn’t pan out, more details here.]

While we’ve proven our nascent CNC could home and respond to individual hand-typed G-Code commands, we have yet to run more than a single line at a time. We’ve just bolted it down to a table but before we put too much effort into more hardware, it seemed like a good idea to make sure the software side is capable of a multi-line program.

Emily found a short snippet of G-Code that purports to draw a smiley face with a pen plotter. It is a great introduction to G-Code, showing us a basic way to start and stop the machine. Curiously, there is no Z-axis motion at all. It uses spindle motor commands to communicate “drawing” (M3 = spindle on) and “not drawing” (M5 = spindle off.)

T1 M6
G90 G94
G54 X0 Y0
G00 X0 Y0
G00 X-25 Y20
G91 X-10
G02 X10 Y-10 I10 J0 F200 M3
G02 X-10 Y10 I0 J10;
G90 G00 M5 X0 Y0;
G00 X25 Y20
G91 X-10
G02 X10 Y-10 I10 J0 F200M3
G02 X-10 Y10 I0 J10;
G90 G00 M5 X0 Y0;
G00 X40 Y0
G02 X-40 Y0 I-40 J0 F200 M3
G90 G00 M5 X-55 Y0;
G02 X0 Y-55 I55 J0 F200 M3
G02 X-55 Y0 I0 J55
M30;

Reading through this, I could see the XY coordinates are all around (0,0) so the center of this smiley face should be at the origin. Other than that, I have no idea. And since we haven’t built our Z-axis yet, Emily volunteered to be a human Z-axis. We sent this snippet of G-Code (some hiccups along the way) and our reward at the end of this work session was an artistic collaboration between human and machine.

Once we can successfully perform XY axis homing in Grbl ESP32 and see that it responds to some simple G-Code commands, it was time to get a little more rigorous about our hardware configuration. Up until this point this machine was mere placed on a dusty table, itself a salvaged piece of equipment.

Based on the appearance of a slot in the middle and a metal shelf underneath, it appears to have been designed for old dot matrix (or maybe even daisy-wheel) printers that use continuous fanfold paper fed through that slot. Given that such printers have a carriage that moves left-right (now our X axis) it was unexpectedly wobbly along that axis. Our X-axis movement now sets the table oscillating.

We may need to reinforce that sometime down the line, but the first task is to bolt our XY stage to the table. Since it is quite powerful and heavy, there’s a lot of momentum involved in its motion and we could not depend on friction to hold it in place: it slides around on the surface. Six holes were drilled in the table for 1/4″-20 threaded rods, each held in place by a nylon insert locking nut above and below. Now XY stage will no longer slide around on the table.

The chosen location is aligned with the front edge of the table, slightly right of center, due to the Y-axis lead screw to the left of the table. This placement left equal amount of space to the left and right for us to plan out how we want to build a Z-axis gantry. The first candidate approach is to use some aluminum extrusion beams that are sitting around gathering dust in the shop. But in the spirit of “build a little, test a little” we want to run a short G-Code file for fun.