error with layer stacking on thick hollow prints

[xboxhacker]

The layering works With thick hollow objects the first bottom layer is fine but all the layers to the top of the inside of the hollow object are also bricked. This is causing a massive elephant type foot.

Slicer: Orcas Slicer 2.1.1
Layer Height: 0.8
extrusionMultiplier: 1.2
Shell walls: 7 (yes, seven)

preview before brickLayering:

preview after brickLayering:

Original gcode:

water_test.txt

New gcode file and output debug:

water_test2.txt
z_shift_log.txt

I could not get the script to work with Orca Slicer, So I am running it from CMD line. I did make a GUI modification to the script and it works fine as a stand-alone, but it has the same results.

THX

[xboxhacker]

Well, maybe never mind? I did some FAFO with the code. I added a way for my modded standalone to start processing at a specified layer height in the gcode. It seems to fix the issue for me!

On the right is the newer version. It now starts the bricking on the first layer AFTER the inside top layer. (or whatever layer you would like.)

Orca preview:

You can see it printed normally until the bricking layer is reached.

GUI:

The GUI gets the layer height from the gcode, so no need to enter it. It automatically populates the layer selection dropdown box. It saves the gcode to a new file rather than overwriting the old one.

Script:

BrickLayersStandalone.txt

[rodrykthingol]

Hi @xboxhacker . I was looking at your g-code, for some reason its squishing the first two layers, basically its printing the second layer at the same height as the first. Thats the reason for the elephants foot.
Could you please create for me a gcode, with the first layer 0.8 , same as layer height. Remove that priming piece of gcode ( just warm the nozzle and bed), then add a skirt, for some reason its detecting that last G1 Z0.28 F240. I wonder if thats causing some issue.

If it looks messy, the usual work around is to activate z-hop, no ramping, print external perimeters first and or change the number of perimeters.

[rodrykthingol]

Also noted something. Reading the log file layer 0 seems fine, except both the outer wall and next inner perimeters are the same height. If you did a external perimeters first, it would probably fix that. I believe the code is probably forcing all exterior walls to be the normal height and the first inner wall is always adjusted in height. So since its doing it in reverse starting with a inner wall, it ends up with last to perimeters being the same height.

On layer 1 thats where the interesting thing happens, it detected a inner wall and adjusted accordingly, so z= 1.4 + 0.4 offset and the log says:
"025-01-24 10:01:21,923 - Inserting G1 Z1.800 for shifted perimeter block #1"

But on the gcode it reads G1 Z1.000. Shifted Z for block #1. Thats what caused the issue. Not sure if it repeats itself, but i think it may be something to do with I/O stuff reading/writing the file. Not sure. Pretty basic programmer here.

[xboxhacker]

@rodrykthingol The G1 Z1.000 is the first layer height if we start with 0.6 first layer height, it is the adjusted_z. Then it resets for G1 Z0.600 ; Reset Z for block #2. This is how it was described to work in the YT vid 0:14.

Layer height: 0.8 mm
Z-shift: 0.4 mm z_shift = layer_height * 0.5
FIrst layer: adjusted_z = current_z + z_shift (1.0 = 0.6 + 0.4)

I think ideally we should be printing the 0.6>1.0.

Although you may be right with starting at a 0.8 rather than the 0.6, but my machine needs the 0.6 for best adhesion.

Any more testing will have to wait till Monday when i get back to work....

[rodrykthingol]

@xboxhacker
Let me check.
Log starts counting at layer 0.
Layer 0 is 0.6 and it offset by 0.4, so you are correct, it does the g1 z1.000 command.
On layer 1 - layer height is 1.4 mm ( so 0.6 mm + 0.8)
and according to the log file it says offset 1.4 by 0.4 = 1.4 + 0.4 = 1.8mm.

The issue i found was while reading the water_test2.gcode file, not the log. On the second layer it seems that the app didn't apply the offsets correctly. It starts applying the offsets of g1 z1.000 where it should be applying offsets of g1 z1.800.

Thats whats causing the elephants foot i believe. Try previewing the gcode file produced and you'll notice that the layers are stacking. Interestingly enough i found a user today that had a similar bug, but in his case the app wasn't able to count the numbers of layers on the part ( according to the log) and it kept on repeating a gcode command to print the first layer on some of the perimeters , but the others were fine.

By the way could you send me the original stl file, let me see if i can slice it.

[xboxhacker]

@rodrykthingol It is in the OP.

Original gcode:

water_test.txt

change the .txt to .gcode