Got rid of ringing/ghosting almost completely

[Hans2004]

Version

1.38

Got rid of ringing/ghosting almost completely EditReport this postQuote Sep 25, 2018 9:20 am

I have written a simple python script that gets rid of ringing in prints. It works by parsing the gcode file and looking for perimeter movements that change direction of more than 45 degrees with respect to a previous movement. If that is the case, it will reduce the x and y jerk values of the printer to a low value by inserting a "M205 X2 Y2" command into the gcode file just before where the move starts, and restoring to a higher jerk value just before the first point where a smaller angle move has to be done.

Why does this work better than just having a low jerk value for the whole print: Because printing with very low jerk values messes up curvatures. It generates a wavy pattern all around curvatures.

It would be great to have such a feature built into Slic3r. I have tried to run the script as a post processing script in Slic3r prusa edition (1.38 Appimage), but it refuses to run python scripts for some reason. Even when I run the script from a bash file and then use the bash file as a post processing script from Slic3r, the script does not run. A bash file that does not call a python script runs fine from Slic3r though.

If you want to try the script your self, it is simple:

• In print settings->output options, select Verbose G-Code. (The script needs this in order to detect perimeter moves)
• Now just call the script with the filename of your gcode file as the first and only argument. The script will then output a file with a .MOD.gcode extension that you can then load into your printer software. Your printer will now print with nearly all ghosting gone.

Below is a copy of the script. Sorry for bad coding standards. I am not a professional programmer and python is not my first programming language.

parser.py.gz

[bubnikv]

Original discussion and some images: https://shop.prusa3d.com/forum/general-discussion-announcements-and-releases-f69/got-rid-of-ringing-ghosting-almost-completely-t24759-s10.html

[supermerill]

You can translate it in perl if you have some bravery.

It would be great to have such a feature built into Slic3r.

What you want is:

• A setting to detect the min angle (from 180 to 0, disabled if 180)
• A setting to set the new min jerk value (mm or percent of the corresponding jerk X/Y)

these two on the printer/machine limits/jerk limits ?

[Sebastianv650]

Thumbs up for your investigation and the script! But I'm not able to stop the feeling that you are fighting a firmware issue with a work around for the slicer side. The basic way how printer FW calculated cornering speeds is very unlucky in my opinion, that's why we introduced a new way for that in Marlin. There it's called JUNCTION_DEVIATION, you can find details how it works here: https://onehossshay.wordpress.com/2011/09/24/improving_grbl_cornering_algorithm/ This should also eleminate the need for your script, at least it does for me.

The other problems with the usual jerk implementation and background informations about the new one is scattered along the Marlin Github, but this might be a good start point: https://github.com/MarlinFirmware/Marlin/issues/9917

[bubnikv]

You can translate it in perl if you have some bravery.

You should not, the perl is going away soon.

On Wed, Sep 26, 2018 at 6:11 PM Sebastianv650 notifications@github.com wrote:

Thumbs up for your investigation and the script! But I'm not able to stop the feeling that you are fighting a firmware issue with a work around for the slicer side. The basic way how printer FW calculated cornering speeds is very unlucky in my opinion, that's why we introduced a new way for that in Marlin. There it's called JUNCTION_DEVIATION, you can find details how it works here: https://onehossshay.wordpress.com/2011/09/24/improving_grbl_cornering_algorithm/ This should also eleminate the need for your script, at least it does for me.

The other problems with the usual jerk implementation and background informations about the new one is scattered along the Marlin Github, but this might be a good start point: MarlinFirmware/Marlin#9917 https://github.com/MarlinFirmware/Marlin/issues/9917

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/Slic3r/issues/1251#issuecomment-424772407, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5I2ZZMZsMR9kIt4UTdO6xFyAPKIm8ks5ue6c2gaJpZM4W4kdn .

[bubnikv]

https://onehossshay.wordpress.com/2011/09/24/improving_grbl_cornering_algorithm/

I don't think this is a good solution for the Prusa i3 kinematics, as the X and Y axes are decoupled. One shoe will not fit all the feet.

On Wed, Sep 26, 2018 at 6:15 PM bubnikv bubnikv@gmail.com wrote:

You can translate it in perl if you have some bravery.

You should not, the perl is going away soon.

On Wed, Sep 26, 2018 at 6:11 PM Sebastianv650 notifications@github.com wrote:

Thumbs up for your investigation and the script! But I'm not able to stop the feeling that you are fighting a firmware issue with a work around for the slicer side. The basic way how printer FW calculated cornering speeds is very unlucky in my opinion, that's why we introduced a new way for that in Marlin. There it's called JUNCTION_DEVIATION, you can find details how it works here: https://onehossshay.wordpress.com/2011/09/24/improving_grbl_cornering_algorithm/ This should also eleminate the need for your script, at least it does for me.

The other problems with the usual jerk implementation and background informations about the new one is scattered along the Marlin Github, but this might be a good start point: MarlinFirmware/Marlin#9917 https://github.com/MarlinFirmware/Marlin/issues/9917

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/Slic3r/issues/1251#issuecomment-424772407, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5I2ZZMZsMR9kIt4UTdO6xFyAPKIm8ks5ue6c2gaJpZM4W4kdn .

[Sebastianv650]

I'm using this Marlin version on a Lulzbot TAZ 5 which has the same kinematics as the i3. The request is to do higher jerks on smaller junction angles an lower ones on high angles. That's exactly the result of the GRBL math, defined by acceleration and the deviation length value. The result is also the same as we can see on the Marvin prints with the script.

There are other ways to achieve this jerk handling, that's for sure. Just wanted to note there is already a working version available.

[bubnikv]

I'm using this Marlin version on a Lulzbot TAZ 5 which has the same kinematics as the i3. The request is to do higher jerks on smaller junction angles an lower ones on high angles. That's exactly the result of the GRBL math, defined by acceleration and the deviation length value. The result is also the same as we can see on the Marvin prints with the script.

There are other ways to achieve this jerk handling, that's for sure. Just wanted to note there is already a working version available.

I agree, that reducing the jerks to zero at the corners limits vibrations significantly. I even did some experiments myself with a "raw" G-code and our modified Marlin, where we were driving the motors with real S-curves. The vibrations were very much reduced by setting the jerk to zeros. Setting the jerk to zeros had a much more significant effect on vibrations than the S-curves (if we applied the S-curves with some jerk at the corners).

https://github.com/prusa3d/slic3r/tree/raw_gcode

My change of the firmware was motivated by keeping the motor axes inside their respective limits, which the original GRBL planner did not guarantee.

Reducing the jerks at sharp angles will cause the print head to slow down significantly, thus increasing the nozzle pressure. Then after the corner, the print head will have to accelerate, starting with a lowered nozzle pressure. This will cause the extrusion to get wider before the corner, and narrower after the corner, if not corrected for by linear advance. When going very fast, you may even get bulges before the corner and gaps after the corner.

We are really trying to satisfy multiple constraints at once:

1) The nozzle pressure

2) Limit vibrations

3) Limit jerk / acceleration of the motors, so they will not skip steps.

By the way, I have never seen any discussion on the stepper motor slip in the 3D printing community. The stepper motors will not follow the programmed tracks exactly if mechanically loaded, they are allowed to slip up to 2 full steps (half a phase) before they skip a single step (actually a stepper will always skip multiples of 4 full steps, which is a full phase of the stepper motor wave forms). And some of the vibrations you see are quite certainly caused by the stepper motor acting as a spring, vibrating around the programmed position.

@Pavel Šindler pavel@prusa3d.cz Maybe we shall do some experiments with the original GRBL jerk handling, whether the original code will reduce vibrations at sharp corners.

On Wed, Sep 26, 2018 at 6:34 PM Sebastianv650 notifications@github.com wrote:

I'm using this Marlin version on a Lulzbot TAZ 5 which has the same kinematics as the i3. The request is to do higher jerks on smaller junction angles an lower ones on high angles. That's exactly the result of the GRBL math, defined by acceleration and the deviation length value. The result is also the same as we can see on the Marvin prints with the script.

There are other ways to achieve this jerk handling, that's for sure. Just wanted to note there is already a working version available.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/Slic3r/issues/1251#issuecomment-424784458, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5IxJUhRwk-gATwQu-WsIaIMKaF1oqks5ue6yMgaJpZM4W4kdn .

[Sebastianv650]

By the way, I have never seen any discussion on the stepper motor slip in the 3D printing community. The stepper motors will not follow the programmed tracks exactly if mechanically loaded, they are allowed to slip up to 2 full steps (half a phase) before they skip a single step (actually a stepper will always skip multiples of 4 full steps, which is a full phase of the stepper motor wave forms). And some of the vibrations you see are quite certainly caused by the stepper motor acting as a spring, vibrating around the programmed position.

That's intresting news to me. While it's clear that the real rotation angle will be slightly behind the "set" angle, I have not expect it to be that much. It would explain some extrusion effects I never found a solution for on all sort of printers. Do you have some more data about this to study?

In one video on youtube about a tour through the Prusa HQ they mentioned a printer packed with load cells, namely mentioning the ability to measure the extruder pressure and load. Sadly nothing one of the visiting guys asked further questions about, for me thats the realization of my biggest dreams. I guess there is a lot to learn on the extrusion side of printers!

[Hans2004]

What you want is:

• A setting to detect the min angle (from 180 to 0, disabled if 180)
• A setting to set the new min jerk value (mm or percent of the corresponding jerk X/Y)

these two on the printer/machine limits/jerk limits ?

Yes. That is what I want. That way we can overcome current limitations in the Marlin Firmware. Also, the option only has to be available for perimeter moves because ringing is not visible in fill.

[Hans2004]

What you want is:

• A setting to detect the min angle (from 180 to 0, disabled if 180)
• A setting to set the new min jerk value (mm or percent of the corresponding jerk X/Y)

these two on the printer/machine limits/jerk limits ?

Yes. That is what I want. That way we can overcome current limitations in the Marlin Firmware. Also, the option only has to be available for perimeter moves because ringing is not visible infill.

As a side note: There should also an option to insert an M400 command before the change jerk command because some firmwares (mainly the Prusa ones) do not send M205 commands to the planner, but implement them upon receipt of the command.

[Hans2004]

You can translate it in perl if you have some bravery.

It would be great to have such a feature built into Slic3r.

What you want is:

• A setting to detect the min angle (from 180 to 0, disabled if 180)
• A setting to set the new min jerk value (mm or percent of the corresponding jerk X/Y)

these two on the printer/machine limits/jerk limits ?

I have written a new, more comprehensive version in perl. As I had to learn perl from scratch in the last few days, I am sure that I have made some beginners mistakes. But the new script is much more readable than the python one, catches more places where to lessen the jerk value, and it is easier to configure. I commented the source where necessary. The perl script also works with appimages of Slic3r. I guess that python has issues with appimages.

deghost.pl.gz

[pavel]

@bubnikv Thanks for notifying me, but it does not seem that I'm involved in this project in any way.

https://blog.github.com/2011-03-23-mention-somebody-they-re-notified/

[bubnikv]

@Hans2004 I have asked our tester lead @jindrichbenes to test your approach.

[rennne]

What was outcome from the tests?

[brotherdust]

Any news here? I'm trying to mitigate the same problem.