After wiring up for Z-axis servo control, I turned my attention to the remaining empty quadrant of the prototype board.
At the moment I have a small laptop running a G-code sender acting as the CNC control console, from which I can access all functionality of Grbl. The ESP32 port of Grbl also offers a built-in web interface, which is a great choice for compact machines that don’t want the overhead of a full computer. Both of these control options have a communication delay, so some things are better handled by hardware switches for immediate feedback.
By default Grbl ESP32 supports four physical switches, in the order of their pin assignment they are:
- Feed Hold: On many CNC, this completes execution of the current G-code command but holds off running the next one. Some machines can pause mid-command but this is not guaranteed. Axis motion stops, but spindle does not. This is a good way to have a machine pause, useful for example when the operator wants to visually check to make sure position and upcoming commands look reasonable.
- Cycle Start: Begins executing the loaded G-code program. Also used to resume execution after Feed Hold.
- Reset: This commands an immediate stop, of everything. Unlike Feed Hold, it will not wait for the current command to complete. It will also turn off spindle in addition to axis motion. Since it is an immediate cutoff of execution, the controller ends up in an unpredictable state. There’s no resuming after a reset. The machine has to be re-homed and all coordinate offsets recalculated.
- Door: Designed to be wired up to a door open detection switch so the machine can take actions to ensure operator safety. On some machines this is effectively a Feed Hold, others treat it as an emergency Reset, most machines treat it as somewhere in between. I don’t know yet how Grbl reacts.
All four are designed for normally-open switches that activate upon closing the circuit to ground. For reasons I don’t understand, these switches don’t use the ESP32 internal pull-ups and require external pull-up resistors. Normally-open switches don’t necessarily make sense for a situation. For example, reset is usually wired up with a series of normally closed switches and, if any of them should open, the machine halts. But this is easy to address in the physical circuit.
Another concern for these switches is that they tend to have long runs of wire. (Such as the aforementioned reset switch.) Long wires have a nasty tendency to act as an antenna picking up stray signals. So a real board would require opto-isolation to avoid triggering from line noise. But again, this is a prototype board missing the full set of protective features.
After I wired up jumpers for playing with these four switches, I made a small piece of label to remind me which pin is which. Then it’s time to bring the results of this prototype soldering session to the shop and run a few tests.
I plan to take advantage of a feature in Grbl ESP32, where a RC hobby servo can take the place of a stepper motor for any supported axis. It won’t be nearly as precise, or have the same range of motion, but it’s a good option for specific situations including tests.
The first part of this task was, obviously, to find it in the code repository and know how to compile with this option active. The second is to wire up my ESP32 dev board to emit the 1-2 ms RC control signal at its 3.3V output and convert that to a 5V signal courtesy of the USB port. Then it’s time to connect a servo.
But not directly, because USB doesn’t supply very much current and would not be a good source for servo motor power. Tasks with high stress or moving quickly will draw more than what USB can supply and cause voltage level to sag. Possibly causing the ESP32 to brown out and restart which would ruin everything.
What I needed for a servo test was a separate power supply. I started digging through my collection of salvaged AC to DC power transformer bricks looking for one in an appropriate voltage range before I decided I was overthinking things. This isn’t going to be the long term solution, it’s just for a short test. I don’t need a long term power source.
RC hobby servos are originally designed to run off 4.8-6V of a four-cell pack of batteries, tracing its lineage back to the age of NiCad radio receiver packs. This is roughly the same voltage as a commodity AA battery cell, so I pulled from my stock of 4xAA battery holders (*) for this test. They even have an integrated on/off switch for convenience.
The ground wire was connected to the servo ground wire as well as ESP32 ground. Servo power wire is supplied by this 4xAA tray, and servo control signal from the 3-pin servo header of the prototype controller board. And finally, the servo gets a 3D printed bracket to clip on to the gantry structure’s 40mm extrusion beams.
The Z-axis test arrangement is now complete. But before I wrap up this session of perf board soldering, I wired up provisions for hardware control switches.
(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.
Strictly speaking, it was not critical to add a shelf for the little laptop used to control everything, but it is very nice to resolve the constant irritation of pausing what I wanted to do just to find a place to set it down. It should speed up future tinkiering of this machine, and the next step in that process is to wire up Z-axis capability.
In hindsight I should have packed the X (lower left) and Y axis (lower right) components a little closer together, but learning these lessons this is why we build prototypes. There isn’t quite enough room to duplicate the same pin layout for Z in the upper right, but then again, I don’t really need to. I’m not interfacing with an existing Parker Motion Control product, the Z-axis will be different.
As a result, the JST-XH connectors have been simplified from a 4+3 arrangement to a single 6-pin arrangement. 4 of the pins are the same: a pair of open-drain signals for step and direction. The remaining two pins are for a normally-open switch to home the Z axis stepper control.
But there’s another twist to the Z-axis: a feature of Grbl ESP32 is the ability to use a RC hobby servo for any axis. It requires changing a few
#define in the source code and recompiling, something I could do on the little laptop who now has a shelf. I thought a servo-actuated Z-axis would work well as a first test of system functionality, before I go through the effort of building a more functional stepper-controlled Z axis.
But I couldn’t use the same pin for both, because an open-drain circuit is the wrong way to send a control signal to a servo. Instead, a separate transistor was rigged up so the ESP32 control signal (3.3V) can emit a 5V servo signal. The signal pin and ground are exposed via a separate 3-pin header.
The 5V source for the control signal came from the USB port connected to the little laptop. Ideally there’ll be some opto-isolation for the control signal, but this will suffice for a prototype. However, it will not be enough to power the servo motor, which will require its own power source.
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.
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.
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.
A 3D printer is not a fast worker, but as slow as they are, they are still faster than waiting for shipping. This means owning a 3D printer can sometimes be a convenience feature, unblocking project progress while real objects are in transit or perhaps substituting them entirely.
While following the current iteration of JPL Open Source Rover instructions, I was tripped up by an error in the parts list reference. As a practical matter, it meant I didn’t have the aluminum spacers on hand to mount RoboClaw motor controllers to the rover mainboard. Once I understood what was going on and filed the issue on Github, I ordered correct parts from McMaster-Carr and they will arrive in a few days.
But what do I do in the meantime? If I’m not able or willing to wait for the correct spacers, I can design and print my own. It is a very simple shape and a small part that will be quick to print. I didn’t model the threads but it would have been too fine to print anyway – the screws will just self-tap into 3D-printed plastic.
Here are 3 printed and 1 metal spacers on a test run on the rover mainboard, before I installed a RoboClaw to verify all parts worked as planned.
While these plastic parts are weaker than the proper aluminum bits, in this particular application I don’t expect the material strength differences to matter. What is far more useful is the fact they are here right now and I did not have to wait for an UPS truck.
One of my early 3D printing projects was motivated by the wasteful battery usage of a cheap Harbor Freight digital caliper. I didn’t want to replace its LR44 battery all the time, and I didn’t want to directly modify the caliper in any way, so I ended with an overly complex tray to hold a AAA battery in place of the default LR44 battery.
The main goal was to avoid the wastefulness of burning through LR44 batteries, and that goal was a success. I was able to use cheaper AAA batteries and use them for longer. In fact, this caliper was able to run on AAA batteries that were too weak for much else, giving them a very useful secondary life. However, my battery tray suffered poor reliability of electrical contact points. In actual usage it was too easy to move a component just enough to break electrical connection, resetting the caliper and losing whatever measurement I had at the time. After a few frustrating episodes, I broke off the plastic head substituting the LR44 battery and soldered wires directly.
After years of use, the battery tray I designed and 3D printed finally cracked. And this time around I decided to go for simplicity instead: a commodity AA battery tray held to the back side of my caliper with double-sided foam tape.
Wires from this battery tray were soldered directly to the battery tabs inside my caliper for reliable operation. I could no longer lay this caliper down flat on a table, but I don’t think that will be a significant concern. I’ll know for sure after some usage and if it proves to be a problem I will re-evaluate.
In the meantime, I have a replacement battery tray allowing me to run my caliper on weak AA batteries already destined to be thrown away. And since this tray is a mass produced commodity item, using it was cheaper and it was faster to install than my previous solution.
Moral of the story: sometimes 3D printing is not the answer.
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.
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.
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:
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.)
G54 X0 Y0
G00 X0 Y0
G00 X-25 Y20
G02 X10 Y-10 I10 J0 F200 M3
G02 X-10 Y10 I0 J10;
G90 G00 M5 X0 Y0;
G00 X25 Y20
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
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.
It didn’t take long before my new old drill press was put to work doing something that was difficult without the tool: I needed to drill a total of eight holes through three half inch diameter aluminum tubes, perpendicular to the tube’s axis.
Because the surface is curved at the point where drilling starts, it takes a skilled hand to perform the task via freehand held drill and workpiece. I did not have such skills in my hands. Putting the workpiece in a vise helps, but still difficult for me to keep a hand held drill on center. What I needed was a way to hold both the workpiece and the drill bit in rigid relation to each other, meaning a custom workholding solution bolted to the drill press table.
It was built using a very cheap Harbor Freight vise. Its jaws were removable and I designed and 3D printed replacement jaws with a V profile to better hold a round object. The other benefit of 3D printed plastic jaws compared to metal jaws is the reduced chance of marring workpiece surface.
The next step is to bolt this vise onto the drill press table. I saw mounting slots on both the table and the vise, and their slots were in the same pattern. I naively thought this was a standard form factor and they will easily line up.
When I put my vise on the table, I found that they did not.
Fortunately even though they did not actually line up, they left enough room for me to use a smaller bolt to try to make things work. In this case, my stockpile of 1/4″-20 bolts.
The slots are too wide for the typical 1/4″-20 washers I had on hand for this bolt, but again I could turn to my 3D printer for custom solutions that help me bolt the vise to the drill press at the location I needed.
It took some adjustment to bolt the vise exactly where it needs to be. (Tip: double check to make sure the drill press table isn’t itself moving!) But once everything was tightened down, the jig made drilling the holes I needed very simple.
Public Onshape CAD file for this project are available here.
When local fellow maker Emily upgraded to a big floor standing Delta drill press, her old benchtop drill press was up for grabs. “Free if you pick it up” were the terms of the sale, and I was glad I could pick it up before someone else did. Taking part in countless Emily projects in the past, it shall now play a role in my projects in the near future.
Its long history in the hands of many handy creators showed clearly, with many stock parts missing replaced by either scratch fabricated or adapted parts. This is not a problem at all, a drill press is fundamentally a fairly simple machine and none of the modifications changed its ability to do its core job. Besides, with a less-than-new machine, I feel less intimidated about adding my own modifications as necessary.
The first project on the list addressed a known existing mechanical problem: the drive belt occasionally rubs against the chassis when it is installed in the lowest and slowest of four pulley slots. I inherited a workaround from Emily which I was content to leave in place, but then I saw the set screws holding the pulley to the motor shaft.
I thought it might be worth a shot to try loosening the set screw and move the pulley a little higher. There might be a good reason why the pulley was in its location. I thought it was possible (likely) the motor was not original and had a shorter shaft, or something along those lines. But it was worth investigating.
I put my hex wrench on the set screw and discovered it is loose now. The reason this pulley is too low is because the set screw came loose and it fell down due to gravity. I moved the pulley a little bit higher, tightened the set screw, and we’re back in business without any rubbing between belt and chassis. This was a great start to what I hope will be a long illustrious career for this drill press, enabling my project ideas in the future.
I remember playing with glass marbles as a child’s toy. I also remember mom being not terribly pleased when she would find them in various corners of the house, and definitely unhappy when some were on the floor where an adult might step on one and fall.
I also remember the swirls of color that were added to the glass to make them look prettier, and those are absent from industrial glass marbles. They have a job to do, and they don’t need to look pretty doing it. Not only do they lack the colorful swirl, they don’t even necessarily need to be perfectly spherical or have smooth exterior surfaces. I hadn’t known about these glass marbles with jobs until I learned of an overturned truck accident that was very difficult to clean up because its cargo were a full load of industrial marbles.
Curious, I read up on industrial glass marbles and how they are employed. I was excited when I learned that they are commonly used inside aerosol spray cans to stir its contents. They are what rattles when we shake up a can before spraying. I consumed several spray cans of Plasti-Dip for my RX-BB-8 project and saved the cans planning to cut into them to look at some industrial marbles up close. I finally got around to that particular project.
Even though they’ve stopped delivering dip, these cans still had some propellent inside delivering pressure. It seemed wise to relieve that pressure before we cut into the can, so I used a clamp to keep the top pressed and waited until the hissing stopped.
A hole is then drilled in the can for a starting spot, where pliers can dig in and start tearing up the thin metal shell. It only takes a few rips to open a hole large enough for the marble to see the light of day.
A little cleanup later, I had my first look at a cosmetically imperfect but still fascinating industrial glass marble.
I had several other empty spray cans which underwent the same procedure for marble extraction. I was fascinated by the surface texture of the first one I extracted, it gave the glass sphere more character than a perfectly smoothly counterpart. I plan to explore putting them in front of LEDs so their flaws can be part of a distinctive light diffuser.
I do not consider those glass imperfections of industrial glass marbles to be bug — I believe they have potential to be very unique features!
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.
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.
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.
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.
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.
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.
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.