Adjusting speed - slic3r?
-
Hi,
I used S3D for my slicing and I was able to change speed while printing.
Now I print a slic3r sliced file and when I set it to for example 150% it happens nothing. Do I need to adjust something in the gcode?
I use M555 P2 in my config file.
-
@hevilp said in Adjusting speed - slic3r?:
Hi,
I used S3D for my slicing and I was able to change speed while printing.
Now I print a slic3r sliced file and when I set it to for example 150% it happens nothing. Do I need to adjust something in the gcode?
I use M555 P2 in my config file.
Assuming you are you changing speed using the slider in DWC, or using M220 to set the speed override percentage, then this will work regardless of the slicer. BUT, it will only increase the speed up to the maximum that is set in your configuration files so check top see what that is set too (M203). Check also that the slicer doesn't change the M203 values. Also, be aware that changing speed during a print is not instant - it can take a few moves to empty the buffer before the speed change comes into effect.
-
I'm using the slider in dwc yes, and I know that takes a little time, that the effect is to see.
The change does not happens in 1-2 minutes what is a lot.
-
Recent versions of Duet Web Control display the requested speed and actual top speed for the current move. Do either of those values show a consistent increase shortly after you adjust the speed slider?
You can send M203 without parameters from the GCode Console to check whether the maximum speeds have been changed by your slicer.
-
The speeds in the DWC are not changing.
Slic3r PE puts this in the beginning of the file
M203 X300 Y300 Z10 E100 ; sets maximum feedrates, mm/sec -
Do you have slicer set to enforce a max print speed?
What gcode flavour do you have Slic3r set to use? -
@hevilp Are you using any form of bed level or flatness compensation? Just looking at the M203 that you are saying Slicr3R PE puts in, and Z10 is a very low value. So if you are using flatness or level compensation, the bed will be constantly moving and that 10mm/sec value might be what is limiting the speed. I assume that you aren't printing at anything like the 300mm/sec that X and Y are being set to.
Edit. You do have print moves that are long enough to reach the desired speed using the accelerations you have I assume? It might be an idea to post you acceleration settings too, both for you configuration files and also any values that the slicer might be putting in.
-
-
@Veti ohhhh thanks, that will be the error.
Slic3r says:
and makes M203 X300 Y300 Z10 E100 ; sets maximum feedrates, mm/sec
BUT: I set the firmware to marlin, in reprap the machine limits button is not there and in the gcode the m203 isnt there too. Thats the fault, wrong gcode flavour. I thought I have to take it, because in Duet I use Marlin compa, too
-
@veti said in Adjusting speed - slic3r?:
m203 for duet is mm/min not mm/sec
Good catch - I missed that.
-
@hevilp said in Adjusting speed - slic3r?:
@Veti ohhhh thanks, that will be the error.
Slic3r says:
and makes M203 X300 Y300 Z10 E100 ; sets maximum feedrates, mm/sec
BUT: I set the firmware to marlin, in reprap the machine limits button is not there and in the gcode the m203 isnt there too. Thats the fault, wrong gcode flavour. I thought I have to take it, because in Duet I use Marlin compa, too
I use Slic3R - both the dev version and PE. I don't see those maximum feedrate buttons regardless of what gcode flavour I select but that's maybe because I'm not using the latest version of PE. Anyway, set the gcode flavour to Reprap. I've no idea why you don't have an M203 command in your config.g but suggest you make one and use sensible values like say 30,000 for X and Y and maybe 600 for Z and 3600 for E (without knowing more about your machine, I can't be more precise)
-
IMO the slicer has no business setting the maximum feed rates, because they depend on the printer, not on what is being printed. Slicers never used to do that.
-
@dc42 said in Adjusting speed - slic3r?:
IMO the slicer has no business setting the maximum feed rates, because they depend on the printer, not on what is being printed. Slicers never used to do that.
Agreed - (although I can't find those settings boxes in my versions of Slic3R PE) . I suspect this must be a later Prusa "thing". I don't have later versions of PE Slic3R because they are becoming more and more orientated towards Prusa's way of doing things with Prusa only printers and Prusa's version of firmware. Multi-filament support is a prime example - fine if you have a filament changing system but a complete PITA if you have a mixing hot end. The dev versions of Slic3R (non Prusa) seem to be behaving themselves though.
-
i think they introduced the feature to have to option of quiet(stealthchop) vs speed (spreadcycle)
The newest version has an option for Silent mode that activates a second set of maximum feedrate. -
@veti said in Adjusting speed - slic3r?:
i think they introduced the feature to have to option of quiet(stealthchop) vs speed (spreadcycle)
The newest version has an option for Silent mode that activates a second set of maximum feedrate.Ah OK. All the more reason to stay clear of it IMO. This stuff really should not be in a slicer, but in the firmware which is where it belongs.
-
@deckingman that's where it gets tricky for Prusa since they are targeting their own firmware as well. As you say, it's become a lot less printer agnostic with their recent releases. I hope that's just a temporary thing while they are working towards the next generation slic3r with a more modern Interface.
I don't have high hopes though. I've posted a few of the issues I've found on their GitHub bug tracker and I've been told a few times that it's not an issue it's a feature, completely ignoring that people other than Prusa printer users might be using it.
I think some of those issues may now be moot because reprapfirmware supports some of the Marlin commands for speed now. But really that should all be set with the gcode flavour to target your slicer to your firmware. As it stands a lot of their new features are only present in the Marlin flavour and so we see issues like this one.
-
@phaedrux I think the clue is "PE" - Prusa Edition. I guess their philosophy is that it's for "our" (Prusa's) customers but they offer it free for other people to try if they want to. I'm not hopeful that they will take much notice of non-Prusa users. Why should they? There is no incentive for the Prusa developers to do that. Fortunately, there seems to have been some relatively recent activity on the non-Prisa versions (Slic3RDev).
-
@deckingman Time will tell. The PE version is inclredibly popular with 3D printing community at large. I imagine there would be some vocal push back if it became too tightly integrated with their own printers. However, the general printer population generally uses Marlin anyway, so these new features generally work for them without issue. So it's really just RepRap users being left behind simply because of the syntax of the gcode.
Hopefully, a lot of the improvements that Prusa has made to Slic3r will find their way back into the main branch of Slic3r.
-
@phaedrux Yes, lets see. TBH, us users of mixing hot ends with 5 inputs are really struggling. I've tried just about all the slicers out there (including some paid ones) and the only one that does most of what is needed is Slic3R - the non PE version. The multi-filament changes that Prusa have made have really ballsed things up for mixing hot ends.
-
@deckingman Not to take this discussion too far off the rails, but have you tried contacting the major slicer makers to see if there is any interest in working with you to expand their support for mixing style hotends? I know that filament swapping and splicing multi material is all the rage right now, but surely there are more mixing hotends actually operating out there in the wild.