Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
The Shapeways bronze-infused stainless steel process reportedly produces objects so hard that they require carbide tooling, so I wasn’t too surprised when this magazine block rounded the threads right off a tap:
Browning Hi-Power magazine – steel block trial fit
The tap turned up while I was clearing off the bench and, seeing as how the upper half of the threads weren’t ruined, I thought maybe I could at least get a bottoming tap out of it.
Step 1: snap off the damaged part. This should be easy, as tap steel tends to punish you when you’re not doing it right. So I grabbed the ruined section in the bench vise and gave the shank a stiff whack:
The tap came from a set of dubious provenance that’s conspicuously labeled: JUNK METRIC. I have no idea where it came from, as it’s slightly younger than dirt. There’s a Craftsman metric set in the same drawer with much better steel (yes, I’ve snapped a few taps) that I normally use; I figured if I was going to wreck a tap on that magazine block, I should wreck a junk tap.
Maybe that Shapeways stainless isn’t quite as nasty as it seems…
The strut supporting the two drawers in the bottom of the refrigerator came out in two pieces during a recent cleaning session. To judge from the condition of the joint, I’d done this once before in its history:
Refrigerator strut – tab clamps
That tab inserts into a slot in the front of the elaborate frame that supports the drawers, where it’s captured by a metal bar. Should you lift the rear of the strut without first removing the bar, the tab snaps off at the base. I’ve annotated the top of the strut in the hopes of reminding me the next time around.
A pair of bumps at the front of the drawer guides should hold the drawers closed, but it’s pretty obvious that’s not working as intended:
Refrigerator strut – worn retainers
I shaped strips of phosphor bronze spring stock around the bumps:
Refrigerator strut – phosphor bronze covers – top
The bottom view shows they’re held in place by crimps and a generous dollop of faith:
That should serve until I know whether the plastic drawer rail will carve through the metal. The drawers slide out with much more enthusiasm now, so it’s a Good Thing until something else breaks.
Yes, this is the refrigerator with the Freezer Dog…
FC1002 Frequency Counter – faceplate – circular polarizer
A sheet of linear polarizing film held in front of the lens:
FC1002 Frequency Counter – faceplate – linear polarizer
For reference, none of the other instrument faceplates on the bench show anything other than uniform gray, with one exception that points directly to the plastic injection point.
I’d say this plate cracked due to unrelieved internal stresses and not anything I did or didn’t do.
Our Larval Engineer’s new camera uses Canon NB-6LH batteries, which have exactly the same nominal capacity as the NB-5L batteries for my camera, despite being not quite the same size. I cannot imagine any reason for that, other than brand fractionation, but there it is.
That hideous Powerpole thing came from one of the AA cell packs I’d been using to power the HTs on the bikes, before switching to lithium battery packs. It’s easier to harvest something suitable than to build a new thing, particularly for such a low duty cycle gadget.
This view of the solid model shows the contact pins, with the lid floating over its alignment pegs (made from snippets of 1.75 mm filament):
NB-6L Holder – fit layout
The pegs simplify gluing the lid in place, a process for which you can never have enough clamps:
Canon NB-6L holder – lid gluing
A cutaway shows the stepped holes around the contact pin, with the coil springs being the largest cylinder to the right of the solid-looking plug:
NB-6L Holder – show layout
The contact pins look like this, at least after one remembers to slide on all the parts before soldering the wires in place:
Canon NB-6L holder – contact pin detail
I filed off the inevitable solder bumps, rounded the butt ends with gentle suasion, and generally tidied the pins up so they’re smooth and symmetrical. The springs don’t have a lot of oomph, so wasting any force on friction or binding is a Bad Thing.
The holes require reaming with twist drills for a nice slip fit around the pins. The OpenSCAD script prints out the relevant diameters and depths:
ECHO: "Contact pin tip dia: 1.6"
ECHO: "Drill depth to taper end: 24.1 -- Dia: 2.4"
ECHO: " to ferrule end: 15 -- Dia: 3.1"
ECHO: " to plug end: 4 -- Dia: 5.2"
Grab the proper drill in a pin punch, adjust so that length protrudes, and have at it. Making the holes about 0.2 mm larger than nominal works well, although your mileage will definitely vary.
The build layout includes extra retaining plugs, as they tend to go walkabout under the bench:
NB-6L Holder – build layout
Add a dab of PVC cement with THF inside the holes and the plugs push firmly into place:
Although the TOM286 conversion won’t need any fancy firmware, I forked Marlin’s Github repository and created a TOM286 branch based on the Marlin_v1 branch for the Azteeg X3 modifications; in theory, we can blend in future Marlin updates without too much hassle.
The Pronterface serial port tops out at 115200, so that’s a mandatory change right up front. [grin]
Marlin has a motherboard definition for an Azteeg X3 (type 67), but without the optional thermocouple inputs. I added motherboard 671, following the lead of the Megatronics board definitions (types 70, 701, and 702). In addition to the changes below, any test for motherboard 67 now includes 671, as the other pins and suchlike (should) be the same.
Motherboard 671 selects new pin definitions for the temperature inputs in pins.h:
#if MOTHERBOARD == 671
#define TEMP_0_PIN 11 // TC1 on shield
#define TEMP_1_PIN 4 // TC2 on shield
#define TEMP_2_PIN 13 // T0 thermistor on Azteeg X3 motherboard
#else
#define TEMP_0_PIN 13 // ANALOG NUMBERING
#define TEMP_1_PIN 15 // ANALOG NUMBERING
#define TEMP_2_PIN -1 // ANALOG NUMBERING
#endif
There’s now a TCOUPLE_AMP_TYPE definition in Configuration.h to select AD595 or AD849x thermocouple interfaces:
// Thermocouple sensor amplifier type
// 0 = AD595 gain = 10 mV/C
// 1 = AD849[4567] gain = 5 mV/C
#define TCOUPLE_AMP_TYPE 1
That picks the proper offset and gain definitions in Configuration_adv.h:
// The AD849[4567] has 5 mv/C gain, half that of the AD595, and requires _GAIN = 2
#if TCOUPLE_AMP_TYPE == 1
#define TEMP_SENSOR_AD595_OFFSET 0.0
#define TEMP_SENSOR_AD595_GAIN 2.0
#else
#define TEMP_SENSOR_AD595_OFFSET 0.0
#define TEMP_SENSOR_AD595_GAIN 1.0
#endif
With those in hand, these temperature sensor selections in Configuration.h will work:
I tweaked the temperature limits and preheat settings; the absolute minimum temperatures are now 10 °C, although I have not verified that a disconnected thermocouple or thermistor will actually trip that limit.
Given the completely arbitrary stepper motor wiring connections, I set all the direction inversions to false and then swapped wires to make the motors turn in the proper direction.
I enabled EEPROM_SETTINGS, but haven’t verified that values can actually store and recall themselves.
The XYZ=0 origin is in the middle of the platform, just where I like it, but that will require some fine tuning:
I think it’s possible to use the Z_SAFE_HOMING position to force Z-minimum homing on the platform height switch I built for the original firmware, but that operation also seems to be tied in with the three-point auto-leveling firmware and rotating switch assembly. Right now, the firmware homes to the Z-max switch as a stock Thing-O-Matic should, but I’ve never liked that arrangement; don’t start with me, you know how I get.
I backed the speeds and accelerations down from the values I’d been using, mostly because the driver hardware and currents are different:
// Computing steps/mm
// for XY = (motor steps/rev * microstepping) / (pulley teeth * tooth pitch)
// for Z = (motor steps/rev * microstepping) / (screw lead) // for E = (motor steps/rev * microstepping) / (gear ratio * drive circumference) // make sure ratios use floating point to avoid integer division!
#define DEFAULT_AXIS_STEPS_PER_UNIT {(200*16)/(17*2.0), (200*16)/(17*2.0), (200*8)/8.0, (200*4)/((7*30.23)/51)}
#define DEFAULT_MAX_FEEDRATE {5000/60, 5000/60, 1500/60, 4000/60} // (mm/sec)
#define DEFAULT_MAX_ACCELERATION {5000, 2500, 1000, 250} // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for skeinforge 40+, for older versions raise them a lot.
#define DEFAULT_ACCELERATION 10000 // X, Y, Z and E max acceleration in mm/s^2 for printing moves
#define DEFAULT_RETRACT_ACCELERATION 10000 // X, Y, Z and E max acceleration in mm/s^2 for retracts
I’m not sure how to calculate the “jerk” settings, but taken as the maximum un-accelerated speed, these seem conservative:
// The speed change that does not require acceleration (i.e. the software might assume it can be done instantaneously)
#define DEFAULT_XYJERK 25 // (mm/sec)
#define DEFAULT_ZJERK 5 // (mm/sec)
#define DEFAULT_EJERK 5 // (mm/sec)
More tuning is in order; that should at least start it up.
For some unknown reason, one of the very rare updates to the Ubuntu 10.04 LTS infrastructure (for LinuxCNC 2.5.3 on my Foxconn D510 box, driving the Sherline mill) stopped supporting the system board’s built-in NIC: networking stopped working. The only symptom was that the NIC didn’t respond and all the usual tricks were unproductive.
After some fruitless searching, I took the easy way out:
NIC added to Foxconn D510 PC
That’s the backside of an ancient NIC using the classic Tulip driver. It used to have a full-size bracket, which I chopped off, bent, and filed to suit, much as with that one in the D525.
Fired it up, the kernel automagically picked the proper driver, and networking Just Worked again.
A few months ago I fired the Thing-O-Matic, only to have it wake up dead. Not exactly dead, but spitting out checksum errors on simple G-Code files sent from Pronterface, which used to work just fine. Trying a bit of this-and-that to no avail, I proposed to The Mighty Thor that I could loan the carcass to Squidwrench, reanimate it with a less bizarre set of hardware and firmware than the much-hacked Makerbot menagerie under the hood, and use it as an exemplar in my 3D Printing classes.
Fortunately, that particular Thing-O-Matic has the most well-documented hardware evah…
Matt suggested an Azteeg X3 controller, because it has thermocouple inputs that match the existing sensor, Thor ordered one, and I tinkered up a first-pass version of Marlin that could read the inputs and twiddle the motors. The firmware is on Github, not that you’ll need it for anything you’re doing; more on that later.
Here’s the Official Doc for the microstepping jumpers hidden under the driver boards:
Azteeg X3 – microstep jumpers
That’s XYZE = 16 16 8 4, respectively, with a spare slot (and spare driver, not installed) for the second extruder it’ll never have.
The extruder’s Type K thermocouple connects to the TC1 port on the shield, exactly reversed from the way you see the test thermocouple there: the red lead is to the left, the yellow lead is to the right. If you get it backwards, the indicated temperature goes down when you touch the bead. The printer’s thermocouple has some backstory.
The 10 kΩ thermistor bead connects to the BED port on the main board and isn’t polarized. The Heated Build Platform has a bit of backstory, too.
The gutted TOM286 carcass with the MBI hardware off to the side:
TOM286 – gutted electronics bay
After a few sessions, it looked pretty cheerful again:
This is what you see when looking down through the acrylic baseplate:
Azteeg X3 – inside TOM286
The blurry silver rectangle off to the left is an aluminum channel glommed to bottom of the acrylic baseplate with silicone snot to eliminate a nasty mechanical resonance.
The thermal cutout circuitry isn’t wired in yet; the ATX power supply has its -Power-On pin hotwired to the adjacent ground pin for now. The X3 gets its power directly from the +12 V supply, so there doesn’t seem to be any way to power the X3 from the +5 V Standby ouput, deliver +12 V to the motors, and switch the supply through the X3’s ATX output pin.
The heaters work fine, the motors turn properly, and the extruder feeds molten plastic; all the motor calibrations seem to be pretty close. The first test object was a total botch, of course, but the printer’s parts seem to work OK again.
The Smell of Molten Projects in the Morning 