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

Extrusion during pause should, somehow, correct E position... #70

Closed
cakeller98 opened this issue Oct 27, 2011 · 4 comments
Closed

Extrusion during pause should, somehow, correct E position... #70

cakeller98 opened this issue Oct 27, 2011 · 4 comments

Comments

@cakeller98
Copy link
Contributor

(oops this was originally posted as issue in sprinter, my mistake, it should have been here)

During a recent print, I paused because I could see there was a plastic problem, so I homed in X and Y.... of course, the nozzle sitting there oozed etc, so I primed the extruder....

After I resumed, the extruder RETRACTED the amount of extrusion I had extruded to prime.
In other words, when I manually extruded 150mm and then resumed, the next E command was now 150mm backward from where the board thought it was, so it retracts 150mm to get there... (IT IS BAD to retract too much filament, gets soft filament into the pinch-wheel... BAD BAD BAD :) )

On Pause it would be nice if Pronterface PUSHed the XYZE position of the last G-Code sent.
Then when un-pausing POPed that position back by, moving to that stored Z position, then that X/Y, then G92'd that E position!

Ideally... maybe even start with Z + some offset, then drop down to the correct Z after the rest...
G1 Z+2.0,
G1 X Y,
G92 E
G1 Z


What do you think?? if this sounds like a good idea - I might give it a shot. If there's a better way to do it, let me know (maybe I'm doing something stupid)

@kliment
Copy link
Owner

kliment commented Oct 29, 2011

Thanks, I saw it before. It's only a problem for E, because XYZ get
reset on the next move and the firmware knows to adjust acceleration to
match. Saving and restoring E is a very good idea though. I've been
looking into tracking E in printrun anyway, because it's a much better
progress indicator than what we have now. So I recommend we add "save E"
to the pause command and "restore E" to the resume command, and make it
only work when NOT printing from SD, because then we don't know the
current E value. Are you interested in doing this or should I give it a go?

Kliment

On 10/27/2011 02:46 PM, Christopher wrote:

(oops this was originally posted as issue in sprinter, my mistake, it should have been here)

During a recent print, I paused because I could see there was a plastic problem, so I homed in X and Y.... of course, the nozzle sitting there oozed etc, so I primed the extruder....

After I resumed, the extruder RETRACTED the amount of extrusion I had extruded to prime.
In other words, when I manually extruded 150mm and then resumed, the next E command was now 150mm backward from where the board thought it was, so it retracts 150mm to get there... (IT IS BAD to retract too much filament, gets soft filament into the pinch-wheel... BAD BAD BAD :) )

On Pause it would be nice if Pronterface PUSHed the XYZE position of the last G-Code sent.
Then when un-pausing POPed that position back by, moving to that stored Z position, then that X/Y, then G92'd that E position!

Ideally... maybe even start with Z + some offset, then drop down to the correct Z after the rest...
G1 Z+2.0,
G1 X Y,
G92 E
G1 Z


What do you think?? if this sounds like a good idea - I might give it a shot. If there's a better way to do it, let me know (maybe I'm doing something stupid)

@cakeller98
Copy link
Contributor Author

I would LOVE to. Unfortunately, I don't know python much at all, and I don't have the time at the moment..

@cakeller98
Copy link
Contributor Author

OK I'll give it a shot, and let you know - I found an extension for VS 2010 for python, so I'll see if that helps me "get" the python part.

will keep you posted, if I get stuck, I might pass the ball back to you. If you've already started, sorry I didn't jump on it sooner!

@kliment
Copy link
Owner

kliment commented Jun 3, 2013

Fixed in current experimental and latest binaries

@kliment kliment closed this as completed Jun 3, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants