Extruder stalls because of problematic Gcode (instant retract without printing anything) #151
Comments
|
That code extrudes 4mm at 53mm/s and then retracts the same 4mm. If this is the first extruder move a blob and some lost steps are what I would expect. I think the idea behind this is that the end of the previous print sucked the filament 4mm in. Even then you might get a blob because of dropping filament during warmup. What printer du you have that can move z-axis with 600mm/s ? |
|
rostock mini, I actually tested it with 1,2 m/s velocity and 10 m/s^2 acceleration altough without the hotend mounted... yes it happes after a previous retract, mulitple times during the print here is the gcode: I will try again today with some fabricated Gcode and very slow extruder settings to see whats happening... |
|
Jerk is a possible reason. You are running 53mm/s in one direction and instantly in the other direction. That is the highest stress you can make, so jerk/acceleration could help to manage it. |
|
isn't this handled just like moving forward stop moving backward? |
|
Yes, it is handled like that. But normally you print slow->retract -> pause ->undo retract. |
|
okay, and the extruder jerk is defined by the start feedrate? |
|
Yes thats the same. |
|
there is definitely an issue with the firmware here: I used a jerk of 1 and acceleration of 500 for these videos: max speed 10mm/s max speed 80mm/s the stalling starts at max speed 35mm/s and seems to be independent from the max start speed of the extruder... |
|
Which firmware version are you using? The development version had a bug that caused such things but it was never in the master version. |
|
I updated to the current Master yesterday. should I try the development version? and this is the gcode I am using to force the problem: |
|
Yes, because it has many improvements for delta printer. And it is the only version where I'm fixing problems since it is the next great version. Since it was a problem in the master version I'm curious if it s gone. With all the changes you never know. |
|
the problem is still there, it happens as soon as i set the max feedrate over 30 mm/s but is unaffected by acceleration and extruder jerk! it would be great if you could fix this, i normally use 8mm retraction and this takes a while with 30mm/s... |
|
My delta does 7mm retract with 80mm/s without problems in this version. What are your settings for the extruder and how do you see the problem? I'm a bit confused by the videos you uploaded. There I saw no extrusion and I thought you were talking about xy moves there getting jerky. I hope I can test your script tomorrow and see something going wrong. |
|
a pure retract with 80mm/s is no problem. the problem are those G92 E0 moves in the first video you can see that the extruder moves fine altough for some reason the low extruder jerk settings seem to cause problems with the xy moves... in the second video the extruder simply stalls and the only thing I changed was the max feedrate to 80mm/s, and so when the next extrusion follow it pushes out too much filament resulting in blobs! my guess would be that when there is a problem in the jerk or junction calculation when there are 2 E commands after one another... you dont need my whole script simply try sending it should produce the error! |
|
I just ran the code without problems, just two short back/forth moves like in video 1 only in fast. Do you have advance enabled? That results in a different extruder handling and might be the difference. |
|
okay I overlooked that advanced and quadratic advanced was activated but when i comment it out i get a compilation error in hal.cpp saying extruder_disable() was not declared in this scope.. edit: i commented the line out lets see if it works now ^^ okay that fixed it! thank you very much! |
|
Simple set advanceL and advanceK to 0 to disable it. But I do not think that is the problem. junction speed computation seems also ok: |
|
advancedK and L were set to 0 in my configuration.h, now after deactivating advance completely and commenting the not compiling line in hal.cpp the extruder problems are gone! |
|
The compile error can be fixed with this line: But that line does not get executed during print anyway. Still strange that it now works. Looks like I need to recheck other code parts depending on USE_ADVANCE |
|
The above example works now... but sometime when there is a very small extrusion to fill a gap the extruder still stalls and the xy moves gets jerky! I will try to isolate this with an example... edit: update: bottom line, slic3r gap fill is the problem... I don't know if this also happens on normal printers or is rostock specific, but the small zig-zag line of the gap fill kill the printer... either it stops completely or when the gap is short you get strange jerk problem or the extruder stalls when retracting... I think the problem is that the message buffer gets emptied because of too many very short moves... |
|
I think i found one part of the problem now in motion.cpp computeMaxJunctionSpeed(previous,act); // Set maximum junction speed if we have a real move before I changed the code to if(previous->isEOnlyMove() != act->isEOnlyMove()) || (previous->isEOnlyMove() && act->isEOnlyMove()) now I got no more problems with this: |
|
If you set this to true, you would fix all speeds thus disabling path planning completely. So it may solve your problem but introduce new problems. |
|
yeah i realised this so I changed the line... see the post above... |
|
I think I have fixed this issue. I had similar issues on my rostock max, and can verify the skipping with the gcode you provided. The issue is that on fast extrude/retracts, the code will run straight from extrude to retract with no decel/accel or jerk test. The code seems to mess up some signs, causing further breakage. I tested my own previously failing gcode and yours, and all seems to be well now. However, I don't know this code well enough to guarantee that this fix is correct. (Note that the GitHub Markdown really screws up the following patch; I don't know how to stop that) diff --git a/src/ArduinoAVR/Repetier/motion.cpp b/src/ArduinoAVR/Repetier/motion.cpp
if (e_diff >= 0) |
|
thx for the fix karloygard, I'm trying it out right now with a print that always skipped extruder steps and till now I got no problems at all! |
|
Eeeeeexcellent! Please post back if you see any detrimental effects on prints. As I mentioned, I don't know the code well enough to say that the fix is 100% correct. |
|
I reverted my changes in the code and everythings still works fine, I run some of my problematric prints without problems and no extruder stalls! Altough i can't tell if it effects quality because my hot end broke... |
|
sadly I found some Gcode which still causes the extruder to stall G1 X-8.694 Y-7.833 E15.77023 after a travel move to a new position there is a very short extrusion and the retract after that stalls, if you add another travel move in between no stall takes place. edit: I did some further testing, the short extrusion is not the problem, it also happens if you remove the extrusion and use this code: G1 X-8.694 Y-7.833 E15.77023 so there seems to be a problem with retracts or perhaps all E only moves after very small XY moves! and again the stall only happens for extruder speeds above 30mm/s so I quess the acceleration is messed up |
|
Cool stuff, I'll take a look at it tonight. |
|
did some further testing, the retract fails as soon as the travel move before is under .03 mm... G90 ; use absolute coordinates and it seems the extruder goes directly into double/quad stepping disabling quad stepping gives you a deeper stall "sound" than with quad stepping enabled. |
|
I can't reproduce that issue. I tested acceleration and deceleration, and I can't find anything unusual. Are you sure you just aren't reaching the limits of your extruder? |
|
i use max feedrate 80mm/s start feedrate 10mm/s and acceleration of 2000mm/s^2. It works fine alle the time, thanks to your fix, except after this small moves the extruder stalls. Maybe it's because you have rostock max and I use a rostock mini? Different computation of the kinematics? |
|
Okay, I'll do some more testing tonight with your values. |
|
okay I really don't know what is happening here: G1 X-6 Y-13 F36000.000 or G1 X-6.281 Y-13.81 F36000.000 G1 X-6.01 Y-13 F36000.000 |
|
I suggest looking at the code that calculates the length of the movement vector. Kyrre From: luke321 okay I really don't know what is happening here: G1 X-6 Y-13 F36000.000 or G1 X-6.281 Y-13.81 F36000.000 G1 X-6.01 Y-13 F36000.000 it is not only related to distance but also to the position of the endeffector... — |
|
what I don't understand is why a mixed xyze move destroys the start speed settings of an Eonlymove which should always be safe if I understand the code correctly... this part in motion.cpp should prevent the forward and backward planner to mess with EOnlyMoves right? if(previous->isEOnlyMove() != act->isEOnlyMove()) So the start speed settings of the EOnlyMove are incorrect even before the updateTrapezoids function is called? how can I view the Debug messages? |
|
Well, that code only runns if they are not equal. Is this the expected behaviour? Kyrre From: luke321 what I don't understand is why a mixed xyze move destroys the start speed settings of an Eonlymove which should always be safe if I understand the code correctly... this part in motion.cpp should prevent the forward and backward planner to mess with EOnlyMoves right? if(previous->isEOnlyMove() != act->isEOnlyMove()) So the start speed settings of the EOnlyMove are incorrect even before the updateTrapezoids function is called? how can I view the Debug messages? — |
|
by default startspeed and endspeed should be computed with safespeed() as far as I looked into the code... it gets set in PrintLine::calculateMove() I tried to set some parameters for the EOnlyMove like this. |
|
Luke, Can you slow the acceleration way down to see exactly what the extruder is doing? I've been doing that in order to check that accel/decel actually runs. Set accel to eg. 50. If you turn on Echo in Repetier, you'll get tons of debugging, but it's not very easy to decipher. There is more logging to be had as well, but that requires recompiling the firmware.
|
|
okay it works with acceleration values up to 100 mm/s^2... where do i have to activate echo? In repetier.h i activated debugging but I'm still getting nothing in repetier host. Or do I have to use another programm for debugging? |
|
Ok, vacation is over and I'm ready to join the problem. First thanks to @karloygard , you were right with your observation. I never checked the queueEOnly. I have now deleted that line you changed and changed in the function the distance calculation to that should have the same effect, since delta is always positive and it removes one computation to speed up computation. For debugging make sure repetier.h has With the small moves followed by pure e move the emove should start with start speed,since |
|
found the problem: this is a after a small move with stall: i added the right parameters in comparision to a working move 16:56:13.283 : N57 G1 E7.77051 F4800 *24 for me it looks like the retract move is getting mixed up with the short travel move.. because the distance is exactly the 0.02mm the travel move should have... here is the link to the complete log files: https://www.dropbox.com/s/gku5ow7r1d4m89t/stall.rar ps.: welcome back! i hope you guys can fix this, than my rostock mini would be perfect ;) |
|
Sometimes the z lift after the retract is also very jumpy! maybe this is also connected to this and the z-lift happens with 1 accel step? |
|
I just uploaded a new dev. version, where I changed rounding to steps. Can you test if your examples get no 1 step moves with extrusion with them? I tried to get your problem with different coordinates, but all tests got 0 for xyz, so I could not test if it helps. |
|
It is working with the above example! I'll try some other prints tomorrow and give you feedback! |
|
Okay I had it happen one time today, while printing the tree frog. I'm gonna try to find the specific part of the code. |
|
I have just finished an other change but not uploaded yet. It makes E move dominant if e > xyz move, which should even help if you get such rounding errors. First tests show correct move data, but I want to run a test print before I upload that version. |
|
okay please post here as soon as you uploaded it and I will check it out! G21 ; set units to millimeters |
|
Ok, test print looked ok, so I uploaded the latest change. Hope that solves all remaining problems. |
|
It works with the above example! I think its resolved now if I find anything else I post back! |
So I have some .stl files which slic3r can't process, but Simplify 3D Creator is able to process them but sometimes generates a move to a point where he simply does the following
retracted previously than moves to new position...
G0 Z0.25 F36000
G92 E0
G1 E4 F3200
G1 E0 F3200
G0 Z1.25 F36000
moving to the position pushing the filament forward and than retract the filament instantly again.
but the extruder makes some strange noise and simply leaves a big blob of pla behind.
I will make a video when i get home to clarify!
The text was updated successfully, but these errors were encountered: