Page 1 of 2

Optimizing STL files

PostPosted: Fri Jan 11, 2013 4:40 pm
by bdring
I thought I would start a conversation regarding STL files. STL files are flat faceted representations of your 3D object. It must convert rounded surfaces to these flat faces. Most CAD software gives some control over the "quality" of the STL. What are the ideal settings?

I have found that rounding a sharp corner can keep the speed up on a print and give a better quality edge. The rounding is actually a lot of little line segments. It appears that if you get too many short lines in the given space the controller starts to stutter a bit on those areas. It probably has something to do with the look ahead count.

Re: Optimizing STL files

PostPosted: Fri Jan 11, 2013 5:37 pm
by cvoinescu
I don't really like that STL files are limited to flat faces and straight lines.

I should qualify that: I don't like when STL files are often offered as "CAD files", because information in the original design is lost, changes are difficult, and, as a triangulation of a curved surface is necessarily an approximation, you're stuck with the accuracy chosen by the creator of the STL file. The way I see it, a STL file is an intermediate step between the CAD file (whatever format) and the machine commands (e.g. G-code), so it's part of the CAM process. STL files do have the merit of being understood by a lot of applications, but that does not compensate for their shortcomings as a source distribution format. By all means, offer the STL files in addition to the source CAD files, but not instead of the CAD files.

bdring wrote:I have found that rounding a sharp corner can keep the speed up on a print and give a better quality edge. The rounding is actually a lot of little line segments. It appears that if you get too many short lines in the given space the controller starts to stutter a bit on those areas. It probably has something to do with the look ahead count.


Looking at Marlin code, I found that even if the G-code specifies an arc, Marlin breaks it down in little segments and that's what goes in the planner. So it would stutter even with arcs, it doesn't really matter where they get broken down into segments. Generating G-code with arcs converted to line segments gives the CAM program more control over the precision of the approximation; generating G-code with arcs as G2/G3 arc commands gives this control to the firmware, and "real" controllers can probably deal with it better, as they "know" the machine better.

Of course, the latter is not possible starting with STL files, unless the CAM application can identify what segments used to be part of an arc and undo the approximation. That, in principle, sounds like going at it backwards. Why lose the information about a feature being round in the first place? That's an objection to using STL even as an intermediate in the CAM process. Again, the ubiquity of STL support goes a long way to compensate for its shortcomings, and my objections to using them during CAM are much weaker than my profound dislike of them as a source distribution format (when not accompanied by the source source CAD file).

Edit: Bart, I'm sorry. Now that my rant is over, I re-read your post and I saw that I was a little off-topic. My point that Marlin breaks down arcs into segments before they go into the planner is somewhat relevant, though.

Re: Optimizing STL files

PostPosted: Fri Jan 11, 2013 5:46 pm
by bdring
I still have troubles on my machine with the jerk on really short moves. The classic is the stepover from one perimeter to the next. It is a quick one filament wide move. It sounds like a thump, and I often loose steps during the print in Y. I have tried all sorts of settings. Last night I moved back to Marlin and it appears to have gone away.

It only happens with my Y axis. That uses a 400 step motor which is 157.48 steps per millimeter. That might be relates to the problem. I don't want to rewire the motor, so I may drop it via microstepping to 39.37 steps per millimeter (quarter step vs. sixteenth step). The other motors are all 200 step/rev.

Re: Optimizing STL files

PostPosted: Fri Jan 11, 2013 6:37 pm
by cvoinescu
bdring wrote:I still have troubles on my machine with the jerk on really short moves. The classic is the stepover from one perimeter to the next. It is a quick one filament wide move. It sounds like a thump, and I often loose steps during the print in Y. I have tried all sorts of settings. Last night I moved back to Marlin and it appears to have gone away.

Could it be that the problem is the double-jerk? There is one jerk when the movement starts, and one when it stops. Maybe the second one comes when the stepper is still reeling from being abused a fraction of a second before, and can't take it anymore. What I mean to say is that oscillations may not have amortized yet, or the stepper/belt/carriage system is still elastically deformed when it tries to jerk the second time.

Edit: Also, a 400 steps-per-rev stepper takes less displacement to skip steps. And unless the firmware is doing something wrong, I don't expect the microstepping setting to matter.

Edit: Stepover from one perimeter to the next, you say. That's a non-extruding move: is it implemented as a G0? If it is, is your traverse rate too high? Is there a bug in the firmware that makes it exceed the jerk limit when switching from the feed rate to the traverse rate (or vice-versa)?

Re: Optimizing STL files

PostPosted: Fri Jan 11, 2013 7:36 pm
by SystemsGuy
Bart - can you post a video of it skipping steps? I've 100's of hours on my various beasts, and I can count on one hand the problems caused by missed steps - and those where all caused by slic3r's insane micro-infill. Is it a single "jerk" you are talking about is really a series of "jerks" when it's doing infill that causes the skipped steps?

Couple of things - in general, stuttering is caused when the planner buffer is empty and your host program can't feed gcode to it fast enough. This rarely happens on my Cartesian 'bots - but is much more noticeable on the delta bots. Part of this is the delta code creating more short segments, but that's another problem - in any event, slow g-code can make your print look crap, but should not be causing skipped steps.

Do you know off the top of your head what your acceleration and jerk setting were before you switched back to Marlin? Were you using Repetier before?

EDITED : There is a bug - more than one, evidently - in Marlin and Repetier that causes jerk to be miscalculated in very small x/y "back and forth" moves. Chris (NopHead) believes this rapid back and forth motion causes harmonic vibrations that result in lost steps. There are a couple of entertaining threads on both the slic3r list and Marlin lists. This is what makes up the handful of "missed step" prints I've experienced.

Here's one I saved for posterity! :P

Image


bdring wrote:I still have troubles on my machine with the jerk on really short moves. The classic is the stepover from one perimeter to the next. It is a quick one filament wide move. It sounds like a thump, and I often loose steps during the print in Y. I have tried all sorts of settings. Last night I moved back to Marlin and it appears to have gone away.

It only happens with my Y axis. That uses a 400 step motor which is 157.48 steps per millimeter. That might be relates to the problem. I don't want to rewire the motor, so I may drop it via microstepping to 39.37 steps per millimeter (quarter step vs. sixteenth step). The other motors are all 200 step/rev.

Re: Optimizing STL files

PostPosted: Fri Jan 11, 2013 8:18 pm
by bdring
In general my problem occurs with very short moves. It can occur on long infill lines. It fills smoothly until it get to a hole and does a tiny jog to start the next section and I hear the thump. In that case the g-code is flowing quite slowly because the long fill lines might take over a second. I might try running off the SD card because that can have more reliable g-code flow.

I have Marlin installed, so I will see how that goes first. All of the speed, accel and jerk settings are the same as Repetier. I even checked the temp on my drivers in case they were shutting down.

My problem does not look as bad as yours. I might get a displacement of about 2 mm over the entire run.

Re: Optimizing STL files

PostPosted: Fri Jan 11, 2013 9:05 pm
by kbob
bdring wrote:I still have troubles on my machine with the jerk on really short moves. The classic is the stepover from one perimeter to the next. It is a quick one filament wide move. It sounds like a thump, and I often loose steps during the print in Y. I have tried all sorts of settings. Last night I moved back to Marlin and it appears to have gone away.


You didn't say what firmware you had been using. I know that in Marlin, you can tune the jerk. I'm pretty sure Repetier has an equivalent parameter.

Jerk, as defined by Marlin (and I think the other firmwares), is not the mechanical engineer's da/dt (3rd derivative of position). Instead, it is the velocity to which the firmware will instantaneously accelerate the motor. In Marlin, the default is 20 mm/sec. You could try turning that down. You could also check what the setting was in your old firmware.

bdring wrote:It only happens with my Y axis. That uses a 400 step motor which is 157.48 steps per millimeter. That might be relates to the problem. I don't want to rewire the motor, so I may drop it via microstepping to 39.37 steps per millimeter (quarter step vs. sixteenth step). The other motors are all 200 step/rev.


The motor can only skip in whole steps, not microsteps. Microsteps are only an electrical concept, not mechanical*. You probably have 9.84 whole steps per millimeter with that motor, and changing the microstepping won't affect that.

*It's more complicated than that, but I think I'm just reminding you of what you already understand.

Re: Optimizing STL files

PostPosted: Fri Jan 11, 2013 9:17 pm
by bdring
Yeah,

I understand all that. I was using Repetier and have lowered the jerk number in it and in Marlin.

You can skip microsteps if it is the software is loosing them, but I don't know if that is the case here.

The high res motor is either a clue or red herring.

At some point the step rate exceeds the interrupt rate so the highest step rate motor would see the problem first.

Re: Optimizing STL files

PostPosted: Fri Jan 11, 2013 9:25 pm
by kbob
bdring wrote:At some point the step rate exceeds the interrupt rate so the highest step rate motor would see the problem first.


Yeah, but you should not be seeing the highest step rate on very short moves.

When you print the exact same G-code file twice, does it skip in exactly the same way, or is it indeterminate? If it's repeatable, then you have a software bug. If it is not repeatable, odds are that it's a mechanical limitation. (Yes, software can do indeterminate things because of timing variation, but these simple little G-code interpreters on AVRs are about as close to deterministic as real-world software can get.)

Re: Optimizing STL files

PostPosted: Fri Jan 11, 2013 10:50 pm
by cvoinescu
kbob wrote:The motor can only skip in whole steps
Just to split hairs, hybrid steppers can only skip in multiples of four whole steps.
bdring wrote:At some point the step rate exceeds the interrupt rate so the highest step rate motor would see the problem first.
The firmware is, or at least should be, smart enough not to try to move faster than the interrupt rate. And for a short move, it won't have room to accelerate more than very little above the jerk number anyway.

There could be a bug in the step generator for very short moves; it's not difficult to make a stepper skip steps if you time the step pulses wrong. This could be a job for one of those cheap logical analysers/data loggers/DSOs on eBay.

I'd still vote with the mechanical explanation. What you're describing is a move that goes from stationary to moving at 20 mm/s to stationary again within 50 ms or so. Let's say the stepper is perfectly capable of going from stationary to moving at 20 mm/s, and from moving steadily at 20 mm/s to stationary. But it doesn't, really -- what it does is to accelerate at a finite rate while its position is behind the commanded position, reach a velocity well above 20 mm/s (possibly double that), and begin to catch up while decelerating to 20 mm/s. If lucky, or perfectly damped, it catches up with the commanded position just as the velocity reaches 20 mm/s, and keeps going smoothly; in practice, I think the speed and the position error oscillate a couple of times. Now what if you try to jerk the motor to a halt while it is still catching up, and moving at 40 mm/s? It may well be too much.

It would be telling to know in which direction the steps are missed. My hypothesis implies that the stepper skips on the second jerk, so for the perimeter stepover it would make a larger movement than intended, never a shorter one.