Minimal Layer Time slows down travel moves as well

[CapnBry]

I'm not sure if this is a feature so if so just close this issue. (Also is there a forum for CuraEngine discussion, feels wrong to have discussion on the issue list)

When enforcing the minimal layer time option, all moves are tallied up and used to calculate the speed factor used for the layer. This speed factor also reduces the speed of "travel moves", that is moves that aren't extrusion moves. On my prints these moves can move the extruder so slowly that there's ooze dribbled along the way that creates seams and lines in my prints.

GCodePlanner::forceMinimalLayerTime() could just count up the travelTime and extrusionTime separately and generate a factor which only uses extrusionTime. GCodePlanner::writeGCode() could then only use the speedFactor on extrusion moves. It is easy to differentiate the two types of moves by their config->lineWidth.

If the current way it handles the slowdown is prefered that's fine. Else, I can submit a pull request for the change.

[ErikDeBruijn]

To me that would make sense... I wonder what David thinks of it.

Thanks for proposing to write a patch. It would be interesting to see the quality difference and difference in processing time. The latter can probably be negligible.

With kind regards,

Erik de Bruijn Co-founder, Ultimaking LTD Op 1 aug. 2013 18:03 schreef "Bryan Mayland" notifications@github.com het volgende:

I'm not sure if this is a feature so if so just close this issue. (Also is there a forum for CuraEngine discussion, feels wrong to have discussion on the issue list)

When enforcing the minimal layer time option, all moves are tallied up and used to calculate the speed factor used for the layer. This speed factor also reduces the speed of "travel moves", that is moves that aren't extrusion moves. On my prints these moves can move the extruder so slowly that there's ooze dribbled along the way that creates seams and lines in my prints.

GCodePlanner::forceMinimalLayerTime() could just count up the travelTime and extrusionTime separately and generate a factor which only uses extrusionTime. GCodePlanner::writeGCode() could then only use the speedFactor on extrusion moves. It is easy to differentiate the two types of moves by their config->lineWidth.

If the current way it handles the slowdown is prefered that's fine. Else, I can submit a pull request for the change.

— Reply to this email directly or view it on GitHubhttps://github.com/Ultimaker/CuraEngine/issues/15 .

Ultimaker - easy, open source 3D printing! http://www.ultimaker.com/ Follow us on Twitter http://twitter.com/ultimaker, Google+https://plus.google.com/u/0/b/105283675489513173942/105283675489513173942/posts , Facebook http://www.facebook.com/Ultimaker

IMAGINE IT >> MAKE IT

[CapnBry]

For a comparison, here's the same model sliced with Cura both with the regular code (left) and with the same slicing except without the travel moves slowed to meed minimum layer time (right). Imgur 1600x600

While they both have some degree of oozing caused by a 45mm travel, it seems the moves with the slower travel do exhibit more ooze. Retraction can probably help this but my Greg's extruder gears mixed with my stepper that maxes out around 14,000 pulses per second means that in my case (making retraction limited to around 13mm/s), keeping the retraction low helps with print speed and quality. Regardless of it helping my case, I still believe that slowing travels to meet minimum layer time isn't the right way to go.

Performance wise, this adds 2 integer compares per point across the board, and one float addition per layer. It also adds one integer compare that removes a some float math on travel moves, only in the case that the layer is going to be slowed (which would be a quick layer anyway). It seems to have very little if any impact on performance (although I admit I wish it were performance neutral because Cura is so fast I want it to stay that way!).

I need to fork your repository and copy my changes into it to create the pull request, which I'll do today or tomorrow.

[daid]

Performance wise, this piece of code isn't the most critical part. I do like your patch, as it makes sense. I did the whole slowdown because it was quicker to code, and that was what Skeinforge did. (And with so much to do, you cannot implement everything exactly how you would want and test it. So I went with the safe route)