which rules? config.g vs slicer?



  • sorry for the newbie question but when the same settings are in both the config.g and slicer then which overrules the other?

    I realise that in an ideal world there will be no conflict but as an ignorant newbie I can see myself making mistakes and also it would be nice not to have to reslice a print job any time I change the machine setting which at the moment is every print as I learn what the limitatons and best configuration are.

    so I have noticed that items like acceleration, jerk, max speed, fan control etc are all available in Cura when slicing and I had rather assumed that the settings in config.g would be the machine settings but since its all Gcode what happens when they conflict?

    say I set acceleration to 100 and jerk to 10 for the X axis in my config.g but the settings in Cura are acceleration 500 jerk 30 for the X axis on a print that I slice.....

    which are used?

    sorry if this is really obvious but it seems like the gonfig.g would be bypassed by a slicer command unless there is some logic to compare the model Gcode to the config and go from there with the most appropriate setting - not sure how that would be achieved.

    I guess what I am really after is what's the best practice - do I get the machine tuned by working with the Config.g file or do I set realistic maximums into the config.g and then tune in Cura?

    The more I think about this I think I have been trying to do this the wrong way and I need to do the tuning in the slicer as different filaments, nozzles and model types may all need slightly different settings.

    so what is the correct way?



  • All gcodes that get sent to the Duet take effect the moment they are sent. Config.g is run first, but it can be overridden at any time. So when you print a file, any gcode contained within it will be executed. That includes any gcodes that change settings originally set in config.g. So in the case of Cura where it can control speed, accel, and jerk on a per move basis, it will modify those settings on the fly.

    Setting realistic maximum or comfortable values in config.g is probably the best way to go. Then you can fine tune with Cura, which is more efficient, because it knows what each movement type is, where the firmware does not. Cura can set speeds slower for outer perimeters and faster for inner and infill.

    Cura has a plugin called Printer Settings. It will let you input the maximum values from your config.g which will give it a better idea of what your machine is actually capable of and should improve the print time estimates as well.



  • Hi,

    If you see things like min and max in reference to a setting in the config.g file that will limit what the printer will do.

    Unless of course the file being printed happens to have those same commands and changes the min/max values - I don't know how common that would be.

    So aside from that scenario the commands from the file being printed will be limited to the range established by the min/max values.

    Any value within the range will be used without any change.

    Frederick



  • Another way this can come into play with the slicer is when your slicer has sections for custom gcode commands. The most basic of these being the start and end gcode. It adds those gcode actions to the sliced file to prepare your printer for printing. But there is also code that can get inserted for tool changes, or layer changes, etc. Slic3r even lets you have custom gcode for each filament. So you could have a default value for pressure advance in config.g and have a different value for a certain filament get executed only when you've sliced a model with that filament selected.

    This kind of raises the tug of war between firmware control and gcode file control and the portability of gcode files. The more settings are hard coded into the gcode file, the less portable the gcode becomes. Retraction is a good example. If you let the slicer handle it, your values are set and can't be changed without reslicing. But with firmware retraction you can modify it on the fly to either find the ideal settings, or to re use the file with a different hotend or material that needs more or less retraction. The same can be said for temperature, fan control, etc. There is the idea that the gcode file should contain nothing but the geometry data and the firmware should determine everything else so that gcode becomes interoperable. But slicers have become print tuning engines in addition to just geometry engines. But I digress...



  • @phaedrux @fcwilt

    thanks for the explanation.

    I think I was working from the assumption that the slicer was pure geometry but the more I used it the more I realised that could not be the case and I was starting to get frustrated that the "tuning" I thought I was doing in the config was apparently having no effect - which of course it wasn't lol

    glad to see that although I was doing it all wrong the thought process that brought me to ask the question was at least heading in the right direction.

    this whole thing is such a steep learning curve but at least the Duet is making things clear if not always obvious to the uninitiated.



  • I don't think you were doing things wrong. It's totally feasible (and probably preferable at first) to have the slicer do as little as possible and control everything from firmware. That way you can modify values from the console while a print is going, and then you can see immediately what the different between 600 jerk and 1200 jerk is. This lets you test things faster since you don't have to reslice. Once you have a good idea of what your printer is capable of and what the values actually change, you can bake them right into the slicer.

    Check this out, it may help with the tuning. Basically a menu system for live tuning various settings.

    https://forum.duet3d.com/topic/6181/tuning-macros-menus-accel-jerk-retraction-pressure-advance



  • @phaedrux

    wow ok that looks like a great way to learn.

    its one of the things I am finding a bit of struggle is that as a beginner I have not found any really basic explanations of what does what and the results of many changes.

    most of the information I am finding seems based on an understanding of how everything works and while I have researched the various settings it seems like two steps forward and three steps back each time I find something new.

    From the link you gave one of the first things mentioned is disabling acceleration and jerk in the slicer - I hadn't realised that could be done and now have found how to turn them off which should help.

    its basic scientific method to only change one thing at a time but with the same settings in more than one place it was difficult to know if that was what was happening so thank you again. hopefully I can work to a basic setup that works and then use your tuning macros to work through each variable.

    I had been trying to slow everything right down to get a good print before starting to speed things up but was not getting the results I was expecting.

    I had a problem with a massive layer shift (5-7mm!) and tried swapping to slic3r and also looking at the gcode file to try and understand what was going on which was where I noticed a high jerk setting which I think was the problem with a fast travel move overpowering the Y axis which brought about this query as I knew I had the config about right but the slicer was giving different settings.

    now hopefully I can start to work forward knowing any changes will hopefully now do what I expect them to.



  • Part of the issue here is that different users and devs have different ideas about what the proper division of labor in the toolchain is. For example, once upon a time, slicing a complex model might take multiple hours, and people had pretty strong incentive to try to reuse gcode files on multiple printers or hand-edit the start gcode to adapt it from one printer/filament/whatever to another. Folks like Makerbot at one point even sold pre-sliced print files! (X3G in this case, which is a post-processed binary format version of gcode containing step counts.) So the idea of printer firmware containing all the printer-specific settings and the gcode just being geometry made a lot of sense. Now that slicing algorithms are fast enough for reslicing to be a matter of minutes, very few people care about gcode portability anymore.

    Some folks really want to tune printer settings at runtime mid-print, so they need a lot more functionality to be gcode controlled. Some folks want to lock down settings (eg to save cost on board components like memory/EEPROM or enforce DRM) and they need more stuff baked into firmware. Some people run non-user-editable print file formats like X3G or JSON or .dremelwhatever exclusively from SD card and can’t make any meaningful runtime changes, while some people exclusively use USB hosts to stream commands and don’t have any runtime-accessible memory for storing settings. It simply varies a lot.

    Basically you’re never going to get a standardized “how it should work” agreement between all the different commercial and community players in the space, so there tends to be multiple ways of doing things in the more modern firmwares like RRF that support different hardware/slicer combos.



  • @opentoideas said in which rules? config.g vs slicer?:

    I have researched the various settings it seems like two steps forward and three steps back each time I find something new.

    Yup that sounds like 3D printing in a nutshell. I don't really have hobbies, I just find complex systems to play with. 3D printing scratches all those itches. It's mechanical, electrical, hardware, software, planning, praying, physical, virtual, engineering, and creativity all rolled into one. If you crave knobs to fiddle with, this is the penultimate.

    Getting the machine mechanically dialed in is really only the start. The magic happens in the slicer. Knowing how fast to go and when. It's very iterative. Isolating variables is difficult because things are very interdependent. It's easy to go too fast, but you can also go too slow. It's basically getting a thousand sweet spots to line up.

    For some people this is fun, for others, this is frustrating. Either way though, the machine demands you put some time and effort into learning it.



  • @phaedrux @RCarlyle

    Lol yes that is what I am finding. Satisfying when it works and frustrating to figure out why it dosnt.

    Reminds me of a prior life working with steel forming rolls. We had a "simple" process for taking rolls of steel and slitting them to the width needed then re-rolling them to reduce the thickness to 0.7x whatever it started at which increaced the yield strength at the cost of ductility.

    Seemed simple enough when the MD decided to send it to eastern europe but what no one at the top realised at the time was that despite all the theory the actual process was more of a dark art that relied far more on instinct and experience than the theory would suggest...... that slitting and rolling line after a year of failed attempts at high cost was eventually just abandoned as by that time the skill base was lost and it just wasnt something that was cost effective to learn by mainly error.

    I am loving the possibilities of 3D printing and I can get usable parts eventually and with each bit I learn The future possibilities seem fantastic but for the moment just getting some working settings and repeatability are my main goal and keeping things simple until I learn enough to move on to the next setting seems sensible.

    I never intended to upgrade to the Duet this early in the process as the downside of so much tunability and control is just more ways for the ignorant(me) to mess things up.

    I was only just getting to grips with the machine when its controller died so rather than replacing it with the same junk the Duet seemed like a good plan.....

    To be fair I cant fault the Duet. It continues to exceed my expectations at every turn and the more I learn, the more impressed I am with its capabilities and its design.

    Unfortunately the main thing holding it back at the moment is my lack of knowledge but hopefully that will change with time.

    A big thank you to you all for answering my basic and I am sure obvious if not stupid questions. Its been a great help.



  • Feel free to post your config set if you'd like a sanity check.



  • @opentoideas said in which rules? config.g vs slicer?:

    To be fair I cant fault the Duet. It continues to exceed my expectations at every turn and the more I learn, the more impressed I am with its capabilities and its design.

    One of the things I like most about the Duet family is that you can change any setting from the DWC console if you want to try something or verify something.

    No more having to recompile the firmware to make such a change.

    Great stuff.

    Enjoy.

    Frederick



  • @phaedrux
    LOL I think sanity is unlikely or I probably wouldn't have gotten into this 3D printing lark but thank you for the kind offer.

    config.g

    this seems to be a reasonably stable starting point.

    the machine is a CR-10 but with dual Z axis also a Titan Aero with volcano which I have rapidly realised is too heavy for the CR-10 carriage to support and a Precision Piezo Z probe which inst much help as between the carriage and flexible bed on this machine i get too much variation for it to be reliable.

    like you said this "hobby" ticks all the right boxes and the engineer in me is already looking at ways to help resolve these issues but for the moment its meaning careful manual leveling and tweaking before each print.

    @fcwilt I couldn't agree more. my biggest problem is the Duet is making it painfully obvious where the machine is lacking as there is nowhere to hide.

    while the piezo always "worked" with the original controller and I was blaming myself for its misuse as soon as I got the Duet up and running it became obvious there was something strange going on and the more I checked the various mechanical parts the more apparent the problem became.

    while in some ways ignorance was bliss at the same time now at least I can work to tighten things up and solve some of the issues.



  • oh dear, some of my confusion has now resolved itself into a reason even if I have no idea why...

    @Phaedrux I hope you can help me with a puzzling problem with Cura, I have been printing test cubes this morning:

    1 : acceleration, jerk and retraction disabled in the slicer - config ruling the print settings

    2 : same as 1 but with retraction enabled in the slicer

    3 : same as 2 with acceleration and jerk enabled acceleration 100 , jerk 1 (vs 300 and 5 in config)

    while there was little difference between 1 and 2 I expected 3 to be the best of the lot but within a few minutes I knew something was wrong as after the first 2 slow layers it went to hell and started looking worse. and all my instincts pointed to acceleration being far to fast......

    so I had a look at the Gcode files for them and cube 3 is strange in that where I expected to see speed and acceleration commands what I am seeing is M566 with settings of 1600 which I understand is jerk!

    I am guessing that I have something fundamentally wrong with my Cura setup but I am at loss as to what. the only real change I have made since moving to Duet was in the machine setting and I changed the Gcode flavor from Marlin to RepRap as I was getting a ton of errors relating to a command that did not exist in Duet and this cured that problem.

    I am totally lost with this though and off to see if I can find anything that may explain where I am going wrong??

    turned off jerk control in cura which removed the strange jerk command so hopefully its not as bad as I first thought.. will have to come back to that later and see why I was getting those huge jerk numbers despite the low setting but for now onward and upward LOL



  • @opentoideas First of all you need to check the units here. Jerk is given in mm/min (as opposed to mm/s). So a value of 1600mm/min means 26.67mm/s.

    Then I think that jerk value of 5 (or 1) mm/min is close to having jerk disabled. The default if you do not set anything in RepRapFirmware for X and Y is 15mm/s or 900mm/min.

    I just checked your config.g and apart from the very low jerk settings (again, I think you missed that this needs to be given in mm/min) at least I did not find anything obviously problematic.

    Personally, I would never use any slicer's jerk or acceleration control. If I need to adjust the values I will do this via DWC at print time and if I like the settings I can immediately enter them in my config.g there as well.



  • @wilriker

    thank you I had noticed the difference in units but you are of course right that i have such low values it is effectively no jerk. I think the main issue is I am trying to work around mechanical slop with settings while I wait on the parts to try and resolve the flex issues.

    The problem is that the tool carriage just is not solid enough and corners are not sharp.
    0_1536755765220_test cube.jpg

    to my thinking (which is most likely wrong!) this seems to be under extruded on the straight sections but over extruded where there is a direction change and I have tried with jerk between 1 and 60 with no change so I think something else must be the issue.

    speed is 20mm/s acceleration 100mm/s2 both of which I believe are quite slow. all of which was to try and combat the sloppy head (its semi stable each time I tweak it but if I tighten it up enough not to move, the bottom wheel bracket which is unsupported will bend over time and I have to straighten it and start again. (was not designed for the heavy direct drive extruder but I am stuck with it for the moment)

    I have some parts on the way to hopefully resolve the flex and I think until these arrive I may have to live with this.



  • @opentoideas Your accel and jerk values definitely are very low. I had mine also set very defensively with only 400mm/s² acceleration when printing but just recently upped this to 3000mm/s² (this reminds me that I wanted to create an online version of an existing spreadsheet that will give you the acceleration your motor can handle...). Also my jerk value is set to 10mm/s or 600mm/min for X and Y.

    In the image you posted I cannot see any under-extrusion (but I am not an expert on this topic) but there is at least some over-extrusion or the nozzle being too low so the filament has to squish out to the sides.

    The not so sharp corners on the other hand might even come from jerk being a bit too low so it cannot take the corner fast enough to counteract on the remaining pressure in the nozzle. What you could try is to either activate Coasting in your slicer or tune Pressure Advance in RRF. I would at least say try the first (they both fulfill similar tasks by different means but enabling Coasting in the slicer is just a one-click-action).



  • @wilriker thanks again,

    I think I will raise the settings back more to the default for the printer and have another try as I am reading that too slow can cause just as many problems as too fast.

    I have had a play with pressure advance though not coast but from my limited understanding I believe these only change the start and end of an extrusion not during and these lines are one continuous run so I don't think there should be a difference but I could well be wrong.



  • @wilriker said in which rules? config.g vs slicer?:

    Personally, I would never use any slicer's jerk or acceleration control. If I need to adjust the values I will do this via DWC at print time and if I like the settings I can immediately enter them in my config.g there as well.

    Well there are good reasons to let the slicer handle it. Mainly because it can set different values based on move type. Inner Perimeter versys outer perimeter versus infill versus solid infill versus first layer, travel, etc. The firmware can only set acceleration based on print or travel. So you have much finer grained control in the slicer which lets you optimize speeds for quality where it's visible and while still helping to eek out shorter print times. It also lets you use modifier meshes to modify settings for separate sections of the model. Go fast on the large wide solid base, and slow down for the detailed slender model on top of the base. One size fits all only works well when the model is rather homogeneous in its structure.

    I treat the config as the default sane values and absolute max values. The slicer gets to determine the exact values during printing based on the rule set I've given it for that model.

    @opentoideas That part looks a little over extruded. Have you calibrated your esteps value and extrusion multiplier? That should really be the first step.

    Good sane starting values for print speed is 50mm/s, 600mm/min (10mm/s) jerk, and 1200mm/min (20mm/s) acceleration. Travel speed 200mm/s with 900mm/min jerk and 3000mm/min acceleration.

    Too slow jerk can lead to the print head slowing down too much on sharp corners leading to plastic oozing out and making the corner bulge. It can also lead to jerky motion on otherwise smooth arcs. Same can be said for too slow acceleration.

    Perhaps this is a good analogy. Have you ever used a silicone caulking gun? As you pull the trigger it pressurizes the tube of caulk and it starts to squirt out the tip. If you keep a steady pressure and distance from the work surface the caulking will look nice and even. If you slow down and speed up or pause your movement the caulking will still come out, even if you release the trigger due to the built up pressure. So the goal is to try and keep the print head moving in a fairly consistent manner throughout the print.

    The firmware has something called pressure advance that tries to combat this by basically relieving the built up pressure sooner and more gently so that by the end of the move the pressure is at 0. This would be the next step to tune.



  • @phaedrux
    jerk is one thats not seeming intuitive as I felt lowering it would reduce jerky sudden speed changes but what you are explaining matches what I was seeing with a sweeping curve being almost like low res step x then y then x etc. rather than a smooth sweep.

    I bumped things up but looking at those numbers I think I need to go further as there was a noticable improvement but not there yet.

    I was initially hesitant to mess with the jerk numbers not fully understanding the implications and now wish I had listened to my own advice and left it alone!

    Oh well, its not the first time and I am sure it wont be the last time I make things worse messing with something I dont understand.

    Yet another learning experience!

    While I get the description of pressure advance does it only change the start and end of an extrusion or does it also vary mid run like these corners?

    I had thought the former but I realise that while thats the easiest way to describe the function the latter would possibly be more usefull and make sense too.

    Whats the saying... a little knowledge is a dangerous thing.

    Its easy to read the description of a function and assume you understand it but I get the feeling that while the description may be simple the implications are anything but!

    Yes the extrusion esteps are callibrated but the extrusion multiplier.... best I could work out for this was its a fudge factor to adjust despite the calibration, which I figured would be an experience thing rather than something that could be calculated so I was leaving this for the moment as I thought it would be near enough until I ran out of other gremlins - wrong again?


 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.