Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
Category: Software
General-purpose computers doing something specific
After printing the Barbie Pistol, I discovered that moving the Z stage to anything less than the absolute maximum was a Bad Idea, so I changed end.gcode to simply home the Z axis to the top. That worked fine in RepG 24, but after printing a few things with RepG 25, I discovered that the Z axis now has uncommanded motion after that homing step: a G0 F4000 X0 causes the Z stage to drop by anywhere from a few millimeters to half the total travel.
Of course, the uncommanded Z motion depends on something imponderable, but it’s consistent for any given setup. This chunk of G-Code causes about 10 mm of downward Z motion:
G21 (set units to mm)
G90 (set positioning to absolute)
(- 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)
G0 F4000 X0 Y0 Z30 (pause at center to build confidence)
(- draw square)
G0 F4000 X-45 Y-45 Z10 (to front left corner)
G1 Y45 F4000
G1 X45
G1 Y-45
G1 X-45 (return to front left)
(- move to eject position)
G162 Z F1500 (home Z to get nozzle away from object)
(G0 F4000 Z113) (this would work fine)
G0 F4000 X0 (center X axis)
G0 F4000 Y40 (move Y stage forward)
As nearly as I can tell, homing an axis trashes its coordinate value, so the only thing you can do next is set the axis coordinate value with G92 or M132. Given that those values are now stored in EEPROM, maybe it’s be a good idea to simply use them, without requiring another command after each homing command?
You’d want home offset values for both the maximum and minimum limits, to accommodate printers with limits on both ends of the axis, rather than the single offset now stored. The two homing commands (G161 and G162) could pick the appropriate offset, if a valid one was stored, and leave the coordinate unchanged (but not trashed!) otherwise.
It would be handy, while doing the fast / coarse home stuff, to switch to G91 relative positioning mode and back off the switches by 2 mm by using a simple G0 X2 Y2 Z-2 that doesn’t depend on knowing the exact coordinates of the endpoint, but it seems relative positioning doesn’t work for any but the most trivial cases.
After some fiddling, this short routine produces a very fast, very long, fully coordinated XY move to some position in the +X +Y direction at the G1 X2 F100 command after the G91 command sets relative motions; it should move 2 mm away from the X switch. When the machine arrives at the new (unexpected) position, it then does the expected slow 2 mm Y and Z moves:
G21 (set units to mm)
G90 (set positioning to absolute)
(- 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)
(- back off switches)
G91
G1 X2 F100
G1 Y2 F100
G1 Z-2 F100
G90
I gave up and used an absolute move with hardcoded XYZ coordinates that should be pretty close to the stored values.
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.
I upgraded to ReplicatorG 25 and the Thing-O-Matic promptly got weird: the initialization code slowed to a crawl. The motors ran fine, the motion was properly coordinated, but the thing moved at a minute fraction of its normal 100 mm/s.
This was most obvious on the first move to the center of the stage after homing the axes. If you peer into the source code, that instruction looks like this:
G0 X0 Y0 Z10 (pause at center to build confidence)
The comment tells you exactly why I put that move in there when I first started tinkering with start.gcode: I long ago discovered that automation doesn’t always do what you want, so having a simple verification at the first opportunity sometimes pays off big.
Anyhow.
A bit of rummaging showed that RepG 25 has changed the semantics of G0, which is supposed to be a fast move to the programmed coordinates. Now G0 moves at the feed rate set by the most recent G1 and also accepts an F parameter, which it shouldn’t. I suspect somebody refactored the code and didn’t notice that G0 isn’t supposed to work exactly like G1.
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.
In order to get good scope pictures of the winding current in a stepper motor, the scope must sync to the step pulses. However, it must also sync to the groups of 32 step pulses that make up a single set of four full steps, because the winding current repeats for each of those groups. Triggering once per revolution and delaying for a fixed amount will get you where you need to be.
The sync wheel provides a once-per-revolution pulse, but there’s some jitter in the edge for all the usual reasons and you’d be better off with a sync based on the stepper driver’s step input. The general idea is to find the leading edge of the optical pulse, find the next step pulse, then produce output pulses based on the step signal. Assuming a regular step pulse stream (from a pulse generator, for example), the output will be both locked to the wheel rotation and to the step pulses.
Normally this calls for a tedious wiring session involving logic gates and counters, but an Arduino has all the requisite machinery built in. The trick is to generate the pulses using the ATmega’s hardware, rather than program instructions, thus eliminating the usual jitter caused by instruction execution time.
I set up Timer 1 in Mode 4 (CTC with OCR1A controlling the matches) to count step pulse inputs on its T1 external clock input pin and produce a once-per-revolution output pulse on the OC1A pin. Because the output changes on the rising edge of the input clock, its rising and falling edges will provide rock-solid stable scope synchronization.
The big picture goes a little something like this:
Tell the counter to set the output on match, load the duration of the output pulse
Wait for the once-per-revolution signal, then enable the external clock input
Wait for the comparison to happen and reset the match flag
Set a one-pulse delay and tell set the counter to clear the output on match
Wait for the compare, clear the flag, turn off the counter
Wait until the once-per-rev signal goes low
And then do it all over again
Which produces this:
Sync Wheel
Top trace = optical signal from interrupter, middle = 1/rev sync from Arduino OC1A pin, bottom = step pulses. The motor is turning 3.5 rev/s = 210 rev/min. The top half of the screen is at 2 ms/div, the bottom half at 200 μs/div.
You could synchronize the counter to the 1/rev input exactly once, then produce the output pulse just by counting stepper pulses. It’d also be nice to have a pulse that repeats for each group of 32 microsteps within each set of four full steps, perhaps settable to a particular microstep within the group. All that’s in the nature of fine tuning.
Of course, devoting an Arduino to this project would be absurd, but for a one-off effort it makes a lot of sense.
The Arduino source code:
// Stepper motor driver synchronization
// Ed Nisley KE4ZNU June 2011
//-- Pin definitions, all of which depend on internal hardware: do *not* change
#define PIN_REV 2 // INT0 = positive 1/rev pulse from optical switch
#define PIN_STEP 5 // T1 = positive 1/step pulse from stepper driver
#define PIN_TRIGGER 9 // OC1A = positive trigger pulse to scope
#define SYNC_OFFSET 15 // steps from 1/rev puse to start of first 4-full-step group
#define PIN_TRACE_A 10
#define PIN_TRACE_B 11
#define PIN_TRACE_C 12
#define PIN_LED 13
//---------------------
// Useful routines
//--- Input & output pins
void TogglePin(char bitpin) {
digitalWrite(bitpin,!digitalRead(bitpin)); // toggle the bit based on previous output
}
//----------------
// Initializations
void setup() {
pinMode(PIN_REV,INPUT); // INT0 1/rev pulse from wheel
pinMode(PIN_STEP,INPUT); // T1 step pulse from stepper driver
pinMode(PIN_LED,OUTPUT);
digitalWrite(PIN_LED,LOW);
pinMode(PIN_TRACE_A,OUTPUT);
pinMode(PIN_TRACE_B,OUTPUT);
pinMode(PIN_TRACE_C,OUTPUT);
//--- Prepare Timer1 to count external stepper drive pulses
TCCR1B = B00001000; // Timer1: Mode 4 = CTC, TOP = OCR1A, clock stopped
pinMode(PIN_TRIGGER,OUTPUT); // OC1A to scope trigger
}
//----------------
// The main event
void loop() {
//-- Wait for rising edge of 1/rev pulse from optical switch
TCCR1A = B11000000; // COM1A set on compare
TCNT1 = 0; // ensure we start from zero
OCR1A = SYNC_OFFSET; // set step counter
while(!digitalRead(PIN_REV)) { // stall until 1/rev input rises
TogglePin(PIN_TRACE_A);
}
//-- Got it, fire up the timer to count stepper driver pulses
TCCR1B |= B00000111; // enable clock from T1 pin, rising edge
digitalWrite(PIN_LED,HIGH); // show we got here
digitalWrite(PIN_TRACE_A,LOW);
while(!(TIFR1 & _BV(OCF1A))) { // wait for compare
digitalWrite(PIN_TRACE_B,digitalRead(PIN_STEP));
continue;
}
TIFR1 |= _BV(OCF1A); // clear match flag
//-- Scope sync pulse now active
digitalWrite(PIN_LED,LOW); // show we got here
digitalWrite(PIN_TRACE_B,LOW);
//-- Wait for another step pulse to clear scope sync
TCCR1A = B10000000; // COM1A clear on compare
OCR1A = 1; // wait for another pulse
while(!(TIFR1 & _BV(OCF1A))) { // wait for compare
digitalWrite(PIN_TRACE_B,digitalRead(PIN_STEP));
continue;
}
TIFR1 |= _BV(OCF1A); // clear match flag
digitalWrite(PIN_TRACE_B,LOW);
//-- Shut down counter and wait for end of 1/rev pulse
TCCR1B &= ~B00000111; // turn off timer clock
while(digitalRead(PIN_REV)) { // stall until 1/rev pulse goes low again
TogglePin(PIN_TRACE_C);
}
digitalWrite(PIN_TRACE_B,LOW);
}
The Smell of Molten Projects in the Morning 