User avatar
DarthRevan
Posts: 466
Joined: Wed Feb 18, 2015 8:29 am

Re: Slow down for small loops?

Fri Apr 28, 2017 8:44 am

I've been working with an Ultimaker 3 more recently and the acceleration/jerk values used were 1500 and 15. I've not had any issues with small circular movements on that machine yet.

Jake
Posts: 8
Joined: Sun Feb 02, 2014 10:23 am

Re: Slow down for small loops?

Fri Jul 28, 2017 6:55 pm

Old post, but 4.0 just came out and I still wish for this.

I know that some think this is a firmware or acceleration issue. I disagree. I'll quote Dan, a primary contributor to the sailfish firmware again, as I did in the original 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.
Basically, we're talking about 8-bit processors here without the processing or memory to look ahead like a motion planner like Mach3 might do. (See this post discussing the lengths that some motion planners go to) Hence, its up to the slicer to "dumb it down" for the machine, which has a very limited motion planner.

I can't speak the 2.x versions that may have had a similar feature --I hadn't purchased Simplify3D yet. I just know that this is something I want. If users were misusing it, then its user error. Put it on the advanced tab.

iZz0s
Posts: 7
Joined: Sun Jul 30, 2017 12:00 pm

Re: Slow down for small loops?

Tue Aug 15, 2017 7:23 pm

I have the same problems, small loops are often a problem.

Bad looking finish, sometimes the perimeters are not connecting to the others (in case of 2-3mm diameter loops). A internal solution which are can slow down print speed based on islands would be awesome.

for now im currently developing a small utility which can edit simplify's generated gcode. it's a bit tricky to detect small perimeter loops but for now the first tests on 2-3 objects went very well.

GregFisk25
Posts: 17
Joined: Thu Mar 06, 2014 4:15 am

Re: Slow down for small loops?

Wed Aug 16, 2017 9:30 pm

I would love this. I cant use the software the way I need to because of the types of thingsI print, and the way it works. Makerware always does a much better, faster job

iZz0s
Posts: 7
Joined: Sun Jul 30, 2017 12:00 pm

Re: Slow down for small loops?

Thu Aug 17, 2017 11:44 am

Hey,

here a picture how i'ts currently working.

hoewer, it's currently for windows only but maybe i can develop it's similar for an online platform where it's possible to upload the gcode file. For sure i have still to fix some small bugs, but this shouldn't be a problem.

I've tested it also on a designed plate with a lot of circles with diameter sof 1-20mm and a lot rectangles and some other elements, the results were really good and im currently happy with the progress :)

Image

User avatar
DarthRevan
Posts: 466
Joined: Wed Feb 18, 2015 8:29 am

Re: Slow down for small loops?

Sat Aug 19, 2017 11:18 am

I finally set down and re-wrote my previous c++ app as a python script. Sorry to keep you all waiting https://github.com/quotetherevan/slowDownFeatures

Layer4 of pi case I was trying to print:
Original.png
Original
Processed.png
Processed
All command line arguments are required. The following order is needed: Path to the gcode file, then the speed in mm/min you wish to set the small loops to, then the threshold for the length of the perimeter you wish to slow down.

For this pi case I used the following to run the script on my g-code file "Primus_Pi_Body.gcode":

Code: Select all

python3 smallFeatures.py Primus_Pi_Body.gcode 360 30

siamak2153
Posts: 2
Joined: Fri Mar 10, 2017 10:42 pm

Re: Slow down for small loops?

Wed Sep 13, 2017 8:13 am

hello
i did solve this problem with split my part and use of several part with some FFF settings . then u can move your parts to the correct positoin and print finally . like the attached file.
Attachments
speed1.JPG

Nepherael
Posts: 21
Joined: Thu Nov 30, 2017 5:57 pm

Re: Slow down for small loops?

Sun Mar 18, 2018 10:38 am

This is also a feature I would greatly benefit from. However, I would go one step further. I've tried Darth Revan's script (thank you very much!) and it it only for outermost perimeters. I have parts that, for example, use print in place hinges. Most of the circles in these parts are not considered an outer perimeter or they are part of a much larger total perimeter.

Is there a way to detect multiple direction changes against a certain extrusion length, assume it is a circle/loop/arc, and modify the speed for these moves? This would help not only with the perimeter but with the 2 or 3 circles printed inside of it. That's just a first idea. If there is an easier/smarter way to do this codewise I am all ears.

Since this topic is heading toward 4 years old I'm having serious doubts that S3D will supply us with this feature. I'm not going to even test the Makerware slow down mentioned but I am interested in the RepG plugin mentioned earlier in the thread. I've never actually sliced with RepG (just used it for mobo changes) but I'm happy to do so if it can help me with this issue.

I want to be a part of this discussion. I have perused this thread MANY times because I have continually found myself on Google looking for solutions to this issue and this thread is the main return on such searches.

Nepherael
Posts: 21
Joined: Thu Nov 30, 2017 5:57 pm

Re: Slow down for small loops?

Sun Mar 18, 2018 11:35 am

To add:

After using Darth Revan's script I get a gcode file in return. In order to convert that gcode file to x3g I'm using S3D's GPX app (because my printer does not recognize .gcode files). The x3g file that is spit back out at me is not correctly converted. I didn't even let it get through the print very far because it lost my heated bed settings as well as which extruder to use. So I had a cold bed and it was using my right extruder instead of my left.

Just wanted to report my findings

Edit: One solution after googling around a bit. Convert the file with the python script. Open a blank STL in S3D (I created a square surface with no thickness so it wouldn't get picked up). Create a process with the settings you used. Copy all gcode in the python processed file and paste it in the scripts tab under ending script. I'm trying to get the exact point at which to copy/paste. Currently I'm leaving the starting script in the start tab, replacing the ending script with all lines starting at the first printed line. I'm thinking S3D should export the starting script, starting settings, then all of the print moves with the ending script that I copied into the ending script tab. It should have already placed the ending script when the file was created. It looks good so far on preview and is keeping my settings correct as of layer 1

Return to “Feature Requests”