Switch off sorting Gcode by z-height

Hi there,

I have found a problem, witch is caused by OctoPrint, when it is loading a gcode file. OctoPrint seems to sort all imported levels by the z-height. But somtimes this is not wanted.

For example, when I print an object with a 3 layer raft, to have a better print support, the following layers are printed:

Layer 1 : z = 0,30 (raft 1)
Layer 2 : z = 0,57 (raft 2)
Layer 3 : z = 0,84 (raft 3)
Layer 4 : z = 1,36 (object 1)
Layer 5 : z = 1,24 (object 2)
Layer 6 : z = 1,34 (object 3)
Layer 7 : z = 1,44 (object 4)

Here we can see, that layer 4 is printed at a z-height of 1,36 witch is higher than the next layer 5, with a z-height of 1,24. At first sight, this looks wrong, but when you think about it, that there has to be a gap between the raft and the printing object, the unusual z-height make sense. The gap is needed to be able to smoothly separate the object from the raft. And because the filament-line is “falling” down to the raft the layer 5 has to be printed at a lower height, so that the two layers (4 and 5) can stick together.

But unfortunately OctoPrint tries to correct this and swaps the layers into this order: 1, 2, 3, 5, 6, 4, 7…

I searched in all setting tabs, if I can find a switch to avoid sorting layers, but did not succeed. Is there a way, to switch off sorting?

Or could it be a option for future releases?


/hanks for helping
Martin

Btw: Even with onboard Cura, when I load the .stl file, the layers are sorted.

  • Do you upload an STL to OctoPrint or an already-sliced GCODE file? (It sounds like you slice outside of OctoPrint from the "Btw" comment)
  • If you pre-sliced it, which software/version are you using?
  • It would be nice to know the OctoPrint version (and OctoPi if you imaged using that)
  • It wouldn't hurt to see the output of the Terminal console

Honestly, this sounds like the slicer's doing this rather than OctoPrint but @foosel is the best resource.

I'm using:
Cura 15.04.6
Octoprint 1.3.8
OctoPi 0.14.0

I did both: I sliced it with Cura and loaded the gcode file, and, as I mentioned in the "btw" comment, I uploaded the .stl file to Octoprint and sliced it with the onboard Cura engine. With both methodes the layers where resorted.

As I'm able to read the gcode files, I was looking into the gcode file and there the layers are in the correct order. So it is definetly not a problem of the slicer.

Ahm, sorry, I do not know, what you are mean with "Terminal consol". If you explain it to me, where to get the output, I will send it to you. If you want, I can send you the gcode file (when this uploud button here is working as i expect :wink:

Behaelter.gcode (234.4 KB)

maybee it worked.

My printer's printing some now, so I just did a screencap of the Terminal tab of OctoPrint.

Notice that I selected all three checkboxes to remove some of the "noise". There is a "Copy All" link in the bottom/right. It would be interesting to see the ordering of commands, as sent to the printer.

I'm currently using Cura 3.4 which sounds like it's a lot newer, although this probably isn't the problem.

Are we talking about the purely visual sorting that takes place in the GCODE viewer? If so:

To the best of my knowledge, there's no sorting done on the gcode stream that is sent to the printer. It goes out line by line. The gcode viewer does sort by default and as @foosel pointed out, it can be turned off.

Ok, I apologize, I was wrong. OctoPrint is not mixing up the layers during printing. I made a TestCube.gcode file with a minmum amount of data and printed it. I captured the output of the terminal window and had a closer look at the data. I found out, that during printing, the layers are printed in the correct order.

TestCube.TerminalOutput.log (17.9 KB)

But still, when I'm looking at OctoPrint "Gcode Viewer" and browsing thru the layers, the layers are not displayed in the correct order. So it seems to be only a problem of the gcode viewer.

Oh, thanks foosel, this seems to be the option, I'm searching for. But I was overlooking the small advanced options. Finally I found it and my weekend is saved.

__
/hanks to all
Martin