[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: https://github.com/MarlinFirmware/Marlin/pull/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.

[shitcreek]

The limit still makes sense for normal fan usage since the fan doesn't need to be updated so frequently. What was the problem before can you recall?

[DrywFiltiarn]

I feel this issue would be resolved with my pull request #16077

[p3p]

What was the problem before can you recall?

The PR that added it referenced an issue with the LPC176x software pwm updates blocking and eating all the cycles, no mention of any other reason.

[shitcreek]

@DrywFiltiarn what do you think about my suggestion above?

[THE-BOW]

@shitcreek I did not try FAST_PWM_FAN - but i can if it helps.

[THE-BOW]

@boelle Would it help for testing to order one of this boards for you?

[boelle]

no i dont think it would

[AnHardt]

If a limit of the update frequency is required or not, or if it's useful or not depends on the way the PWM is realized. Our software PWM (in the standard case) has a clock of ~1 KHz and overruns at 128. So the PWM frequency is ~8 Hz. Updating the compare value any faster does not hurt, but is not useful. When we use hardware PWM and only the compare register (or its preload register) is updated frequently, it does not hurt. But if done more often than the PWM frequency it is not useful. When using Arduinos AnalogWrite() (depending on the framework) each time the function is called: the pin is prepared, the counter prepared, reset and started at 0. If the value update here comes to early (before the on-phase is over) this results in a permanent on, 100% PWM. That's not what we want.

A update limit to about the PWM-frequency is a good thing.

[THE-BOW]

@shitcreek Trying to compile with enabled FAST_PWM_FAN resulted in following error.

In file included from Marlin\src\HAL\HAL_LPC1768../../inc/MarlinConfig.h:39:0, from Marlin\src\HAL\HAL_LPC1768\HAL_SPI.cpp:51: Marlin\src\HAL\HAL_LPC1768../../inc/../HAL/HAL_LPC1768/inc/SanityCheck.h:57:4: error: #error "BLTOUCH and Servos are incompatible with FAST_PWM_FAN on LPC176x boards."

error "BLTOUCH and Servos are incompatible with FAST_PWM_FAN on LPC176x boards."

^~~~~

In file included from Marlin\src\HAL\HAL_LPC1768../../core/../inc/MarlinConfig.h:39:0, from Marlin\src\HAL\HAL_LPC1768../../core/serial.h:24, from Marlin\src\HAL\HAL_LPC1768\DebugMonitor.cpp:26: Marlin\src\HAL\HAL_LPC1768../../core/../inc/../HAL/HAL_LPC1768/inc/SanityCheck.h:57:4: error: #error "BLTOUCH and Servos are incompatible with FAST_PWM_FAN on LPC176x boards."

error "BLTOUCH and Servos are incompatible with FAST_PWM_FAN on LPC176x boards."

^~~~~

In file included from Marlin\src\HAL\HAL_LPC1768../../inc/MarlinConfig.h:39:0, from Marlin\src\HAL\HAL_LPC1768\HAL.cpp:25: Marlin\src\HAL\HAL_LPC1768../../inc/../HAL/HAL_LPC1768/inc/SanityCheck.h:57:4: error: #error "BLTOUCH and Servos are incompatible with FAST_PWM_FAN on LPC176x boards."

error "BLTOUCH and Servos are incompatible with FAST_PWM_FAN on LPC176x boards."

^~~~~

[.pio\build\LPC1768\src\src\HAL\HAL_LPC1768\HAL_SPI.cpp.o] Error 1 [.pio\build\LPC1768\src\src\HAL\HAL_LPC1768\DebugMonitor.cpp.o] Error 1 *** [.pio\build\LPC1768\src\src\HAL\HAL_LPC1768\HAL.cpp.o] Error 1

[shitcreek]

I tested my code above: https://github.com/MarlinFirmware/Marlin/issues/16058#issuecomment-560937093 but with a minor tweak:

// Limit check_axes_activity frequency to 10Hz
  #if ENABLED(LIMIT_FREQUENCY)
    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;
    }
  #else
    planner.check_axes_activity();
  #endif

Which does the exact thing as commenting out the three lines. It looks like this limit does affect the new laser improvement PR code. It fixes the issue where laser doesn't turn off after a job is done.

I shouldn't have closed this issue thread so eagerly since the fix has not been added.

[houseofbugs]

Progress on this issue should be continued in https://github.com/MarlinFirmware/Marlin/pull/16082

[boelle]

if no protest are made in the following days i could go with that :-)

[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.