Pauses in K factor test pattern - read ahead issue?

[Squid116]

When I am printing the k-factor test pattern, the hotend slows right down/comes to a complete stop after the initial slow segment - I would have expected the planner to have detected the change of speed is moving in the same direction and not slowed down/or stopped towards the end of the slow segment? Because of this I am seeing blobs at the start of the fast segment even with K=0.

I don't think I have configured anything that would have messed with the read-ahead like this, but I'm
not 100% sure,and I don't know where to look.

Happens both from USB and SD card.

here is my config:
https://github.com/Squid116/Marlin/blob/bugfix-1.1.x/Marlin/Configuration.h

and config_adv:
https://github.com/Squid116/Marlin/blob/bugfix-1.1.x/Marlin/Configuration_adv.h

kfactor (16).gcode.txt

(Edit: updated links to correct branch in my github repo)

[Squid116]

Here is a quick video showing the pause:
https://youtu.be/wWB5UVfcHV8

[thinkyhead]

What is your Z Jerk set to? Try increasing it to see if it helps.

[Squid116]

Z zerk @tinkyhead? Sure you don't mean E jerk?

[thinkyhead]

No, I mean Z Jerk.

[Squid116]

But it isn't moving in z at all? I have the same results with ubl disabled.

[thinkyhead]

That answers my question, then. In some instances having too small a Z jerk interacts with bed leveling to create unwanted pauses. If I think of anything else for you to try, I'll let you know.

[Squid116]

I'll try the jerk anyway and see, but unless G29 D isn't working, I doubt it.

Could it be related to my lowish acceleration values? It should be reaching speed in those distances...not that I'm sure that matters.

[thinkyhead]

There should be no pauses in the middle of single linear moves. Would you mind attaching the G-code you're using so we can make sure it has no weird issues? (May need to ZIP it first.)

[Squid116]

@tinkyhead, already Attached to first post. Kfactor (16).gcode.txt

[Squid116]

I have a re-arm sitting on the shelf, waiting for the right time to pull it out, could this be that time?

[Squid116]

Used the same file but removed the G29, and manually did a G29 D beforehand, same result.

[thinkyhead]

@Sebastianv650 — How does E jerk affect the behavior of the K-factor test? Can it lead to pauses as the extrusion amount changes in that test?

[Squid116]

I can try upping the E jerk in the morning, and see how it goes. What is a sensible value? Titan extruder (3:1), 16 microsteps, 837 steps/mm

[Sebastianv650]

If the exactly same thing happens with K=0 we can rule out E jerk. Also the low acceleration shouldn't hurt, if any it should help for the print. My first intention watching the video was also in the bed leveling direction. Can we say for sure that Marlin with UBL enabled but without G29 behaves like Marlin built without UBL? Never played with UBL, so it's maybe a dumb question..
If we can rule out UBL, I will load the latest bugfix to my printer and check if I can see something strange during the pattern.

How does E jerk affect the behavior of the K-factor test? Can it lead to pauses as the extrusion amount changes in that test?

E jerk can slow down the used acceleration for the print move, but it will never alter entry or exit speeds.

What is a sensible value? Titan extruder (3:1), 16 microsteps, 837 steps/mm

I don't know, but if you find one let us know as I will convert my printer to a Titan as soon as my 3mm filament is eaten away :)

[Squid116]

This morning I tried:
Changing to bilinear
Changing to no levelling
Doubling jerk

All with no noticeable difference to the result. I'm going to try the alternate pattern to see if the problem is only with the first segment.

[Squid116]

Just tried the alternate pattern and the pauses still seem to be there on the acceleration phases, although the blobbing seems to be less.

Is there a way to check the entry and exit speeds?

[Squid116]

Just tried with //#define LIN_ADVANCE commented out and same behavior.
Also tried increasing the length of the slow segments, no dice.

[Squid116]

Changed the slow print speed to 10 - Bingo! It worked, no pause, could see a nice starvation at the start of fast segment.

Same result at 15, but a pause for 20 and higher (also test 50).

Just a thought that it might be pausing at 10 & 15, but the deceleration phase is fast enough that I cant see it/it isn't notable, but it definitely produces the result id expect from a LA test (with LA disabled) which the faster speeds don't.

[Sebastianv650]

Good to know it's LA independent. I should be able to do some tests this evening.
First thing to check is if the problem persists if there is no E movement..

Is there a way to check the entry and exit speeds?

Nothing you can enable by sending an M code or so, but you can insert some serial echo lines inside the planner and/or the trapezoid_generator_reset function which is called once on every new executed block. But it will slow down the execution speed so it's only useful to test specific short gcodes like this slow-fast-slow combination.

[jokeman3000]

I can confirm this behavior as well, at first I thought it was because I enabled Bezier_Jerk_Control but upon disabling the issue remained. Also using UBL for whatever that's worth.

[Sebastianv650]

I can reproduce the issue even with X axis only moves. I guess it wasn't noticed until now because it's only noticeable with very low acceleration values. With a=100mm/s² it's obvious, with 1000 it's not visible.

Let's see what's the reason behind it!

[Sebastianv650]

The jerk limiting code inside the planner is limiting the junction speed between slow-fast moves to the axis jerk speed. During the fast-slow transition, no limit is applied so
vmax_junction = min(block->nominal_speed, previous_nominal_speed);
is used as junction speed.

I don't understand the meaning of the smaller_speed_factor involved in v_exit calculation, but I guess that might be the crucial point.
@thinkyhead do you understand this section of the jerk code? I compared it with Prusa FW and its behaviour is identical, so it's no fault which occurred after its porting to Marlin.

[Sebastianv650]

I'm not sure if the current way of calculating "jerk" is doing what we want at all:

• If we define jerk as a speed change per axis as we do it at the moment, the observed behaviour (stop between slow-fast) is true: The speed change on X is 70-20 = 50mm/s for example. 50mm/s > jerk (say 5mm/s) so the printer has to slow down to 5mm/s during the junction.
  -> In this case, the issue is in fact the not used jerk speed during the fast-slow transition!
• Logically, we want the junction speed in this example to be 20mm/s (=speed of slow section) in both slow-fast and fast-slow transitions as it results in 0 jerk due to acceleration regardless of the used speeds for fast and slow part..
• Again "logically" jerk means an amount of speed change due to a direction change. We can't detect direction changes by comparing each axis independetly from each other as the current code does.

All the madness is visible if you let Marlin travel along a regular poligon like an octagon at constant speed. Each cornering happens by the same angle, so I would expect the same junction speed due to jerk at each corner.
I used a nonagon for this part, circling it twice, here is the result showing the junction speeds:

Gcode:

G91
G1 F4200
G1 X7.019 Y-19.284
G1 X17.772 Y-10.261
G1 X20.209 Y3.563
G1 X13.191 Y15.72
G1 Y20.521
G1 X-13.191 Y15.72
G1 X-20.209 Y3.563
G1 X-17.772 Y-10.261
G1 X-7.019 Y-19.284
; second loop
G1 X7.019 Y-19.284
G1 X17.772 Y-10.261
G1 X20.209 Y3.563
G1 X13.191 Y15.72
G1 Y20.521
G1 X-13.191 Y15.72
G1 X-20.209 Y3.563
G1 X-17.772 Y-10.261
G1 X-7.019 Y-19.284

Junction speeds:

4.00 (start = jerk speed)
7.64
8.00
6.75
6.22
6.22
6.75
8.00
7.64
11.69
7.64
8.00
6.75
6.22
6.22
6.75
8.00
7.64

If we want to stay with the per-axis code (think about deltas, Core and others) we have to understand how to fix the special case "same direction - increased speed". And make a decission which behaviour is the wanted one.

[Squid116]

@Sebastianv650 Thanks for that investigation - I thought I was going mad, but good to see it isn't just me...

[thinkyhead]

My initial reaction is, "Dammit, are we ever going to fix the bloody jerk code? We've been over this a million times, and there's no end to the problems."

I would recommend we take whatever Grbl is currently doing and completely replace our broken jerk implementation, assuming it's not just as bad.

[Sebastianv650]

In fact the grbl planner looks incredible lean, so it's always worth a look anyway. Only regarding the trapezoid realtime-calculation and step execution I'm not sure if this can be transfered to Marlin. And the planner is not written for deltas.

I can't invest the time for a planner port at the moment, but just mention my name if there are questions if someone starts it. I spent some time last winter for initial thoughts for planner changes, so maybe I can help in some cases.
And of course it's always fun for me to test and analyze the behaviour of a planner like I did above :)

[Squid116]

// Calculate jerk depending on whether the axis is coasting in the same direction or reversing.
const float jerk = (v_exit > v_entry)
    ? //                                  coasting             axis reversal
      ( (v_entry > 0 || v_exit < 0) ? (v_exit - v_entry) : max(v_exit, -v_entry) )
    : // v_exit <= v_entry                coasting             axis reversal
      ( (v_entry < 0 || v_exit > 0) ? (v_entry - v_exit) : max(-v_exit, v_entry) );

Following on from what @Sebastianv650 suggested, I think this code is the root of the problem - I think coasting vs reversal is the wrong concept to apply here.

At the end of the day we are either accelerating, decelerating or maintaining.

• If accelerating or maintaining on a given axis
  • no changes to the junction speed should be made.
• If decelerating on an axis:
  • the junction speed should be restricted so the axis doesn't exceed v_entry+max_jerk[axis], which will allow v_entry to be hit instantaneously.
  • if the deceleration is also a reversal (I'm not sure youd need to specifically check this) the junction should speed not exceed max(v_entry+max_jerk[axis], 0)

[thinkyhead]

My dad is getting a new hip tomorrow, and I'll be taking over a lot of duties in the family business for a little while

Best of luck! We're going miss your help around here. Be sure to check in from time to time.

[Sebastianv650]

Just wanted to report I redid my nonagon testpattern (see #10341 (comment)) with the new jerk code enabled, here is the result:

0.00 (initial speed, starting from 0)
70.00 (continued block, second half = nominal speed)
19.34
19.34
19.33
19.35
19.35
19.33
19.34
19.33
19.35
19.33
19.34
19.33
19.35
19.35
19.33
19.34
19.33

Looks like it works just perfect, at least in this short only travel moves test 👍

[thinkyhead]

@Sebastianv650 — That's encouraging news!

[Squid116]

@thinkyhead @Sebastianv650 @ejtagle @hoffbaked

I'm pretty happy that everything in my initial bug has been solved (plus heaps more) - is everyone happy to close this issue? Anything else the pops up should get its own issue.

[jokeman3000]

Well I'm definitely still experiencing it but i know that linear advance 2.0 is still in the works so if you want to close this I'm fine with waiting.

[Squid116]

@jokeman3000 is your problem due to the junction speed, or is it purely a LA thing?

[jokeman3000]

I believe linear advance, as it occurs with and without junction enabled. I did not have this issue with 1.0, it presented with 1.5 and it is just as you described in the first post.

[Squid116]

The slowdown at the junction will occur without junction enabled - the jerk calculation is wrong. Maybe it hasn't been noticeable previously, but it was there.

[jokeman3000]

Perhaps it could be with how the kfactor test is generated for 1.5, I'm not sure. I'm happy to test any alternatives anyone comes up with to help isolate the issue.

[thinkyhead]

is everyone happy to close this issue?

I suppose that as long as it's still being seen in the current bugfix branches, we might as well leave it open and continue to try to solve the problem.

[Sebastianv650]

@jokeman3000 I just retested the decribed problem and on my printer it's eleminated by the junction deviation option. If you still get the slow down to 0 issue, can run this code to see if we are talking about the same problem:

G28 X ; Home X
M204 T100 ; Set travel acceleration to 100mm/s²
G1 X80 F1200 ; Slow move
G1 X130 F4200 ; Fast move
G1 X160 F1200 ; Slow move

If you can't hear a slow down to zero before it accelerates to the fast section, you have another problem.

[jokeman3000]

OK - so ignoring the output quality (need to re-level) and the wire mess (in the middle of some cleanup), I think this video demonstrates the issue well. I switched to the alternate pattern to see if there were any changes but it seems as k increased, movement overall slows down. It really starts becoming evident at the 30 second mark. As soon as the test finishes and it goes about printing numbers and such, speed increases significantly.

https://streamable.com/s/kay33/ssuspq

[Sebastianv650]

You might call me blind, but I can't see the extruder going to full stop during a straight move in your video?

[jokeman3000]

I'm not sure how that's relevant, is linear advance about stopping or optimizing extrusion during movement?

The observation is that as K increases movement becomes slower, which junction deviation has definitely improved but the issue remains.

I assume that if it was working properly, the speed of the x,y movement should be consistent from line to line (it is the same movement after all), the only thing different from one line to the next would be the pressure of the filament coming out calculated based on k.

Again, if you want to close this issue that's fine, I'm just pointing out there is still an issue.

[FiCacador]

Isn't Linear Advance v1.5 supposed to do just that, slow the movement if necessary to ensure that the maximum E jerk value is respected?
On my printer I have tuned the E jerk value to 8, so these slow downs are minimized but the extruder still can keep up with it.

[jokeman3000]

I guess, what I go back to is in the following quote from the lin advance article (http://marlinfw.org/docs/features/lin_advance.html)

While you will most likely not run into this on direct drive printers with filaments like PLA, it will happen most likely on bowden printers as they need higher K values and therefore faster speed adaptions. If this happens to an amount you don’t want to accept, you have the following options

This is a direct drive printer, acceleration is set to 3000 on x, y and the default for z and e0. If I'm seeing these results then either the defaults need to be adjusted or there is a bigger issue. I don't mention jerk because per my understanding junction deviation trumps it.

[FiCacador]

If LA is enabled, the E jerk value is still taken in consideration, even if using junction deviation.
@jokeman3000 what values for E0 jerk and k are you using?

[jokeman3000]

I can double check when I get home tonight but it EJerk is most likely 5.0.

The item printed in the video is the kfactor test with a range of 0-2. I think the movement issues begin at a K of 0.6 or 0.8.

[FiCacador]

Then it's the E jerk limitation for sure that is causing the slowdown.

[jokeman3000]

Happy to adjust and try something else, I just assumed the default was the safe value. What is a decent value to try with? It's a e3d titan (and aero).

Perhaps the defaults need to be adjusted given the linear advance 1.5 requirements?

[Sebastianv650]

Yes, the slowdown is due to your e jerk limits. The issue here was a stop to 0mm/s on line junctions, which is not related to your "problem". So I think we should close this.

The maximum ejerk value will depend on the extruder used, trial-and-error is the best method I know.

[whimsycwd]

Very informative discussion! Really helpful.

Still, I have one problem.

Initial, it has centripetal force implementation, although disabled.
https://github.com/prusa3d/Prusa-Firmware/blob/3.0.7/Firmware/planner.cpp#L954

then change to new implementation, and delete relate code.
https://github.com/prusa3d/Prusa-Firmware/blob/v3.0.8/Firmware/planner.cpp#L1028

Is it just a mistake made by Prusa folks?

[thinkyhead]

Initial, it has centripetal force implementation, although disabled.

That comes from Marlin 1.0.0.

then change to new implementation, and delete relate code.

Marlin 1.1.6 or 1.1.7 adopted the jerk implementation from Prusa Firmware, but it's only recently that Marlin added the new tested and optimized version of Junction Deviation.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.