Improvement proposal - more silent print with "dynamic" linear advance  

RE: Improvement proposal - more silent print with "dynamic" linear advance

Posted by: @ondrej-sienczak

Hi folks 😉

as I built my new printer based on trinamics silent steppers, I also tried to tune up linear advance to get better print results. As my main aim was to built as silent machine as possible, I found one little issue. This issue is that linear advance feature produces jerky movements of extruder stepper motor. This is logical, because fast injestion and releasing preasure on filament is required in this case. However this also produce noise (noise similar to cricket animal ;-)) with every sharper change of direction. I started to thinking if this can be somehow solved. As linear advance is really required when surface is printed, there is no way around, but for infill, the situation is different. Usually infill is not needed to be printed with such high precision, so linear advance can be temporarly disabled.

So what is my improvement proposal? Proposal is to add configuration item which allow to switch off linear advance for infill.

As I wanted to try it first, I made script which tries to do that from already generated G-CODE (see code snippet at the end). As infill is one part which spent most of the time when printing (at least with larger objects), I observed that the noise level was reduced significantly. So the script basically works and theoretically no change is needed inside slicer, but:

1. As script try to find when infill is printed, it requires verbose code to be generated. Parser get information from additional comments injected by slicer. This may theoretically cause troubles on some weak systems (with AVR) which consumes time by reading meaningless characters from UART
2. Script also try to guess when top layer is printed. For this layer is considered also to use high precision (linear advance activated) to preserve all details on surface. Problem is that script can only "guess" top layer according to configured top layer speed, so this is not 100% working usecase

Instead of letting guess script where to inject M900 G-CODE would be better if slicer do this job internally for us (of course only when this feature is activated in config). Slicer knows very well when is what printed, including infills, perimeters, ....

So what is your opinion about this feature? 😉

 

 

Here is my script which I used to check impact of "runtime" linear advance tune up:

<blocked content>

You could activate this option in PrusaSlicer:

This feature comments at the end of the line whether it's perimeter or e.g. infill acts. With a python script you could add or change the code accordingly.

RE: Improvement proposal - more silent print with "dynamic" linear advance

@karl-herbert

Hello Karl,

thank's a lot for quick reply 😉

Thanks for hint, but actually I know how to enable verbose G-CODE and script works just fine to me (unfortunately my attempt to insert script was recognised as attempt to exploit and content was blocked). I also used column allowing automaticall invoke of post processing script ([Print Settings] --> [Output Options] --> [Post-processing scripts]). This parts are just perfectly done and I like them as they allow me to tweak slice procedure in the case of need.

Verbose code isn't problem i my case as I'm using ARM based powerfull controll board and cartesian machine without any complex arithmetic required for delta or scara.

The issue can be in this case recognition of top infill. It works to me just fine as I uses different print speed for this layer, but problem only may appear in the case I use the same speed for top and iner infill.

However I still have some feeling to apply some kind of custom "workaround' over functionality which may be possibly implemented inside slicer. In principal this change seems not be such a big deal to be implemented, but of course "seems" does not mean that it is 😉. That's why I'm posting it here as proposal to comunity which knows the architecture and implementation of slicer modules much better then me (actually I didn't do any investigation in source code because of lack of time, otherwise pull reques would be better then proposal in forum 😉).