[BUG] Input shaping causes delay in laser actuation

[Moeschus]

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

Yes, and the problem still exists.

Bug Description

I use Marlin to control a laser engraver (using inline mode) and when I activate input shaping this causes delays in laser actuation. Therefore I cannot use input shaping, although it would be a great feature for laser engravers, because powerful laser modules are quite heavy and have to be moved around quite quickly. This generates quite a bit of vibration that can be nicely cancelled by input shaping.

The delay becomes clearly visible when I engrave text or images in bidirectional mode. This means that the laser moves across the whole text or image in lines in alternating directions (left to right, then right to left and so on). A delay causes all features to get a shifted "twin". This behavior is only present when input shaping is active (see image below). The shift between the letters in this picture is about 4 mm and the text was engraved with 200 mm/s. This means that there must be a time delay of the laser actuation of approximately 10 ms. This behavior is only present when input shaping is active.

Bug Timeline

Present in 2.1.2.1 and bugfix-2.1.x. No other versions tested.

Expected behavior

No laser actuation delays caused by input shaping

Actual behavior

laser actuation delays caused by input shaping

Steps to Reproduce

• activate input shaping
• engrave any picture or text in bidirectional fill mode

Version of Marlin Firmware

2.1.2.1

Printer model

custom laser engraver

Electronics

SKR mini E3 V3.0

Add-ons

No response

Bed Leveling

None

Your Slicer

None

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Configuration.zip
Test_gcode.zip

[narno2202]

@Moeschus, do you test input-shaping before 20 July Babystep commit ? If yes and works fine, try diabling Babystepping in Configuration_ADV.h as babystep isr has changed.

[Moeschus]

Thank you for the quick answer @narno2202! I downloaded my version of bugfix-2.1.x on 19th of July. So it is before that commit. Disabling Babystepping in Configuration_ADV.h doesn't change the behavior.

[narno2202]

Answering to @danbrianwhite about FT_MOTION and talking about buffers, i remember your issue with INPUT_SHAPING. Have you try to change SHAPING_MAX_STEPRATE ? With your config, the calculated value is 40 000 and shaping_echoes is 836 (the buffer size), it's perhaps not the good size for X axis as Y axis is OK on your pics. Enable in Configuration_ADV.h SHAPING_MAX_STEPRATE to a value over 40 000 and test it.

[Moeschus]

I have tested different values for SHAPING_MAX_STEPRATE with this test gcode file delayTestGCode.zip and these are the results:

As you can see there is a shift present for all directions that you scan across the image. It is not only limited to the x-axis. The arrows on the upper end of each picture indicate the direction and order in which the laser scanned across the cross in circle and also text below. As a reference there is also the rightmost engraving that was done following the contours of the picture. In this engraving (and also in the arrows) you can see how bad the oscillations in the gantry can get without input shaping.

The higher SHAPING_MAX_STEPRATE gets, the more severe the shift becomes. But there seems to be a limit at around 40000. Increasing it above this value seems to not increase the shift any further.

I have also recorded a slowmotion video from the process. Unfortunately quite out of focus but you can still see what is going on: The laser fires always too early (or the movement lags behind).

laserDelay.mp4

If I can do any other tests that help in identifying the cause of the problem I am glad to do so...

[narno2202]

@Moeschus, how have you determined your shaping frequencies ? They are perhaps too low : when they increase, the buffer size diminishes as if you were decreasing SHAPING_MAX_STEPRATE (best results in your pics).
Now it's vacation time. I'll hope you find a solution.

[Moeschus]

For now it was just a rough estimation based on wavelength of engraved oscillations. Frequencies on this system are really low because of the heavy weight of the toolhead.

Thank you for your help and have a nice vacation!

I won't close the issue yet, because I still think this is a bug. IS should not introduce any shift at all between motion and laser actuation imho.

[JonBr306]

IS should not introduce any shift at all between motion and laser actuation imho.

It looks like the laser feature thinks that the position includes half steps that have not yet been fully processed. So the laser is turning on slightly too soon, for example when scanning from left to right the image is shifted to the left and vice versa, the equivalent occurs with up and down.