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.