Adjusting Nozzle Temperature Based on Flow Rate

[ramorimdias]

Maybe we could improve print quality by adjusting nozzle temperature based on the flow rate. You know how some prints look different in terms of surface appearance depending on the filament temperature? Well, printing at the same temperature doesn't always solve the issue, especially when the flow rate varies, you can get different artefacts on the same print. So, what if we tweak the temperature to match the flow rate? Higher flow rates get higher temps, and lower flow rates get lower temps. This might help with overhangs too, where the nozzle's slow speed at higher temps causes problems. Just throwing it out there, not sure if it makes sense though!

[awabom]

I think it could work. When testing max flowrate on my printer, I can squeeze out about 15% more flow going from 220C to 240C with PLA.

It would probably only be useful on prints where the flowrate is high or low all the time though, since the temperature of the hotend doesn't change very fast.

[ramorimdias]

I think it will be hard to implement as different hotend have different speeds when controlling the temperature…

[sb53systems]

Hi, this idea has been on my mind for months: the temperature should automatically adjust based on the average flow rate over a certain duration of printing time. I’m not sure if this is possible through a post-processing script on any slicer (Orca is my favorite), and I would like one of their team to help us implement this project because I believe it is a revolutionary idea in 3D printing. In summary, the goal is to vary the temperature according to the flow rate that can be reached during a certain time of the print, and then adjust the maximum flow rate to stabilize the quality of the extruded filament and save printing time with best quality.

[sb53systems]

I attempted to program an app to modify the temperature and speed in the G-code, but I am missing the algorithm to calculate the printing time. Additionally, I am not sure if a post-processing script in the slicer could assist with this.

[ramorimdias]

I agree that if the goal is to push the flowrate above the limit, and still get print quality, this feature would be interesting. Exemple: Achieve 40mm³/s on PLA at 240°C but have the ability to slow down in some parts and then decrease to 220C would benefit print quality and overhangs. If the goal is only the glossy finish on some external walls, this PR #5148 has much better approach.

[sb53systems]

I believe that the variation in the appearance of external walls is caused by many parameters in the slicer, all of which are related to the flow and extrusion temperature and the geometry of the printed object. The solution I propose, which w'ill be applied to the entire print and not just external walls, will significantly reduce this visible effect and also improve the properties of the filament by simply avoiding flow variations with inadequate temperature

[ltwmichalw]

It will be much easier to set the temperature based on the layer printing time. In the filament settings, we need a place where we can enter, for example, that for time over 30 seconds the temperature is 230 degrees and for time less than 10 seconds it is 220. In my opinion, the algorithm should work like this: after generating all the layers, the script should set the temperature for each layer. Since the temperature change takes a relatively long time, the script should take into account the average of the next 5 layers, this will reduce the number of changes/make these changes milder.

Let's take a benchy print as an example: the first several dozen layers are relatively long, at high printing speed the temperature should be slightly higher, I will assume 230 degrees. Then there is the cabin, where the printer slows down anyway, it could be 220-225 degrees. The last layers are the chimney, it is so small that the hotend moves really slowly. At this point, 210-215 would be the ideal setting.

This should be easier to implement than relying on flowrate.

[ramorimdias]

The problem is that layer time doesn't have a direct link to extruded material, it depends on the line width and layer height. That's why I proposed flowrate insted. I agree that we should get an average on some parts rather than fine-tuning the temperature on every flow rate change.

[ltwmichalw]

I agree that the layer time is not clearly related to the flow rate, but it is really about the time of cooling the filament below the glass transition temperature. These differences over time mean that the prints show that some pieces are more matte and others are more shiny. The point is that if the next layer is applied before the previous one cools down, the print will be shinier. I know it's purely aesthetic, but sometimes it looks really bad.
In fact, I think both approaches will work. It seems to me that the slicer calculates the required flowrate anyway, you can limit the max flowrate for a given filament.

[ramorimdias]

I'm not sure if that's really what's happening. Don't think Tg is the issue here. I think the problem comes from "undermelting" the filament in the nozzle itself. 10mm3/s will have more time to absorb heat (and melt) than 15mm3/s for example. There is a fine line whether the filament will come matte or shiny from the nozzle after melting. Not enough heat will make the filament not completely melted, and it will "stretch" as being deposited on the part, making it matte as the surface will be irregular. More heat will make it shiny because the material will be completely melted as deposited.

[ltwmichalw]

I have a hotend that easily gives 28mm3/s, I usually print at half that speed. The problem is not the difference in the heating of the filament, the problem is the subsequent heat reception. In the case of PLA, more intensive cooling is enough (although up to a certain limit), in the case of other filaments (e.g. ABS), this is not an option. Of course, we have a minimum layer printing time and a minimum printing speed, but when the hotend moves slowly, it also heats the material that should already be cooling down.
I have the impression that we are looking at this problem from two sides: you are wondering how to raise the temperature when high flow speeds are needed, I am wondering how to lower it when I print a fragment at low speeds.
I watched the flow speed while printing for a while. In fact, it changes several times per second, it will be difficult to establish limit values.

[sb53systems]

Hi, I believe that reducing the temperature based on layer duration may not be effective in all cases, especially when the object contains multiple surfaces where the layer duration wouldn’t be reduced, but the average flow would. Newer, fast printers with better acceleration reduce delays and variations in flow, where the only reduction in speed is caused by the cooling of small layers. In these cases, reducing the flow rate and adjusting the temperature would be beneficial.

I think this concept could also be beneficial for slower printers with an algorithm based on an optimized flow rate according to a certain temperature that should be stabilized during printing. For me, this is the best approach for polymer extrusion to ensure better quality of the extruded filament.

Calculating the average flow rate that can be achieved during the printing time should be easily provided by the slicers, as they already estimate the printing time and the amount of filament used. Then, the extrusion temperature should be adjusted by a few degrees per second, varying the maximum volumetric speed to balance everything.

This allows:

• Reducing the number of speed parameters in the slicer for different layer times, heights, and complexities.
• Saving time only where it is possible to go faster.
• Stabilizing the quality of the extruded filament.

[sb53systems]

To carry out this project and attempt to optimize it, we would need help from an expert in G-code post-processing scripts with OrcaSlicer or one of its contributors, to get at least an indication of the time spent in the G-code, or to have the ability to modify profile parameters during G-code generation, such as the maximum volumetric speed and extrusion temperature, with the prediction of several movements in advance.

[ramorimdias]

I'm not sure if this relates to the initial problem I raised in this thread. I also doubt that smoothing the flow rate is the solution. The slicer already has a pressure smoother option to handle abrupt speed changes, such as from internal to external walls. The actual flow rate constantly changes, especially when using pressure advance. Smoothing the line might affect that. Regardless, I think it's worth investigating if you have the time and energy—I'm certainly not an expert.

[sb53systems]

My goal is not to smooth the flow, but to calculate the average flow over a period of time (previous examples: 0.8, 1, 2, 3 seconds), then estimate the ideal temperature which can be varied according to certain conditions.
This is exactly the problem raised!!!
What do you think is the best approach to vary the temperature based on the flow?

[ramorimdias]

Ooh I get it now! Sorry for the misunderstanding. It all makes sense now 🤣
I think we should take in account the reactivityness of the hot end when changing temperatures, this will vary from printer to printer and will be a challenge to get it right I think. Then the average flowrate timeframe must be calculated taking the temperature change delay into account. Ideally it would be nice to link this with the PID coefficients but this is way out of my knownledge.

[sb53systems]

This is the 3DBenchy GCODE

After averaging the Flow/1s (green plot) , then averaging it with max requested flow (turquoise plot) and use the moving average method to smooth the result, adjusting variation to adapte the temperatue change by second, and flow by temperature, and get the Blue plot.
Below is the last 35% of the print


At first the estimated temperature will be around 223°C, drop to 220°C before the cabinet roof, rise to 229°C, finish the print at 217°C !!! I think it's perfect

The calculation of the Average/Max flow will vary closer to the average flow or closer to the maximum flow !!!!!
This approach is an example of my own reasoning, and I would like to have your opinions.

the next problem that bothers me, is the sudden change in speed, below an example of a first layer with a speed of 10mm/s (1mm3/s), second layer with higher speed (7mm3/s)

Next is a 20/20/20 Cube with slower internal infil.


My first proposal was to modify the temperature/average flow, then adjust the speed to correspond to the flow/temperature.
Adding to the GCODE :

• M104 commands before each movement
• modify the frequency (speed) of the movements if needed
• Set PID value
• pressure advance value
• .....etc

I'm trying different conditions and geometries, and observing the results, waaaaaw.

sorry for my English.

[sb53systems]

there is the estemated temperature for a 240° PETG 3dbenchy print.

Next with Average/Max flow based on max speed optemization

Next with Average/Max flow based on max quality optemization

I would opt for a value between (30% and 70%).
I am very convinced that we must limit the speeds of the peaks which exceed the recommended flow by the temperature reached.

Next job is GCODE edition, then start testing finaly .

[sb53systems]

guys, I swear this is a game changer, this is the future of 3D printing.
I will share the caude and instructions here on github in the coming days.
Welcome to the smart printing generation

[ramorimdias]

Great work man! I admit that's way out of my league in terms of understanding how you will achieve that. But I am confident that this will be beneficial in some way. I didn't understand the quality-speed slider. The print duration is the same, isn't it?
On the sudden changes of speed, maybe prioritize the higher flow? So we don't have problems with underextrusion?

[sb53systems]

You are welcome if you want to try the program before anyone else, and give me a different opinion and other ideas, apparently you are the only one who understands the concept.
send an address to send it to you, I would have liked to discuss and exchange.
you can cantact me at : [email protected]

[sb53systems]

Traying to get max quality with wet PETG (don't have a filament dryer)
Original GCODE with 240° 11mm3/s recomanded flow

Generated GCODE is based on best quality and speed limitation, add 7minutes to the print time

with my old printer and depending on the parameters I try, the temperature will vary between 215° and 228° for this 3dbenchy (may go higher in the case where the printe is larger)

vlc-record-2024-06-19-06h22m21s-VID20240619043923.1.mp4-.mp4

vlc-record-2024-06-19-06h24m35s-VID20240619043923.1.mp4-.mp4

vlc-record-2024-06-19-06h26m41s-VID20240619043923.1.mp4-.mp4

vlc-record-2024-06-19-06h27m51s-VID20240619043923.1.mp4-.mp4

VID20240619052205.2.mp4

[ramorimdias]

Cool, it woule be nice to print it normally to see the if there is any improvement. However I think PETG is not the best candidate to run those tests as the finish will always be glossy.

[sb53systems]

I was sure of the result before moving on to practice, I think that this concept must be developed and included in all slicers to facilitate its use. depending in the different geometries of the printed objects, this concept will automatically adapt the speed and the temperature in order to obtain a better speed/quality ratio, and facilitate configurations in the slicer by having a single profile for the different speeds, printing temperatures, layer heights and line widths.

small prints with changing geometry like a 3dbenchy have a lot of variations in the flow because of small movements and depending on the acceleration of the machine the result would be more or less difficult to balance (less variations with higher acceleration).
with other larger prints or with a geometry that does not change very much the result would be easy to balance.
the photos below show the result obtained for a 3 benchys with a wep PETG with max speed, temperature and flow (PLA is next) :

• printed without change (240°, 11mm3/s, estimated time : 31m50s, Real print time : 33m8s).
• another with an optimization based on the maximum speed (219° to 238°, Real print time : 33m34s) .
• last one with an optimization based on the maximum quality (215° to 228°, Real print time : 39m43s).

with a difference of 24s between the first and the second for a print of 33 minutes, by just varying the temperature with a minimum of reduced peaks, the quality of the print is greatly improved. the last one was 6m30s longer, with excellent quality.
below the difference between first and second prints

tell me a test I could do with which filament to use and the objective of the experiment.
Otherwise I will publish my code soon and you can experiment yourself.

[sb53systems]

I found a similar approach in orca which consists of softening sudden changes in flow rate

below the original gcode with the option disabled

the next is enabled with max softening (orca only)

notice that flow/moves with orca softening at max, are exactly aligned with my program average flow/time with the deactivated option (green curve) !!!!
Is Orca Flow Max softening the same as if I used a quality optimization limiter in my program ? just missing the temperature adjustment!!!
by deactivating the speed limiter in my program, the temperature will be estimated more or less the same if I take the average by my program (example below)

Are the two options exactly the same?.......................................
Nooooo, below the generated moves by my program's speed optimization limiter
Note :
I still have a problem with some peaks still sticking out. to be fixed soon !

one is based on the sudden change in flow per second, the other on the limit not to be exceeded if the temperature is not ideal. I think both are beneficial !!!!!

in orca I used a reasonable value of 10mm3/s² to soften the flow, and it gave this:

after that, use the speed optimization algorithms and gave this :

below a benchy without orca flow optimization

Next with orca flow optimization

Next is after speed optimization

Next is with quality optimization

quality optimization without orca softening

promising result !!!!!!!!!!
your opinion is welcome.

[sb53systems]

I do not recommend excessive use of orca smoothing because it will cause significant slowdowns which influence the quality of the filament and the quality of the print.
I generally get better results by deactivating it.

[sb53systems]

VID20240621075903.1.mp4

[sb53systems]

With alwase the same orcaslicer profil (PETG, 240°,11mm3/s)

Using quality optimization, with 2minutes 22s more

vlc-record-2024-06-23-04h08m01s-VID20240623033544.1.mp4-.mp4

vlc-record-2024-06-23-04h09m35s-VID20240623033544.1.mp4-.mp4

VID20240623040059.1.mp4

With the same 0.04 PA and same PID, i get the best print Quality with a max speed, using a 2018 3D printer and old PETG Filament !!!
i'll get PLA in few days..............

[sb53systems]

with 210°/1mm3s lowest values

[sb53systems]

It was impossible for me to print this before
https://www.thingiverse.com/thing:6635071

VID20240623171919.1.mp4

[ramorimdias]

Wow, that's really promising!

[sb53systems]

Printing PLA with auto nozzle temperature

My program is used as a post-process script befor print

using 70% quality based optemesation

below generated gcode

vlc-record-2024-07-07-02h23m19s-VID20240707010503.1.mp4-.mp4

vlc-record-2024-07-07-02h24m49s-VID20240707010503.1.mp4-.mp4

vlc-record-2024-07-07-02h26m29s-VID20240707010503.1.mp4-.mp4

below a 13m print

VID20240707003258.1.mp4

next a 43m (200% last print)

VID20240706235632.1.mp4

The program will be shared soon !

[sb53systems]

Even if the temperature drops to 174° due to a very low average flow, stringing is still present !

• Is it caused by a High/low temperature
• Or caused by cheap filament
• Or old hot end and extruder equipment
• or Pressure Advance
• or retraction parameters ....
  ??!!!

[ramorimdias]

The results are awesome with PLA, very very clean.

About the stringing, I don't know for sure, but low temperature can indeed cause some stringing... maybe increase the overall temperature on the script?

[sb53systems]

hi dias, yes I agree with you, I try to optimize the ideal temperature for the low flow and i think 185° is better for 1mm"/s flow.

with always the same orcaslicer profile (maximum speed), the temperature is automatically estimated in the script based on the average flow during the print time, then sets a speed limiter for each movement if the speed of the original gcode exceeds the recommended flow rate for the actual temperature.
This approach allows me to print faster with the best quality and without slicer adjustments for each print.
I will never print with a fixed temperature.
Finally, after less than a month, the script works perfectly under orcaslicer provided you avoid the G2 and G3 commands in the GCODE, avoiding ARC Fiting, spiral Z Hope, ...

this is a 28m print (with support)

VID20240707155210.1.mp4

[ramorimdias]

Very good job indeed. Let me know when we can test the script! I hope they implement this approach directly on the slicer at some point!

[sb53systems]

PETG also gives good results !
Next is ABS calibration...

-->

[sb53systems]

I reached my goal, have a better speed vs quality Optemization, below a print of 3h50m
https://www.thingiverse.com/thing:6428358
At 60% Scale.

To

Using 70% Speed optimization vs 30% Quality, the print time will increase by 20 minutes, Note that in general Klipper Estimator (Used in this script) have more acurate time than orca due to Look-ahead and Square corner vilocity calculation. https://www.klipper3d.org/Kinematics.html

But Klipper Estimator d'ont take in concideration the acceleration change set by orcaslicer with Emit Limits in G-Code option

It uses the max_acceleration value of the printer in config.json File, and this causes a small advance in the estimated time.

below is real time

VID20240708213806.1.mp4

VID20240709013229.1.mp4

My script will be shared for free in less than a week in my github, I just have to integrate PA adjustment, add indications and prepare a readme file

[sb53systems]

https://github.com/sb53systems/G-Code-Flow-Temperature-Controller

GCode Flow/Temperature Controller repository
The current version is still under development and will be updated daily.
Take into account that this script is supposed to work under certain conditions :

• Does not accept G2 and G3 in G-Code.
• Time Estimation is based in Klipper Look-ahead Kinematics (may not be compatible with Marlin or Others).
• Reading or generating large G-Code files with this Script can takes up to 2 minutes, depending in your CPU.
• Generated G-Code are 30% to 80% larger than the original one due to Temp and Speed adjustment (can be optimized).
• This Script is not tested with Print Start Moves in G-Code (My Print Start moves are in klipper Macro).

Be responsible and careful with this script by using reasonable values ​​and controlling the behavior of your printer.
Happy Smart 3D Printing...

[sb53systems]

SLYPRO White PLA with Max Quality Optemization

[sb53systems]

Changing PA during printing makes small dots!

to avoid this, I think that PA must be changed during sparse infill !

[sb53systems]

I am delighted to announce a first release of G-Code Flow/Temperature Controller, a post-processing script for Slic3r based Slicers and Klipper Printers.

Repository :

https://github.com/sb53systems/G-Code-Flow-Temperature-Controller

Releases :

SB53 G-Code Flow/Temperature Controller V1.0 (3 Aug 2024)

Happy Smart 3D Printing :-)

[sb53systems]

A new version of the SB53 Flox/Temperature Controller Script was released yesterday (04 Sept 2024) .

https://github.com/sb53systems/G-Code-Flow-Temperature-Controller

Happy Smart 3D Printing :)

[Rickthebig]

Can I use this post-processor script with Orca If I am not using Klipper but RRF?

What happens if the post-processing script finds G2/G3 commands in the gcode file?
a) they will be ignored and will work as before, but will not profit from the postprocessing
b) they will cause the postprocessing script to fail
c) they will produce a gcode file that will bring the 3d printer to explode in pieces

Can I use the "Klipper_Estimator.exe" program even if I am not using Klipper (probably not)? Is it then possible to rely on Orca's own time estimations without using the Klipper_Estimator.exe?

[sb53systems]

You can also try the script as a normal program (without adding it to the Slicer), and see the result!

[Rickthebig]

You can also try the script as a normal program (without adding it to the Slicer), and see the result!

I will try that out, thanks.

Having so much evidence of the positive effect I would submit this as a feature request!

[sb53systems]

@Rickthebig know that time estimation is based on Klipper look ahead Kinimatics, sow all the Estimations are not the same (Flow Averages, temperature Rise/Fall)....

If G2/G3 are found in the G-Code, the Script will show an Error and the print will be canceled.

[sb53systems]

Sory i forgot that i used my Printer acceleration values. :)
How did you deal with the config.json file?

[sb53systems]

@Rickthebig Be aware that the current version is not able to identify when the printing start, with Klipper it is easier with a start macro.

Possible, we could take into account the moves after the first Line_Type

This will be a cool project for you :-)
I won't have time for that, at least not in the next few weeks. sorry.

I remain at your disposal for help.

[Rickthebig]

Didn't you say you need the estimated execution time for every individual move in the gcode file?

Here is a RRF gcode file of a Benchy (sliced with Orca):
3DBenchy_PETG.zip

Yeah, I am willing to engage in these experiments but I need at least a converted file from your postprocessor. If you explain to me how to create the missing printer and filament profile files for 1st time use, I will retry the postprocessing and even dare to print it (keeping a finger on the emergency button).

Where did I get my config.json from? It is located in the sys-folder of the SD card where all RRF configuration is done - please find it attached; I am not assuming that this should be correct to do, I am just cheating your program to get it to do something.
config.zip

[sb53systems]

Estimating time is still the most important problem, and maybe others,
I can experement only in one Kliperized 3d printer!

I dont recomand you to print with your 3d printer any GCode yet, this will result an error from the begining.
I'll make a new version that can start from the correct first move, then you can try a print.

This is my config.json and config.sdb files.
config.json.zip
Config.sdb.zip

I'll let you informed.

Thank you for you contrubution.

Salim.

[sb53systems]

Didn't you say you need the estimated execution time for every individual move in the gcode file?

Here is a RRF gcode file of a Benchy (sliced with Orca): 3DBenchy_PETG.zip

Yeah, I am willing to engage in these experiments but I need at least a converted file from your postprocessor. If you explain to me how to create the missing printer and filament profile files for 1st time use, I will retry the postprocessing and even dare to print it (keeping a finger on the emergency button).

Where did I get my config.json from? It is located in the sys-folder of the SD card where all RRF configuration is done - please find it attached; I am not assuming that this should be correct to do, I am just cheating your program to get it to do something. config.zip

I'll need a 3d Benchy GCode file with the recommanded Max speed

[sb53systems]

I created a new RRF Support discussion in my repositorie
sb53systems/G-Code-Flow-Temperature-Controller#13

[Rickthebig]

I created a new RRF Support discussion in my repositorie

Continuing there then.

[Rickthebig]

Let me kindly point to past posts about this same issue:

#1163

Unfortunately:
github-actions bot closed this as completed on Jan 17

That's a pity considering that now we have a working proof-of-concept
https://github.com/sb53systems/G-Code-Flow-Temperature-Controller
just waiting to be implemented in the slicer.

[sb53systems]

Today, I released the V1.1 Final version.

• All firmwares compatibility.
• Supports Arc moves.
• Faster due to an optimized Klipper_Estimator script.

https://github.com/sb53systems/G-Code-Flow-Temperature-Controller/releases/tag/V1.1

Happy Smart 3D Printing :-)