Now that I understand why the M2 Z axis stepper gets so hot, the question is: does it matter?
The Z axis stage moves very smoothly along the two guide rails, so there’s little friction and no binding involved. I can’t weigh the thing without dismantling the whole printer, which isn’t going to happen right now, but some crude experiments indicate that 7 pounds = 3 kgf = 30 N isn’t too far from the truth.
The 8 mm OD leadscrew has a 4-start thread at 3.25 turn/inch = 0.311 inch/turn = 0.13 turn/mm = 7.8 mm/turn.
[Update: Thanks to Jetguy for pointing out the blindingly obvious fact that it’s really 8 mm/turn = 0.125 turn/mm and you can do the inch conversion yourself if you need it. That doesn’t materially affect the results, given that they have about one significant figure of accuracy to start with.]
The firmware uses 1/16 microstepping at 400 step/mm = 3077 3200 step/turn.
Using a pull scale to, yes, pull a string wound around the knob on the Z axis leadscrew shows about 1 pound raises the platform at a slow, constant speed. The polygonal knob is about 35 mm in diameter, so the torque works out to 11 ounce·inch = 80 mN·m. Presumably, holding the platform at a given position would require somewhat less torque, but I can’t measure that with any confidence.
The motor has very little excess torque: a gentle touch can stall the Z axis motor as it raises the stage. I guesstimate the motor produces 150 mN·m, tops, during low-speed motion at 600 mA.
Lowering the stage requires no effort at all: it falls under its own weight, prompting me to install those bumpers. The design doesn’t have much compliance, but it’s well-adjusted and works fine.
Searching with the appropriate keywords produces a 17HD-B8X300-H motor from Kysan:
- 12 V
- 400 mA
- 30 Ω
- 42 mH
- 2.6 kg·cm = 260 mN·m
That’s a close-enough match to suggest my measurements are in the right ballpark. The extremely high resistance and inductance indicate this is the wrong motor for a high-performance microstepping application.
The firmware has DEFAULT_MAX_ACCELERATION = 30 mm/s2 for the Z axis. It’s 9000 for X and Y, 10000 for the extruder. The extremely low Z acceleration says there’s something badly wrong with this setup.
There is also a DEFAULT_ACCELERATION = 3000 for all axes. I don’t know how that interacts with the per-axis limit, but I’m certain the Z axis doesn’t come close to that value.
I do not know how the firmware actually handles motor steps while ramping up and down, but I do intend to clamp a current probe around a motor wire and measure what goes on. Let us assume it works in the usual way all ideal components behave in physics labs.
Assuming a constant 30 mm/s2 acceleration for the first half of a 0.25 mm Z axis move, the time should be:
0.25 / 2 = (1/2) * 30 * t2
t = 90 ms
At the end of that ramp-up, the Z stage will be trundling along at:
v2 = 2 * 30 * 0.25/2
v = 2.8 mm/s
The move requires exactly 50 steps = 0.25/2 mm * 400 step/mm.
Assuming the same deceleration during the second half of the move, a 0.25 mm layer change requires about twice that long: 180 ms for 100 steps.
Along the X axis, a 0.25/2 mm move requires 5.3 ms and reaches a peak speed of 47 mm/s. The total move requires 11 ms and 22.22 steps (= 0.25 mm * 88.88 step/mm, obviously rounded to 22).
I think a difference of more than an order of magnitude matters, although some actual measurements are definitely appropriate.
The Smell of Molten Projects in the Morning 
Like they do with z-axis in CNC bench mills, would adding counter-weights to the z-axis help?
Sort of like the lead lump dangling beside my Sherline? [grin]
There’s no good way to route the cable directly out of the chassis and it’s sitting on the corner of my desk in the living room: I can’t just casually drill a hole in the ceiling for the pulley.
The right solution is to just install a motor with enough oomph for the job.
That 4-start worm gives me a bad feeling. I once had some kind of stepper-driven elevator mechanism from the usual Silicon Valley surplus house with a multi-start worm, but the load on the beast wouldn’t have been more than a couple of pounds. It also didn’t need much precision, with likely acceptable errors of approx 0.25mm. Thus, a 48 step motor was OK.
Looks like your Z application has the worst of all possible worlds. A pessimal solution?
It’s good enough for the job, if only because all the motion happens in one direction. There’s definitely some backlash, but I think the normal process of always lowering the platform soaks it up at the start.
There is a bit of binding on the rods at some positions, but a stiff look at the platform breaks it free. I should measure the backlash just to be sure I know what’s going on…
Ed, use some STP oil treatment on the rods and screw. You will be mildly pleased with the results. I put some on the T-O-M’s rods, screw and bushings a year ago. Amazing! And – Yes – still using bushings. They work very well once properly worn in and treated with the right lube. :-)
It’d certainly smell better than the genuine 3-In-One included with the printer; that snapped me back to my childhood when my father applied it to nearly everything, WD-40 being Mil-Spec stuff at the time.
Count me in!
Hi Ed,
Having Fun! I see.
You state that you feel you Z axis is 7lbs. WOW! Is it solid Steel? That would take two hands to hoist. How heavy is the M2? From sight knowing most of the machine is aluminum I’d guess a single pound – max. ???
Say, The math – I started to read and it started with a problem. Then I gave in —-
I see an error – by stating a distance then setting your equation up to halve that distance then carry that halving through to your constant halved the constant to 15. What ended up being calculated was half the distance at half the acceleration rate. OR actually the whole distance at the full acceleration rate. If you revisit you’ll see. I know it was a fast oversight. You think so fast. Anyway the number for the first equation is — square root of (.125/30) = 64ms
Cheers.
I’m anxiously waiting on your buying the 2X bigger motor and writing how quiet and well it works. ;-)
Happy SPRING!
Not quite, but the Y and Z stages include an impressive collection of parts: 3/8 inch Al for the Z stage, which holds linear slide and hulking Y axis stepper, 1/4 inch Al plate spider atop the steel adapter plate, the 8×10 inch sheet of glass atop the 1/8 inch Al heater plate with the silicone heater pad under that, plus a generous handful of steel hardware.
My admittedly crude experiements included putting a 5 pound capacity scale under the platform and lowering it until the leadscrew went slack… as the scale went out of range. So I’m pretty sure it’s more than 5 pounds; the 7 pounds is at best a guesstimate.
The machine frame is stainless steel and the whole affair weighs 22 pounds without the filament spool. It’s a handful!
The basic equation is
x = 1/2 * a * t2, with the distance x = half the total move = 0.25/2 and the acceleration being the 30 mm/s2 from the firmware configuration. That’s assuming the motion controller ramps up and ramps down equally throughout the whole move, which many not be the case; I must measure that to see what’s going on.Heh. It takes me quite a while to work through all this stuff and convince myself I know what I’m doing; what you see here is just the hand whipping the rabbit out of the hat. Of course, I’ve been known to drop the rabbit or fling it offstage, so I appreciate you checking my work… [grin]
In Marlin’s trapezoidal acceleration, a given trapezoid (segment) uses only a single constant acceleration albeit negated when deceleration is called for. So, if accel/decel is called for at both ends of the segment, then the same non-zero value is used. Makes the computations at the planning stages slightly easier.
When two segments are juxtaposed, you may see one constant acceleration value then change to another constant acceleration value. The point at which the change occurs is the end of the one segment and the start of the next segment.
As to the DEFAULT_ACCELERATION of 3000 vs. the maximum Z axis acceleration, the former is for the overall motion (including the extruder); whereas, the latter is for the component of the motion along the Z axis. All as you would expect. Question of course then is, “Well what happens when the acceleration component along an axis exceeds the limit for that axis?”. In that case Marlin just uses the max acceleration for that axis as the overall acceleration.
And, BTW, if the max X & Y accel is 9000 mm/s^2 but the acceleration for non-retraction moves is 3000 mm/s^2, then you won’t see any faster acceleration than 3000 mm/s^2. The acceleration is set from one of two values: the value for moves which involve at least one of the X, Y, or Z axes, the other value for moves which do not involve the X, Y, or Z axes (i.e., an extruder only move). If the acceleration for these “normal” moves — moves with any of X, Y, or Z — is, say, 3000 mm/s^2, then that’s the largest the acceleration will be. The code then only revises that value downward when planning for that segment. It doesn’t revise it upwards.
The value used for the max. acceleration of normal moves can come from a M204 command. In the absence of such a command, it can come from the EEPROM (I believe). And when neither of those two exists, it comes from the DEFAULT_ACCELERATION in the code which is 3000 mm/s^2.
If I understand that correctly, DEFAULT_ACCELERATION sets the maximum total “Cartesian sum” acceleration for any XYZE motion vector, with DEFAULT_MAX_ACCELERATION limiting the acceleration along each of the XYZE axes. In addition to that, DEFAULT_RETRACT_ACCELERATION sets the limit for retraction, which might be different.
So, right now, a single-axis XY move can’t exceed 3000 mm/s^2, no matter what the per-axis limit might be, and it’ll drop to 2100 = 3000/sqrt(2) mm/s^2 for a 45 degree XY move.
I gotta goose those to 10000 mm/s^2 just to see what happens: a long Y axis move will probably fling the M2 right off the desk!
I guess we’ve hit a nesting depth for Replies? This is actually a reply to the intuitive assumption about 45 degree motions.
Actually, I have to think a bit about that 45 degree motion and I’ll do it out loud here. For a given line segment there’s a “dominant” or “major” axis. Namely the coordinate axis for which there are the most steps to execute. (In the case of a nice, clean — dare I say “perfect” — 45 degree motion vector, both X and Y should have the same number of steps in which case they are equally dominant.)
Okay now about this dominant axis. It gets a step executed every time the stepper interrupt fires[*]. The other axes may have fewer steps executed. Their steps are distributed using a “DDA” algorithm (Digital Differential Analyzer). In the case of Marlin (and most RepRap firmwares, I believe) the integer version of Bresenham’s Line algorithm is used (see Wikipedia). But the key thing is that the final chosen acceleration for the 4-dimensional motion (XYZE) is then applied to this dominant or major axis. The other axes, which see their steps distributed uniformly amongst steps for the dominant axis arguably see a lower rate of acceleration. I write “arguably” as I’ve personally never come to grips with what all this really means for the ideally discrete motion of stepper motors. Obviously the motion isn’t ideally discrete: physics — plain old boring classical physics at that — intrudes with details such as mass/inertia, inductance, etc. But what about slow enough rates where you can observe a start/stop (LA traffic style) motion? Worth writing a paper on if it hasn’t been done already, I suppose.
Back to that nice clean 45 degree motion where there’s an equivalent number of X & Y steps to be executed. The stepper interrupt will think that it’s to perform an acceleration of 3000 mm/s^s for the dominant axis or axes. (Translated into steps/s^2 and carried in the field block->st_acceleration, IIRC.) The stepper interrupt will approximate that by adjusting the time until the next stepper interrupt, taking a step when the interrupt fires, then reducing the time until the next interrupt, taking a step when the interrupt fires, etc. If there are an equal number of X & Y steps and they are the dominant axes, then both axes will/should experience something akin to an acceleration (or deceleration) of 3000 mm/s^2. So, some of the vector thinking goes out the door. (Which is one of the things which annoys me about how these firmwares behave: they don’t exactly behave how we expect them to.)
[*] At sufficiently high step rates, the stepper interrupt in Marlin begins taking multiple steps per interrupt. At that point, the max accelerations and jerks are definitely not being observed. Mind you the jerk controls were only applied during the initial planning phase and subsequently get thrown out the door (i.e., routinely violated to varying degrees) by the iterative planning section of Marlin. Much of this becomes evident when you go to the effort of building a simulator around Marlin (or in my case Sailfish) and can then look at the planning results produced.
I dropped the max depth to 4, so as to avoid one-word-per-line commentary in that tiny fixed-width column. There seems to be no way to make it expand to your screen width, alas.
Ouch. As the sage observed, it’s not what I know that gets me in trouble, it’s what I think I know that just ain’t so. Thanks for smartening me up a bit.
I didn’t realize the stepper interrupts used variable timing instead of a constant tick; that’s a good way to handle multiple axes. I think LinuxCNC uses a constant tick rate for software stepper generation, which leads to granular speed choices at high speeds. The solution is hardware stepper control, using something like a Mesa card, to make that problem Go Away.
I’m definitely going to stir those constants around and see what happens…
Oh, and if X & Y then both see 3000 mm/s^2, what did we just end up with the acceleration for the motion viewed as a vector in the XY plane? About 4,200 mm/s^2, that’s what. That’s sqrt(2) * 3000 mm/s^2. So there’s a strong argument that the 3000 mm/s^2 should not be considered as a limit on the acceleration for the vector motion (as I wrote in parroting other information / docs for Marlin) and that it’s really a limit on the maximum axial acceleration for any one axis. Is it more useful to think in those terms? Maybe, but then why also have the per axes max accels? Well, I know the answer to that: the X & Y axes are typically mechanically different from the Z axis which is again typically different from the E axis. But then why not just have the max per axes accels and not this other DEFAULT_ACCELERATION? Good question. I expect that some of this grew to be this way by incremental changes which didn’t remove old concepts, and maybe some of it suffered from not thinking it through its entirety.
The variable stepper frequency is, IMO, one of Marlin’s early, important contributions. Warning: some other firmwares may have introduced it first, but it’s my perception that Marlin is the firmware which made the idea stick. For example, Rob Giseburt’s port of Marlin to the MBI firmware did not emerge from MBI with a variable frequency interrupt. When asked, MBI responded with a statement I had heard several times before: variable frequency interrupts lead to printing artifacts and as such are not viable. (MBI, in adopting Sailfish’s Marllin derived acceleration planner and stepper interrupt, crossed that bridge.) The variable frequency works quite well. However, at some point you hit an upper bound on the frequency which you cannot pass since the period is then shorter than the time the interrupt requires to execute. At that point, you have to kick over to taking multiple steps per interrupt. At that point, there can be models which exhibit a degradation in print quality. Hence the desire in some quarters for hardware faster than a 16 MHz — hardware which can run a higher frequency stepper interrupt at a frequency in excess of, say, Marlin’s 10 KHz limit.
The MAX_STEP_FREQUENCY in the M2 firmware is 40000, which suggests a 25 us minimum step time. That’s scary-fast on a 16 MHz system: call it 400 machine instructions, maybe 40 C-level statements.
Dividing that by the 88.88 steps/mm setting suggests a top speed of 450 mm/s in XY, which is below the 500 mm/s set by DEFAULT_MAX_FEEDRATE. You’re right about the “just grew” quality of the code, at least as far as the settings go. Not like I’ve never left some stray constants behind, I’ll admit.
Dunno how all that correlates with reality out in the steppers, but it’s painfully obvious I must do some doodling, then devote some Quality Shop Time to an oscilloscope probe…
Bzzzzzt! The underlying stepper interrupt in stepper.cpp has an upper limit of 10 KHz. The value you are seeing takes into account that Marlin will allow it’s stepper interrupt to double or quadruple step. So, there’s a FICTION that it can handle up to 40 KHz. But in actuality, it cannot. Look at the routine calc_timer() in stepper.cpp. That’s where the double and quad stepping is imposed. That’s the routine which, given a necessary step rate (steps/some time unit), determines what the interrupt’s frequency needs to be. The value “step_loops” is how many steps per axis will happen in a call to the stepper interrupt. The maximum actual frequency without taking multiple steps per interrupt is this the frequency allowed by calc_timer() while keeping step_loops == 1. That’s 10 KHz. (Even then, I’ve seen that stepper interrupt have late issue. I.e., at the start of a new segment and when it does setup work for the new segment, it’s possible for it to take a little too long and hold up the next interrupt.)
OK, I hereby swear a mighty oath on the bones of my ancestors that I will not believe what any of the constant or variable names would have me believe, at least not before running them past you: obviously, I’m totally unprepared for the quiz. [grin]
“The 8 mm OD leadscrew has a 4-start thread at 3.25 turn/inch = 0.311 inch/turn = 0.13 turn/mm = 7.8 mm/turn.”
Are we sure that isn’t the same TR8x8(P2) thread everyone else uses?
That looks conspicuous considering the T-O-M uses 200 steps/mm at 1/8th stepping on a TR8x8 and here 1/16th stepping on the same thread would be 400steps/mm as indicated?
http://www.shapeoko.com/forum/viewtopic.php?f=5&t=727
From user cvoinescu:
“Tr8x8(P2) means you have a trapezoidal lead screw with a diameter of 8 mm (that’s the first eight) and a lead of 8 mm (second eight). P2 means it has two starts, so its pitch is 8 mm / 2 = 4 mm. However, it’s the lead you want to enter as “pitch” in DrRob’s calculator: it’s the distance the lead nut travels when the screw rotates one turn. In your case, that’s 8 mm (not 4, and certainly not 2). For leadscrews with one start (like the standard ShapeOko M8 allthread) the lead and the pitch are the same, hence the frequent confusion.”
Actually, I think that post is wrong too, in that (P2) refers to the pitch not number of starts. If you don’t see the end of the screw and just measure the distance between adjacent threads, then it’s 2 but knowing by looking at the end, you realise it’s 4 starts then it all falls together 4*2 equals the real pitch 8mm per turn. What I’m saying is, the looks are deceptive from the side. If you take a marker and trace the thread you’ll see the “real” pitch since that same thread actually “jumps” up 4 places on the same side. In all, it’s a confusing subject and often abused documentation system. Apparent pitch VS real pitch and multistarts really throw most people.
I could be wrong, but the steps per mm is telling, and knowing these all come from China, likely to be the same standard. I’ll bet money your T-O-M nut will easily thread onto that motor.
All that to say, it’s 8mm pitch, not 7.8mm.
You’re right!
I stood on my head, coerced the caliper into metric / relative / zero, lined it up up, turned the knob three turns, divided the total travel by three, and the result now seems closer to 8.0 than 7.8.
That’s the kind of operation which goes better with three or four hands. I should, of course, print a dial indicator adapter, right?
Good catch: thanks…
I am just so not going to dismantle both printers to test that assertion!