benspawn

Thank you both for the feedback. @GregValiant it was a design intent. I did set the slicing resolution to the smallest value possible and expected the sliced model to approximate as close as possible visually when printing with at 0.12 with a 0.4 nozzle but wasn't expecting the resolution error to contribute that much of an error. Although I'd imagine with the subtle feature removed, with horizontal hole expansion set to non-zero, the issue would still persist because at the change of the affected layer height, Cura no longer interprets it to be a hole and there would be a shift in the opening size. But thank you for the detailed analysis and time. I really appreciate the feedback. I'll be sure to keep all of this in mind for future designs/slicing.

Thank you for the response. Here are the enclosed screenshots and the project file as requested. PartB.3mf

Hello Cura Community. I hope someone can provide some insight to the following issue. I have the STL file here and both gcodes. With the object laying up and the object laying flat. Somehow, with the object laying up, Cura introduced a layer shift that is not present in the STL file. Also when sliced with the object laying flat, there is no such discrepancy. I have checked and tried various options but nothing seem to remove this issue. I would think that at iteration 4.8.0 (Cura with its constant development of features and upgrades), would not introduce unwanted features/or rather features that are not designed onto the sliced model. 😞 The inconsistency/layer jump/additional feature is introduced at layer 125 in the gcode file of the object sliced laying up. Also, the preferable print method is of course with the object laying up as no supports are necessary in this mode. Thank you. PartB_up.gcode PartB_flat.gcode PartB.STL

Not sure if have this figured out yet but I do something similar except for different extrusion widths when I was running Marlin. Just changed over to Klipper now and figuring out how I can do the same so still looking into an elegant solution but for the moment I use post-processing in Cura to set my K values Basically in my start gcode in Cura I have: M140 S{material_bed_temperature_layer_0} ; Start heating the bed to initial layer temp G4 S30 ; wait 30 secs M104 S{material_print_temperature_layer_0} ; start heating the hot end to initial layer temp M190 S{material_bed_temperature_layer_0} ; wait for bed M109 S{material_print_temperature_layer_0} ; wait for hotend In Search and Replace with the checkbox for expressions ticked I do the following Search: M190 S85.1\t; wait for bed\nM109 S225\t; wait for hotend Replace: ;POST-PROCESSED DETAIL PETG 0.2_0.42\nM190 S85.1\t; wait for bed\nM109 S225\t; wait for hotend\nM92 E414.63\t; set new extruder setting for PETG\nM301 P14.19 I0.81 D62.17\t; set PID hotend 230C/50% fan\nM304 P114.31 I19.93 D437.00\t; set PID bed 85C\nM900 T0 K1.635 L1.72\t; Linear advance for DETAIL PETG 0.2_0.42 And then in my specific Cura profiles, I just make sure to set the initial bed temperature to 85.1 (or whatever else triggers you use) so that it will trigger the search and replace code that I want. I also use this to set my extruder E steps, as well as PID settings. Because I have my PID values, and E-steps tuned for whatever setting that I'm using (PLA or PETG etc). So in the end I have about 15 different Search and Replace code to handle the various settings that I have. All hinging on this initial bed temp value. I even use this Search and Replace method to set different K (and L) values when I'm doing a different initial layer height for example. Bear in mind this was all for Marlin, so you'll have to modify the code to your needs.