Add a bed offset temperature setting

[codejedi365]

I would like to see a temperature offset field per spool. Your offset persistence for the filament is awesome and I would like the same persistence for a bed offset. I realize these are not always related but it would be nice to ensure when I switch between PLA and PETG or ABS that my bed temperature adjusts with the filament brand.

Currently Octoprint has no intention of adding temperature offset persistence based on the comment #2835 since different users use offsets temporarily or permanently. As for your (@malnvenshorn) users they are more likely to want permanent filament related permanent offsets.

I have read the FAQ and provided all required information.

Thanks for all the work you have done thus far!

[malnvenshorn]

Actually this has been requested before and I've always been of the opinion that I don't want to replace the slicer. But I'm wondering to what extent his would be possible. Together with #122 we could set the bed/hotend temperature and the flow rate. Would this be sufficient to successfully print different materials with the same gcode file?

[codejedi365]

@malnvenshorn I've been thinking about your comment above and I think you are right. I am realizing now that I'm not using the slicer settings as they should be used (printer & print specific). Rather I am just going with what is easiest and also so that I remember the odd needs of my printer (glass bed needs a higher temp to stay at the right adhesion temperature). Basically, I was keeping my slicer settings to print "PLA on any printer" (even though I only have one HA).

Thanks for pointing that out. I do although see no harm in providing that feature anyway even though its unusual since it can be helpful. I do also agree with the flow rate feature could be added in as well. And as for your question, It might but I would think other changes would need to be made like fan speeds, retraction amounts, etc. I was more of like "shiny penny"..."ooh an offset feature, I want to use it". Then I would separately slice each gcode file per filament.

[joshpainter]

What about custom GCODE commands for each filament that would be inserted at the top of the print kinda of like Octoprint's events? This way you could just use GCODE to set bed, nozzle, etc. I do understand that the slicer can be used for this too, but the slicer doesn't automatically keep track of my remaining filament like FilamentManager does, so I'd rather put offsets per filament in FilamentManager, even if it is GCODE commands. Then I can use any slicer and not worry about specific filament settings in each slicer. Also, I run Klipper, and the Pressure Advance feature is actually supposed to be tuned per filament, but slicers don't support it obviously. It would be nice to tune PA per filament and then use this proposed feature in FilamentManager to insert Klipper's custom GCODE command to set it correctly per filament at the beginning of the print!

[malnvenshorn]

I organized a PETG sample to test what adjustments might be necessary (only printed PLA before). I made a short test yesterday and as I expected there are more settings to tweak then just the temperature and flow rate (which surprisingly I had not to change). I had issues with adhesion at first, the fan is running at very low speed now while with PLA it is always at max and I adjusted the Z-Offset a bit. I still have issues with massive stringing and bridges were a total failure. So there is a lot more to do.

After this little experiment my position is still the same. Every model should be sliced with the specific settings for the used material and for me it doesn't make sense to somehow "hack" the gcode to make it compatible with different materials.

Besides that I'm open for settings that are really depending on the filament and not the material. I've added the extruder temp offset because some filaments might have a small working window and might need a different temperature for different colors, e.g. clear filament can be printed at lower temps that black.

@joshpainter Why should slicers not support this feature? I'm using slic3r and for each filament profile a can add custom gcode. And I guess the value for the 'Pressure Advance feature' is material dependent?

[joshpainter]

@malnvenshorn that's cool, I didn't know slic3r allows that. I use Cura and don't see any similar feature, so it seems to me that adding this feature to FilamentManager would allow users to use their slicer of preference and let FM handle it. And the Pressure Advance feature is actually filament dependent - even different colors of the same material from the same manufacturer could each need a different PA value. I doubt that slicers would support the feature anytime soon because it is a proprietary feature that only exists in one firmware (Klipper). Please see the Klipper documentation for PA here: https://github.com/KevinOConnor/klipper/blob/master/docs/Pressure_Advance.md

"The pressure advance value is dependent on the extruder, the nozzle, and the filament. It is common for filament from different manufactures or with different pigments to require significantly different pressure advance values. Therefore, one should calibrate pressure advance on each printer and with each spool of filament."

[joshpainter]

(By the way you should give Klipper a shot for PETG printing. The PA feature is specifically designed to be a smarter retraction algorithm to avoid stringing and blobbing. Also PETG likes to be printed SLOW - try 30mm/s or less)

[malnvenshorn]

Is thePressure Advance feature something like Marlins Linear Advance? [1]

I have to look at this in more detail. It definitely sounds interesting and I'm considering your suggestion to add a field for custom gcode for each filament. I appreciate your input :+1:

And thanks for the tip with lower printing speed. I'll try that.

[joshpainter]

Yep it sounds like it! From your link:

"Since the root cause is pressure, LIN_ADVANCE de-couples extrusion from the other axes to produce the correct pressure inside the nozzle, adapting to the printing speed. Once Linear Advance is properly tuned, bleeding edges and rough solid infill should be nearly eliminated."

I didn't see any mention on that page of specific LIN_ADVANCE settings per filament though, so it might be different (smarter?) than Klipper's implementation.

Thank you for your consideration and FM!

[joshpainter]

Another good reason for FM controlling these settings: one of the features I love about Klipper is "macros." I can define custom macros in the firmware that have custom GCODE command names (including parameters). So instead of putting all of my "start" and "end" GCODE in my slicer, my slicer just has a single command in Cura that looks like this:

START_GCODE BED={material_bed_temperature} NOZZLE={material_print_temperature}

Even better just would be:

START_GCODE

And let FM control those two variables as well! The concept here I think is "separation of responsibilities." The slicer's job should be to take a 3d model and make gcode out of it. Ideally it would not care about temperature or other settings that do not directly affect the basic GCODE - that should be the printer's firmware's responsibility IMHO. This way you could slice a model one time on any slicer and print it easily on different printers, different materials, etc. Some of the fancier printers even scan a QR code on the filament spool to use its exact settings - the user doesn't have to know or care about exactly how the printer will tune itself for the material.

Obviously this wouldn't apply to advanced slicer features like changing temperatures per layer and stuff like that, but I think that's where your temperature offset fields make sense. The slicer can be set at a "base temp" and then FM will add/subtract from those temps just like it does now (I assume).

[joshpainter]

Oh and a speed offset would be nice too, especially for PETG since it needs to print slower! So in review, if we had nozzle temp, bed temp and speed as offset fields plus a custom GCODE field for any other custom features like Pressure Advance, then I think I could print 99% of my models without ever touching temp or speed settings in the slicer! Once I find the right temp and speed for a filament, I usually write it down on some tape on the spool. That's exactly what I would like FM to keep track of for me! :)

[malnvenshorn]

In my opinion it doesn't make sense. Stuff like speed and flow rate for example has to be adjusted on the fly, which might put a lot of load on a RPi especially for complex models, or the gcode needs to be modified beforehand and in this case there would be no difference in using a slicer, except that it would take a lot more time on a RPi then on a Laptop for example. I tested this once on a RPi 3. Slicing and analyzing took almost half an hour (resulting gcode file was around 50 MB), the same task took only seconds on my PC.

My suggestion is to slice a model for each material you are printing and upload the files to OctoPrint. Then you can select the prepared gcode for the selected material. This task can be easily automated.

Maybe this plugin can help to make this some more convenient. E.g. if you have a file for PLA selected and you change the filament to PETG the plugin might look for the appropriate sliced model and automatically load it. Just an idea that came to my mind while writing this.

[joshpainter]

Yep I understand your point. My perspective is from always trying to make things easier for new users to get into 3d printing. Eventually a company like Apple will come along and make an app store for 3d models and they'll try to sell you a new "upgraded" model every year. The 3d printing software will evolve along the same lines as 2d printing software. Today you can literally send a Word doc or a PDF directly to a wireless printer and it will figure out how to parse it, "slice" it and adjust itself for different paper (filament) etc.

However, running Octoprint on a Pi along with FM is still in the pretty technical (nerdy) category right now anyway, so I understand your point about current tools. I just think the first developers that embrace this concept of offloading all processing to the printer (or the firmware/pi attached to the device) will get a lot of attention from normal users who just want to have the same experience they do on the App Store: find a cool model, pay 99 cents and your printer hums to life and starts working, regardless of what model it is and regardless of what filament/material you have loaded in your printer.

I don't have enough development experience with the Pi to understand the processing performance of analyzing GCODE, but I know Octoprint comes with the Cura slicer, and the Pi 3 can run several webstreams at once while running Octoprint and Klipper, so I'd have to understand what is so processor-intensive about what (seems) to amount to just grepping text files. In fact I know that Klipper literally analyzes the GCODE in real-time and does some cool processing on the 32bit quad core Pi proc instead of the 8bit, limited memory control board proc.

Anyway, I'm getting way off topic now - thanks for responding and consideration! FM is still one of my favorite plugins exactly as is, because the most important thing to me is knowing how much filament is left! :)

[posicat]

I would love this feature, some of the PLA I get varies at what temperature it's happy, but otherwise prints the same. I would love to be able to warm the bed up 5 deg to get the blue to stick, but the green doesn't need the extra temps. My ideal would be to have 1 setting in Cura for each type of filament I print, and a matching profile in Filament Manager that would pick up the generic and adjust the temperatures for the particular spool I have on.

[a8bit]

I was going to chime in and say that adding a bed temp offset would be a good idea but thinking about it, I have never had to change it unless I'm changing material. I change the end temp from spool to spool but the bed hasn't needed to change yet.

[chatainsim]

What do you think about adding the print speed ? With one of my filament I have to lower the print speed to get better result. For the bed, I've never change it (only using PLA for now).

[sam2b]

At the very least, it would useful to have a "notes" section of each roll of filament so we can write down what settings work well for that roll. Then it is up to ourselves to adjust the slicer accordingly.

As for me, I run a series of tests to collect settings data for each different roll I acquire followed by writing it down in a text document for a personal log. But having such a note/log section integrated into this tool would be very useful (in my opinion). 👍 :-) Just as long the database is reliably backed up and restored!

[brentahughes]

I agree with not replacing the slicer, but I'm of the opinion that a slicer shouldn't be what determines the filament used.

I'd like to see the ability to set the tool and bed temp for each filament and the plugin take the gcode temps and do the math to get the correct offset and set them.

I really like having some calibration or printer part gcode files always ready to go and would be better if I didn't have to manually set the temps when it starts for each filament.