Tweak gcode before sending to printer? (bump fan speeds)

Get Help
1

What is the problem?
Printer occasionally stalls with fan speed errors when using lower fan speeds.

What did you already try to solve it?
Manually inserting M106 S255 to bump fan speeds before any M106 command resolves the problem.

I'd like to enable this capability in Octoprint since sending sliced gcode to Octoprint via PrusaSlicer/Slic3r makes post-processing scripts break. A checkbox to bump speeds would be ideal, or at least understand how to build a pre-print processing pipeline.

I understand from searching on this topic that Octoprint already strips comments out of gcode prior to sending, so it sounds like a mechanism for this is already in place. I'd appreciate any pointers to understanding how this works and how (if) it can be modified.

2

Does PrusaSlicer even run post-processing scripts when doing the upload to OctoPrint? I've found that my scripts work great when exporting to a file, but don't even execute when doing the upload.

Unfortunately my workaround for this until it's fixed in the slicer is to export to a file and then drop that file manually to OctoPrint. I'm sure there is a way to script this but haven't tried to code it up yet.

3

Yes. I've got a pipeline of scripts. When I hit the PrusaSlicer button to export to a file, they work fine. When I hit send to Octoprint, some scripts fail. I believe they are attempting to write to an intermediate file that is not present when "sending" versus "exporting". I'd like to move this sort of functionality to octoprint to eliminate any slicer dependencies.

4

What happens when you add this to the OctoPrint Settings -> Gcode -> Before Print Starts script?

5

That will bump the fan once. The fan is turned on and off at many points throughout the print, so I want to "bump" the fan to full speed (S255) immediately followed by the actual desired fan speed each time the fan is enabled throughout the print.

6

And what about adjusting the fan speeds in the slicer? It's the most easy way.

1 Like
7

You might look for M106 something and replace it with M106 S255\nM106 something or possibly even M106 S255 M106 something.

8

And what about adjusting the fan speeds in the slicer? It's the most easy way.

That will set the fans to the specified speeds (e.g. 20%) which may cause the fan error if the fan doesn't start up (PWM "stiction" if you will). The idea is to bump it briefly to 100%, then to settle at the target level. Simplify 3D incorporates this feature.

9

Yes, that's what I do in my current slicer-side post-processing script in PrusaSlicer. The problem is when trying to send the job to Octoprint from PrusaSlicer or using a slicer that doesn't allow easy post-processing scripts. I'd like to have it set up so that ANY gcode sent by Octoprint has EVERY occurence of M106 preceded by M106 S255 to bump the fan.

Since Octo already strips comments (if I'm correct on that), there's apparently some mechanism in place that would work for this.

10

In theory, you could write a one-file plugin script which hooks into the gcode stream.

Since you're not interested in G29 you would edit this to be M106 instead. You might then do something like...

cmd = "M106 S255 " + gcode

You'd want to test this from the Terminal to see what's actually sent.

11

Ah, I didn't realize a plugin could be that simple. This answers other questions I have as well. Thanks!

Edit: Looks like I can hook in as a preprocessor to avoid slowing prints down. The strip all comments plugin example is a perfect starting place. Thanks again for the pointer. I was getting lost in the docs.

1 Like