Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Travelspeed of wipe-tower / toolchange not adjustable #5483

Closed
ReneJurack opened this issue Dec 15, 2020 · 2 comments
Closed

Travelspeed of wipe-tower / toolchange not adjustable #5483

ReneJurack opened this issue Dec 15, 2020 · 2 comments

Comments

@ReneJurack
Copy link

ReneJurack commented Dec 15, 2020

Version

2.3.0 Beta3

Operating system type + version

osX 11.0.1 (20B29) BIG SUR

3D printer brand / version + firmware version (if known)

E3D Toolchanger, RRF 2.x

Behavior

Travelmoves during a toolchange to the wipetower are very slow.

  • In my case, the tools are picked up outside of the printarea and do perform some preparing actions all done by firmware, when issued a T-command. From there, the printhead needs to move to the wipetower, generated by prusaslicer. This is usually a long move, ~150mm long. The speed of this move is very slow, like extruding speed of ~40mm/s

  • To recreate the problem, have the firmware do some toolchange preparation-moves outside of the printarea and use the wipetower feature.**

Expectation

  • Expected is a fast move, like the 300mm/s that is set in the option as travel speed OR to have an option to set this speed.

Actual happening

  • Actual, when looking at the gCode, there is no F-parameter at all in the mentioned travel move.

sources

is this a new feature request?

Maybe?

@lukasmatena
Copy link
Collaborator

Just for my reference: this seems to be a one-liner on WipeTower.cpp:1025 (function toolchange_Change). It needs some thought and testing to make sure that setting feedrate there will not affect further moves under any scenario.

@lukasmatena
Copy link
Collaborator

This issue should be fixed for 2.4.0 release ( 3459231 ). The move that is described above is now using travel speed as set in Print Settings.

I'll close the issue. Let us know if you consider the issue solved after first public 2.4 alpha is released (in several weeks probably). Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants