Printspeed mm/s and mm/min
-
Hi there,
I have two thing to solve.
Maybe someone has an idea or a solution.I have a Prusa i3 and converted the Einsy-board with a Duet 3 mini. My slicer of choice is BambuStudio. Thats already on my PC, I am used to it and I want to save further discussions with our IT to get another Slicer.
RepRap uses mm/min and I couldn´t find any way to change it in the slicer. BambuStudio outputs mm/s. The printspeed will be way to slow (by factor 60).
I don´t want to multiply all the speeds by 60 as the flowsettings in the filament won´t work anymore.
Though the max-flowrate for filament is capped to 70 mmÂł/s which will cap automatically the printspeed again.
Is there any other practical way to solve this?On the same printer I want to print a part in vasemode,
I want to increase the Printspeed every second loop (Layerheight 0,24 mm) by 5%.I think for both problems a post-processing script could solve this. But maybe there is any other possibillity.
Would such a script be a big thing?
I couldn´t find a site where the basics of scripts are explained.Thanks in advance and have a nice day.
-
@koreandi BambuStudio is meant for Bambu machines, and is targetted specifically for them. I didn't know they use mm/s feed rates; that is not standard. Usually the G0/1/2/3 F parameter is defined in mm/min, and that's how all other firmwares (Marlin, Klipper, CNC machines using LinuxCNC, Mach 3/4) interpret feedrate. I don't know if there is a setting in Bambu Studio to change this. It's also possible that it's not the G1 F parameter that is being output incorrectly, but that machine configuration for speeds and accelerations (eg M201, M203, M204, M566) are being output in the Gcode, and are set in mm/s, which is a more common error. Can you share a short Gcode file generated by Bambu Studio?
I think Bambu Studio also does other things that RRF does not like, like changing acceleration mid-move. You may be better off using OrcaSlicer, which is based on Bambu Studio (which itself is based on PrusaSlicer) so should be familiar to you, which will generate gcode more appropriate for RepRapFirmware.
For your second question, you can usually make changes on a per-layer basis within the slicer, by adding custom gcode (ie a script) at each layer change, using variables that the slicer understands. In Prusaslicer and OrcaSlicer, these variables are called 'placeholders' and are pretty much any of the settings that you set, plus a few more. You can find a list of Prusaslicer ones here: https://help.prusa3d.com/article/list-of-placeholders_205643
Bambu Studio placeholders look the same, documented here: https://wiki.bambulab.com/en/software/bambu-studio/placeholder-list
Orca Slicer has a dictionary of sorts to help compose custom Gcode. See this OrcaSlicer forum thread which shows how to access it: https://github.com/SoftFever/OrcaSlicer/discussions/5498For example, in PrusaSlicer (should work OrcaSlicer and probably Bambu Studio uses the same format), you could add the following custom g-code in 'Printer Settings>After Layer Change G-Code' to increase speed:
;Increase speed every 0.5mm of Z height {if layer_z >= 0.5}M203 X1000 Y1000{endif} {if layer_z >= 1.0}M203 X2000 Y2000{endif} {if layer_z >= 1.5}M203 X3000 Y3000{endif} {if layer_z >= 2.0}M203 X4000 Y4000{endif} {if layer_z >= 2.5}M203 X5000 Y5000{endif} {if layer_z >= 3.0}M203 X6000 Y6000{endif} {if layer_z >= 3.5}M203 X7000 Y7000{endif} ; ... etc ...
If you set the print speed in the slicer to the maximum you want it to go, ie 10000mm/min, then limit the machine speed with M203 (or M204, if you prefer), and increase it by layer height, I think you'll get the effect you're looking for without using a post-processing script. I'm not exactly sure if this will work in vase mode, but I think it should. There is probably a way of writing this script to increase speed by 5% every layer, I just haven't worked it out exactly!
Ian
-
@droftarts since Bambu studio is derived from PrusaSlicer, I think the mm/s vs mm/min scale refers to acceleration control
-
@oliof acceleration is always specified in mm/sec^2. The problem arises because RRF allocated and published the M203 command (in the RepRap wiki), then Marlin added support for M203 and chose mm/sec as the unit. In fact there is no reason for slicers to generate M203 commands, but unfortunately they do.