[BUG] Laser engraving blurry in the center of the image.

[THE-BOW]

When laser engraving, the center of the image is out of focus.

In the bidirectional movements, the start and end points are always sharp (left and right side), but the center deviates from the left and right depending on the direction in which the head moves.

In the following picture it can be clearly seen that the movement deviates both to the left and to the right.

In the ZIP file you will find the configuration files. -> Config.zip

I have also done tests using classic jerk. The result is identical.

I also attached a GCode which I could engrave without problems with the 8-bit Melzi board on Marlin 1.1.9.
I also tested this file with the same result.
Testfile -> Marlin 1.1.9 - Testfile.zip

I have no deviation in 3D prints and laser cuttings - just the engravings.

Test scenario:
Laser raised to focus point
X and Y axis aligned to zero point
Zero point set with G92 X0 Y0 Z0
Gcode executed by onboard SD card

System information:
Printer: Creality CR-10
Board: SKR 1.3
Firmware Marlin 2.0 Bugfix from 28.11.2019

[p3p]

I think this was mentioned before could you try changing Marlin.cpp @ line 612

  // Limit check_axes_activity frequency to 10Hz
  static millis_t next_check_axes_ms = 0;
  if (ELAPSED(ms, next_check_axes_ms)) {
    planner.check_axes_activity();
    next_check_axes_ms = ms + 100UL;
  }

to just

planner.check_axes_activity();

There is a PR in the queue that should improve laser engraving accuracy considerably if this isnt the cause.

[THE-BOW]

@p3p The change did it. Thank you.

@boelle Hi There - commenting out following line fixed it like p3p wrote.
Marlin.cpp - line 611 (in my version)
next_check_axes_ms = ms + 100UL;
As p3p wrote there should exist already a PR including this fix.
If so - we can close this issue.
Thank you

[p3p]

@thinkyhead we can trace this rate limit to a PR designed for the old LPC176x software PWM, I don't think its still required, but with the other laser improvements coming in (controlled via the planner) is it worth taking it back out?

[shitcreek]

Here is the aforementioned PR: #15335
Closing thread, please refer to the PR and add any commentary regarding this there. Thank you.

[boelle]

yes but that PR is not merged and have a bad ending :-D

however we are now back with the laser not turning off after a job is done.

[shitcreek]

@THE-BOW I forgot to ask if you've tried 'FAST_PWM_FAN'?

@boelle yeah but I'm certain we'll have it sorted out soon enough...

[boelle]

@shitcreek total unrelated, but are you able to test with SKR boards? we seem to have a few issues with those and i only have re-arm

[p3p]

@shitcreek The laser update rate limit of 10Hz caused by the code I made them modify is independent of pwm frequency? so that shouldn't effect the "blurred" edges.

[shitcreek]

@p3p I see.

Maybe we should keep the frequency limit but add a condition for it such as:
in configuration_adv.h

/**
 * Limit check_axes_activity frequency to 10Hz
 * Affects M106
 * Undefine this if for instance when laser engraving with M106 produces blurry results
*/
#define LIMIT_FREQUENCY

in marlin.cpp

// Limit check_axes_activity frequency to 10Hz
static millis_t next_check_axes_ms = 0;
if (ELAPSED(ms, next_check_axes_ms) && ENABLED(LIMIT_FREQUENCY))
{
  planner.check_axes_activity();
  next_check_axes_ms = ms + 100UL;
}
else {
  planner.check_axes_activity();
}

@boelle I have yet to.

[thisiskeithb]

The fix in PR #16077 looks great.

[p3p]

I'm not sure the limit is still needed .. it was added to work around a problem that no longer exists, but then again I'm not sure of all the consequences of removing it either.