The Smell of Molten Projects in the Morning
Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
Electrical & Electronic gadgets
The garage door opener just ate another rough-duty bulb, so let’s see how a $7 LED bulb fares:
It has no external heatsink fins and the color temperature looks just like the old-school incandescent bulb it’s replacing, so they’re getting a clue about what’s acceptable to ordinary folks.
That’s equivalent to a 60 W incandescent bulb, too, at least according to the package:
I love the “Return the package and reciept for replacement or money back” part…
I installed the 24 V white LED panels under the M2’s X-axis gantry, connected it to a 24 V wall wart, and all was good:
The red plastic block shows that picture happened before the V4 hot end installation…
Now, with the V4 hot end and fans installed, I popped a 24 V supply brick off the heap and connected another set of Powerpoles:
The 24 V supply now powers everything on the RAMBo board, with the platform heater running from the 40 V supply through the DC-DC solid state relay.
Unfortunately, wiring the LED panels to the RAMBo MOSFET driving the fans didn’t quite work. Turns out that the extruder PWM pulses produce corresponding LED blinks; the V4 hot end draws 1.5 A and that’s enough to flicker the lights. So they’re back on the wall wart and glow steadily again.
For whatever it’s worth, the panels don’t have limiting resistors, just eight 150 mA LED emitters in series…
Given that I’m throwing all the balls in the air at once:
It seemed reasonable to start with the current Marlin firmware, rather than the MakerGear version from long ago. After all, when you file a bug report, the first question is whether it happens with the Latest Version.
Marlin has undergone a Great Refactoring that moved many of the constants around. I suppose I should set up a whole new Github repository, but there aren’t that many changes and I’ve gotten over my enthusiasm for forking projects.
Anyhow, just clone the Marlin repo and dig in.
In Marlin_main.cpp, turn on the Fan 1 output on Arduino pin 6 that drives the fans on the extruder and electronics box:
pinMode(6,OUTPUT); // kickstart Makergear M2 extruder fan digitalWrite(6,HIGH);
You could use the built-in extruder fan feature that turns on when the extruder temperature exceeds a specific limit. I may try that after everything else works; as it stands, this shows when the firmware gets up & running after a reset.
In Configuration_adv.h, lengthen the motor-off time and set the motor currents:
#define DEFAULT_STEPPER_DEACTIVE_TIME 600
#define DIGIPOT_MOTOR_CURRENT {185,215,185,185,135}
The Configuration.h file still has most of the tweaks:
#define STRING_CONFIG_H_AUTHOR "(Ed Nisley - KE4ZNU - Hotrod M2)"
#define STRING_SPLASH_LINE2 STRING_VERSION_CONFIG_H
#define BAUDRATE 115200
#define MOTHERBOARD BOARD_RAMBO
#define TEMP_SENSOR_0 1
#define TEMP_SENSOR_BED 1
#define HEATER_0_MAXTEMP 290
#define HEATER_1_MAXTEMP 290
#define HEATER_2_MAXTEMP 290
#define HEATER_3_MAXTEMP 290
#define X_MAX_POS 136
#define X_MIN_POS -100
#define Y_MAX_POS 125
#define Y_MIN_POS -127
#define Z_MAX_POS 175
#define Z_MIN_POS 0
#define HOMING_FEEDRATE {75*60, 75*60, 30*60, 0}
#define DEFAULT_AXIS_STEPS_PER_UNIT {88.88,88.88,400,424.4}
#define DEFAULT_MAX_FEEDRATE {450, 450, 100, 94}
#define DEFAULT_MAX_ACCELERATION {5000,2500,2000,10000}
#define DEFAULT_ACCELERATION 10000
#define DEFAULT_RETRACT_ACCELERATION 10000
I missed the max & min position settings on the first pass (they’re new!), which matter because I put the origin in the middle of the platform, rather than the front-left corner. Marlin now clips coordinates outside that region, so the first thinwall calibration box only had lines in Quadrant 1…
So the ancient Dell E1405 laptop on the Electronics Bench, connected to this-and-that, woke up without network connections. As in, right after booting, the link and activity lights jammed on solid, the usual eth0 device wasn’t there, WiFi was defunct, and nothing made any difference.
After a bit of searching, the best summary of what to do appears on the Ubuntu forums. The gist of the story, so I need not search quite so much the next time, goes like this:
The laptop uses the Broadcom BCM4401 Ethernet and BCM4311 WiFi chips, which require the non-free Broadcom firmware found in the linux-nonfree-firmware package. There’s a proprietary alternative in bcmwl-kernel-source that apparently works well for most Broadcom chips, but not this particular set.
Guess which driver installed itself as part of the previous update?
The key steps:
sudo apt-get purge bcmwl-kernel-source egrep 'blacklist (b43|ssb)' /etc/modprobe.d/* ... then manually kill any files that appear ...
Apparently that problem has been tripping people for at least the last four years. That this is the 14.04 Long Term Support version evidently has little to do with anything at all.
While I was at it, I deleted all the nVidia packages that somehow installed themselves without my noticing; the laptop has Intel 945 integrated graphics hardware.
I vaguely recall what I intended to do before this happened…
The Dell 2005FPW monitor that I’d been using in portrait mode suffered the common failure of rebooting itself, which suggested failing capacitors. Despite my reservations, I dropped eleven bucks on a repair kit containing exactly the right caps (from sunny California via eBay), hauled the carcass to a couple of Squidwrench sessions, replaced the offending caps, and it’s all good again.
No pix of the recapping, but a few notes that may prove useful next time.
The standard advice from the usual Internet Sages recommends prying the bezel apart along the nearly invisible outside joint. I did that, then found the user manuals and the Fine Repair Manual and discovered that you jam your fingernails under the inside of the bezel against the LCD screen, pry upward, rotate / bend the bezel around its outer edge, and it Just Pops Off. I doubt it’s that easy, but …
You should start from the top of the bezel, because the PCB behind the buttons & LEDs along the bottom doesn’t have a whole lot of slack in its cable. This shows the PCB and disconnected cable:
Just pull the small brown latch away from the cable and the cable will slide out. That would be significantly easier if the socket were on the backside of the PCB, but you must pop the PCB out of its own latches before you get access to the socket latch. Rotate the bezel carefully around the PCB and maybe it’ll survive.
The pushbutton that releases the stand’s not-quite-a-VESA-mount bracket remains in place when you remove the rear cover, held in place by a wedge:
It is, however, the only thing sticking that far out of the back surface and, if you leave it alone, it will eventually release itself from captivity, whereupon its spring will fire it across the room. You have been warned.
Reassembly is in reverse order, although I didn’t snap the button-and-LED PCB firmly into place. Fixing that will require dismounting the bezel again, which I’m so not doing for a 1 mm gap along the bottom edge.
Part of the flailing about while working around the Ubuntu video driver update glitch included blindly swapping a Displayport cable, which triggered another failure after everything settled down: the (empty) DVD drive’s activity light remained dimly lit with the PC off and both monitors in power-save mode. Unplugging the PC’s power cord extinguished all the internal LEDs on the system board, but left the drive light shining the same dim green. Disconnecting the USB cables to the monitors (they both have USB hubs) had no effect. Unplugging the monitors extinguished the LED after a bit. Unplugging one of the Displayport cables turned it off instantly, which was a clue that took a while to recognize.
Worse, the landscape monitor, a year-old Dell U2711, now refused to wake up from power-save mode during boot, even when it was the only monitor connected to the PC. Searching with an assortment of relevant keywords produced several interesting results, including a lengthy Dell support forum thread, all suggesting a deeper and surprisingly longstanding problem with Displayport connections on big Dell monitors.
I knew most of the remedies weren’t relevant, because this failure happened while the BIOS felt around to identify the monitors: not a driver issue (not in effect yet), not a Windows issue (fer shure!), not a Linux issue, and not a BIOS configuration issue (nothing changed, plus Dell doesn’t allow much configuration).
It turns out that the original pair of Displayport cables bore Amphenol logos on the connector shells and cable. One of the replacements was a Genuine eBay cable from halfway around the planet, bearing no markings of any sort. Given the hints in those search hits, I discovered that the Amphenol-branded cables did not carry pin 20 between the connectors, but the eBay cables did: just a little something extra from eBay!
Installing the two Amphenol cables extinguished the DVD drive light by preventing the monitor standby power from backfeeding the PC through the video card and the monitor woke up correctly on the next two boots. Whether that will permanently cure the startup problem remains to be seen, as it was somewhat intermittent with the wrong cable and the forum threads suggest that the monitor will continue to work for a while before failing again.
While pondering all that, I severed the pin 20 connection in one of the eBay cables, just to have a different cable in hand. This diagram from the Wikipedia article, with pin 20 highlighted, shows it sitting under the longer blank section above one of the keys:
The connector shell has snap latches that succumb to gentle prying with a razor knife, revealing the hot-melt-glue potted interior, with the orange wire snaking away from pin 20 at the top of the other side:
One snip, a bit of prying to extract the end from the glue, and it’s ready to be buttoned up again:
Both Amphenol cables and the modified eBay cable now have labels noting that they do not connect pin 20. We’ll see if that makes any difference…
Adjusting the output voltage vs. position for the sewing machine’s food pedal quickly revealed that the code shouldn’t depend on the actual ADC values. That’s blindingly obvious in hindsight, of course.
The maximum with the pedal in its overtravel region doesn’t change by much, because the Hall effect sensor output voltage saturates in a high magnetic field. I used a hardcoded word PedalMax = 870; which comes from 4.25 V at the ADC input.
On the low end, the sensor output can change by a few counts depending on small position changes, so I sampled the (presumably released) pedal output during the power-on reset:
PedalMin = ReadAI(PIN_PEDAL); // set minimum pedal input value
printf("Set PedalMin: %u\r\n",PedalMin);
PedalMaxClamp = 100; // set upper speed limit
Given the complete ADC range, this function normalizes a value to the range [0,100], conveniently converting the pedal position into a percent of full scale:
int PedalPercent(word RawPos) {
int Clamped;
Clamped = constrain(RawPos,PedalMin,PedalMax);
return map(Clamped,PedalMin,PedalMax,0,100);
}
Graphing the normalized values against pedal position would have the same shape as the ADC values. All I’m doing is rescaling the Y axis to match the actual input limits.
The top of the main loop captures the pedal position:
PedalADC = ReadAI(PIN_PEDAL); PedalPosition = PedalPercent(PedalADC);
Now, it’s easy to add a slight deadband that ensures the sewing machine doesn’t start when you give the pedal a harsh look; the deadband is now a percent of full travel, rather than a hard-coded ADC count or voltage.
For example, in needle-follows-pedal mode, you must press the pedal by more than 10% to start the stitch, slightly release it to finish the stitch, and then almost completely release it to proceed to the next stitch:
case PD_FOLLOW:
if (PedalPosition > 10) {
printf("Pedal Follow\r\n");
ParkNeedle(NS_DOWN);
do {
PedalPosition = PedalPercent(ReadAI(PIN_PEDAL));
} while (PedalPosition > 10);
ParkNeedle(NS_UP);
do {
PedalPosition = PedalPercent(ReadAI(PIN_PEDAL));
} while (PedalPosition > 2);
}
break;
Adjusting percentages turns out to be much easier than fiddling with ADC values.
Obvious, huh?
The Smell of Molten Projects in the Morning 