Using Autodesk Fusion 360, Cura 4.12.0 and OctoPrint 1.7.2 running on an ODROID N2 SBC under Ubuntu 20.04.3 LTS (GNU/Linux 4.9.277-117 aarch64). The ODROID has 64GB of eMMC disk.
I print directly from OctoPrint via USB into my BiQu B1 SE Plus USB - not using an SD card.
Using eSun PLA+, I get best performance printing the first layer with bed preheated to 60 degrees and subsequent layers with the bed at 55 degrees. This all works perfectly when printing a single object.
When printing multiple objects, the bed temperature adjusts to 55 degrees after the first layer of the first object is printed. I expected it to stay at 60 degrees until ALL first layers are printed.
When creating the multiple objects in Fusion 360, I join them together with a 1x1mm "bar" across the bottom, so that all objects can be treated as one. The objects are all sort of "chained at the ankles". Once imported into Cura, I drop the model down by 1mm to put the bar below the printer bed so the bar won't print. That adjustment does not affect Cura in that Cura still treats the multiple objects as one. You cannot select any of the objects separately and they all share the same Print Settings properties.
I change the Print Settings temperatures for first and subsequent layers in Cura and then slice. I save the resulting GCode file and upload that to OctoPrint.
Once printing starts, the bed is at 60 degrees as instructed. But after the first layer on the first object is printed, the bed adjusts to 55 degrees, meaning the next object to print has it's first layer at the wrong temperature. How can I fix this?
The gcode file has the bed temperature at 60 for the first layer and changes to 55 at the start of the second layer. I resliced the stl file using your placement instructions and the gcode produced has the same bed temperature commands at the same spots. Previewing your gcode in Cura and looking at your gcode with a gcode viewer (other than Cura) shows both "objects" as part of the first layer. I believe the gcode is correct so I can't explain the observed behavior.
The next step would be to enable the serial.log and examine the communications between OctoPrint and the printer.
I would suggest that first you create a smaller test object. Something like two 4x4 squares 1mm tall with your connecting bar. Print this object and see if it exhibits the same behavior. If it fails, we have a much smaller data set to sort through.
Thanks for the reply. Yes, I am setting the temperatures in Cura as you suggest. I don't know of any other way to set initial and subsequent layers bed temperatures other than in Cura. I'm sure it can be hard-coded in the GCODE file, but that is what Cura is supposed to handle for me and I want to avoid setting it manually in GCODE.
As I said in my original post, Cura treats the two objects as one, because they are "chained at the ankles". It doesn't matter that the "chain" is positioned below the bed so that it won't print.
If they are considered one object, why is Cura changing to the subsequent layer temp half-way through that one object?
The thing is, from reading the gcode it shows that the bed temperature is changing after the first layer of both objects has been printed.
The M140 S55 command is in line 1549 in the gcode file. Prusa Slicer claims the first layer has 1494 lines, so adding the start gcode (~35 lines) + the comments in between sections I think it is right.
So it seems that the gcode is correct - but you are seeing a different behaviour to what is in the gcode file?
@KMorley, Both @Charlie_Powell and myself have manually examined the gcode with a text editor and we both agree that the gcode bed temperature change occurs after both objects are printed.
You are saying that the temperature change is occurring after one of the objects is printed and have asked why. Our answer is we don't know and won't know until you provide more information, which would be enabling the serial.log (<<< link with instructions), reproducing the problem, and uploading another SystemInfo bundle.
I also suggested using a smaller test object to reduce the amount of data.
