mattw

Yes, this is old, but we found another solution to remove the blobs. Just posting answers for future folks that reach this via a search. When we disabled power loss recovery, the blobs went away. Our printer had poor power loss implementation and would write the position to the sdcard repeatedly. The system couldn't keep up. To disable, put "G413 S0" in your preprocess g code.

Did this ever get merged into mainline Cura? This would be a useful feature, but I haven't seen any updates in a few years.

Yes, this is old, but it still comes up in related google searches, so here is how I fixed it. It is indeed a data transfer problem, but for me it was internal to Marlin. The default Planner Buffer size in the Ender firmware is only 4 lines of G Code! This results in a lot of calls to the disk for little chunks of G Code. When I adjusted the Planner Buffer to 16 or 32, the problem totally went away. So yes, reducing your speed and resolution are potential fixes, but they have obvious drawbacks. Removing the restriction of an overly conservative planner buffer allows you to print faster and finer without blobs ( assuming your control board processor and memory is strong enough to handle the larger planner buffer.)

This actually started with a post on this forum, where it was recommended I ask on github. If the original post would be of interest:

Yes, Issue 11047. Thank you for the info, I will only attach the project from now on. Perhaps, Spiralize might be inconsequential? The offending travel moves are in the "base" part of the model where it is still printing/slicing in normal mode.

When posting a "travel blocker" feature request on the Cura github, a mod deferred the request (understandable), but also suggested a workaround using a second STL and setting wall thickness, top/bottom thickness and infill % all to zero. They even posted a screen shot of it (apparently) working. I can not for the life of me get it to work. The Cura github is not the proper place to troubleshoot a workaround so I am bringing it to the forum. Attached is a project file set up with a secondary "travel blocker.stl" as the mod suggested. Just to give context of some of the slicer settings in the project. We make lot of little custom vase type prints using spiralize mode. We keep the raft and a 100% infill support as a built in stand. The file will be sliced as normal for the first 3mm of Z axis and then switch to spiralize mode as it travels further up (this is as expected). In Preview, you can see the offending travel lines still going through the "travel blocker.stl" file in the support region (first 3mm of Z axis on the print). These travel lines inside the vase a terrible for internal surface quality. We would much rather have them outside the vase. No combination of combing settings nor this "travel blocker workaround" has been effective. Any ideas on what the mod was talking about? Has anyone had success with a workaround like this before? Thanks. P.S. - I'm never sure if "Save Project" or "Export" is the best way to share the model and slicer settings, so both are attached. P.P.S. - yes, this project is set for an Ender. Our shop has many Ultimakers, several Creality machines, some Taz's, a Raise3D, a Flsun delta, and a partridge in a pear tree. This was just the profile I had up at the time. This is a Cura travel related question and pertains to any printer hardware. CE3_SpiralizeSupportTester-SAVEPROJECT.3mf CE3_SpiralizeSupportTester-EXPORT.3mf

Thank you for the suggestion, I will try posting on Github.

What: We would like to load one or more secondary STLs and set them as a "Travel Blocker". Travel moves would have to go around the Travel Blocker region. If the end of a print move finds itself within the Travel Blocker for some reason, it would take the shortest distance out of the travel blocker region and then plan it's travel move. If the start of the next print move is for some reason inside the travel blocker, the travel planner would locate an entry point on the perimeter of the travel blocker that is the shortest path the start of the print move. Why: Combing is very useful, but we still have models where travel moves cross regions we prefer to avoid. How: We are willing to pay for a developer to implement this as a 3rd party add on IF they a contributor to Cura and can eventually roll it in to regular Cura releases. Fallback: If this is too difficult to implement, an acceptable fallback solution would be to optionally set the slicer to serial rather than parallel and set the XY start point of the subsequent layer to match the XY end point of the previous layer. We have noticed that most of the offending travel moves are interlayer to the new start point (regardless of Z Seam Alignment setting). We are aware and understand the reason the new layer XY start can not match the prior layer XY end is due to the nature of parallel slicing. Having the option to sacrifice slicing time for improved print quality would be desirable in some cases.

Please see the attached project file. Look around layer 10 to see the issue. The only parameter you need to change is checking/unchecking "Mold" Slicing with Mold CHECKED creates the desired fully dense support with no Z distance between the support and part/raft. Slicing with Mold UNCHECKED reverts to a sparse support with a visible Z distance between support and part/raft. Thank you. Mold Mode not respecting Support Parameters.3mf

I appreciate the offer, but I don't think we are in a position to pay for this at the moment. The cost/benefit is not there for a "nice to have" feature. We will continue to tape a label on and deal with the occasional label that falls off during post processing. Maybe one day something like this will make it into the base package. Thanks for the response!

Our workflow prints a high volume of small parts. We would like to engrave/emboss the file name (which is a "job number" in our workflow) onto an exposed portion of the raft during the print. This would allow us to track the part/job through the rest of our post-print workflow. Having it on the raft would not interfere with the part geometry. This can not be done "In CAD" as a single model is printed in many different jobs. Does Cura have some mechanism to print the job # or file name that we are missing? Again, looking for a method that does not interfere with part geometry, but is physically attached on a break-away raft. If not, that would be a nice, business focused request. Thanks.

When using the "Mold" special mode, modifications to Support parameters are not respected in the slice. The slice preview still shows a Support being generated at the bottom of the print, but it reverts from a modified dense zig zag to a very sparse grid when "Mold" special mode is enabled. I might assume the "Mold" special mode has hard coded support parameters? Is this intended? More info: "Spiralize Outer Contour" is required for our workflow We modify the Support parameters to remove the gap between support and print We modify the Support parameters to make it solid at the base (lowest inch of the print) by setting the distance between zig zag supports to zero These modified Support parameters and Spiralize Outer Contour work well together when Mold is not enabled We then enable the "Mold" special mode to translate the printed spiralized single wall to just outside the part "Minimal mold width" is set to the line thickness plus 20% to keep it a single wall count "Mold roof height" is set to 0, this opens the top of the mold and allows us to pour in media "Mold Angle" is set to 90 degrees to trace the contour of the part Problem: the modified solid support structure then reverts to a sparse grid