Archive for category Machine Shop
$$ 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.
The folks I’ve been coaching through their plotter build project showed it off at the local MiniMakerFaire this past weekend. Next time around, I’ll insist they secure their circuit boards and use good wiring techniques, so as to avoid destroying more stepper drivers.
To that end, adding mounting holes to my proto board holder seems in order:
The board dimensions now live in an associative array, so you just pick the board name from a Configurator drop-down list:
/* [Options] */ PCBSelect = "ArdUno"; // ["20x80","40x60","30x70","50x70","70x90","80x120","ArdDuemil","ArdMega","ArdPro","ArdUno","ProtoneerCNC"] PCB_NAME = 0; PCB_DIMENSION = 1; PCBSizes = [ ["40x60",[40,60,1.6]], ["30x70",[30,70,1.6]], ["50x70",[50,70,1.6]], ["20x80",[20,80,1.6]], ["70x90",[70,90,1.6]], ["80x120",[80,120,1.6]], ["ArdDuemil",[69,84,1.6]], ["ArdMega",[102,53.5,1.6]], ["ArdPro",[53,53.5,1.6]], ["ArdUno",[69,53.1,1.6]], ["ProtoneerCNC",[69,53.1,1.6]], ];
Which seems easier than keeping track of the dimensions in comments.
You can now put the PCB clamp screws and mounting holes on specific corners & sides, allowing oddball locations for Arduino boards with corner cutouts along the right edge:
A “selector” notation separates the hole location from the board dimensions & coordinates:
ScrewSites = [ // [-1,1],[1,1],[1,-1],[-1,-1], // corners // [-1,0],[1,0],[0,1],[0,-1] // middles [-1,1],[-1,-1],[1,0] // Arduinos ];
Might not be most obvious way, but it works for me. Most of the time, corner clamps seem just fine, so I’m not sure adding the clamp and mounting hole locations to the dimension array makes sense.
The OpenSCAD source code as a GitHub Gist:
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.
Radio communication between our bikes failed on the way back from a grocery ride and the problem turned out to be a failed radio:
The Wouxun KG-UV3D radio seems jammed firmly somewhere in its power-up sequence, doesn’t respond to any buttons, and has no hard-reset switch. On the other paw, it’s been in constant (and rugged!) use for almost exactly five years, so I suppose it doesn’t owe me much of anything.
The new radio, another KG-UV3D from PowerWerx, has marginally different spacing around the screw attaching the plug cover preventing the previous screw from fitting, so I kludged up a screw from a 2 mm socket-head screw, a 2.5 mm (yes) washer, and a pair of 2 mm nuts:
Which looks a bit odd, but holds the plug adapter plate firmly in place:
I suppose when the radio on my bike fails, I must rebuild both APRS + voice interfaces for Yet Another Radio, because the Wouxuns will be completely unobtainable.
The weather abruptly became too cold for riding, at least for sissies such as we, but maybe we’ll get out later in the month …
Cranberries grow best in acidic conditions, as shown by the conditions inside an antique cranberry harvester:
Admittedly, it’s been sitting untended for many years, but the worst corrosion formed along the midline of the machine, eating the conveyor housing, drive shafts, and support struts.
I managed to go all this time without realizing cranberry plants are evergreens.
Being a big fan of having a CNC machine know where it is, adding endstops (pronounded “home switches” in CNC parlance) to the Mostly Printed CNC axes seemed like a good idea:
All the mounts I could find fit bare microswitches of various sizes or seemed overly complex & bulky for what they accomplished. Rather than fiddle with screws and nut traps / inserts, a simple cable tie works just fine and makes the whole affair much smaller. Should you think cable ties aren’t secure enough, a strip of double stick tape will assuage your doubts.
A snippet of aluminum sheet moves the switch trip point out beyond the roller’s ball bearing:
I’m not convinced homing the Z axis at the bottom of its travel is the right thing to do, but it’s a start:
Unlike the stationary X and Y axes, the MPCNC’s Z axis rails move vertically in the middle block assembly; the switch moves downward on the rail until the actuator hits the block.
Perforce, the tooling mounted on the Z axis must stick out below the bottom of the tool carrier, which means the tool will hit the table before the switch hits the block. There should also be a probe input to support tool height setting.
The first mount fit perfectly, so I printed four more in one pass:
All three endstops plug into the RAMPS board, leaving the maximum endstop connections vacant:
Obviously, bare PCBs attached to the rails in mid-air aren’t compatible with milling metal, which I won’t be doing for quite a while. The electronic parts long to be inside enclosures with ventilation and maybe dust filtering, but …
The switches operate in normally open mode, closing when tripped. That’s backwards, of course, and defined to be completely irrelevant in the current context.
Seen from a high level, these switches set the absolute “machine coordinate system” origin, so the firmware travel limits can take effect. Marlin knows nothing about coordinate systems, but GRBL does: it can touch off to a fixture origin and generally do the right thing.
The OpenSCAD source code as a GitHub Gist: