Jumping Belts When Print Finishes

[lars86 42]

Hi guys,

I don't know if it is related to the newer Marlin firmware, or the newer version of Cura, but I have a strange issue where after a print, as the head moves away, I'm either jumping the belts, or skipping steps.

I'm running GT2 belts, and have everything tuned for very nice motion. The print head can be manually moved by hand easily. I can 250mm/sec for travel moves with ease, yet something gets screwed up on the final retract move.

Here is the tail end of the code I just ran:

 

G1 F2700 X114.426 Y134.507 E182.46481G1 F2400 E179.46481G1 Z0.900G0 F15000 X114.426 Y134.507 Z5.800;End GCodeM104 S0                     ;extruder heater offM140 S0                     ;heated bed heater off (if you have it)G91                                    ;relative positioningG1 E-1 F300                            ;retract the filament a bit before lifting the nozzle, to release some of the pressureG1 Z+0.5 E-5 X-20 Y-20 F15000 ;move Z up a bit and retract filament even moreG28 X0 Y0                              ;move X/Y to min endstops, so the head is out of the wayM84                         ;steppers offG90                         ;absolute positioning

 

Could I be skipping steps when trying to move all 3 axes at full speed?

G0 F15000 X114.426 Y134.507 Z5.800

 

[gr5 2,173]

Definitely. There was a bug in Marlin that happened when you moved all 3 axes at the same time. I thought the bug was fixed approximately a year ago but maybe not. The bug meant that it would move some axes faster than they are supposed to move (but again, only if you move all 3 axes at the same time).

Normal Cura generated gcode never (or rarely) moves all 3 axes at the same time.

[gr5 2,173]

Actually the bug fix might be in "normal" "erikZalm" Marlin but it might never have gotten into the ultimaker branches of Marlin. The bug and probably the fix were posted in the erikZalm branch of marlin on github a year or two ago by "Illuminarti" aka "Simon" so it shouldn't be too hard to search for that patch and then see if it got pulled into Daid's versions of Marlin for UMO and/or UM2.

Edited June 1, 2015 by Guest

[lars86 42]

Thanks for the insight!

I edited the Gcode and reduced feed to 5000 mm/min on that G0 move, but left the:

 

G1 Z+0.5 E-5 X-20 Y-20 F15000 ;move Z up a bit and retract filament even more

 

line the same. The initial lift seemed fine, then that second fast move skipped steps.

I'm wondering if that bug could also be the intermittent extruder step skipping I see during a retracting, Z-hopping, rapid moves. I keep tuning my extruder motion parameters to help mitigate it, but after watching the movement work perfectly a bunch of times, I'll leave the room, then hear skipped steps, and come back to under-extrusion.

@Illuminarti and @Daid, help!!!

[gr5 2,173]

Unfortunately Illuminarti is extremely busy handling USA UM customer support and rarely visits the forum. And Daid is angry that UM changed the forum -- I haven't seen any of his posts lately either. So I doubt those 2 will help you. But maybe someone else will.

[lars86 42]

Is this the thread/bug you were referring to?

https://ultimaker.com/en/community/view/2734-marlin-bug-the-myth-of-retraction-speed?page=1

[lars86 42]

Is it possible that tuning the stepper driver current could help with this? I've never done that.

[gr5 2,173]

I don't think that's the bug, no.  It was different.  In marlin it looks at the movement and plans out an acceleration phase, a constant velocity phase, and a deceleration phase for every move and there is also the jerk limitation at the endpoints.  The code is written such that it may be the XY acceleration that limits the acceleration or it may be the Z or E acceleration that limits the acceleration.  But the code that checks this has a bug I think and so the XY acceleration can be exceeded in certain cases - possibly by a factor of 10.  I *think* that was what the bug was but not certain.  Maybe easier to look on github than in the forum as Simon has only had 2 or 3 pull requests ever I think.

Edited June 3, 2015 by Guest

[lars86 42]

This one?

https://github.com/Ultimaker/Marlin/pull/7

[lars86 42]

I found that those changes were not adopted in the latest firmware I am using. I backed up those files and hand edited in the changes. There is one line shown in the the change log (but not changed), that doesn't match up:

Changelog:

block->acceleration_rate = (long)((float)block->acceleration_st * 8.388608);

My file:

block->acceleration_rate = (long)((float)block->acceleration_st * (16777216.0 / (F_CPU / 8.0)));

[gr5 2,173]

That one you link to is it - that's the one - nice find - I'll add it to my notes.

[lars86 42]

Okay, so I finally edited my planner.cpp to implement those changes.

I ran prints that caused this issue back to back with the new firmware changes, using Slic3r's "wipe during retract" option to help show the issue. This causes more frequent movements that involve all axes simultaneously.

It seemed to improve it slightly, but the steppers skipping steps still exists.

Is there a possibility of fixing this with stepper drive tuning?

[gr5 2,173]

No there is almost certainly a bug in Marlin. Is there a way to have fewer axes moving at the same time? Or just lower the feedrate (speed) to the maxv of the slowest axis on multiaxis moves?

I think Marlin is ignoring one of the "max" parameters - either max accel or max speed - but only on multiaxis moves. Usually X and Y are the limiting speed factor because usually the extruder hardly moves at all compared to those axis and the Z axis usually doesn't move at all or in spiralize it moves a very very small amount. It's only when Z or E axis moves longer distances and simultaneously X or Y move very small distances. I assume. Right?

[lars86 42]

So, besides the print end move (XYZE), I am seeing the skipped steps when doing a retracted rapid, with "wipe" enabled. Instead of performing the retract move first, then making the rapid move, it allows the retract to happen during the rapid positional move. So simultaneously it is retracting, doing a Z lift/hop, and moving XY in rapid. This avoids the print head dwell during retracts.

It's not the only way to do things, but it should still work in my eyes.

[gr5 2,173]

It's somehow getting the max acceleration or max speed of E or Z axis confused with XY axis.

It looks at the distance it needs to move in XY, E and Z. It tries to figure out which axis is the limiting axis and it usually correctly identifies XY axis and it uses that axis accel/jerk limits and applies this to all the axes (for example if XY jerk is 20 and XY is limiting axis then XY axis moves with jerk of 20 but E axis may be moving 1/10 as far so it's jerk is set to 1 and D axis may have be moving 1/2 as far in this move so it's jerk is set to 10 in this move. Then it does a similar thing for the accelerations and max speed. Somewhere in this logic it messes up and instead of limiting XY jerk to 20 it sees that E jerk is 10 and then says XY moves 10X as far so sets the XY jerk to 200. Or similar with the acceleration. Something like that. The code is complex and confusing. If you set jerk to 200mm/sec then it will go from 0mm/sec to 200mm/sec instantly (infinite acceleration, infinite true jerk) which won't work and it will skip steps.

It would be easy to fix if I understood the problem - I think setting feedrate to 1mm/sec might fix the problem. Or better to just not move 4 axes all at once. Ideally it would be best to understand the bug 100%. The code is here:

https://github.com/Ultimaker/Ultimaker2Marlin/blob/master/Marlin/planner.cpp

I think around line 840-860 but I could be totally wrong and it's a bug somewhere totally different.

[gr5 2,173]

It would be helpful if you could publish the exact line of gcode that causes the problem *and* the 2 moves before that (to establish the incoming junction speed and such).

[lars86 42]

The newest Marlin build has that section of code rewritten. I'm hoping they nailed it this time:

https://github.com/MarlinFirmware/MarlinDev/issues/77

[neotko 1,417]

Was this only fix for um2 marlin or it also was on umo/umo+? If not it just as easy as using the planer from um2 firmware and compile?

[tinkergnome 927]

Was this only fix for um2 marlin or it also was on umo/umo+? If not it just as easy as using the planer from um2 firmware and compile?

 

AFAIK these are changes of the Marlin development tree. Those things are not ported to any of the Ultimaker firmwares. Neither for the UM2 nor the UMO. And i don't expect that this will ever happen...?

Anyway- the main idea seems to be: limit the acceleration to the minimum allowed value of all moved axis, right?

The (old and new) code looks a bit over complicated..., perhaps the developers tried to optimize it for performance or such things...?

[lars86 42]

There is definitely some development going on in the main Marlin branch on Github.I think they are getting close to a release, though I'm not sure how extensive the port to UM specific firmware is.

Their response to this issue was that they have rewritten much of the code that governs this, so it would need to be tested to see if it was fixed.