UBL : uneven printing moves on Bugfix

[joris57]

With UBL switched on (corexy), printing moves are so uneven that the the borders of the probing grid are clearly visible on the print surface.

[Roxy-3D]

Can you show us a video?

[joris57]

You can find a video here : https://drive.google.com/open?id=11Ja9cLx8UBMKiTy4EfzkSUCC7RyeHeTW

At the beginning of the print, UBL is active. You can clearly see the grid lines. Then UBL is deactivated and the gridlines disappear.

A few seconds into the video, UBL is reactivated and the gridlines reappear. You will hear the stutter in the audio. The irregularity seems to be in the X/Y movement, I don't notice stutter in the Z leadscrew movement or the extruder. A bit later UBL is disabled again and the gridlines disappear again.

[thinkyhead]

Are you certain you have a good accurate mesh and the nozzle isn't being driven too low when UBL is enabled? Please paste the output of M420 V so we can have a look at the mesh.

[Roxy-3D]

That is very strange. Are you using bugfix-1.1.x ? Besides the mesh, can you post a G29 W and your Configuration.h files?

[joris57]

@thinkyhead Have you looked at the video? I don't think the perfect 31 mm squares that appear and disappear can be attributed to the nozzle being driven too low, would you agree?

@Roxy-3D bugfix-1.1x of yesterday.

Requested data attached.

In the meantime, I've reloaded the printer with a configuration for ABL (bilinear) and I see something similar, this time with a repetition rate of 5mm (from #define LEVELED_SEGMENT_LENGTH 5.0 ???) along the print direction.

So i looks to me like the printhead slows down at the end of a print segment (either at the border of a cell or at the end of a 5mm sement).

M420_V.txt G29_W.txt Configuration.h.txt

[Roxy-3D]

Have you looked at the video? I don't think the perfect 31 mm squares that appear and disappear can be attributed to the nozzle being driven too low, would you agree?

It has something to do with the way lines are split as they cross mesh boundaries. It would be helpful if you can verify the nozzle is not shift in its height as it crosses the mesh boundaries. Because once that is confirmed, the other possibility is slightly more (or less) filament is coming out. The cause of this might be several things. There might be a slight pause and some extra filament ooozes out. Or it might be there is an error in the calculations and that is causing the artifacts.

Your mesh isn't crazy. But you do have more left to right slant than is ideal. You will have better results if you can correct the left to right slant some what.

That is very strange. Are you using bugfix-1.1.x ?

It will be helpful to know which code base you are using.

[AnHardt]

Is 'lineare advance' involved?

define DEFAULT_ZJERK 0.0 //JJ

is a really bad idea. It means x/y has to slow down to zero at every z-direction change.

[AnHardt]

Come on @Roxy-3D , @thinkyhead . We have seen that before - just not in this glorious intensity.

[Roxy-3D]

@AnHardt I think you have found the root cause of the problem! If the nozzle has to stop as it crosses a mesh line, the filament will keep ooozing out and you will see an artifact on the surface!!!! THANK YOU!!!!!

@thinkyhead Can we have a Sanity Check that disallows a Z-Jerk of 0.0 for Linear Advance?

@joris57 Can you change your DEFAULT_ZJERK to a 'reasonable' value and see if the problem goes away? And if that doesn't cure the problem... Can you try turning Linear Advance off and seeing if the problem still exists?

[joris57]

I set the DEFAULT_ZJERK back to the original value (0.3) and the artifact and the stuttering disappeared as predicted.

Note that "linear advance" was not on, so the sanity check should be executed (at least) also for UBL and Bilinear ABL.

Great troubleshooting, guys. Can I close this issue?

[Roxy-3D]

Great troubleshooting, guys. Can I close this issue?

Soon! Let's leave it open until @thinkyhead sees this and makes a decision on whether we should put a Sanity Check in to cover this case.

[thinkyhead]

A sanity check seems like a good idea, and it might be good to throw a warning if this is set via G-code when leveling is enabled — and maybe even when leveling just happens to be available.

[thinkyhead]

Come on @Roxy-3D , @thinkyhead . We have seen that before - just not in this glorious intensity.

I must have been elsewhere when this was discussed.

[thinkyhead]

#if HAS_MESH
  static_assert(DEFAULT_ZJERK > 0.1,
    "Setting DEFAULT_ZJERK too low may cause bad behavior with "
      #if ENABLED(MESH_BED_LEVELING)
        "MESH_BED_LEVELING"
      #elif ENABLED(AUTO_BED_LEVELING_BILINEAR)
        "AUTO_BED_LEVELING_BILINEAR"
      #elif ENABLED(AUTO_BED_LEVELING_UBL)
        "AUTO_BED_LEVELING_UBL"
      #endif
    "."
  );
#endif

[Roxy-3D]

I think it would be OK to simplify this:

#if HAS_MESH
  static_assert(DEFAULT_ZJERK > 0.1, 
        "Setting DEFAULT_ZJERK too low may cause bad behavior with mesh based leveling systems." );
#endif

[thinkyhead]

I can do that. And for M205 Z…

  if (parser.seen('Z')) {
    planner.max_jerk[Z_AXIS] = parser.value_linear_units();
    #if HAS_MESH
      if (planner.max_jerk[Z_AXIS] <= 0.1)
        SERIAL_ECHOLNPGM("WARNING: Low Z Jerk may lead to unwanted pauses.");
    #endif
  }

[AnHardt]

This is (again) fixing only the symptoms you see, not fighting the reasons. Any jerk of any axis being 0, or very low, will cause that axis to be very slow around a change of direction. Slow enough to let us see oozing effects. Here especially at the points where a ,in xy straight move, is subdivided, but in general always when an axis with very low jerk changes direction.

Possible fixes/workarounds. Spread the knowledge about 'zero jerk is crap.' Limit jerk on all axes to be above a unknown limit. (where did you get the idea about 0.1? It's a gradual process. (1) ) Enabling LA could help. Change to a calculation of junction speeds where minor changes in direction cause minor drops in speeds. (grbl?)

(1) How fast/slow is jerk 0? That should be determined by MINIMAL_STEP_RATE and steps/mm of that axis. ( Interestingly a highly hardware (timer) dependent value like MINIMAL_STEP_RATE is still a fix constant)

[Roxy-3D]

(1) How fast/slow is jerk 0? That should be determined by MINIMAL_STEP_RATE and steps/mm of that axis. ( Interestingly a highly hardware (timer) dependent value like MINIMAL_STEP_RATE is still a fix constant)

• v = d(distance)/dt
• a = dv/dt
• jerk = da/dt

If the jerk was REALLY 0, it implies the acceleration is also 0. Obviously the GRBL code isn't respecting a truely 0 jerk, because if it did... the nozzle could never accelerate.

So... if GRBL is not respecting the 0 number for jerk, I guess it always assumes it can bump the step rate by 1 unit???

[AnHardt]

jerk = da/dt

OMG, you discovered the physically correct definition for jerk. We never used that! In Marlins context jerk is the maximum speed an axis can start with from zero in mm/s.

Grbl is not using jerk anymore. Their term is "junction_deviation". https://github.com/grbl/grbl/search?utf8=%E2%9C%93&q=jerk&type=

If i remember correctly our former definition of jerk was "maximum speed difference of an axis between two moves."

[p3p]

From the config.

• "Jerk" specifies the minimum speed change that requires acceleration.

Marlins "jerk" is the maximum instantaneous velocity impulse that can be handled by the hardware configuration, shouldn't really be compared to actual jerk but works .. mostly. Therefore a jerk of 0 will mean on any junction where an axis needs to start from 0 all other axes need to match that velocity before an acceleration can be started, you can see how that will not make for a smooth print when you introduce a zero jerk Z axis with mesh bed levelling.

[thinkyhead]

where did you get the idea about 0.1?

As an open source project I like to put in placeholders from time to time that will get corrected later as more knowledge accumulates. Often this results in quicker action than endless discussion. People just love to point out mistakes.

[thinkyhead]

OMG, you discovered the physically correct definition for jerk.

"One who cannot resist snarking"?

the maximum speed an axis can start with from zero in mm/s If i remember correctly our former definition of jerk was "maximum speed difference of an axis between two moves."

I believe it still applies to any instantaneous change in speed, not just from zero. But don't quote me on that.

Their term is "junction_deviation"

Indeed. We have discussed whether to apply junction deviation before. A commented-out section with some junction deviation code has been hanging around in planner.cpp for a long time, actually.

[Roxy-3D]

OMG, you discovered the physically correct definition for jerk.

"One who cannot resist snarking"?

Actually... He was being very gentle and kind. That list where I was trying to convey my thinking should have had C's everywhere. And for sure he knew that.

• v = d(distance)/dt + C
• a = dv/dt + C
• jerk = da/dt + C

[thinkyhead]

Actually, I quite enjoy our snarkiest contributors. And junction deviation is something we're long overdue to include, if only as an option.

[github-actions[bot]]

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.