Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
Shortly after replacing the battery, the dreaded Malfunction Indicator Lamp popped on with a P0420 error code that, according to the Nice Man at Autozone, translates into “low catalytic converter efficiency”. A bit of diagnostic sleuthing reported that the most likely cause was an exhaust leak, followed by an out-of-calibration downstream oxygen sensor, followed by a bad converter. Internet lore has it that replacing the cat cracker is a dealer-only event (here in New York State, with a van sporting the California emissions package) that costs upwards of $2 k, which seems excessive for a 14-year-old van.
Actually, the most probable cause was replacing the battery: the brief power outage wipes out the stored performance data for the emissions control machinery. Because we make only short trips and it’s been bitterly cold, the algorithms may conclude the converter’s dead when it’s just a matter of measuring the variables under suboptimal conditions.
With all that in mind, after a peek under the van ruled out the exhaust leak, I decided to replace the oxygen sensor. All this happened during a week when the outdoor temperature hovered around 10 °F = -12 °C, but the forecast called for an atypical January day with a high of 55 °F = 13 °C; I might not get a second chance before the annual inspection came due in February.
The sensor is relatively cheap (about $70 at the local Autozone) and, entirely unlike Bank 1 Sensor 1, readily accessible on the tailpipe downstream of the cat cracker:
Sienna Bank 1 Sensor 2 – in place
The OEM sensor cable runs in a sheath held to the chassis with a plastic clamp:
Sienna Bank 1 Sensor 2 – cable clamp
Jamming a small screwdriver into the clamp released the tongue and the sheath. The sheath vanishes into the van’s interior through a squishy rubber boot, with a crimped metal band joining the two:
Sienna Bank 1 Sensor 2 – floor boot
Internet lore would have you believe you can replace the sensor without removing the front passenger seat, but it’s much easier if you remove the four bolts, disconnect the seat sensor, and lay the seat on its back:
Sienna Bank 1 Sensor 2 – interior connector
More fiddly-diddly with the screwdriver under the van wrecked the band enough to separate sheath from boot, at which point deploying the BFW with the magic oxygen sensor socket showed that the anti-seize compound on the sensor’s thread worked as intended: after one oomph the sensor turned out by hand.
Then you just punch the boot through the floor and bring it all inside to splice new sensor onto OEM connector. Standardization is a wonderful thing; the sensor cable may use any one of eight color codes. The Toyota OEM sensor was a “Type B” that matches up with the Bosch replacement sensor thusly:
Heater = two black leads ↔ two white leads
Signal = blue lead ↔ black lead
Ground = white lead ↔ gray lead
Although the splice block has water-resistant seals, I figured putting it inside the van couldn’t possibly be a Bad Idea, so there it is, nestled snugly into the recess in the floor:
Sienna Bank 1 Sensor 2 – splice block
Picked up a nice new Autel AL519OBD Code Scanner from the usual Amazon vendor, reset the trouble code, drove to-and-from Squidwrench (across the river, just barely far enough to reset the performance data), and so far it’s All Good. The motivation for getting my very own scanner, rather than returning to Autozone, is that the AL519 can do real-time graphing and data capture from various sensors, so I can perform Science! should the spirit move me.
The AL519 has a USB connection that appears as a USB serial device but, alas, the relentlessly Windows-centric host program won’t run under Wine.
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.