Dynamic FeedRate change plugin (Speed and extrusion)


#1

I am currently working on a vb.net application to insert feedrate changes into gcode and I think that this could be a good prospect for a plug-in for octoprint (and Cura).
The idea is that a print that is in some way tapered should really be printed at a slow speed but setting the whole print to a slow speed to accommodate this would result in a print that is slower than it needs to be.
If a plugin could be made to allow the setting of a lower layer number, a top layer number and a percentage reduction value then it could insert M220 ans M221 commands into the Gcode between the lower and top variables to slow the print down by the given percentage by the time to top layer number was reached.
The result would be a print that could start fast but reduce in speed and extrusion rates as it got towards the tapered parts.
Is anyone aware of such a plugin already existing?
I am able to code this in vb.net (and have almost done so) but I have no idea how to make plugins for either octoprint or Cura so if anyone with enough skill in that area thought this was a good idea it could benefit the community as a whole.
Could I have comments please. It sounds good to me but I'm no expert and there might be reasons why this would be unworkable.
Thank you.


#2

I've not seen any plugins which do this.

I have done some work with variable feedrate/speed for the purpose of creating textured transparency. It's called Velocity Painting. I tried it and didn't love the results on my printer.


#3

Thank you.

My purpose is quite different from velocity painting (which I have tried and was quite impressed with on certain prints), as I want to reduce speed and extrusion in small increments between a range of layers, in order to print slower any upper levels that are tapered and need slower printing for better quality.

I have created the .Net program I mentioned and the program inserts the correct M220 and M221 lines into the gcode at the right layers. I just need to test it on an actual print. If it works I suspect it would make a useful plugin but don’t have the knowledge to write it.


#4

So... the thought is to install the .NET Core Runtime on a Raspbian operating system? Have you tried this on Raspbian Stretch Lite yet?

This is an odd stack of dependencies for the standard Python-based pip process that normally occurs to support plugin installations. I'm pretty sure you'd be the first to attempt this.

Honestly, I don't think I'd recommend going this route. Is there another language that you could use?


#5

No. You misunderstand. I will use the .net program I created as it does a lot of other gcode related things. I just wondered if anyone would think the idea good enough to create a plugin for it, as I don’t have that skillset.


#6

Oh, alright.

I myself do all sorts of one-off projects using the Go language.


#7

S3D has this ability built in to the slicer, multiple process with full control of all settings at the layers you wish to change them. But it would be nice to be able to change the speed with out doing it manually during the print (at the time the layers are being printed) but after the print has started.
Good luck with your project.


#8

Thank you. I have tested my code (without using filament J) and it works correctly to gradually reduce feed and extrusion rates during the selected portion of the print. Depending on the model, this could take place over possibly hundreds of layers.

Now I just have to learn how to create octoprint (and maybe Cura) plugins. I assume this is all done in Python?


#9

Most of the work is done in Python. The user interface is JavaScript.

Just noting that people now print with both absolute and relative extrusion these days. I would guess that a sliced GCODE file with absolute extrusion would be difficult to adjust the extrusion audit to keep it happy. (I was looking at something similar over a year ago before Cura added relative extrusion. At that time, I abandoned the work since managing the audit was a pain.)


#10

Yes, I agree. My method is simply to parse the gcode and insert M220 and M221 commands at the levels determined by the code. I’m not sure how these work across both relative and absolute extrusion.


#11

Try some parts, having sliced with both extrusion modes. See if both behave correctly.

Since you're triggering this in firmware, I would guess that it will behave.

A year ago, I was trying to do this as a post-slice process with a Go language program, for what it's worth. And I didn't have those two M-commands.


#12

@Al_Wilson
One tip. Slic3r does this automagically:


#13

Szafran.
That's interesting, though I see that it does it based on the amount of time taken per layer (Like S3D). It's a nice idea. It seems to switch immediately from the default speed to the min speed, which might not always be the best option as fast layers don't always mean the top layers, but I can see how it would work well enough. I use either S3D or Cura, both of which I can handle in my vb.net code.
I am keen to learn how to code plug-ins for Octoprint (and maybe Cura) when I find enough time so maybe I'll eventually get to convert my vb.net code to a plugin. That would be cool.