Category Archives: robots

Pocket NC Touch Probe – Software (Part 4/4)

This is a series, check out the previous posts at part 1, part 2, or part 3. This time, I’m going to make this probe hopefully do something.

I started out just verifying that the Pocket NC would treat the vers.by probe the same as the built in tool setter probe. So I ran a tool measure cycle, and then just tweaked the probe by hand. Woohoo! It stopped the cycle just like normal. Actually measuring a tool worked too if the probe wasn’t activated, or if it wasn’t plugged in. Success.

Probing Scripts

Next, I got a crash course in G-Code. Mostly I used the Linux CNC reference, since that is what the Pocket NC used and all I needed to be interoperable with. Having done no real manual G-Code programming before aside from my limited python auto-generation, I was I guess surprised that there was any real support for in-program scripting. The fun limitations:

  • Variables can either be “numbered” or “named”. 30 of the “numbered” variables are function local, (and are also necessary for argument passing), and all the remainder are global variables. “named” variables can be global or function local.
  • All control flow requires human assigned unique integers for each instance of that control flow construct. i.e., an “if-else-endif” chain requires a human assigned integer that is unique script wide to be applied to the if, and its matching elses and end-if statements.
  • Largely, subroutines need to be in a file by themselves, and all in the same directory.
  • Annoyingly, expression grouping is with square braces “[]”, not parentheses, “()”.
  • “comments” are overloaded to also be used for all “non-machine” operations. If you want a comment to actually be a comment, the best and seemingly standard way is to ensure all comments are prefixed with a space.
  • Some things can be indirected natively, but not for instance, “which axis to move”. That must be specified using a literal character in each command.

The first probing function I needed was to reference the outer diameter of a cylindrical feature. I started by writing a subroutine which would perform a single linear probe in a parameterizable axis. It first probes quickly, then backs off a bit to probe again slowly. To work around the lack of axis indirection, it just uses if-else chains to handle the X, Y, and Z axes.

https://github.com/jpieper/pnc_probe/blob/main/gcode/pnc-probe-xyz.ngc

Next, I used that in an cylindrical feature probing script, where you manually position the probe along one of the major axes at the proper Z probing depth, assuming that the feature is “roughly” at the center of the current coordinate system. It would then probe all 4 axes, finally setting the coordinate system 0, 0 to be the center of the feature. For this, I “simulated” some arrays using the 30 numbered function local variables so that the probing logic could be implemented in a loop.

https://github.com/jpieper/pnc_probe/blob/main/gcode/pnc-probe-center.ngc

This did the trick, and now I could reference cylindrical (and square) features using G54.

Repeatability

I ran this around 30 times over the course of a few hours, including remounting the probe a few times and changing the temperature and airflow to get an idea of the repeatability of the probing process.

AxisStandard DeviationPeak to Peak
X0.00031″ (0.0079mm)0.0012″ (0.030mm)
Y0.00044″ (0.0112mm)0.0015″ (0.038mm)
Probing Repeatability

So, roughly around 1 thousandth or 0.02mm of absolute repeatability. I might be able to improve that by tweaking the probing speed or otherwise adjusting parameters, but the Pocket NC itself isn’t a whole lot better so it should be “good enough” for now.

Next Steps

First, all of the work I have so far is publicly available on github: https://github.com/jpieper/pnc_probe

This project is at a functional point for myself, but isn’t quite ready for others to use. The biggest issue is the necessary modifications to the shaft of the vers.by probe, as they aren’t easy to do and require additional equipment. The other pieces also still have some rough edges that should be filed off, including keeping chips out of the RJ45 connectors and getting a PCB in that doesn’t require bodge wires to work.

I also intend to do a little work to demonstrate that the probing can be used to register features across operations properly.

My eventual goal is to eventually get the design to a state where it is nearly “off the shelf” and list it on tindie. To do that will depend upon if I can figure out a better solution for the probe shaft.

Pocket NC Touch Probe – Electrical (Part 3/4)

In part 1 and part 2, I covered my motivation and the mechanical hardware behind a touch probe add-on for my Pocket NC V2-50. In this post, I’ll cover my prototype electrical hardware.

My intention with the probe was to connect it logically “in parallel” with the existing tool setter probe that the Pocket NC has. I figured that would be likely easiest to integrate with the Linux CNC scripts when I got to the software point. The existing tool setter probe is located in the rotating B axis. That is connected to the Y axis via a single CAT5-ish cable, so my hope was that I could devise something which would pass through the necessary signals on that cable while also paralleling in the new touch probe.

To start, I acquired some RJ45 to .1″ header breakouts from Amazon and broke open the bottom of the Pocket NC B axis table, and wired up a pass through on a breadboard:

Using a multimeter to probe around, it was pretty obvious the first 4 pins went directly to the B axis stepper motor. Of the remaining, 5 was pretty obviously ground. Slightly confusingly, the one that had 3.3V on it appeared to be a pullup for the open-drain normally open tool setter, while the pin with 2.8V on it was the power for tool setter and the B axis hall effect homing sensor. The one remaining pin was the output of the B axis homing sensor.

There were a few electrical challenges here. The first was that the vers.by probe needs 5V, not 2.8V. To begin with, I just wired in 4 AA batteries, and for a longer term solution I picked up a 5V charge doubler from digikey, the TPS60241.

The second required a fair amount of thought: how to make the normally closed vers.by probe act “in parallel” to the built in tool setter, while still being able to disconnect the probe and maintain tool setter functionality. Just inverting the normally closed signal would result in something that made the tool setter appear to be always activated whenever the touch probe was disconnected.

Here, I relied on a design artifact of the vers.by probe. The “USB cable” connector had both D- and D+ connected together, but in the probe itself. So if the probe or cable were disconnected, those two nets would have no connection. Thus I pulled one high, and pulled one low. Then the three states I cared about looked like:

D-D+
Probe Disconnected01
Probe Connected and Inactivated00
Probe Connected and Activated11

I used a 74HC series NAND gate to only activate a parallel N-FET in that final case, where the probe is connected and activated.

I breadboarded this with the 4 AA batteries, then did a proto-board implementation that used the 5V charge pump too. I was going to use the same SMT components on the proto-board implementation, but the NAND gates, despite being labeled as the same 8VSSOP package as the charge pump, and both from TI, turned out to be a package that was too small for me to “dead bug” solder. So, instead I just flipped over the DIP package NAND I had and wired that up.


The charge pump wired up under the microscope
The final “proto-board”

Then using some cardboard, hot glue, and a zip tie, I fastened it to the back of the A axis stepper motor on the Pocket NC:

Before I was able to really test this well, a PCB from OSHPark came in, so I used that with a 3D printed enclosure:

Next up, making it actually do something!

Pocket NC Touch Probe – Mechanical Hardware (Part 2/4)

Last time in part 1, I talked about why I wanted to add a touch probe to my Pocket NC. This time, I’ll cover the basic hardware necessary to make it happen.

I decided to start with an inexpensive probe so that as I was figuring things out, I wouldn’t be too sad if I smashed it a few times. I’ve seen a number of other hobby machinists use the “vers.by” probes, so I decided to give them a try too.

This probe requires 5V-24V power, has a 6mm shank, and provides a NPN-NC output with a USB connector as the physical connector. Note, it isn’t USB, but just uses that connector for power and the signal.

Mounting

To start with, I needed to get the probe such that I could mount it in the spindle of the Pocket NC. The V2-50 I have can handle a 4mm shank at most, and that is what I primarily use. Obviously, 6mm is bigger than 4mm, so something needed to be done.

So, I wouldn’t be a quality engineer if I didn’t have the brand new toy disassembled within hours of receiving it:

What I ended up doing was turning down the 6mm shaft to 4mm on one of the Artisan Asylum’s manual lathes.

This was pretty challenging. First because the shaft was already permanently mounted into that relatively thin base section, so getting the part trued up in the chuck took some time. Second, because it sticks out so far, I could only take excruciatingly light cuts. In hindsight, I should have worked harder to get the opposite side supported. The entire operation took something like 3 hours. However, when done, I had a probe with a 4mm shaft!

And hey, it fits!

After a bit of tuning with my 2 micron dial indicator, and the provided adjustment screws, it seems to pretty dialed in.

Pocket NC Touch Probe – Motivation (Part 1/4)

When machining, you need to accurately position the cutting tool with respect to the workpiece. With the stock Pocket NC, there are two methods for doing so. The first is to rigidly locate the workpiece with respect to the B axis reference point using a fixture. The second, is to do manual touch offs. Nearly all of my work so far has relied on the former method, as using a manually touch off on a machine without manual controls isn’t all that precise or pleasant. And while possible, it is tedious to touch off against features more complicated than a single edge.

My Approach So Far

To make that first approach work, I’ve been making 3D printed fixtures (1, 2, 3, etc) to hold the work while simultaneously registering it to the mounting holes or alignment pins on the B axis. Simultaneously, I need to keep the machine well calibrated so that the X, Y, Z, A, and B offsets are all aligned as closely as possible to the center of rotation of the A and B axis.

About the best alignment I’ve achieved between calibration and my fixture is about 50-150 micrometers (2-5 thousandths of an inch). So for any parts or features which need relatively alignment better than that, I need to design it such that all the features can be completed in a single operation without moving the A or B axes.

To date, all the parts for the qdd100 servo were designed with that constraint in mind, so that I could prototype them locally. The rotor and stator need to be aligned with precision approximately 25-50 micrometers, and there are multiple pieces involved in maintaining that alignment, all of which need to be machined accordingly. However, designing the assembly to satisfy those constraints made actually assembling it a relatively time consuming operation, which I would like to improve.

Touch Probes

A third method of workpiece locating, not mentioned above because the Pocket NC doesn’t support it natively, is with a touch probe. A touch probe, is a stylus mounted in the spindle like a tool, which can detect when it is deflected in one or more axes. Then the machine can move the spindle around, and sense where the part is located with respect to the machine coordinates directly.

In this series, I’m going to explore adding a touch probe capability to my Pocket NC. We’ll see how it goes!

Fixing a chip evacuation problem on the Pocket NC

My Pocket NC v2-50 is a fine machine for its size class, but there are still plenty of annoyances. One of them is that chips can accumulate places they shouldn’t, either during a run, or over the long term.

There is a cavity near the back of the machine where the Y axis cables and cable guide retract into. That cavity is exposed to chips flying around, so they tend to accumulate there. There is a hole in the bottom of the machine where the chips could maybe fall out, except the hole is too small for any but the smallest of chips, and further, it is completely sealed off when mounted in the stock Pocket NC enclosure.

Basically every time I’ve taken the machine out of the enclosure, I’ve found that cavity so packed with chips that you wouldn’t think the cables could even more anymore. That is even with a thorough vacuuming after every part and often every operation. Plus the Y axis cables are just ethernet cables, which means once you unplug them, those chips can easily fill the RJ45 jacks.

While replacing a failed cable chain, the always responsive Pocket NC support team mentioned that some customers had machined an extra hole in the back of the housing to allow for cleaning that cavity out. Why didn’t I think of that! I did mine with a hand drill and dremel, assuming it would be faster than either disassembling the entire machine or fixturing it assembled into a manual mill. While that was probably true, it was still a painful process.

Despite the pain and the unpolished finish, the end result seems like it will have the desired effect.

moteus firmware release 2021-09-19

This new release makes minor improvements to support for r4.8 moteus boards, notably it makes the Kv and winding resistance calculation more closely match that measured by r4.5 and decreases audible noise when controlling to 0 current or torque.

Get it from github: moteus 2021-09-19

Note, this does require a new version of moteus_tool to be able to flash over CAN, version 0.3.29. You can get it from pypi using any of the normal pip3 methods: https://pypi.org/project/moteus/

Compensating for FET turn-on time

A motor driver like moteus switches power to the phases of a brushless motor using a set of 6 (or possibly more), MOSFETs. The typical topology involves 3 high side N channel MOSFETs and 3 low side N channel MOSFETs arranged in 3 half bridges like this:

(example 3 half-bridge from DRV8353 reference manual)

Since the gates of these FETs need to be driven with potentially high voltages, and you never want the high side and low side to be on at the same time, typically a gate driver is used. For the moteus r4.5 and earlier controllers, the DRV8323 driver from Texas Instruments is what performs this function. This driver lets you configure the drive current for each of the gates for both operations, charging up the gate and discharging it. For high power drive systems, charging up or discharging the gate too fast can result in undesired transients like accidentally switching the other FET on due to capacitive coupling, or inductive ringing as the current starts moving through the FET instead of the body diode. If the gate charges too slowly, then the FET spends much of its time not fully on, which increases power dissipation in the FETs.

For the purposes of this write-up, this means that the FETs do not turn on or off instantly, and the turn-on time can differ from the turn-off time.

Control structure with PWM mapping shown

One of the lowest levels of control in moteus accepts a set of desired voltages on each of the 3 phases, and then selects a PWM duty cycle for the 3 phases which attempts to achieve those voltages. For most control purposes this mapping isn’t too critical, as usually it is driven by an outer current loop, which selects these values to try and achieve a desired phase current. Thus any non-linearities are mostly washed out, just reducing the control performance a bit. The times it is most important is during motor calibration when a fixed voltage waveform is applied for spinning the motor, and when the phase resistance and inductance of the motor are estimated.

To date, that function has used a relatively simple model that treats the 3 phases independently. For each phase, the voltage is mapped to a PWM using a piecewise linear approximation with two segments. This works reasonably well on the r4.5, and gets the resistance and inductive measurements into a usable territory.

Problems brewing

As a consequence of the global semiconductor apocalypse, I’m working on a new version of the moteus controller that uses a gate driver which it was possible to purchase with less than a year lead time. Unfortunately, it is more sensitive to failure induced by ringing than the DRV8323 was. Because of the abbreviated design timeframe, I left the power stage of the r4.5 alone when making this switch, and it had a fair amount of ringing when using the drive currents it is configured with by default. So, for the new board, it needs to be run with much slower gate drive waveforms than the r4.5 board could achieve.

Using the lower current results in a very distorted mapping between PWM and voltage on the phase terminals, such that calibration wouldn’t complete and measuring the phase resistance was not practical. You can get an idea of the problem by looking at the plot below of phase current during the motor calibration phase. The driving voltage is a sine wave, and the current is supposed to be a sine wave also. Because of the additional distortion, low voltage commands result in nearly no actual current production and there is a large undesired waveform when the three phases are active, but at different levels.

Thankfully current control mostly worked, although it likely suffered from degraded performance at small currents. Despite that, not being able to calibrate is a big deal, so I had to take another look at this control step to make it able to handle the larger non-linearity.

Quantifying the problem

I didn’t necessarily want to try and model the gate drive at a more detailed level to understand this, to tackled the quantification problem by brute force. I wrote a simple tool which commanded a fixed PWM on the A phase, and then did a 2D sweep over the B and C phases in a region where my power supply could provide sufficient current without undue heating. The plots of the B, and C currents as 3D surfaces are shown below (the A current can be found from those two currents).

B and C phase current vs PWM

I think numerically inverted that mapping, to determine the necessary B and C pwm values to achieve a given B and C phase current.

The C phase plot looked the same just mirrored. Notably, this has two distinct regions. There is a region which extends to infinity where the command B is related to the desired B 1 to 1 with a fixed offset. However, that region only seems to exist beyond a line that is related to the C command. On the other side of that line, the fixed offset is no longer required. I did a rough curve fit to this, which looks like:

In the above plot, the sampled data is now faded out, and the simple surface fit is fully saturated. It works plenty well, and is controlled by 2 parameters as before (since the dividing line between the two regimes seems to not be something that is likely to need to be configured).

Results

I reworked the mapping to always operate in terms of a B and C phase that are larger than the A phase, then shift things back to the correct phase and balance afterwards. That way this correction surface could be applied as is.

This new technique gives much better low-voltage performance, especially when more than one phase is active and when larger amounts of compensation are required. Here’s a plot showing the current waveform during a sinusoidal calibration sweep.

Comparison of PWM compensation methods

With the r4.5 board, you can see the low voltage performance improve a fair amount. With the newer r4.8 board and its higher required compensation, the improvement is dramatic.

moteus r4.8

I’m excited to announce the release of moteus r4.8!

Due to the ongoing semiconductor apocalypse, this minor release uses some alternate components which were easier to source. It remains compatible with the r4.5 and r4.3 both electrically, mechanically, and with firmware.

For now, the biggest win is that the board and the devkit are actually in stock!

A secondary win is that external primary encoders are now supported, via an unpopulated connector pad on the backside of the board. I’ll write up more about that in a later post.

Good luck building!