Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
Based on the discussion attached to the post on Z axis numbers, I wanted to take a look at the points where Marlin switches from one step per interrupt to two, then to four, just to see what the timing looks like. The RAMBo board has neatly labeled test points, to which I tack-soldered a pin for the scope probe poked through one of the ventilation slots, and an unused power connector on the left edge of the PCB that provided a ground point (admittedly, much too far away for good RF grounding, but it suffices for CMOS logic signals). The Tek Hall-effect current probe leaning in from the top right captures the current in one of the X axis windings:
X axis Step and Current probes
I’ve reset the Marlin constants based on first principles, per the notes on distance, speed, and acceleration, so they’re not representative of the as-shipped M2 firmware. Recapping the XY settings:
Distance: 88.89 step/mm
Speed: 450 mm/s = 27000 mm/min
Acceleration: 5000 mm/s2, with the overall limit at 10 m/s2
The maximum interrupt frequency is about 10 kHz and the handler can issue zero, one, two, or four steps per axis per interrupt as required by the speed along each axis, up to a maximum of step rate of 40 kHz. There are complexities involved which I do not profess to understand.
The maximum 10 kHz step rate for one-step-per-interrupt motion corresponds to a speed of:
112.5 mm/s = (10000 step/s) / (88.89 step/mm)
The maximum 40 kHz step rate produces, naturally enough, four times that speed:
450 mm/s = (40000 step/s) / (88.89 step/mm)
Assuming constant acceleration, the distance required to reach a given speed from a standing start or to decelerate from that speed to a complete stop is: x = v2 / (2 * a)
The time required to reach that speed is: t = v/a
Accelerating at 5000 mm/s2:
112.5 mm/s = 6700 mm/min → 1.27 mm, 22.5 ms
150 mm/s = 9000 mm/min → 2.25 mm, 30 ms
450 mm/s = 27000 mm/min → 20.3 mm and 90 ms
An overview of a complete 6 mm move at 150 mm/s shows the acceleration and deceleration at each end, with a constant-speed section in the middle:
X Axis 150 mm-s 6 mm – overview
The bizarre patterns in the traces come from hp2xx‘s desperate attempts to discern the meaning of the scope’s HPGL graphic data where the trace forms a solid block of color; take it as given that there’s no information in the pattern. I described the trace conversion process there.
The upper trace shows the X axis motor winding current at a scale of 500 mA/div, with far more hash than one would expect. The RAMBo drivers evidently produce much more current noise than the brick drivers I intend to use.
The lower trace is the X axis step signal produced by the Arduino microcontroller. You can barely make out the individual step signals at each end, but there’s not enough horizontal resolution to show them when the motor moves at a reasonable pace.
In round numbers, the acceleration and deceleration should require about 30 ms each. The overall move takes 63 ms, so the constant-speed section in the middle must be about 3 ms long. That’s probably not right…
Here’s a closer look at the step pulses as the motion starts from zero on the way to 150 mm/s:
X Axis 150 mm-s 6 mm – 1 ms-div 0 ms dly
Over on the right, the 5 kHz step rate after 8.5 ms suggests a speed of 56 mm/s and counting 28 pulses says it moved 0.32 mm. Plugging those numbers into the equations:
a = v/t = 6600 mm/s2
a = (2 * x)/t2 = 8900 mm/s2
It’s not clear (to me, anyway) whether:
The firmware accelerates faster than the alleged 5000 mm/s2 limit
It’s accelerating near the overall limit of 10000 mm/s2
The acceleration isn’t constant: starts high, then declines
The measurement accuracy doesn’t support any conclusions
I understand what’s happening
In order to see the double- and quad-step outputs, here’s a 50 mm move at 450 mm/s, with a 19 ms delay to the point where the interrupt handler transitions from single-step to double-step output:
X Axis 450 mm-s 50 mm – 200 us-div 19 ms dly
The interrupt frequency drops from just under 10 kHz to a bit under 5 kHz, with the doubled pulses about 16 μs apart. At the transition, the axis speed is 112.5 mm/s, pretty much as predicted.
If that’s the case, the overall acceleration to the transition works out to:
5800 mm/s2 = (113 mm/s) / (19.5 ms)
Delaying the traces to 41.9 ms after the motion starts shows the double-to-quad step transition:
X Axis 450 mm-s 50 mm – 100 us-div 41.9 ms dly
Once again, the pulse frequency drops from 10 kHz down to 5 kHz. The speed is now 225 mm/s, half the maximum possible speed, which also makes sense: at top speed, the pulses will be essentially continuous at 40 kHz.
The average acceleration from the start of the motion:
5300 mm/s2 = (225 mm/s) / (42.1 ms)
That implies the initial acceleration starts higher than the limit, but it evens out on the way to the commanded speed.
Those scope shots come from moving only the X axis. Moving both the X and Y axes, with Trace 1 now showing the Y axis output, for 50 mm at 450 mm/s, produces similar results; the Y axis output lags the X axis by a few microseconds:
XY 450 mm-s 50 mm – 100 us-div 19.5 ms dly
Once again, that’s at the single- to double-step transition at 19+ ms. The overall timing doesn’t depend on how many axes are moving, as long as they can accelerate at the same pace; otherwise, the firmware must adjust the accelerations to make both axes track the intended path.
None of this is too surprising.
For a motor running at a constant speed just beyond the single-to-double step transition at 112.5 mm/s or the double-to-quad transition at 225 mm/s, the rotor motion should have a 5 kHz perturbation around its nominal position: it coasts for nearly the entire period, then a pair of steps kicks it toward the proper position. At those transitions, the rotor turns at:
The perturbation should look like a 5 kHz oscillation (not exactly sinusoidal, maybe triangular?) superimposed on the nominal position, which is changing more-or-less parabolically as a function of time. I expect that the overall inertia damps it out pretty well, but I’d like to attach a rotary encoder to the motor shaft (or a linear encoder to the axis) to show the actual outcome, but I don’t have the machinery for that.
In any event, LinuxCNC’s step outputs should behave better, which is why I’m doing this whole thing in the first place…
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
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
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…
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
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
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
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 (ycleptextrusion 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
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)
Turns out that there’s no difference between the Mac and PC versions of the Logitech Dual Action Gamepad:
Logitech Dual Action Gamepads – Mac vs PC
I picked up a Mac version cheap from the usual eBay seller and discovered that LinuxCNC / HAL was perfectly happy. That wasn’t too surprising; they have the same model and part numbers. Most likely, the only difference was the CD and maybe the Quick Start Guide that I didn’t get in the opened retail box…
So now I have either a hot backup for the Joggy Thing or one for a different box.
Most likely, it was cheap because nobody wants a blue-and-black peripheral next to their shiny white Mac…
The best orientation for the Z-minimum switch seems to be slightly angled back:
M2 – Z min limit switch
I used an M4x0.7 socket head cap screw for the height adjustment, with a Nylock nut below the stage:
M2 – Z min limit screw
The assembly instructions show a hex head screw, but the item numbers don’t match the BOM listings. The SHCS lets me hold it firmly in position with the ball-end driver provided in the M2 tool kit while adjusting it:
1/4 turn (the handle is square-ish) = 0.7/4 = 0.175 mm
1/6 turn (the shaft is hex) = 0.12 mm
1/12 turn (you can do it!) = 0.06mm
less than that is probably fooling yourself.
I printed a pair of tomlombardi’s 7 mm wrenches, which work well for adjusting the Nylock nut underneath the Z axis stage:
M2 – 7 mm wrenches
The left end of the top wrench didn’t adhere to the glass plate, but the business end of the wrench came out OK.
I adjusted the screw to trip the switch with the nozzle 1.0 mm above the platform, then feed that offset in using a G92 Z1.0 instruction in my customized Start G-Code.
However, the most accurate way to set the switch height involves measuring the as-printed thickness of the skirt extrusion around the object. The average value should be 0.25 mm (for my current slic3r settings, anyhow) and all sides should be equally thick: adjust the screw to change the average and adjust the platform screws to remove any tilt. You’ll quickly accumulate a pile of skirt threads, but they make good tchotchkes when you give a presentation on your new toy:
M2 skirt extrusions
You could fiddle with the G92 value to make the average thickness come out right, but I favor making the machine as accurate as possible, so that the software begins from a known-good mechanical setting.
set port /dev/ttyACM0
set baudrate 115200
set build_dimensions 200x240x195-100-120+0
set temperature_abs 200
set last_bed_temperature 70.0
set last_temperature 155.0
set xy_feedrate 30000
set z_feedrate 2500
set e_feedrate 300
set last_file_path /mnt/bulkdata/Project Files/Thing-O-Matic/Calibration
set temperature_pla 165
set preview_grid_step1 10
set preview_grid_step2 20.0
set preview_extrusion_width 0.4
set bedtemp_pla 70
Line 3 sizes the preview and offsets the XY=0 origin to the center of the plot.
The 200 mm X axis dimension is slightly larger than the actual 195 mm buildable area on the platform, but if the object gets that close to the maximum size, this isn’t the place to discover it.
The 240 mm Y axis dimension is slightly shorter than the actual 250 mm buildable area and slightly larger than the distance between the snouts of the bulldog clips holding the glass plate to the heater. In this case, the object can slightly exceed the preview size if it fits between the clips.
Lines 12 and 13 produce a relatively coarse grid that’s both meaningful and easy on the eyes, with the XY dimensions in Line 3 producing a major grid line crossing at the origin where it should be:
The Smell of Molten Projects in the Morning 