hierarchy of control over gcodes, machine vs filament vs slicer

magnets99

Hi,
So i'm trying to tune my printer and it's very slow going.
i've got the basics sorted and i'm happy with my config.g code but now i'm trying to reduce stringing, increase speed and quality etc.

What is the best practice for gcode location and run order?

The machine runs it's own gcode when it starts called
sys/config.g

but then, it can override that with sys/config-override.g

then there is a filament folder and it has a config.g file in which will override the sys/config.g; and presumably it will override config-override.g too. but only if i click it or always if it's loaded?

My Slicer, Orca, also has a section called Machine G-Code for the selected printer and that has bits like

G21; metric values
G90; absolute positioning
M82 ; set extruder to absolute mode
M107; start with the fan off

Then, Orca Slicer has a filament profile with a section called Setting Overrides

i think i could even put codes in there that would then override the orca machine code section which would override the myfilament/config.g which would override the config-override.g which would then override config.g!

So what is the best practice for where g-code goes? Is there a handy flow chart guide about what type of code goes where?

should i not use the filament folder on the machine at all and just use the slicer filament profile since the the slicer has both model and filament?

Should i try to reduce any and all 'static settings' in the slicers printer template otherwise if i change slicer half of my config.g will revert to sys/config.g and might not be correct?

I'm having trouble with tuning and i really don't want to end up with a whole load of changes that i can't track or worse... are having no affect because i didn't know something else is overwriting them.
How are you managing this?

Superbrain8

personally i like to keep as much configurations on the printer itself, has a few benefits in case you loose your slicer configs from a fresh OS install or similar.
also if you run more than one printer with the same build volume you could run sliced gcode for one machine on other machines if you keep the settings on the machine itself.

The filament manager is only used if you configure the filaments in there and load them to the tool, personally i use it for PID models (working with materials that have vastly different printing temperatures benefit a bit from a model tuned for the target temperatures) also feedforward is set there for me.

running most settings on the Printer itself also allows you to switch slicers on the fly, sometimes one slicer struggles while a other one does it fine.

T3P3Tony

@magnets99 There are no hard and fast rules about this in general however IMO:
config.g = things that relate to the physical machine and its configuration have to go hear along with networking etc. Some of these settings may get overridden in other places. two examples: Heater tuning can be stored to config-override.g automatically, and you may wand different maximum accelerations and speeds for a particular filament.

config-override.g = automatically generated, optional, I don't use it and prefer to comply heater tuning etc into config.g but its fine to use it as long as you know you are doing so.

filament configs = stuff you want to set per filament (e.g. limits on extrusion rate or max temp or firmware retraction. Alternatively don't use these and use the slicer settings.

The more you use the various options on the machine in various configs, vs the slicer settings, the more portable it is between slicers. That said slicers are becoming quite sophisticated in changing setting per feature type so you may find leaving it to the slicer is easier.

gloomyandy

@magnets99 There are a few other things you may want to consider (sorry this probably makes things more confusing). When a print job starts start.g is executed and (in recent versions of RRF) when it completes stop.g is executed. Some people prefer to use these files rather than having code in the slicer start/end. As others have mentioned you have the choice of managing filament settings either via the slicer or using the system built into RRF. Similarly you can use slicer generated retraction control or use firmware based retraction (to some degree these go hand in hand with filament control).

As you can see there is a theme developing here, some folks like to have very generic gcode being generated and have as much as possible handled by the firmware. This may allow the same gcode file to be used on different machines more easily. Others use the slicer to control pretty much everything. I tend to use a mixture of the two, though because I like to experiment with settings I'm moving towards minimising what the slicer does. But really there is no hard and fast rule.

droftarts

@magnets99 to calculate accurate timings out of the slicer, it will need to know the speeds and accelerations the machine is capable of. Some slicers then confusingly override the machine settings by emitting these in the exported Gcode. You should be able to turn this off, and use the slicer machine settings just to calculate times. It gets inaccurate anyway as soon as you start setting pressure advance and input shaping.

I think you’re running a Volcano hot end, and because of the larger melt zone, they do tend to string and blob more, particularly on small/slow prints and features.

Ian

magnets99

Thank you all,
some great advice there.

I'm going to stick with orca slicer, so with that in mind i shall:

try and avoid override_config (i've moved my heater pid settings over)

not use the filamanet section on the duet and instead use the slicer filament settings

check that my slicer isn't messing about with static settings (as i do want to do pressure advance and input shaping).

@droftarts
I took the little silicon jacket of the HotEnd and i agree with you that it's a volcano-175-AS. that's really good info about the stringing as i'm currently doing teachingtechs benchmark for temperature
https://teachingtechyt.github.io/calibration.html#temp
and i can't even get one bridge working. But at least i feel a bit more confident now about why.

martinv

@magnets99 just regarding the bridging, I have a couple of machines with the volcano hot end and they bridge fine. They are both running 0.6mm (used to run 0.8mm) nozzles. I have found them to be 'blobbly' and 'stringy' however compared with a 0.6mm V6 nozzle for example.

I hear you regarding all the configs all over the place. I'm not sure what to suggest, but I have spent ages trying to optimise a setting only to find out that it's being overwritten and my changes are having no effect whatsoever. Plus, I think slicers are not without bugs; I'm using the latest PrusaSlicer and I think there is at least one bug in there to do with what you see on the screen not being what is sent to the printer. I'm talking actual speed/volumetric flow. I also tried OrcaSlicer, and at least once managed to somehow produce a retraction tower test where the retraction didn't vary at all!

Here's a thought though. The latest PrusaSlicer (and similar) let you display actual print speed, but there's no way for this to be accurate unless PrusaSlicer is the component that's controlling the speed. So my current thinking is to set speed and acceleration high on the printer, and lower in the slicer. This means however that one can't make use of (say) hardware retraction on the printer because then that cannot be accurately displayed in the slicer, leading to great confusion. At least that's my experience.

I'm starting to find that tuning a printer is not that easy.

magnets99

Yes!
I understand now why the previous owner was reluctant the upgrade the firmware.
I'll get there eventually.
Just trying to bend the bed flat Again....

dc42

@martinv said in hierarchy of control over gcodes, machine vs filament vs slicer:

So my current thinking is to set speed and acceleration high on the printer, and lower in the slicer.

The printer speed and acceleration limits should always be set no higher than the printer can reliably achieve. Otherwise you may end up with the slicer commanding the printer to move faster than it can manage, especially if you use the speed factor control in DWC or PanelDue to increase speed. You can of course set lower speeds and accelerations in the slicer settings.

A user submitted a pull request to PrusaSlicer some time ago to fetch the printer speed and acceleration limits from the RRF object model and to modify the print time calculation to better reflect RRF when RRF is the selected firmware type; but unfortunately it wasn't actioned. See https://github.com/prusa3d/PrusaSlicer/pull/8087.

n8bot opened this pull request in prusa3d/PrusaSlicer

open Fix RRF Time Estimates and Add "Get Machine Limits" button for Duet printer hosts #8087

martinv

@dc42 said in hierarchy of control over gcodes, machine vs filament vs slicer:

The printer speed and acceleration limits should always be set no higher than the printer can reliably achieve. Otherwise you may end up with the slicer commanding the printer to move faster than it can manage, especially if you use the speed factor control in DWC or PanelDue to increase speed. You can of course set lower speeds and accelerations in the slicer settings.

That's something I have wondered in the past. If the slicer says to move at 100mm/s, and RRF has the speed limit set to 150mm/s, I would expect the printer to move at 100mm/s. If the speed factor control is then set to 200% in DWC, what happens? How fast does RRF drive the printer? 150 or 200mm/s?

I mention speeds, but presumably this applies to accelerations just the same?

I did look in the DWC manual for the speed factor control but it wasn't clear to me what limits were still imposed, if any.

This also had me wondering the other day as I was adjusting pressure advance as well as input shaping. In particular if pressure advance could result in extruder feed rates outside the limits that I had specified in RRF, and if some sort of clipping might occur if hard limits were enforced resulting in some obscure printing artefact. Same with input shaping and how the actual moves sent to move the head might look after going through a 'shaper filter' and whether they too were being 'clipped'. ... I have a background in audio design where clipping is just about the worst thing imaginable for a poor audiophile.

Now that I'm running two linear delta machines, where the amount the effector moves is not nicely related to the rotation of a single stepper but some combination of all three depending where on the print bed you are, it really starts to do my head in. Plus that's without considering bed mesh correction, tapering, skew adjustment, or others I don't even know about.

A user submitted a pull request to PrusaSlicer some time ago to fetch the printer speed and acceleration limits from the RRF object model and to modify the print time calculation to better reflect RRF when RRF is the selected firmware type; but unfortunately it wasn't actioned. See https://github.com/prusa3d/PrusaSlicer/pull/8087.

Oh, that's a shame, I for one would have found it useful.