Request CURA 5.x & Avoid Filling Small Gaps

[OPC 2]

Hi,

Is there anyway to avoid filling small gaps in CURA 5 ?

In previous versions I REALLY liked the "Fill gaps between walls" & "Filter out tiny gaps" setting, so I could avoid filling these gaps. 

 

I have a decade old ultimaker II ext Mark II w Octoprint (which I have a love hate relationship with), but it prints way better when I can avoid the unnecessary blobs of extrusion, travel moves, and print in continuous loops.

Here are a few examples: I've recently been using large nozzles (.8/1.0/1.5) so I can get through a large part quicker.

 

As a work around I've been creating modifier meshes, that change the print parameters (to 1 wall, no infill, no top/bottom), but it's really a pain in the neck and not always feasible.

 

It would really be great if we could re-introduce "Filter out tiny gaps" back into Cura 5.

or any advice as a work around would be greatly appreciated.

[giostark 1]

+1

Same here... I'll switch back to the previous version 4.13.1 . (that work properly for this issue)

 

Edited August 19, 2022 by giostark

[giostark 1]

edit: double.

Edited August 19, 2022 by giostark

[Rustaxis 0]

Bump. I would also like to know how to prevent this.

[MariMakes 208]

Hey @Rustaxis,

 

There are settings that you can change to improve this behavior.

You can read more about them here: 

https://support.ultimaker.com/hc/en-us/articles/4792077687068

[Jhawk6553 8]

On 12/13/2022 at 9:32 AM, MariMakes said:

Hey @Rustaxis,

 

There are settings that you can change to improve this behavior.

You can read more about them here: 

https://support.ultimaker.com/hc/en-us/articles/4792077687068

@MariMakes Im unsure at which setting to adjust to achieve the same outcome that the old setting "fill gaps between walls." It looks like a combination of all of these while simultaneously none of them. Say I have a "line" that's 0.25mm long and 0.4mm in diameter. It is essentially a tiny dot that would otherwise get ignored with the old setting. How would you adjust these new settings to ignore that size of "gap or line" without giving the printer thumbs up to go all wild with the line widths for all of the inner/outer walls? The flow rate sounds like it could vary like crazy and potentially give someone extrusion issues. I do love the new settings and their potential. I'm just not convinced that they are a solid substitute for the old way of ignoring gaps.

 

 

Edited February 18, 2023 by Jhawk6553
Tagging peeps

[MariMakes 208]

Hey @Jhawk6553,

 

You are right that it really depends on your situation. 🤔

In my experience, the Wall Transitioning Threshold Angle leaves most gaps as a gap.
But that's super specific per design. 

Do you have a project file for us? It contains the printer and settings we need for troubleshooting. 

To save a project file go to File -> Save project.

 

[Jhawk6553 8]

@MariMakes Thank you for the reply! I actually have it sort of explained in this post. Im printing a lithophane and I noticed that the white sections had these weird artifacts that you can see in the picture below. I then looked at the layer view and saw that the printing order is out of wack, even though I had it set to "inside to outside." It was trying to print a thinner inner wall between two outer walls after it had already printed the outer walls. It was only happening on the thin sections where it had to reduce the line width to get a 3rd wall in place. Areas where the inner wall didnt have decreased line width printed in the proper order, inside to outside. I think the heat or drag of the nozzle between the two outer walls was causing these weird artifacts. I havent tried to mess with the "odd" wall line width though. Would be nice if you could just set the tolerance of the variable line widths to say +0.1mm and -0mm instead of its current +-0.1mm. Unfortunately changing the Wall transitioning threshold angle didnt work. I did "fix" it by increasing the outer wall line width to 0.45mm and decreasing the  "Wall Transitioning Filter Margin" to 0.1mm from 0.2mm, increasing the "minimum wall line width" from 0.25mm to 0.3mm and disabling print thin walls. However, the flows was no longer a uniform color after slicing it and looking at the flow color scheme.

.

 

Edited February 21, 2023 by Jhawk6553

[MariMakes 208]

Hey @Jhawk6553,

Ahh... I think I understand.
I have not tested this, but if you are just printing a thin Lithophane in this printjob.... 

It might be worth it to just change the following settings:
- Infill 0
- Wall Line Count 2
- Top Bottom Thickness 0
 

That you might have the hollow printjob you are looking for. 

[Jhawk6553 8]

@MariMakes I do set my infill to 0 and my top/bot to 0 as well. But ive never tried to print a lithophane with only 2 walls. Im not entirely sure how well thatll work because the color depth is created by the light being absorbed by the varying thickness of plastic. Although in the case I listed above, it still wouldnt make too much of a difference because the thin wall was printed between the 2 outer walls so it would still fall in that 2 wall line count.

 

I do think these varying line widths are crazy for engineering prototypes. Look at the picture below. I designed a calibration print originally for lithophanes to test how well the printer can capture different horizontal depths in the image. Each shade is 0.1mm thicker than the previous. Notice on Cura 4.x the shades are grouped in 4's. With some adjustments of the new Cura 5+ settings I was able to get the complete contour and all of the shades measured exactly +0.1mm from the previous. However, the new settings did not work well for an actual picture lithophane as well as they did for this calibration print. I think it worked well in the picture below because the transitions are very gradual from one step to another. In a picture lithophane, the corner transitions from lights to darks are much more harsh and erratic. And because the new settings are letting the flow be adjusted to vary the line width, I think the printer cant keep up with the corner transitions in a lithophane. A high jerk value could be used but mine is set to 20 and still had issues.

Edited February 22, 2023 by Jhawk6553

[PCLoadPLA 1]

Has this issue been fixed? I just switched to Cura 5.6 and immediately realized this "Filter out tiny gaps" option was removed. This option is an absolute necessity to reduce blobbing when printing with large nozzles. Is there any plugin or other way to re-enable this feature?

[Slashee_the_Cow 620]

1 hour ago, PCLoadPLA said:

Has this issue been fixed? I just switched to Cura 5.6 and immediately realized this "Filter out tiny gaps" option was removed. This option is an absolute necessity to reduce blobbing when printing with large nozzles. Is there any plugin or other way to re-enable this feature?

If you can give me an example file (preferably a Cura project so it's set up for your machine) I'm happy to trawl through settings for a bit seeing if I find anything.

[Jhoanor 0]

I don't know if it is still wanted, but I have written a python script to remove all lines shorter than a certain value from a gcode file.
Just edit the first three lines of the code and run it on the command line with > python gcode.py.
Of course you have to install python first.
And Z Hop should be activated, because the script calculates the total length of printed lines between two Hops.
Only G0 and G1 lines are removed. All other lines are preserved in the original order.

gcode.zip

Edited April 11 by Jhoanor

[Slashee_the_Cow 620]

@Jhoanor While your contribution is appreciated it would be much better if you created a Cura post-processing script as that can easily be installed and run by any Cura user without any requirements like having Python installed, as well as being integrated into the workflow and not requiring the extra steps of editing and running the Python script afterwards.

 

Now, as the forum's resident Python snob 🐍🧐 there are some improvements that could be made (and while this might seem like a long list of criticisms, I aim to educate about how to follow best practices, not criticise... I just suck at wording them in ways that don't seem like flat-out criticisms):

• It would be very, very easy to unpack and parse an *args or **kwargs and avoid having to edit the Python file to change the input or output filenames, or distance.
  • You could also do it with a little more verbosity but prettier with argparse.
• It could potentially be more efficient to precompile your regex searches and store them in memory than to run raw versions so many times.
  • You can achieve largely the same thing by using str.split() and checking the first character of each item in the results of that without the hassle of the regex, but then you definitely have to be careful when casting the results to a numerical type.
• Your regex doesn't entirely filter out invalid values (for example "X." will capture ".") and as you can't trust an input file it's important to use defensive programming and put your casts inside a try...except block ready to catch a ValueError.
  • Cura should never output a floating part without prepending it with a 0 but this isn't true of all slicers and your script isn't Cura specific.
• Your if check at the start of distance() could be a bit cleaner. Comparison operators (like is) have higher precedence than logical combinators (like or)

  if p1[0] is None or p1[1] is None or p2[0] is None or p2[1] is None:

  That's still a bit of a mouthful. Let's just use a membership test:

  if None in (p1[0], p1[1], p2[0], p2[1]):

  That just creates a tuple in place (any iterable will do, but a tuple is quickest to work with) and checks if any of its members are None.

  • Again, Cura should never perform a move with an X but not a Y (or vice versa) but other slicers might.

  • Returning 0 is a bad idea if the result is being used in a "less than" comparison. If all moves in a segment end up missing one coordinate (and "all moves" could be one or two) then it will pass the comparison and delete would could potentially be long moves on a single axis.

• When declaring variables (as you are at the start of your filter_gcode() method) and initialising them as None it's important to test if they're None before you use them in anything but the left side in an assignment.

• Reading the whole file in advance at putting it in a list can be a very slow operation, especially with a larger gcode file. You only ever perform a lookahead once (and then it's only by one line).

• You're making it rely on Cura's behaviour again when using G0 to check for travel moves and G1 for extrusion moves. Not all slicers are guaranteed to follow that convention.

• Line 65:

  elif line.startswith('G1') and (segment != []):

  Once again, the brackets are unnecessary, but more importantly, you're checking to see only if segment isn't a list which is empty. This doesn't include possible errors like segment being None. The Pythonic way to do it is to take advantage of the fact that many of the things you'd be checking for (like an empty list or None) are considered falsy so you can perform a simple boolean check:

  elif line.startswith('G1') and segment:

• Lines 90-93:

  	if not remove_segment:
  		output_lines.extend(segment)
  	else:
  		output_lines.extend(subsegment)

  Using if not condition_a...else is a sadly popular antipattern which makes the code harder to read because it relies on the reader having to flip things around in their head. It's much better to have:

  	if remove_segment:
  		output_lines.extend(subsegment)
  	else:
  		output_lines.extend(segment)

• You're using tabs instead of spaces 😠

[Jhoanor 0]

@Slashee_the_Cow No worries, I'm used to criticisms. 😉
- I have made a new version of the script and I have tried to incorporate all your advice, which I value.
Except for the: "You're making it rely on Cura's behaviour again when using G0 to check for travel moves and G1 for extrusion moves. Not all slicers are guaranteed to follow that convention." It would be a disproportionate amount of work for me to make it multicompatible, and I don't use other slicers and I don't want to try and study them. Sorry.
- I was in need for this script, and I made it quick and dirty so to speak, just to use it. When a new Cura version was launched I wanted to know if this function was present now, so I landed on this thread.
- I understand a Cura post-processing script would be preferable. However, when I see how that works with classes and a whole different setup which is completely new to me, I have to conclude that that is at the moment too much for me. I regrettably don't have time to submerge myself at that level in this kind of scripting.
- However, feel free to adapt my script for that purpose if that is something easily done. I do not claim any copyrights!😋

 

gcode-v1.1s.zip

Edited April 13 by Jhoanor

[Slashee_the_Cow 620]

3 hours ago, Jhoanor said:

- I understand a Cura post-processing script would be preferable. However, when I see how that works with classes and a whole different setup which is completely new to me, I have to conclude that that is at the moment too much for me. I regrettably don't have time to submerge myself at that level in this kind of scripting.

It's not as complex as it might look at first - but it's always a refreshing change to see "I'm worried I might be biting off more than I can chew" instead of "I'm a divine gift to the programming world" whose gift ends up being a mess of code which gives you a migraine.

 

3 hours ago, Jhoanor said:

- However, feel free to adapt my script for that purpose if that is something easily done. I do not claim any copyrights!😋

Challenge offer accepted! If only so I can make your life easier so you can run this in Cura instead of doing it manually yourself 😉

[Slashee_the_Cow 620]

@Jhoanor Try this. I don't have any easy test cases set up so I can only confirm "it works" insofar as "it runs without error". I did try to copy your logic as well as possible... except where I thought I could improve it 😄 - but that's mostly just keeping track of the extruder position and setting it after extrusions have been removed so the first move after doesn't overextrude.

ShortLineRemover.zip

[Jhoanor 0]

Thank you! 🙂 
However, there is something not right. The script does not delete anything.
Even if I change line 119 in remove_segment = True, every line stays in place. With my script the file would at least be halved in size.
If I write str(layer_index) to a file, I get only a single zero. Looks like only layer 0 is processed.

Edited April 14 by Jhoanor

[Slashee_the_Cow 620]

@Jhoanor 🤦‍♀️ Can you post a Cura project file that has this problem so I can actually test it for myself?

[Jhoanor 0]

@Slashee_the_Cow
beam-clean.gcode: the sliced model without post-processing.
beam-PythonScript.gcode: post-processed with my original script.
beam-CuraPlugin.gcode: post-processed with the Cura plugin.
(beam.3mf is included)
The Cura plugin does something, because there are differences, but it is just as big and when viewed, all infill lines are still there.
For clarity I used a length of 5.0 mm.

beam_model.zip

[Slashee_the_Cow 620]

Finally beat the [five minutes of high quality Australian swearing] thing. At least for the test case you provided, it replicates the results from yours exactly. In theory it's replicating the logic from yours exactly, except that your version is blind to layer changes (since it's iterating through the whole file) whereas mine will end segments at the end of layers (which usually have a G0 that would end it anyway).

 

You mind if I add it to my collection of post-processors? 

ShortLineRemover.zip

[Jhoanor 0]

Of course I don't mind! I'd be honoured! 😋
I see with larger files minor differences. The sequence of lines, start and endpoint is sometimes altered by Cura dependent on the plugin being active or not and the Extrusion numbers become slightly different of course. I suspect calculations by Cura are better than the mindless deletions my script did, so it must be an improvement!
Thank you!

I would only add a description in the plugin under the length field that Z-hop should be active for it to work.