Slow down for small loops?

[Jake]

Is there a way to instruct Simplify3D to slow down for small loops? Funny, I was just having this issue yesterday, and now there's a discussion of the phenomenon here: https://groups.google.com/d/topic/maker ... discussion

I was specifically experiencing the problem with concentric fill, since the loops get very small towards the center of the fill. The machine gets very shaky due to the speeds involved.

As Dan points out into aforementioned post:

This is often discussed: small tight circles need to be printed slower.
Use a slicer which can slow them down (e.g,, RepG + Altshell plugin with
slowing down for all loops enabled). The issue is that the firmwares
control for linear acceleration but not centripedal. That's because
the firmware has no clue that a small, tight circle is being drawn.
And for centripedal acceleration, it's square(velocity) / radius. Since
you cannot do much about the radius, you're left with reducing the velocity
and that's the job of your slicer.

It would be great if Simplify3D could identify small radius turns and lower the speed appropriately... is this available and I'm just missing it?

[dnewman]

It would be great if Simplify3D could identify small radius turns and lower the speed appropriately... is this available and I'm just missing it?

+1.

And I throw this over the wall to the slicers since the slicers have the entire geometry before them and far more CPU horsepower than the puny uprocessors in our bots. The bots just see a stream of line segments tossed at them unless they just happen to have arc support built in and the slicer generates G2/G3 commands. If you're a very busy, 8bit, 16 MHz 1990's uprocessor with no floating point support and terribly busy driving an extruder around, the added task of fitting circles to sequences of 4+ consecutive inbound points is a bit too demanding. The slicer, OTOH, had the full geometry before it and probably wasn't making the 2+ GHz, 32bit processor with built in floating point break a sweat. But that's easy for me to say: throwing problems over the wall is always easiest.

Dan

[3Drasle]

+1

/Michael

[Mobilinkd]

+1. Need something like "doDynamicSpeed" in Makerware. This allows one to slow down in tight curves.

[JohnnyRobot]

We use this in robotics. Small Circle Accuracy. When a small circle is detected, decrease the speed. We use 3X diameter (10mm = 30mm sec.) perhaps it can be adjustable in S3D. "Print circles less than Xmm diameter at Y * Diameter speed"

[JoeJ]

In reality, the built-in acceleration controls already do some of this. When you print a small loop, you are changing direction much faster than larger loops, so the accelerations can't ramp up to higher speeds. So if your acceleration settings are correct (min starting speed, accel ramp up/down, etc), then you will already be printing small loops slower than large loops and at an acceptable speed.

To be fair, many robotics projects don't implement any form of true acceleration, so I can understand why it is needed there

[CT4]

OK still coming to grips with all of this. Where do I set otr view the acceleration settings? I have a Makerbot 2

[JoeJ]

It depends what firmware you have. I think you may have to install Sailfish to edit these parameters, but the point is that the manufacturer should already have some reasonable defaults that cause slow down for these situations

[bot]

With Marlin/Repetier based firmwares, for tiny loops, it is usually the "jerk" setting that will determine the speed at which the loop is drawn, because each segment has no time to accelerate, but starts at the jerk speed. In fact, for ALL curves, this is the case. If each segment is short enough, curves are drawn at basically the jerk speed.

[andre]

Using lower acceleration in Sailfish doesn't work completely, and you would have to use a very low number on both X,Y accel and X,Y max speed change, which then ends up slowing your print drastically.

You may be able to do this:

- Scan your GCODE file before converting to .X3G/.S3G for any E segment of your choosing of which anything less than will have to run at a slower speed.
- Add Fxxxx (any speed you want) to the end of each of those lines
- If the 'next' extrusion line is above that segment, you'll want to add Fyyyy that puts you back to the speed you originally had (this may require C++ or coding language, but some of you have abilities to do this via other means)

This method allowed me to raise my acceleration levels back to 'normal' values, allowing a much higher speed for all my regular prints, yet slow down during small arcs AND when filling in spaces between narrow shells, which would usually cause the bot to shake. I can now get much cleaner bosses and screw holes, arcs and corners which more closely match the tolerances in my model.

S3D just needs a parameter to automate this for you.

BEFORE:

AFTER: