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.

Category: Machine Shop

Mechanical widgetry

  • Capping a Sink Drain Pipe

    We put the new furnace (replacing the old one) closer to the wall with the flue pipe, displacing an ancient slop sink (which vanished from the end of the driveway in about an hour) in the process. I “plugged” the drain with a twist of paper towel until the installation was done:

    Corroded sink drain nut
    Corroded sink drain nut

    The overexposed blue-hot glow comes from the LED worklight on the right.

    Despite being chrome-plated brass, the nut at the base of that vertical chrome pipe was firmly corroded to the short nipple emerging from the iron tee. After a few minutes of fruitless wrenching, I deployed a Dremel cutting wheel, slit the nut, gave it a shot with a chisel, and it popped loose. A rubber cap clamped around the nipple finished the job:

    Sealed sink drain pipe with split nut
    Sealed sink drain pipe with split nut

    Next case!

  • Arduino Leonardo + TC4 Thermocouple Shield + TC4 Server

    Because I want to measure several fairly high temperatures in and around the extruder with the LinuxCNC controller for the M2, I need a multi-channel thermocouple input. LinuxCNC’s hal_input interface module exposes the values produced by USB HID peripherals as HAL pins, which seems to be a nice way to add devices. A bit of searching revealed the TC4 Arduino Shield four-channel thermocouple + four-channel thermistor + assorted I/O board produced by the homeroasters.org folks as part of their DIY coffee roast controller.

    The gotcha: ordinary Arduino boards cannot (without extraordinary effort) become USB HID peripherals, as their USB interface works only as a serial data device. The solution: the new-ish Arduino Leonardo has an on-chip USB interface that can act as a USB HID peripheral as well as the usual serial device.

    Dan Newman, of Sailfish firmware fame, conjured up an a Arduino program (which, IMO, is far more complex than a mere sketch) that provides both a human-readable terminal interface and a LinuxCNC HAL-compatible USB HID interface using the Leonardo’s USB capabilities; the TC4Server project repository is on my GitHub account to keep it close to all the other stuff that should appear over the course of this project. His firmware builds on the libraries for the homeroaster’s tc4-shield Google Code project, but is intended for use with LinuxCNC, rather than as part of an Arduino controller.

    It’s worth noting that the Leonardo has a mere 32 kB of program storage, so the extensive help documentation built into the program helped prevent feature creep.

    Although I’m not yet using LinuxCNC with the M2, I can use TC4-Server’s serial terminal interface to read four channels of thermocouple data to help figure out what’s going on with the M2’s extruder thermistor. The TC4 shield has screw terminals for the thermocouples, but I also added a Proto ScrewShield board for thermistor resistors and easier connections:

    TC4 on ProtoScrewShield on Leonardo
    TC4 on ProtoScrewShield on Leonardo

    The TC4 Shield PCB layout assumes it’s being used with the original Arduino series of boards that bring the I2C (aka I2C, IIC, etc) SDA and SCL signals out on the A4 and A5 analog input pins, respectively. The newer Leonardo board brings SDA and SCL out in a separate header, so you must hotwire them across the board. The green and blue wires (stripped from a ribbon cable) accomplish that purpose: they’re plugged into the new Leonardo header through bent male header pins and clamped into the ScrewShield terminals. This assumes the Leonardo’s A4 and A5 pins remain as inputs, which is true for Dan’s firmware. If you actually need those pins for analog inputs, then you must remove the header pins that interconnect the boards and hotwire directly to the TC4 headers.

    The TC4 shield includes an on-board temperature sensor that serves as the thermocouple cold-junction compensation reference. In my simple tests, the board has about 1 °C of self-heating, so I also use it to report the ambient temperature.

    With all that in hand, I connected the thermocouple epoxied to the M2’s nozzle to the TC4 and re-ran the previous test with the modified thermistor table:

    Rescaled extruder - thermocouple in TC4 board
    Rescaled extruder – thermocouple in TC4 board

    The TC4 shield produces the same result as the Fluke meter with the same thermocouple, so we know those results will be consistent.

    The modified thermistor table produces results that overlay thermocouple data. The questions come down to the accuracy of the thermocouple and whether bending the thermistor table actually represents an inherent property of the thermistor or just compensates for another problem.

    Part of my motivation for using thermocouples, rather than thermistors, is that thermocouples avoid the whole dance of matching a given thermistor with a set of properties. Given the uncertain provenance of most thermistors, I have no reason to believe any of them match their alleged datasheets…

  • Makergear M2: Thermistor vs. Thermocouple

    With the stock thermistor and my added thermocouple epoxied to the M2’s nozzle, I stepped the temperature upward, let it settle, and recorded the temperature from the Pronterface status display and my Fluke thermocouple meter:

    First Heat - M2 thermistor - Fluke with thermocouple
    First Heat – M2 thermistor – Fluke with thermocouple

    Because the firmware servos the temperature through the stock thermistor, that line is dead straight at the exact setpoint values: the reference never disagrees with itself. The thermocouple, however, reads low by about 12%: according to it, the nozzle runs much cooler than the thermistor value.

    Huh?

    Several explanations come to mind:

    • The firmware is using a lookup table that doesn’t match the thermistor
    • The Fluke thermocouple meter reports the wrong value
    • The thermocouple junction is defective
    • Despite the epoxy blob, the two sensors aren’t at the same temperature
    • Something else is kaflooie

    This obviously calls for more data…

  • Makergear M2: Nozzle Temperature Sensing

    The stock Makergear M2 hot end uses a 100 kΩ thermistor for temperature sensing. A wrap of Kapton tape holds it against the brass nozzle, with a stretchy fiberglass-lined tube for protective insulation and a bit of pressure. This picture shows the tape pocket around the thermistor, with my thumbnail on the left:

    M2 Nozzle Thermistor - as-shipped
    M2 Nozzle Thermistor – as-shipped

    Peeling back the tape a bit shows the thermistor against the nozzle, with the glass bead reflecting the LED ringlight around the macro lens adapter:

    M2 Nozzle thermistor - exposed
    M2 Nozzle thermistor – exposed

    The RAMBo board in the M2 has four thermistor inputs and no thermocouple inputs, which surely drove the decision to use themistors. I want to use thermocouples with the LinuxCNC controller, because they’re more compact and happier at higher temperatures.

    So I unwrapped the nozzle and lined up a thermocouple beside the thermistor:

    M2 - extruder - thermistor-thermocouple
    M2 – extruder – thermistor-thermocouple

    Where a dab of JB Weld firmly bonds them to the nozzle:

    M2 - extruder - epoxied sensors
    M2 – extruder – epoxied sensors

    As nearly as I can tell, the JB Weld that I used on the Thing-O-Matic is still going strong. I think the trick is to not apply mechanical force to the bond when it’s hot; secure the leads firmly and use the epoxy only as a thermal connection. Yes, you can get fancy higher-temperature adhesives, but this seems to work well enough.

    For the moment, I’m using ordinary cotton cloth secured with Kapton tape as insulation:

    M2 - extruder - cotton insulation
    M2 – extruder – cotton insulation

    The brown dot that looks like a bead is actually a flat stain on the nozzle.

    The insulation should become something more suited for high temperatures, perhaps the ceramic fiber I used on the Thing-O-Matic, but cotton will suffice for now.

    Now, wisely is it written that a man with one thermometer knows the temperature, while a man with two thermometers is never certain…

  • M2 vs. Marlin: Acceleration

    Three firmware constants (seem to) control the acceleration applied to each axis, presented here in their original form:

    #define DEFAULT_MAX_ACCELERATION      {9000,9000,30,10000}    // 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          3000    // X, Y, Z and E max acceleration in mm/s^2 for printing moves
    #define DEFAULT_RETRACT_ACCELERATION  3000   // X, Y, Z and E max acceleration in mm/s^2 for r retracts
    

    I do not pretend to understand their interaction and, pursuant to that discussion, some tests and measurements seem to be the only way to find out what’s happening. However, estimating some masses and guesstimating motor performance can put some boundaries on the problem.

    Based on weighing a slightly larger stepper motor and the hot end, the complete extruder assembly may weigh (OK, mass) about 600 grams, which I’ll round up to 1 kg to cover bending the filament guide tube and friction. In order to accelerate the extruder carriage at 9000 mm/s^2, the X axis stepper motor force must be:

    F = ma = 1 kg * 9 m/s2 = 9 N

    The pulley drives 36 mm of belt per revolution, so the effective diameter = 11.5 mm and the radius = 5.7 mm. That means the motor torque will be:

    50 mN·m = 9 N * 5.7 mm

    I don’t have specs for the Makergear motors, but similar motors have pull-in torques in the 200 to 300 mN·m range, which is flat out to 1000 (full)step/s and decreases to zilch as the speed approaches 10000 (full)step/s. Because the motors run in 1/16 microstep mode, Marlin’s peak 40000 (micro)step/s rate works out to 2500 (full)step/s, where the motor pull-in torque is maybe half of the maximum.

    The motor pull-out torque falls off to nothing around 1000 (full)step/s = 16000 (micro)step/s, which suggests you can’t slow the stages down nearly as fast as you speed them up, at least beyond about 10000 (micro)step/s.

    All of that depends on the motor current, of course, and that depends on the amount of heat you’re willing to generate in the motors. I really must build a better dynamometer.

    Assuming the Y stage + heater + glass weighs 4 pounds = 2 kg, the numbers are twice as large, but they’re in the same ballpark.

    I tried a few values for the Z acceleration and settled on something slightly larger, but that won’t apply to a different motor.

    I have no way to estimate the force required to drive the filament, but the gearbox multiplies the motor torque by a factor of 5, so there’s a speed-torque tradeoff lying in wait.

    I modified the acceleration constants to bring the overall limits in line with the per-axis values:

    #define DEFAULT_MAX_ACCELERATION      {9000,9000,75,10000}
    #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 r retracts
    

    Changing the last two values from 3000 to 10000 produced a dramatic increase in acceleration, so those numbers do act as overall limits on the per-axis values in the first line.

    Because the motion planner ramps the velocity up at the maximum possible acceleration (reduced, as needed, to accommodate the motor with the lowest acceleration involved in the motion), higher acceleration values allow the motor to reach the desired speed sooner, so shorter motions run faster.

    For example, reaching 200 mm/s2 from a standing start requires 6.7 mm at 3000 mm/s2 and 2.2 mm at 9000 mm/s2. Braking to a stop requires the same distance, assuming the pull-out torque allows it. Contemporary motion planners that can match velocities around corners where straight-line segments join will allow higher sustained speeds, so they don’t require slowing to a dead stop.

    But, of course, the 3D printer’s overall structure must be rigid enough to restrain the reaction forces caused by high accelerations and the printer must be anchored well enough to not sidle off the table. The M2 can handle a single high-speed move, but chaining multiple moves together shakes the steel chassis rather violently; that happens when you select the Slic3r “Avoid crossing perimeters” option.

  • M2 vs. Marlin: Speed Calculations

    Knowing the number of motor steps required to move an axis by 1 mm, the next step is to figure out how fast each axis can possibly move, given the restrictions of the Marlin firmware driving the motors.

    Dan Newman pointed out that Marlin runs with a maximum 10 kHz interrupt rate, with up to four steps issued per interrupt. The constant controlling (or at least defining) that is in Configuration_adv.h (with a comment that seems irrelevant to the M2’s setup):

    #define MAX_STEP_FREQUENCY 40000       // Max step frequency for Ultimaker (5000 pps / half step)
    

    Below the 10 kHz rate, the step interrupt occurs whenever the next step must happen, so it does not have a constant frequency. Above 10 kHz, the steps (seem to) emerge in bursts, so there’s likely a good bit of jitter that I should measure. In any event, there’s an obvious loss of resolution at high speeds, which is a problem common to all variable-frequency pulse generators that’s worse for relatively low-frequency software generators used in high-speed applications.

    In any event, these numbers show the absolute maximum possible speed for each axis:

    • X and Y axes: 450 mm/s = (40 k step/s) / (88.89 step/mm)
    • Z axis: 100 mm/s = (40 k step/s) / (400 step/mm)
    • Extruder: 94.3 mm/s = (40 k step/s) / (424.4 step/mm)

    Due to the low torque available from the Z axis motor, the actual maximum speed seems to be around 30 mm/s = 1800 mm/min. After I replace the motor, I’ll measure the actual performance and see what’s reasonable.

    One could quibble about the extruder, as the extrusion multiplier affects the final speed. The extruded thread squirts out at a pretty good clip if the motor turns at full speed:

    2350 mm/s = (1.75 mm)2 / (0.35 mm)2 * 94 mm/s

    It’s not clear the hot end can melt plastic fast enough to keep up with that pace more than momentarily, but I haven’t measured that yet.

    However, if the X and Y axes both move at 450 mm/s, then the nozzle moves at 640 mm/s = √2 * 450 mm/s relative to the platform, so the maximum extruder speed while printing will be roughly:

    26 mm/s = (640 mm/s) * (0.35 mm)2 / (1.75 mm)2

    That assumes the printed thread has the same cross-section area as the nozzle, which is roughly true for my choice of output:

    • Thread: 0.1 mm2 = 0.4 mm wide * 0.25 mm thick
    • Nozzle: 0.096 mm2 = pi * (0.35 mm)2 / 4

    If you bake the extrusion multiplier into the step/mm value, then compute the maximum speed without applying the same multiplier in slic3r, the plastic should come out of the nozzle at the same speed.

    So the speed setup looks like this:

    #define DEFAULT_MAX_FEEDRATE          {450, 450, 30, 94}    // (mm/sec)
    
  • M2 vs. Marlin: Step/mm Calculations

    After Dan Newman nudged me a bit in the comments to the Z axis calculations, I walked through the constants in Marlin’s Configuration.h file to see if they were all consistent. The earlier values sufficed to get going, but a bit of pondering suggested some tweaks.

    The motor microstepping mode determines the number of (micro)steps per motor (single)step:

    #define MICROSTEP16
    

    That single constant implies all motors must run in the same microstepping mode. Typical stepper motors have 200 full step/rev = 1.8°/step, so 1/16 microstepping means 3200 step/rev.

    However, each motor can have a different “gear” ratio that converts from motor rotation to linear distance, so you must measure or calculate the actual values.

    For the X and Y axes, the motor pulleys have 18 teeth and the belt pitch is 2 mm/tooth, so one motor revolution drives the belt:

    36 mm = 18 teeth * 2 mm/tooth
    M2 - X axis motor pulley
    M2 – X axis motor pulley

    Each revolution requires 3200 steps, so the X and Y stages move at:

    88.888 step/mm = 3200 step / 36 mm

    Makergear uses 88.88 step/mm, rather than the rounded 88.89, but the difference across 250 mm amounts to 2.5 steps, so it doesn’t matter.

    For the Z axis, the four-start leadscrew moves the stage 8 mm, so:

    400 step/mm = 3200 step / 8 mm
    M2 Z axis bearing - shimstock bushing
    M2 Z axis bearing – shimstock bushing

    The situation with the extruder drive isn’t quite so clear, because the actual filament movement depends on the effective diameter of the drive pulley’s teeth engaging the filament. Mechanically, the extruder motor runs a 5:1 gearbox, so each drive pulley rotation requires 16000 (micro)steps.

    The filament drive pulley has 22 teeth and a 12.0 mm OD = 37.7 mm circumference:

    424.4 step/mm = 16000 step / 37.7 mm
    M2 - Filament Drive Gear
    M2 – Filament Drive Gear

    That’s measured at the tooth tip. If you think of the filament as being a belt, then you’d expect it to move precisely that distance… except that the teeth dig into the filament, so the effective diameter comes out a bit smaller and the step/mm value a bit higher.

    Makergear’s default 471.5 step/mm is, indeed, larger, but the ratio of the two values seems both oddly familiar and eerily exact:

    0.900 = 424.4 / 471.5

    The “packing density” Fudge Factor (yclept extrusion multiplier by slic3r) that accounts for the difference between the drive gear OD and the actual filament motion runs around 0.9, with passionate arguments justifying more specific values. It looks like Makergear baked that number into the firmware, so the nominal slic3r extrusion multiplier should be pretty close to 1.0.

    After a few quick measurements while getting the printer running, I settled on extrusion multiplier = 0.9, so the actual step/mm value in effect for the extruder works out to:

    424.4 = (471.5 step/mm) * 0.9

    Now, that would seem to imply that the filament skates along the top of teeth, but that’s not the case:

    M2 extruder - filament embossing
    M2 extruder – filament embossing

    So, for whatever reason, the effective diameter of the drive pulley matches its actual OD. That will surely vary with a number of imponderables, including the setting for the clamp screw holding the bearing against the filament and drive pulley.

    Being that type of guy, I favor baking the actual drive pulley OD into the firmware (because I can actually measure that value), then using the extrusion multiplier to account for the difference. I’ve heard cogent arguments to the contrary, but, for my purposes, the proper value for the extruder should 424.4 step/mm, with a corresponding extrusion multiplier change to 1.00 in slic3r’s configuration.

    I wouldn’t be surprised in the least to discover:

    • I’m multiplying where I should be dividing (or the other way around)
    • There’s a squaring / rooting operation hidden somewhere in there (area vs length)
    • Another obvious blunder has tripped me up

    Selah.