@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.