Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
After adding F feed speed parameters to all the G0 commands in my start.gcode (to work around that bug), I decided to use the new-with-firmware-2.8 feature that stores the home offsets in the Thing-O-Matic’s EEPROM. That turned out to be, one might say, a thinly documented feature, so this may be a useful summary…
The Official Way to set the EEPROM, which you can find in ReplicatorG/scripts/calibration/Thing-O-Matic calibration.gcode, goes a little something like this:
Manually position the nozzle dead center on the build plate, just touching the surface
Use G92 to set all axes to 0.0
Home the axes to the switches
Use M131 X Y Z A B to store the current values in EEPROM
Having already found good values for those offsets as part of the aluminum build plate adventure, I jammed them into EEPROM using RepG’s Machine→Motherboard Onboard Preferences. The values I’m using are:
X = -53.0
Y = -59.0
Z = 116.0
For some unknown reason that has nothing to do with floating point representation (I mean sheesh even the 32-bit version of IEEE 754 floating point has at least 10 decimal digits of precsion), RepG modifies only the negative values sufficiently to be bothersome:
X = -52.964
Y = -58.976
Having stored the offsets, I wondered how to fetch them. That is also, of course, completely undocumented, but I eventually traced down the answer in (deep breath)
That’s not true for all the start.gcode files you might find, though, and there are many such in far more obvious places.
So, OK, I fetch the EEPROM coordinates using M132 after doing both the coarse home (they’ll be pretty close) and the fine home (they’ll be dead on, modulo the changes), then wipe the nozzle and poke the Z-minimum height switch (which is why I really really care about random changes in the stored values) to find the actual height above the aluminum build surface.
At exactly this position it would be nice to set only the Z height to the actual switch thickness, but G92 sets all un-mentioned axes to zero, so you can’t set just one axis. I have no idea how M131 and M132 behaves in that regard; none of this stuff is documented anywhere that I can find and this stopped being funny a while ago.
So, knowing the XYZ coordinates of the switch, I reset the XYZAB axes using G92.
The current working start.gcode that I devoutly hope will continue to work for a while:
(---- start.gcode begins ----)
(MakerBot Thing-O-Matic with aluminum HBP and Z-min platform switch)
(Tweaked for TOM 286 - Ruttmeister MK5 stepper extruder mod)
(Ed Nisley - KE4ZNU - July 2011)
(Hack to work around bad G0 speed)
(- set initial conditions)
G21 (set units to mm)
G90 (set positioning to absolute)
(- begin heating)
M104 S210 T0 (extruder head)
M109 S110 T0 (HBP)
(- coarse home axes)
G162 Z F1000 (home Z to get nozzle out of danger zone)
G161 Y F4000 (retract Y to get X out of front opening)
G161 X F4000 (now safe to home X)
M132 X Y Z A B (fetch home offsets from EEPROM)
(- fine home axes)
G0 X-51 Y-55 Z114 F400 (back off switches)
G161 Y F200
G161 X F200
G162 Z F200
M132 X Y Z A B (fetch home offsets from EEPROM)
(- manual nozzle wipe)
G0 F6000 X0 Y0 Z10 (pause at center to build confidence)
G4 P500
G0 X40 Y-57.0 Z10 (move to front, avoid wiper blade)
G0 X56 (to wipe station)
G0 Z6.0 (down to wipe level)
M6 T0 (wait for temperature settling)
G1 Y-45 F1000 (slowly wipe nozzle)
(-----------------------------------------------)
(- Make sure the XY position matches the G92 )
(- home Z downward to platform switch)
G0 F6000 X56.4 Y7.6 Z3 (get over build platform switch)
G161 Z0 F50 (home downward very slowly)
G92 X56.4 Y7.6 Z1.60 (set Z height)
G0 F6000 Z6.0 (back off switch to wipe level)
(-----------------------------------------------)
(- start extruder and re-wipe)
G0 X56 Y-45 (set up for wipe from rear)
G1 Y-57.0 F1000 (wipe to front)
M108 R2.0 (set stepper extruder speed)
M101 (Extruder on, forward)
G4 P4000 (take up slack, get pressure)
M103 (Extruder off)
G4 P4000 (Wait for filament to stop oozing)
G1 Y-45 F1000 (slowly wipe nozzle again)
G0 F6000 X0 (get away from wiper blade)
(- build some pressure)
M108 R2.0 (set stepper extruder speed)
M101 (start extruder)
G4 P100 (run for a bit)
(---- start.gcode ends ----)
For what it’s worth, I put that file in the sf_40_alterations directory, blew away the previous versions in all the profiles, and replaced them with symlinks to that single file. When the next change comes along, I can modify one file and all the profiles will pick up the change at once.
Some simple measurements using that Pololu driver in its default mixed decay mode and that Arduino sync generator. The captions give the operating conditions; basically, I’m varying the rotation speed by cranking the signal generator driving the Pololu board.
At 1 rev/s, it’s about as good as it gets:
Back EMF – 9V 400mA 1 RPS
At 5 rev/s, the driver has trouble getting current out of the winding:
Back EMF – 9V 400mA 5 RPS
At 10 rev/s, things are getting ugly:
Back EMF – 9V 400mA 10 RPS
At 20 rev/s, the back EMF has pretty much taken control of the current and the driver is going along for the ride:
Back EMF – 9V 400mA 20 RPS
At 25 rev/s, the driver produces only occasional dents in the waveform:
Back EMF – 9V 400mA 25 RPS
At 25.3 rev/s, the motor stalled. Even with no back EMF (what with the rotor being stopped and buzzing in frustration), the driver can’t force the current to behave:
Back EMF – 9V 400mA 25.3 RPS
I don’t have any way to measure the motor’s output torque, but at 1500 RPM there won’t be any worth mentioning.
For what it’s worth, 25 rev/s means the driver is handling 40 k steps/sec = 25 µs/step. The motors in a Thing-O-Matic run at 3 rev/s to move the XY stages at 100 mm/s, so scale what you see here accordingly.
Printing went smoothly after two preliminary passes to work out the sizes and alignments; this is the second pass, which you can tell because the mirror shoulder has three supports instead of the two shown in the solid model:
Mirror mount parts on build plate
One view of the parts, with the mirror shaft in place:
Mirror mount partial assembly – top
Another view, showing the bottom of the Elevation Plate with the recessed nut:
Mirror mount parts partial assembly – bottom
Assembling the two glue joints required an overnight clamping:
Mirror mount – glued and clamped
Then a layer of double-stick foam tape affixes it firmly to the helmet:
Mirror mount – on helmet
It’s a bit too big and way ugly, but works pretty much as expected.
Two lengths of heatshrink tubing now lock the mirror shaft sections in place; they tended to rotate slightly under normal vibration.
The OpenSCAD code and model have a few modifications from this object. The next one won’t have the third section of mirror shaft, which makes the shoulder and Az Mount smaller, and the Az Mount is 1 mm closer to the El Body. That shaves a few millimeters off the whole thing.
The mirror clamp out there on the end is much too large and has too many fiddly parts. I think a little printed doodad would work, but that’s in the nature of fine tuning.
After a bit of OpenSCAD twiddling, those doodles turned into a printable model. This view shows what it looks like all neatly assembled:
The tiny hole on the top of the Elevation Body accepts a 2-56 setscrew that grabs the arc protruding from the Elevation Plate and locks the up-and-down setting. The Azimuth Mount pivots on the 3-48 screw holding it to the Elevation Mount.
Both of those pivots must be loose enough to move when you bump the mirror and tight enough to stay put in normal use. It’s a delicate balance and I’m not convinced this will work for the long term, but it’s a brassboard.
The 2-56 stud on the end of the mirror shaft screws into a socket in the rear side of the Az Mount. Another 2-56 setscrew in the Az Mount (facing the El Body), grabs the side of the shaft and prevents it from rotating.
The mirror shaft shoulder on the Az Mount (front center) sticks out in mid air and requires a little bit of support.
The El Mount (left rear) builds surprisingly well with its curved top surface downward. If it’s rotated 90 degrees with the curve facing to the left, Skeinforge grumps about not being able to do something or another and generates totally bogus G-Code.
The Helmet Plate has a 3 mm deep depression that more-or-less corresponds to the helmet’s surface. It’s gouged out by a huge sphere sitting on the plate, with a radius calculated from the measured helmet curvature.
The OpenSCAD source code has two useful parameters near the top:
Layout selects the overall appearance: Fit, Show, or Build
Examine selects a single part for inspection & tweakage
You’ll need the MCAD and Visibone libraries to make this work. It’s the original code, without the tweaks to the grid mentioned in the comments there:
This OpenSCAD module spreads an array of cubes across the otherwise featureless preview window, so I know whether the gizmo I’m building or the parts I’m arranging actually fit on the Thing-O-Matic’s build platform. This doesn’t get out to the very edge, but if it looks close, then I should pay more attention anyway.
module ShowPegGrid(Size) {
for (x=[-5:5])
for (y=[-5:5])
translate([x*10,y*10,Size/2])
cube(Size,center=true);
}
ShowPegGrid(1.0);
You obviously don’t want to extrude these things, so put the ShowPegGrid() statement inside an if, so you can turn it off for the final build layout.
Here’s how the stepper drive voltage affects the current rise, using that kludge to sync the scope on one of those motors with L=2.6 mH and R=2.2 Ω. The peak winding current is 1 A, so the first step current-limits at 200 mA.
At 9 V:
Current Rise – 9 V 1A 3 RPS
At 18 V:
Current Rise – 18 V 1A 3 RPS
Knowing the rise time and current change, you can calculate the actual voltage across the inductor using:
VL = L di/dt
With 9 V drive the motor sees:
4.4 V = 2.6 mH x 220 mA / 130 us
With 18 V drive the motor sees:
14 V = 2.6 mH x 240 mA / 45 us
So, in round numbers, the driver MOSFETs, winding resistance, and all the crappy solderless breadboard connections soak up about 4 V of the available supply voltage. There’s some back EMF in there, too, but I haven’t measured that part of the puzzle yet.
The motor is turning at 3 rev/s in 1/8 microstepping mode, so each microstep is:
