[BUG] Rough XY motion with LASER_POWER_INLINE (only when Z < 10mm)

[borys-wwa]

Did you test the latest bugfix-2.0.x code?

No, but I will test it now!

Bug Description

After enabling LASER_POWER_INLINE, X and Y axies run rough and skip steps. This happens regardless of the speed of G0 movement. G0 X20 F8000 then G0 X120 F8000 make the axis move, but You can hear a distinct sound every x no. of steps, like if stepper wasn't getting the impulses properly. That happens even, when I remove the stepper and it runs alone, with no parts attached to it. Same thing happens on both axies - X and Y. The most interesting thing is, that it only happens, when Z axis is below 10 mm. If it's above 10 mm, all runs smooth. Also - this issue doesn't occur during homing and Bed Leveling. When I disable the LASER_POWER_INLINE, the issue goes away.

Bug Timeline

No response

Expected behavior

Axies move without issues even with LASER_POWER_INLINE enabled.

Actual behavior

No response

Steps to Reproduce

No response

Version of Marlin Firmware

2.0.9.3

Printer model

Anet A8

Electronics

RAMPS 1.4 + Mega 2560, DRV8825 drivers. X axis stepper - 0.9 deg per step, 1/16 microstepping. Y axis stepper - 1.8 deg per step, 1/32 microstepping.

Add-ons

BL Touch, Laser

Bed Leveling

ABL Linear grid

Your Slicer

No response

Host Software

No response

Additional information & file uploads

drive-download-20220329T212325Z-001.zip

[GMagician]

Your issue seems related to DEFAULT_LEVELING_FADE_HEIGHT. You have bilinear bed leveling and it works up to above value (default is 10mm). Maybe your bed is so unplanar to cause leveling to work in a bad way?

[borys-wwa]

Thanks for the reply. Below is the result of the G29.

Recv: Bilinear Leveling Grid: Recv: 0 1 2 Recv: 0 -0.133 +0.047 +0.194 Recv: 1 -0.366 -0.173 +0.148 Recv: 2 -0.382 -0.057 +0.184

It's not extremally flat, but I don't believe it's very bad either. Why would that affect steppers in that way?

Other question is - why does this issue only occur with the LASER_POWER_INLINE enabled? I will lower the DEFAULT_LEVELING_FADE_HEIGHT and check if it affects the Z value when this issue occurs.

EDIT: I have raised the LEVELING_FADE_HEIGHT to 12, and indeed, the issue started occurring at Z = 11mm, where it didn't occur before.

The question is - why does this happen? What does bed leveling has to do with LASER_POWER_INLINE and steppers running unreliably and loosing steps? Is there some additional computing happening when LASER_POWER_INLINE is enabled, which the 8bit atmega is not able to cope with and loses steps? Why doesn't this occur during normal prints? Bed Leveling is also in effect then, yet it doesn't show this symptom.

I will try to upload some videos of the issue in a moment.

[GMagician]

I suspect that laser_power_inline add some info into planner adding time spent into isr.

[borys-wwa]

So, does it mean, that this feature can't be used with AtMega 2560? I would expect, that slowing the speed down, would help, as it would give more time for the CPU to process necessary data, but it doesn't seem to be helping. It just slows down that sound that steppers make, when rotating (proportionally to the speed). Or perhaps there are other features, that I could disable, to free up some processing capacity (if that is indeed related to the CPU bottleneck), for this feature to work?

[GMagician]

I've no idea about that, sorry

[borys-wwa]

No prob. Thanks for Your help so far. Thanks to it we've manage to confirm, that it's somehow related to bed leveling. Perhaps someone else will be able to suggest some solution based on that information.

[descipher]

Laser inline is very hard on the CPU, the 8 bit load issue has been improved greatly in a PR that is currently under test. The PR moves laser inline calculations out of the stepper code which results in smoother movement at medium speeds. Bed levelling adds even more CPU load so it will be amplified when enabled.

22690

We could use your help if you are interested in testing: https://github.com/descipher/Marlin/archive/refs/heads/laser.gcode.inline.fix.zip

[borys-wwa]

Thanks for the update. I will test the fix during the weekend and will let you know if that has fixed this behavior.

[thinkyhead]

You probably should not be using bed leveling with a laser. Can you explain why you need it?

[descipher]

Lasers do require a finite focal point so it's not unreasonable to use leveling. It would entail some very high precision work though.

[borys-wwa]

I agree, that using bed leveling is probably an overkill for what I need. The challange I have, though, is that I try to use the same machine for both - 3d Printing, and laser engraving (until I get a proper dedicated laser engraver) - just as a proof of concept and to learn a bit about laser engraving. It would be very convenient to be able to achieve this without the need for reflashing the firmware when switching between Laser engraver head and 3d printing head. That issue is preventing that, as laser inline power can only be set via firmware config (can't be enabled or disabled via gcode), and therefore, when i enable it, this renders that firmware useless for 3d printing due to aforementioned issue, and requires reflashing, when I switch to the 3d printing scenario.

I have tested the fix, and can confirm, that it has significantly improved the steeper behavior. It still lowers the max achievable velocity, but not by much (instead of 9900 mm/min, which I could achieve with the inline_power disabled, I can now only achieve 9737 mm/min, but it's still more, than I need),. What's most important is, that now the issue goes away completely, when the velocity (feedrate) goes below 9737 mm/min. Before, the issue was there regardless of the feedrate.

Below find the video before and after the fix. Gcode performs: 1) Home all axes 2) Level the bed 3) go to x200, y200, z5 (ie. 5 mm, BELOW the Bed Leveling Fade level - bed leveling active) 4) move X to 100, then 50, then 20, with feedrates 9900, 6000 and 3000 respectively 5) do the same with Y axis 6) go back and move Z up to 15 mm (5 mm ABOVE the bed leveling fade level, so bed leveling is no longer in effect) 7) performs steps 4 and 5 again 8) go back to x200, y200, Z5 9) move X axis back and forth with 9737 Feedrate 10) move up to Z15 (above Bed Level Fade) 11) Repeat step 9.

GCODE

Before the fix: Issue is dramatic and can be heard across all feed rates. Before Fix Config: Configuration.zip

After the fix: Issue is only barely noticeable during the fastest feedrate. It completely goes away at lower speeds. After Fix Config: Configuration.zip

I'm yet to test how the inline power works with actual laser attached, as well as to print something with this firmware. I will update in case I find any issues, but for now it seems promising.

[descipher]

Looks great! It was even loosing steps and position before the refactored code.

This example link has 5-6000 laser firing points in a raster burn test. The speed change at burn areas are the G0 to G1 move transition. https://streamable.com/t3mia2

Thanks very much for validating the magnitude in performance improvement.

[borys-wwa]

I finally found some time to connect the laser to the printer, and unfortunately - bad news. The laser doesn't seem to be working on my RAMPS board with new firmware. I have it connected to pin 44 and it works on the official firmware, but won't turn on on this fixed one. I tried M3 S10, M3 O10, OR using the LCD menus to turn the laser on, and all this works with the official version, but doesn't with this bugfix one :( Any clues why?

[descipher]

@borys-wwa Just verified RAMPS pin 44 works, attach the configs and I can check it for you.

[borys-wwa]

Thanks @descipher. Here You can find the config I use.

[descipher]

@borys-wwa When using BOARD_RAMPS_14_EFB you need to add this to override pins_RAMPS.h. You could edit the pins file but that would get clobbered on any update so this is better.

#define LASER_FEATURE
#if EITHER(SPINDLE_FEATURE, LASER_FEATURE)
  #define SPINDLE_LASER_ACTIVE_STATE    LOW    // Set to "HIGH" if SPINDLE_LASER_ENA_PIN is active HIGH
  #define SPINDLE_LASER_ENA_PIN             40  // Pullup or pulldown! (Yes even if it's unused, it permits the override)
  #define SPINDLE_LASER_PWM_PIN             44  // Hardware PWM

[borys-wwa]

I see. I don't believe I needed to change anything in the original Marlin firmware for that board. Actually - i picked pin 44 by looking at the pins_RAMPS.h.? Was anything changed in that matter as a part of that bugfix?

I will try your suggestion and let You know if that worked.

[descipher]

Should work for you. Note: You did enable #define LASER_POWER_TRAP I do not recommend it with levelling on, most laser gcode generation programs will not need it. It will additionally load the CPU.

[borys-wwa]

Yup - works fine :) Thanks for Your help in that matter. Won't LASER_POWER_TRAP help in not overburning the corners during engraving? I would expect that machine would be slowing down when closing to the sharp corner, and if the laser does not power down during such slow down, the corners would turn out darker, than the rest of the shape. At least this is how I imagined this feature to work. I'm probably wrong, though :)

[descipher]

Engraving works better with raster sweep based burns. The movement is started and brought up to linear speed and then the laser is turned on and off at exactly the right points. It performs much better than trying to control power based on accel/decel points. I did not want to remove any functions, the focus was to improve them. Trap works better than b4 the refactor.

[borys-wwa]

Understood. Thank You for guidance. Will have that in mind during further experimentation. Any chances for this to be merged into release branch, anywhere in the near time?

[descipher]

You're very welcome! I hope it will, I am reluctant to invest more time into the code with this sitting for so long. There certainly are many more improvements that can be done. Moving forward really stems on the assurance testing provides. The more testing the more trust it brings to the changes.

[github-actions[bot]]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[thisiskeithb]

https://github.com/MarlinFirmware/Marlin/pull/22690 has been merged.

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