When I print via octoprint on my Original Prusa i3 Mk2.5 (Firmware 3.3.0) it seems to ignore the speed settings on the first layer and for the outer perimeters
What did you already try to solve it?
Sliced the file multiple times using different built in settings of the Slic3rPE 1.40.1
Tried direct print from SD-Card: worked as intended..
same file via octoprint: too fast
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)
Octoprint Version 1.3.9rc2
Octopi Version 0.14.0 (on a raspi zero w)
Original Prusa i3 Mk2.5 (Firmware 3.3.0)
Slic3rPE 1.40.1
Plugins:
Detailed Progress Plugin
Display ETA
Dropbox Timelapse Plugin
Exclude Region
FileManager
Firmware Updater
Fullscreen Plugin
GcodeEditor
Multi Colors
Octolapse
Tab Order
Telegram Notifications
Yeah there seams a inconsistency with the version numbering for this plugin. I just deinstalled (the definetly faulty) 0.1.1, installed it new and "my" bug (issue 3) has gone.
I own a Creality CR-10s PRO and I'm using Octoprint. It seems like the printer uses normal speed when printing the 1st layer, and after that it goes wild. It looks like the printer is increasing speed during the print proces.
Even when I adjust the feed rate and flow rate, Octoprint automaticly changes it back.
I don't use the ExcludeRegion plugin, so that's not gonna work for me.
The flow rate and speeds are set by the slicer (i.e. imbedded in the gcode). OctoPrint doesn't "mess" with them.
There is a flow rate multiplier set in the firmware that will adjust the flow rates set by the GCode by the given percentage. This multiplier is often adjustable via the printer's LCD display.
See the Marlin documentation for M220 and M221 for additional information.
I'm stopping by to say I am researching the same problem on my CR X. No matter what speed I set Initial Layer or Layer 0 for, it always flies at about 65mm/s when I want it slowed down to 10mm/s or 25mm/s. The second layer will slow down to the preferred speed, but by then, I've already restarted the print because the speed of the first layer caused some walls to lift.
@Vicfix@Natalie_Graham The core OctoPrint doesn't change the speeds set by the gcode but I can't vouch for every plugin. Troubleshooting this problem will require at least a serial.log.
The first experiment to try is running OctoPrint in safe mode. This will eliminate all the plugins and if the problem goes away, then please provide a list of plugins. The next step will be to disable plugins until we can isolate which one(s) cause the issue. If the problem still exists in safe mode, then the logs will be essential to us helping you solve this problem.
I would recommend slicing a small object, a cube or something simple and providing the .stl and the .gcode generated by the slicer. You can slice this object multiple times with different speeds and compare the .gcode output. Comparing the .gcode with the serial output should show where the speed changes are being made.