Posts Tagged Arduino
Using 3D printer style endstop switches has the advantage of putting low-pass filters (i.e. caps) at the switches, plus adding LED blinkiness, but it does leave the +5 V and Gnd conductors hanging out in the breeze. After mulling over various enclosures, it occured to me I could just entomb the things in epoxy and be done with it.
The first step was to get rid of the PCB mounting screws and use 3M permanent foam tape:
Get all the switches set up and level, mix up 2.8 g of XTC-3D (because I have way too much), and dab it on the switches until all the exposed conductors have at least a thin coat:
You should use a bit more care than I: the epoxy can creep around the corner of the switch and immobilize the actuator in its relaxed position. Some deft X-Acto knife work solved the problem, but only after firmly smashing the X axis against the nonfunctional switch.
Epoxy isn’t a particularly good encapsulant, because it cures hard and tends to crack components off the board during temperature extremes. These boards live in the basement, cost under a buck, and I have plenty of spares, so let’s see what happens.
At least it’s now somewhat more difficult to apply a dead short across the Arduino’s power supply, which comes directly from a Raspberry Pi’s USB port.
GRBL responds to critical errors by disabling its outputs, which seems like a useful feature for a big-enough-to-hurt CNC machine like the MPCNC. Unlike the RAMPS 1.4 board, there’s no dedicated power-control pin, so I connected the Coolant output to the same DC-DC SSR I tried out with the RAMPS board:
With homing enabled, GRBL emerges from power-on resets and error conditions with the spindle and coolant turned off and the G-Code interpreter in a locked state requiring manual intervention, so turning the stepper power on fits right in:
$x– Unlock the controls
m8– Coolant output on = enable stepper power
$h– Home all axes
The steppers go clunk as the power supply turns on, providing an audible confirmation. The dim red LED on the SSR isn’t particularly conspicuous.
Turning the stepper power off:
m9– Coolant output off = disable stepper power
I think the A4988 drivers maintain their microstep position with the stepper power supply off, because their logic power remains on. In any event, you probably wouldn’t want to restart after an emergency stop without clearing the fault and re-homing the axes.
The board has Cycle Start, Feed Hold, and Abort inputs just crying out for big colorful pushbutton switches.
Unlike the RAMPS board, the Prontoneer CNC Shield does not feed stepper power to the underlying Arduino UNO, leaving it safely powered by USB or the coax jack.
The default MPCNC configuration wires the two stepper motors on each axis in series, doubling the total resistance and inductance of a single motor. The stock Automation Technology motor presents 2.8 Ω and 4.8 mH in each winding to the driver, for an L/R time constant of τ = 1.7 ms. Doubling both doesn’t change the ratio, but including the harness wiring resistance gives 1.6 ms = 9.6 mH / 6 Ω.
The default DRV8825 driver configuration uses 1:32 microstepping, which I thought was excessive. I replaced the stock RAMPS setup with a Protoneer / GRBL setup using A4988 drivers in 1:16 microstepping mode, got it configured, and made a few measurements:
The current probe measures the winding current in the red wire. The voltage probe at the bottom isn’t doing anything, because I ran out of hands.
Here’s a 10 mm X axis move at 3600 mm/min = 60 mm/s:
The top trace shows the winding current at 500 mA/div. The bottom trace shows the voltage applied to the winding at the A4988 driver pin.
Basically, the +12 V supply doesn’t provide enough headroom to let the driver force the required current into the winding at full speed, which is why the peak current decreases as the step rate increases and the sinusoid becomes a square(-ish) wave. The applied voltage switches rapidly to maintain the proper winding current when the axis is stationary or moving slowly (where the driver’s PWM current control works fine), but turns into a square (well, rectangular) wave as the pace picks up (and the driver loses control of the current).
The motor drives a 16 tooth pulley with a 2 mm belt pitch, so each revolution moves 32 mm of belt. With 1:16 microstepping, each revolution requires 3200 = 200 full step × 16 microstep/step pulses, which works out to 100 step/mm = (3200 step/rev) / (32 mm/rev). At the commanded speed near the middle of the trace, the driver must produce 6000 step/s = 60 mm/s × 100 step/mm, so each step lasts 167 μs, about τ/10.
In round numbers, the first full cycle on the left has a 20 ms period. Each full cycle = 4 full steps = 64 microsteps, so the belt moved (60 step) / (100 step/mm) = 0.6 mm, at an (average) speed of 30 mm/s = 1800 mm/min. The current begins to fall off by the third cycle with a 12 ms period, a pace of 50 mm/s = 3000 mm/s, and pretty much falls off a cliff by 60 mm/s in the middle.
To be fair, those are aggressive speeds for milling, but lasers and 3D printers tick along pretty quickly, so they’re not unreasonable.
More study is indicated, as the saying goes …
$$ command (in the first line) produces output in exactly the format it will accept as input, so just pour the captured file into GRBL’s snout. I used
ascii-xfr with a 250 ms line delay:
ascii-xfr -s -v -l 250 MPCNC-GRBL.cfg > /dev/ttyACM0
Now, to be fair, the MPCNC hasn’t yet done any useful work, but it moves.
$22=1 requires home switches to be installed and working, with
$23=7 putting them on the negative end of the axes, which may not work well in practice. In particular, having the Z axis homing downward is just plain dumb.
The step/mm values in
$10 require 1/16 microstepping with 2 mm belts on 16 tooth motor pulleys. The MPCNC’s Marlin config uses 1/32 microstepping, which doubles the step frequencies and (IMO) doesn’t provide any tangible benefit.
The speeds in
$11=6000 seem aggressive, although they actually work so far.
The accelerations in
$12 may push the motors too hard with anything installed in the toolholder.
The travel limits in
$13 depend on the rail lengths you used.
The Protoneer Arduino CNC shield (*) has a row of 2-pin headers for bare endstop switches. Being a big fan of LED Blinkiness, I have a stock of 3-pin Makerbot-style mechanical endstops that require a +5 V connection in addition to ground and the output.
A crude-but-effective adapter consists of half a dozen header pins soldered to a length of stout copper wire, with a pigtail to a +5 V pin elsewhere on the board:
A closer look:
The pins get trimmed on the other side of the bus wire, because they don’t go through the PCB.
Installed on the board, it doesn’t look like much:
Looks like it needs either Kapton tape or epoxy, doesn’t it?
Three more endstops at the far end of the MPCNC rails (for hard limits) will fill the unused header pins.
(*) It’s significantly more expensive than the Chinese knockoffs, but in this case I cheerfully pay to support the guy: good stuff, direct from the source.
Plugging an Arduino with GRBL into a USB port on a Raspberry Pi 3 with bCNC causes an immediate crash: the Arduino doesn’t power up and the Raspberry Pi stops responding. A hardware reset / power cycle with the Arduino plugged in doesn’t improve the situation, so it seems the Arduino draws more current from the USB port than the default setup will allow.
Most likely, the Arduino’s 47 μF power supply caps draw too much current while charging, as the steady-state current seems to be around 40 mA:
The solution / workaround requires a tweak to
#-- boost USB current for Arduino CNC max_usb_current=1 # blank line above to reveal underscores
Update: As mentioned in the comments, the
max_usb_current option doesn’t apply to the Pi 3 you see in the picture and, thus, shouldn’t have changed anything. Your guess is as good as mine.
I’d be more comfortable with a separate power supply plugged into the Arduino’s coaxial power jack, but that’s just me.
A reader (you know who you are!) proposed an interesting project that will involve measuring audio passbands and suggested using white noise to show the entire shape on a spectrum analyzer. He pointed me at the NOISE 1B Noise Generator based on a PIC microcontroller, which led to trying out the same idea on an Arduino.
The first pass used the low bit from the Arduino runtime’s built-in
Well, that’s a tad pokey for audio: 54 μs/bit = 18.5 kHz. Turns out they use an algorithm based on multiplication and division to produce nice-looking numbers, but doing that to 32 bit quantities takes quite a while on an 8 bit microcontroller teleported from the mid 1990s.
The general idea is to send a bit from the end of a linear feedback shift register to an output to produce a randomly switching binary signal. Because successive values involve only shifts and XORs, it should trundle along at a pretty good clip and, indeed, it does:
I used the Galois optimization, rather than a traditional LFSR, because I only need one random bit and don’t care about the actual sequence of values. In round numbers, it spits out bits an order of magnitude faster at 6 μs/bit = 160 kHz.
For lack of anything smarter, I picked the first set of coefficients from the list of 32 bit maximal-length values at https://users.ece.cmu.edu/~koopman/lfsr/index.html:
The spectrum looks pretty good, particularly if you’re only interested in the audio range way over on the left side:
It’s down 3 dB at 76 kHz, about half the 160 kHz bit flipping pace.
If you were fussy, you’d turn off the 1 ms timer interrupt to remove a slight jitter in the output.
It’s built with an old Arduino Pro Mini wired up to a counterfeit FTDI USB converter. Maybe this is the best thing I can do with it: put it in a box with a few audio filters for various noise colors and be done with it.
It occurs to me I could fire it into the 60 kHz preamp’s snout to measure the response over a fairly broad range while I’m waiting for better RF reception across the continent.
The Arduino source code as a GitHub Gist: