A Shelf For CNC Console Computer

The first thing I wanted to address after a wobbly (but successful!) first run was placement of the control console computer. I didn’t have a good place to set the tiny laptop down. The machine may not look like it would take up the entire table, but once machine’s range of motion is accounted for, there’s not a whole lot of space left. During the test run, the laptop was literally on the ground next to the table. It would be useful to have a dedicated computer shelf.

The shelf was designed in two parts. The right side could be bolted to the end of an extrusion beam, but the left side didn’t have that luxury. I thought I would design it to clip on to the extrusion beam, but the first draft hooks were far too aggressive. I had to trim them back with a saw before I could fit the piece around the beam.

HAKCNC computer shelf overly agressive claws

Both hooks installed and ready to host the computer. The right hand hook was printed with the final filament from one spool and start of another spool of PLA. Even though I ordered from the same vendor (Monoprice) they have apparently changed vendors or specification and the new spool filament is visibly different.

HAKCNC computer shelf in place

At first glance this design may appear to be heavily cantilevered, with most of the weight on the front of the hook placing great stress on the mounting points. This is only true when the laptop lid is closed. When the lid is open, where this shelf mounts on the beams is actually very close to the center of gravity of the laptop.

It still needs to be able to accept some weight, though, since there’ll be physical forces as I type on the keyboard and use the trackpad. But PLA is plenty strong for this application, with very little flex even when I rest my wrists on the computer.

This shelf is probably not permanent, but it is nice to have a convenient shelf to hold the laptop while I figure out how to work the rest of this machine.

Drilling Wheels For JPL Open Source Rover

Jet Propulsion Laboratory’s Open Source Rover uses six wheels adapted from Traxxas remote control trucks. Traxxas suspension has a hex shaped mounting point for these wheels, but the ServoCity motor hubs used by OSR does not fit. To bolt these wheels onto those hubs, rover builders need to drill two holes aligned with two diagonally opposite holes on the ServoCity hub. Precisely locating these holes may prove challenging, and some rover builders have offered their solution to the problem. This post outlines my approach.

The heart of my approach is a 3D printed jig that is clamped in a drill press vise. It is tall enough to accomodate one of these wheels, with a cylindrical tip that locates the center hole for the wheel. There are two holes on either side of this tip, corresponding to the locations where we want to drill. For setup, the vise and jig are positioned such that one of the holes are aligned with the location of our drill bit.

OSR wheel drill jig with wheel 1

Once aligned, a wheel is mounted on the jig and we drill our first hole. Once that is done we turn the wheel 180 degrees. We can visually align the newly drilled hole to the printed hole in the jig, or we can use another drill bit as a locating pin. Drop this drill bit through the just-drilled hole into the 3D printed hole in order to locate the wheel.

OSR wheel drill jig with wheel 2

This setup has room for improvement in terms of precision. The holes aren’t precisely the correct size so the location pin/drill bit has room to move. But it is sufficiently precise for the task at hand so I didn’t put in the time to revise the jig for additional precision.

The 3D printed jig is shared on Thingiverse, and a video demonstration has been posted to YouTube:

 

 

A Wobbly First Draft Of Z Axis Gantry

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.

Making Our Way To A Z-Axis Gantry

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.

 

Computer Running UGS As CNC Control Console

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.]

Freehand + CNC Pen Plotter

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.

Some Nuts And Bolts For XY Stage

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.

XY Stage Successfully Homing Both Axis Using New Board

Deciding on the machine axis was a useful piece of information for configuring Grbl ESP32 settings, but it was also an important decision for which wire connects to which pins. All of these could potentially be changed later if we change our mind, but hopefully spending a few minutes thinking now would save us that effort later.

The wires for both axis were put into JST-XH connectors for connection with perforated PCB. We could use other form of wire terminals but these polarized plugs seems like a good way to keep things orderly.

The Parker ZETA4 motor drivers offer a wide range options in microstepping. While it is tempting to go up to insane number of microsteps just because we can, for the immediate future we’ll go with “merely” 10 microsteps for a total of 2000 pulses per revolution. This lead screw is cut for 5 turns per inch, which made things a little tricky as Grbl uses metric values. Using 25.4mm to represent an inch, a setting of 2000 pulses per revolution works out to 393.7 steps per mm. It is not perfect but should be close enough for our purposes. If this causes a problem down the line, these ZETA4 drives do have a metric-friendly option of 25,400 steps per revolution. This will divide evenly but we may be trading off torque or run into problems with generating pulses fast enough.

For now, using 393.7 steps/mm is enough for reasonable precision in movement, and this machine homes on both X and Y axis according to newly decided axis alignment. Our dreams of a mini CNC is a little bit closer, and we can start thinking about how we want to approach building the Z axis. Part of that process will be deciding how everything will be bolted down to a table.

Deciding Machine Axis For XY Table Project

With a new control board built, there remained a few firmware configuration settings to pin down. Several of these parameters will dictate movement direction of the machine. We should decide on the direction our two machine axis will point, in a way that would make the most sense for the machine operator.

When exploring and working with a machine to bring it up and running, the most obviously convenient place to work is a place where it is easy to access various components of the machine. For me, this meant I had been spending most of my time staring at the side of XY stage where I could most easily access the motors and lead screws.

But aligning operational axis with this perspective would be a mistake. Assuming we get this machine up and running, the priorities will change. We would want machine components to be out of the way when actually using the machine. This translates to a desire to have the front of the machine be the least cluttered side of the machine, away from components. The cleanest side of this XY table mechanism is the far side from where its motors are.

If we designate that side as “front”, the motors would be out of the way of normal operation and so will one of the lead screws. The other lead screw will still reach close to the front, but at least it would be the simpler side away from where the motor (and associated cables) would have to be routed.

Based on this designated front side, it was then easy to decide on the location of machine zero, and the direction of X and Y axis, Once Grbl ESP32 was configured accordingly, we could test if the machine responds as expected.

 

Perforated Board Iteration of Grbl ESP32 Control

Grbl ESP32 packed a lot of functionality in software, so it was relatively simple to put it to work controlling the salvaged industrial XY table. An ESP32 development board already included voltage and USB serial converter on board, all I really had to provide for the project are a few simple components to stand between the delicate 3.3V pins of a ESP32 and the physical world. If the goal was maximum simplicity, I would have used an ATmega based Arduino board  with its robust 5V IO pins that could have been used directly. But I was enticed by the feature set of Grbl ESP32 and willing to put in a little more effort.

These components were first proven out on a temporary breadboard, and a successful single axis home gave me the confidence to move that circuit to a perforated circuit board with soldered instead of jumper wires, and also duplicate the circuit so we could control both X and Y axis.

Grbl ESP32 board abandoned layout

I first laid out the ESP32 development module in the center, with roughly equal space for circuitry all around. As I started planning on component layout, though, I quickly realized this was silly. Even spacing was not a feature, it was actually very constrictive. Thankfully I had not yet soldered everything down so I could rotate the layout 90 degrees giving more space to the left and right of my ESP32 dev board for components. It didn’t matter this reduced the free space top and bottom – they weren’t convenient to use in this layout anyway.

For the step and direction lines on both axis, there’s a simple 2N2222 transistor allowing delicate ESP32 output pins (via a 1 kΩ resistor) to control the ground line of a much larger 5V circuit going into the Parker ZETA4 stepper motor driver. In parallel with the output ground pin going to the ZETA4, there’s also a LED (with a 470 Ω current limiting resistor) to indicate activity on that line. Following the footstep of my Pixelblaze axis test, I used two red LEDs for X and two green ones for Y.

I had originally intended to install an optoisolator for each of the two homing switch input pins, but I ran short on time for the work session. I was too squeamish to connect the pins directly so I put in another 1 kΩ resistor between the ESP32 pin and the input that would be shorted to ground. It’s not a very robust level of protection, but it is better than nothing. A future iteration will have to revisit the topic of ESP32 protection measures, potentially after one is damaged from insufficient protection…

But that’s a problem for later. For the purposes of this work session, we have to decide how we want our machine axis to be configured.

Successful Single Axis Homing On XY Stage

Once the intermittent wiring problem had been tracked down and fixed, we could resume where we left off on the previous work session with this salvaged Parker XY stage: trying to command an axis to find its homing position. The previous attempt failed because the stage sailed right past the homing switch due to the homing switch.

We did get the homing operation to work, but we had to adjust a few settings from Grbl defaults before everything started moving as planned. Those defaults made sense for a relatively lightweight motion control table using physical micro switches for home and limit switches. This salvaged industrial stage is quite sturdy with significant momentum once it starts moving, and it uses magnetic reed switches for its home and limit switches.

  • To compensate for greater momentum, homing seek speed (Grbl parameter $25) was halved from 2000 mm/min to 1000 mm/min.
  • Reed switches have greater hysteresis than micro switches, so the homing pull-off distance (Grbl parameter $27) was increased from 1 mm to 6 mm.

We haven’t yet decided which direction will actually be positive or negative nor which motor will move which axis. This will affect direction port invert mask (Grbl parameter $3) once the decision is made. For now, it only matters that we wire up the correct reed switch to function as a homing switch.

Seeing the large Parker Motion Control linear actuator move and find home position was quite satisfying, and with this much confidence in functionality, I can transfer the control circuit from a temporary breadboard with jumpers to a perforated prototype board with more reliable soldered wires.

XY Stage Switch Test Board Helped Find Loose Wire Inside Connector

Following plan for the switch test board, I crimped 3-pin JST-XH connectors on loose wires at the end of XY stage’s limit and home switches. The colors matched the wiring diagram I found in documentation, which also matched what we determined via probing with a meter. But there was a problem hiding somewhere in this system, and that’s what the test board is here to determine.

The first discovery is that one of the limit switches is no longer closing before the carriage runs into a hard mechanical stop. In my eagerness to move the switches as far out to their limits as I could, I’ve managed to move one of the limit switches too far out of detection range. This will have to be fixed eventually but it isn’t the top problem right now.

Moving the axis back and forth and watching LEDs on the test board, we eventually figured out the problem: there is a loose connection somewhere in the system. There are six LEDs on the test board, a pair of complementary LEDs for each of three switches. In normal operation we expect one of the two LEDs to illuminate. But for the homing switch, it occasionally goes dark and neither LEDs are illuminated.

XY stage switch connector interior

Hunting for loose connections, we eliminated the more likely suspects first (such as my JST-XH crimps) and worked our way down the list. We did not expect the strong industrial standard AMP circular connectors to be the problem, but that’s where it was: pin for the black wire, which is the common wire of the homing switch, had backed out from its proper location and unable to make a strong and reliable connection. We pushed it back into position and it seemed to stay in position. At least, for now.

With this intermittent connection, homing the machine would have been an unreliable process. It is conceivable this was the very problem that caused the original machine to be retired, but that is just speculation. With the homing switch repaired, it’s time to get back to work.

Create A Board To Test XY Stage Switches

It was fun to tear apart an old optical drive for its stepper driven carriage, but the main objective was to figure out why my Grbl configuration didn’t work. When it worked on the first try with my home stepper test configuration, suspicion went to switches on the salvaged XY stage. Something about it did not behave as originally expected and I intend to find out why.

The first thing to do was to hunt for a manual. I found the manual for the ZETA4 controller on Parker Motion’s web site, and this time I returned in an attempt to find the manual for the switches. This type of mechanism no longer appears to be Parker’s main line of business, but hunting around their product pages I eventually found the Open Frame Series 300AT that is either the same XY stage still in production, or more likely a product that is its successor. But even if it’s not the exact same thing, the specifications table is instructive: this table is quite capable for every project we had in mind as a potential project candidate.

Backing off from daydreaming of possibilities, I found what I was looking for on that page in the link to a PDF titled Linear-Rotary Product Manual. This appears to be a scan of a paper document and not a digital original, but the important wiring diagram is perfectly legible.

Daedal switch wiring

This information matches what we’ve found by probing with a meter, giving us greater confidence our expected behavior is indeed the intended behavior. Using this information I planned to wire up each of these switches to their own 3-pin JST-XH connector in the following order:

  1. Normally Closed
  2. Common
  3. Normally Open

Each of these three connectors were then connected to a pair of LEDs that shared a connection to pin 2. One LED would illuminate when the “Normally Closed” circuit is closed, and the other would illuminate when “Normally Open” circuit is closed. If neither illuminate, there’s a problem somewhere. If both illuminate, we have a more serious problem somewhere! If all goes well, as long as this board receives power three out of six LEDs would illuminate. As each switch closes, the LED that is illuminated would switch within its pair of LEDs.

This test board is simple and, as it turned out, effective in successfully finding the problem.

Successful Axis Homing Test In Grbl

When I played with the salvaged XY stage, I had only about 10 minutes at the end of that work session to play with homing. I connected the homing switch so it can bring the pin low when the switch closes, and the stage moved right past the homing switch and into the hard end stop.

Before my next work session, I wanted to learn how to properly set up a homing switch for an axis in Grbl. So I started playing with salvaged optical carriages and, when I found it had very little mechanical power, I salvaged some tiny switches requiring only a very light touch to trigger.

Since this was only serving as a test chassis for Grbl configuration, I didn’t put too much work into making this an elegant and durable setup. The new limit switch was placed roughly in the right position with tape. All I needed was for the carriage to touch and close the switch when it nears one end of the travel. There was a secondary benefit to this very temporary setup: if the carriage runs past the switch as I expected, the switch is able to fall out of the way without damage.

I commanded this carriage to home and, much to my surprise, it functioned exactly as expected. I had thought this would replicate the problem I saw with the full sized salvaged XY stage running past the homing position. The fact that it did not implied the problem was not in Grbl configuration, but in the limit switch on board the XY stage.

The switch looked fine when I tested continuity with a meter, but it was an awkward setup and I could only look at one switch at a time. To help isolate the problem, I shall create a simple test circuit to watch all three switches (min and max limit, plus home) on a single axis.

Salvage Surface Mount Switches For Homing Test

After I managed to destroy a stepper motor during experimentation, Emily graciously donated another one to the cause. Hooking it up to my A4988 test board, I can tell this optical drive carriage had more power than the one I salvaged from a laptop drive. At least this one could win a fight against gravity. However, I was dismayed to find it is still quite weak in absolute terms, and this time I’m wary of cranking up the power in fear of destroying another motor.

So in order to set up something to learn how to wire up a homing switch for Grbl, I need to find switches that take less force to activate than the switches I already have on hand. Where might I find tiny switches that take tiny force to activate? The recently disassembled laptop optical drive!

SMD switches

Its control board had a few tiny surface mount switches. They were connected to small mechanical linkages throughout the drive so this control board can determine various states of the eject mechanism and such. There were a total of four switches and I put them under a heat gun in an effort to remove them.

This was a tricky procedure, as I had to melt the solder without melting the plastic. I put too much heat into two of the switches and destroyed them in the process. Fortunately, two of them were removed relatively undamaged. I put one of them under a meter to check for continuity, and it appeared to still work as a switch.

And soon, if all goes well, it will be a homing switch.

Optical Drive Carriage, The Sequel

During my learning and exploration of stepper motor control, I managed to destroy an optical carriage I salvaged from a laptop drive. In order to continue experimentation I need another stepper motor linear actuator of some kind. I rummaged in my pile of parts and came up empty-handed, but I am fortunate to have another local resource: Emily‘s pile of parts. My request was granted with an assembly that had an intact motor, drive screw, and linear carriage. The optical assembly in that carriage had been torn apart, but that is irrelevant for the purposes of this project.

Unlike the previous two stepper motors I played with, this one has exposed pads on the flexible control cable so I tried to solder to them. Given my experience soldering fine pitched parts, I knew it’s problematic to solder one at a time: they are so close together heat from one pad will melt solder on an adjacent pad. My best bet is to set things up so all the wires are soldered at the same time.

Emily salvaged stepper motor wiringThere is slightly less solder than I would have preferred on each of these joints, but several efforts to add solder created solder bridges across pins. Requiring removal by solder sucker, which reduced the amount of solder even more. Since there was enough for electrical conductivity, I left it as is to continue my experiments.


Unrelated to stepper motors or Grbl:

While I was taking the above picture to document my work, I noticed I was being watched and took a picture of the watcher. This little beauty was surveying my workbench perched on top of a cardboard box of M3 fasteners from McMaster-Carr. The spider was only about 5mm long overall including legs. Unfortunately at the time of this shot I had set it for shallow depth of field to photograph the above solder joint. I adjusted my camera to bring more into focus, but this little one was camera shy and jumped away before I could take a better shot. Still, I’m quite pleased with my camera’s macro lens.

Spider on McMaster Carr box

Resuming Pololu Stepper Driver Adventures with Arduino and A4988

By the time I got around to playing with homing switches on a salvaged industrial XY stage, it was getting late. I only had a few minutes to perform one experiment: connect the normally open homing switch to X_LIMIT_PIN (GPIO02 as per cpu_map.h), set HOMING_CYCLE_0 to X_AXIS in config.h, and sent command to home X-axis. The motor moved right past the switch into the hard stops, so I turned off the ESP32 marking an unsatisfying end to the work session.

I wanted to be able continue learning Grbl while at home, away from the salvaged hardware, so I dug up the A4988 motor control board I’ve played with briefly. It’s time to get a little further in depth with this thing. Motivated by my current state in the XY stage project, the first goal is to get a stepper motor to activate a homing switch. If I could get that far, I’ll think about other projects. People have done some pretty creative things with little stepper motors controlled by Grbl, I could join that fun.

Rummaging through my pile of parts, the first stepper motor I retrieved was one pulled from an optical drive. This particular stepper motor had only the drive screw, the carriage has been lost. But with four exposed pins in two groups of two, it is a bipolar motor suitable for an A4988 motor control board. I just had to solder some wires to make it usable with a breadboard.

Since this stepper motor was a lot smaller than the one used in my previous A4988 stepper motor experience, I thought this was a good opportunity to learn how to tune the current limits on these modules by following instructions published by Pololu and using an Arduino as a test controller running code published on this page. I started with a limit of 100mA, but the motor got quite toasty at that level after running for a minute. I turned it down to 50mA, and it no longer got hot to the touch running that Arduino sketch.

This is a good start, but a motor with just a drive shaft is not useful for motion control. The next step is to find something that could push on a limit switch. I don’t seem to have anything handy, so it’s time to start digging into salvaged hardware.

XY Stage Position Detection Switches

When I built my prototype Grbl ESP32 controller on a breadboard, I thought I would get X and Y axis to start moving before looking at other parts of the system. Once I got X moving, though, I changed my mind. Instead of getting Y to run, I wanted to make sure I understand more of X. Which meant learning about limit switches and homing routine in Grbl.

But first, a look at the actual hardware, which meant picking up the other wiring harness leading inside the linear actuator. There were nine wires, only six of which were connected from its previous usage. Three of the six were connected together resulting in a total of four unique pins.

On the assumption the three wires twisted together is a common ground, I probed between it and the remaining wires. I found two of them were closed circuit and the remaining one was open. This is consistent with a homing switch and two limit switches. The homing switch is normally open and, during homing operation, the controller looks for that switch to close. When that happens, the controller knows where home is. The limit switches are normally closed because that allows them all to be wired together in series. If any limit is reached, the circuit opens, and the controller stops. For the purposes of machine protection, it didn’t really matter which limit was reached, as long as it was detected.

With the ZETA4 unplugged, the stage could be moved by hand. Watching the output from a meter wired up to these pins, I looked for positions where these switches were tripped. The initial results were very disappointing! The limit switches would trip when there were still over ~10cm of travel remaining, and the home switch is ~5cm further inside of that range. This severely constrains the usable area to a very small subset of total area. When I reported this finding to the rest of SGVHAK, I was told “Oh. Why don’t you move them, then?”

Move them?

I didn’t know these switches are adjustable to fit specific installations. In its previous life, this tables only needed to deliver a small range of its overall motion and were set appropriately. An allen wrench was all I needed to remove the cover and look inside: I saw three devices labeled Hamlin 59135, still in production and available from Digi-Key for $7.48 in single quantities. Each of these is a reed switch with a normally-open and normally-closed wire in addition to their common wire.

This explains the nine wires in the bundle: three wires for each of the switches, and the previous installation only used the common wire plus one of the other wires, leaving the remaining unconnected.

I loosened the screws holding these reed switches in place, and move them as far to the ends as I could push them with existing wiring. This still leaves approx ~3cm on either end, but I’m content to leave them as safety margin. The physical size of the home reed switch meant it couldn’t get within ~4cm of the limit switch. I don’t know if this is a problem yet. Next step: figure out how to interface these switches into Grbl.

Successful First Commands From Grbl ESP32 To Parker ZETA4

Once I could bring my breadboard prototype Grbl ESP32 controller into the shop where the salvaged XY stage lives, I was eager to hook up some wires to see if anything moves. While I put provisions for two axis on my breadboard, it felt like a good idea to start with just the X axis. It moved, but not accurately, because I had not configured the two components to match.

These stepper motors have 200 steps per revolution. ZETA4 controllers can easily handle full steps, but there are a lot of options for microsteps configurable with switches. The headache here is the lead screw: it is an old Imperial unit with a pitch of 5 revolutions per inch, but Grbl is a metric minded piece of software with everything in terms of millimeters. Using a conversion rate of 25.4 millimeters per inch, the most obvious ZETA4 microstep option that divided evenly is 25,400 steps per revolution.

The good news is that Grbl ESP32 appears fast enough to generate pulses at this speed, which is orders of magnitude beyond what I can generate with AccelStepper on an ATmega. But even with tests along a single axis, the system would halt at various times and I don’t always understand why. For example: one of the halts gave an error of “Door Open” but Grbl configuration file explicitly said to ignore the door sensor switch, so why is it stopping motion? There are more to this system I don’t yet understand.

So for the sake of eliminating potential problems, both the ZETA4 and ESP32 were configured for 2000 steps per revolution, or 10 micro steps in between whole steps. We know this is easily within the timing capabilities of the chip and, while it may introduce some error converting between Imperial and metric, it’s not the biggest problem right now so we’ll deal with it later.

These intermittent errors will likely continue as I run this system, and I will have to diagnose and debug as I go. In parallel with this, I’ve changed my plan: as my next step I will not connect the Y axis step/direction motion control pins. Instead, I will continue to refine X axis operation by getting position homing to work.

ESP32 Grbl Controller Breadboard Prototype

An ESP32 plus Grbl motion control software seems like a good candidate for running an old industrial XY table, definitely promising enough to move forward with prototyping. I had originally intended to use an Olimex ESP32 DevKitC (*) as it was equipped with two rows of sockets. This is easy to connect with jumper wires while not leave pins exposed to risk of short circuits.

This plan was short lived, because I quickly ran into a problem: The ATmega at the heart of an Arduino is a beefy 5V part that can supply up to 40 mA per pin. In contrast, the ESP32 is rather delicate 3.3V part that should not exceed 12 mA per pin. The data sheet for the ZETA4 controller I want to connect to this board expects a minimum of 3.5V to signal step and direction, which means I need external components to shift the ESP32 voltage level up to what the ZETA4 expects. When I made this discovery I was momentarily tempted to switch back to an ATmega solution, but the siren call of higher performance carried me forward.

Since I would need external components, the project brain switched to my HiLetgo ESP32 development board (*) which is mostly identical but came equipped with two rows of pins appropriate for a breadboard. Four level-shifting units were installed, each built around a 2N2222A transistor. They were connected to the step and direction pins for X and Y axis, and each received a LED (and corresponding current-limiting resistor) to indicate activity.

Staying consistent with the system I used for Glow Flow, red LEDs indicate X axis activity and green LEDs indicate Y. These LEDs allowed me to perform a quick test to verify the presence of blinking activity. Next step: connected them to ZETA4 controller to see if the motors move as commanded.


(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.