GregValiant

I don't see any downside to scaling the part up if it gives you a dimensionally acceptable print. I'll assume that's what you want to end up with. Some random thoughts... Cooling of a spiralized model is a lot quicker since there is really no mass around to provide any thermal inertia. There is always some shrinkage and certain materials are worse than others. Could your material have soaked up some moisture? is the shrinkage all in the XY or is the part getting shorter as well? Is the print staying on the bed? If it is well adhered then that portion can't shrink in the XY as the sticking is keeping it where it was extruded. You could compare a dimension taken near the bottom to a dimension taken up higher. When designing molds the ballpark shrinkage number we used was 8% so your 9% is right about there for what would normally be expected. Many production molds are water cooled so they suffer from the "quick cool" thing as well.

It is unlikely that the Cura gcode is causing this or everyone using Cura would be having the same problem. It's possible that AnyCubic (or a Cura contributor) has altered the Kobra Max definition file, but what you are getting still should not happen. You can open a gcode file in a text editor and search for {space}Z. The numbers should climb upwards. If Z-hops were enabled then there will be hops coupled with downs and the Z will drop back to the working height. At every layer change you will get an upward movement of the Z.

I have the design specifications right here and there are absolutely no criteria that said the steps had to be TALL.

This model is a wedge 1.6mm wide at the base and tapers to a point at 75mm tall. The model on the left was sliced in 5.6.0 and 4.13.1 is on the right. "Print thin walls" was enabled for both slices. Notice that on the 5.6 slice there are two "transitions" that will show up on the print, and the slice is 352 layers. The 4.13.1 slice has no transitions and the slice is 369 layers.

There are rules: You can put your new file into the AppData folder in "...Roaming\cura\5.6\scripts" but it must have a different filename or the file stored in the Cura installation folder ("UltiMaker Cura 5.6.0\share\cura\plugins\PostProcessingPlugin\scripts") will take precedence and your new file won't load. You can put your script into either folder. If it's in the installation folder then it might get lost when you update Cura. The line: "name": "Filament Change" can be whatever you want to show up in the Post Processor dialog. The line: "key": "FilamentChange" must match the filename of the post processor. So if you change the filename, this line must change to match it. You can enter your own text into any "description": line. So "description": "Uncheck to temporarily disable this feature." could become "description": "Deaktivieren Sie diese Option, um diese Funktion vorübergehend zu deaktivieren" provided that Google got the translation correct. Watch your quotation marks and any parentheses. If there are mismatches the script won't load. The Cura log may show that there was an error ("Unknown post processing script...", but it won't tell you what line it's on if the error is in the settings section of the script. "It is unbearable that several scripts offer similar functions" I've been on a mission to straighten that out. Eventually the new versions should make it into Cura. It won't be tomorrow. If you want to hide some of the post-processors so they don't load then create a new folder in the installation directory under "scripts" (like "Originals") and cut out the scripts you don't use out of the "scripts" folder and paste them into the "Originals" folder. They will be hidden. One more thing - the post-processor list is sorted by "File name" (the "key") not by the post processor name ("name").

You want pretzels with your beer too?

Geometries like that were what the Arachne engine is designed to fix. For an example, if a wall was designed at (3 * Line Width) thick then it presented a problem. You could get an outer wall on both sides, but the inner walls (which also have to be on both sides) don't fit. So you get outer walls with a 1 X Line Width gap between them. That was the reason for "Fill gaps between outer walls". Now Cura will adjust it's line width and allow a situation where there can be an odd number of walls across the part. This is in 5.6 @ 0.4 line width and Wall Count = 2. The model on the left is 1.6mm wide so 2 walls fit on the left and 2 walls fit on the right. The model on the right is 1.2mm wide. Can't get two on the left and two on the right. The Arachne effect is to add a single inner wall to fill the gap. This is in 4.13.1 with the same setup with "Fill gaps between outer walls" turned off. The center model shows the gap because a left inner wall and a right inner wall won't fit. Going across the model, there must be an even number of walls. The model on the far right has "Fill gaps between walls" turned on. Note that the gap is filled with yellow which is skin and not "inner-wall".

One has been repaired (MS 3D BUilder). It did not have a hollow base...it just looked hollow.

Yeah, a project file is necessary. All those "Outer Walls" that are showing on the bottom of the tall model aren't right. Make sure "Remove all Holes" and "Make Overhangs Printable" are turned off.

This is the original project I downloaded as sliced by 4.13.1. No gap. The gap is there because a second wall won't fit (a single "mid-wall" can't be done). This seems to have been the primary reason for the development of variable line width.

In the "Preferences/Configure Cura" "General" tab - under "Viewport Behavior" is "Automatically drop models to the build plate".

The 4.13.1 setting "Fill Gaps Between Walls" became obsolete with the variable line width feature of 5.X. If you set it to "Everywhere" in 4.13.1 you should get the fill. It will be yellow as it is "skin" rather than "infill".

@HienoKaveri Either bow would work. I figured since I'd just be looking at one side (till it got thrown away) I went with "Starboard" so they all collected out of site. Thinking about it...Port and Starboard are a little confusing on that as they depend on which cabin you happen to be standing in. I wonder how they figure it out on double-ended locomotives? I see @Slashee_the_Cow has the Zseam of her ballet dancing "en-pointe" version (I had to look that one up) set to "Keel" which in my (never humble) opinion shows imagination but a possible lack of respect for a very serious model. Here is another test - my infamous "1/2 Mobius". (It's a double sided, double edged, double loop, head scratcher of a model.) Half Mobius.stl

Not just that. There is a flaw in the model that is causing Cura to ignore the lower layers. This is from formware.co/onlinestlrepair -> Analysed your file: --> 236 Naked edges (?) --> 2 Planar holes (?) --> 0 Non-planar holes (?) --> 116 Non-manifold edges (?) --> 172 Inverted faces (?) --> 0 Degenerate faces (?) --> 2 Duplicate faces (?) --> 0 Disjoint shells (?) That's a fair number of errors in a small non-organically shaped model. It's the "duplicate" and "inverted" faces that are causing the problem. The non-manifold edges aren't helping.

Your model is on the left and the polka-dot surfaces indicate errors. The model on the right was repaired (MS 3D Builder). The model with the errors doesn't start to print until the tenth layer. This view shows that the floors of the pockets aren't flat and level.

The bottom of the model either isn't flat (likely give what I see there) or the model isn't lying flat on the Cura build surface. See if using the "Lay Flat" command under the Rotation Tool helps settle this down. An alternative would be to drop the model into the build plate by 0.1 or something. You can see in the black oblong that there is a definite edge going across the print. It appears that the only things toucing the build plate are the area above my black oblong, and the little area that the black arrow is pointing to. The corner that the red arrow is pointing to is so high off the build plate that it requires support. If it isn't truly flat then you might have to make it so in an app that can alter a model file. Depending on how far off the model is - sometimes things like this can be fixed by increasing the Initial Layer Height.

If you want to get printing then use the closest definition to your printer. The definition files start with the standard "fdmprinter.def.json" then go through "creality_base.def.json" and finally to the specific printer. 99% of the settings are available in Cura, the definition files just give some defaults. In the "Machine Settings" under "Manage Printers" you'll find pretty much all you need to get going. The StartUp G-Code might need to be tweaked if you have ABL and the definition file you use doesn't have the G29/M420 commands in it. That's easy to get help for. @Slashee_the_Cow has a newer machine and would know something about that.

It looks like the pull request to add them was merged on November 1st and so they should have been in 5.6.0. Maybe @MariMakes knows about this.

Was there an announcement about the Halloween winner???

I never liked it much either. That's why I've written the post processor that nobody else would. Use Cura's "Help | Show Configuration Folder" command and locate the "scripts" sub-folder. Unzip the attached file and copy "AddCoolingProfile.py" to that "scripts" folder. The post processor "Advanced Cooling Fan Control" fill be available under "Extensions/PostProcessing/Modify Gcode" and then "Add a script". "By Layer" allows you to determine the fan speeds at any point in the file, or to turn it off. By Layer works well with smaller models. You can change speeds 8 times and if you need more than that you can add another instance of the post (but without "Remove existing M106 lines" checked). "By Feature" allows you to configure the fan to run at different speeds for walls, skins, whatever. Because it takes a few seconds for the fan to react to speed changes, By Feature is better suited to large models. AddCoolingProfile.zip

I use Notepad++. You can open them in regular Windows Notepad as well. You have the "Regular Fan Speed" at 0. Cura is adjusting the fan speed per the setting "Regular/Maximum fan speed threshold" which you have at 10 seconds. When the layer time falls below 10 seconds the fan speed approaches 100%. When the layer time climbs above 10 seconds the fan speed goes to "Regular" which is zero. So what you are getting is expected behavior given your settings. Set that regular speed to what you want it to run at and the fan will stay on regardless of the layer time. You could also set the threshold to 0 in which case the fan will run at that regular speed starting at layer 36 and continuing to the end.

The fan speeds in those gcodes are bouncing all over as the print approaches the top. I've never seen that before. Cura has added an M107 line at layer 94 so yes, the fan is being shut off before the top. With the model loaded and Cura set up to slice, use the "File | Save Project" command and post the 3mf file here. This might be a setting issue. Your "Regular fan speed" is set to zero.

The picture didn't show up. You can't re-order a layer but changing the Z-seam location and/or the Layer Start positions (in "Travel") may allow you to fool Cura into printing the portion you want first. You could also slice with "Relative Extrusion" turned on and then cut and paste sections in the gcode to get the order you want. That's "Advanced Gcode Editing" and I wouldn't advise it unless it's practiced.

Understand that this will clear all files from the SD card so make copies if you don't want them erased. Stick it in the computer, right click on the drive letter in Explorer, select "Format". A "quick" format is sufficient.

That second comment about only printing a partial gcode might be because of bad sectors in the SD card. You could try reformatting it. I have had to do that every few months. You first comment about "extrusion stops" might also be related. I found the hardware to be pretty nice and my printer works well. I just couldn't print anything more than 3 or 4 layers tall as the prints would collapse from their own weight.