burtoogle

Done. See https://github.com/Ultimaker/Cura/pull/4144 and https://github.com/Ultimaker/CuraEngine/pull/781

Hi, @amagro, I will post another archive later this morning.

Well, I'll submit some PRs to reinstate the "not over skin" behaviour as "over infill" and the Cura developers can decide what to do.

I am guessing that you have changed to using relative extrusion mode?

Yes, it looks like it is going back to fix something. Anyway, as I mentioned, life gets much easier if the walls are an even number of line widths wide.

Hello @Link, the problem with combing over infill only mode is that it doesn't recognise the existence of skin and walls and so won't avoid them and therefore the nozzle will happily traverse a skin region when moving from one side of a part to another. Personally, I would not mind if the existing "no skin" behaviour was still available as a "infill only" option as I would never use it! As for combing over thin walls leading to ugliness due to extra material being deposited, there is now an option to retract when combing distance is greater than a threshold so that can be used to reduce dribble.

Thanks for the project file. I can see what is happening. The travels across air are due to a combination of settings and a deficiencies in the version of Cura that you have. The "no skin" combing option has always been broken as it doesn't stop combing travel over skin and allows travel over air. Actually, the "no skin combing" option works OK when you understand that it actually combs over infill and nowhere else. So it should have been called the "infill only combing" option and then its behaviour would match its name perfectly! I have a fixed version submitted for a future Cura release that really does comb over non-skin areas (i.e. walls and infill). So when I use that the travels from side to side are being routed over the wall rather than through air which is why you don't see them but the travels are still happening as you can see here: The other problem is that Cura doesn't make a good job of walls that are an odd number of lines wide. Your model has walls approx 1.2mm wide so if I was printing that I would just up the wall line width to 0.6 (which my 0.4 e3d v6 has no problem with) and you get 2 walls with no extra travels. If you want to persist with 3 walls then I recommend that you enable the wall overlap compensation and also there is a setting called Minimum Wall Flow which, when set to something like 10 or 20, will remove a lot of the lines that have been overlap compensated down to a small flow. It still wants to travel rather a lot and with the combing bug mentioned above is pretty unusable with your model.

Please save your project file (.curaproject.3mf) and attach to this thread so I can check your settings.

Here's my attempt. I am using a relative x/y z-seam hint without any corner preference. The z-seam is located on the left hand side of the little bump all the way from the bottom to the top. Hope this helps.

Hi @amagro, I attach the gcode. This was sliced with combing mode "no skin" and "avoid printed parts when travelling" turned off. I haven't printed it but the layer view looks OK. As for the gfortran error above, it looks like you need to install the fortran runtime libraries so do "sudo apt-get install gfortran" and it should download and install what you need. If you get the Linux version working, I will post another archive as I have done some more work on the combing. CFFFP_marcador_1.0.gcode

You can find my Linux archives at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0 Just unpack somewhere and run cura/bin/cura.sh Sorry they are so big, I haven't succeeded in creating an appimage, these are just copies of my installation tree which has lots of files that you don't actually need. Good luck!

Hi @amgro. I can only build Cura for use on Linux, I don't have any Windows computers or Macs here. So I can offer you a Linux archive (just unpack and run the included script). Let me know if you want that. I attach the gcode for your current model. Please note that combing may not give you the best quality results with this model because in the honeycomb region the walls are very narrow and so the nozzle will be right on the edge of the walls in some places. Maybe in the future Cura will comb over thin walls better than it does now. It is still under development (like all of Cura, actually). CFFFP_MM_combo.gcode

Hi @amagro, I know what's happening now and have fixes for when combing is "all" and "no skin". I need to test the changes some more but it's likely that a future version of Cura will have a fix for this. Here's a couple of images showing the "all" and "no skin" results.

Thanks for the project file, I have verified the problem and will try and find out what's going wrong and come up with a fix.

Hi @Noga, it looks like it is a bug in the layer view, I see those weird lines too. When I save the gcode and look in another gcode viewer I cannot see those lines. There is still a possible problem with your end gcode because you have G28 X0 Y0 which in the gcode viewer I used shows the nozzle being returned to the left hand front corner straight through the large printed part! Hope this helps.

Hi @Noga, glad to hear that it is OK again. BTW, that file you attached is not a project file. You need to save project (on file menu).

Hello, it would help greatly if you could attach your project (.curaproject.3mf) file. Thanks.

Hi @amagro, please attach the project file, without that it's not easy to investigate the issue. Thanks.

However, I have found something weird. After slicing it flashes up the save to file button and then changes back to the prepare button immediately so I can't actually save the gcode! I think the development version of cura must be broken right now.

Thanks for the project file. Again, no problem to slice in a couple of seconds. I am using the current development version of cura on linux.

It sliced for me in about 2 seconds. Could you please save the project and attach the curaproject.3mf file?

Hi @meowsqueak, yes, making it time based could be done as you suggest but do people want to think in terms of time or distance when considering this setting? When you look at the layer view you can see all the travels it is doing and think to yourself, hmm, those travels from one side of the piece to the other should be using retraction but those travels in a small area don't need retraction, let's set the value to, say, 10mm to stop the dribble on the long travels. But you're not going to think, hmm, those travels from one side of the piece to the other should be using retraction, let's set the value to, say, 100mS (or whatever). It's much easier for the user to set the limit as a distance rather than as a time (IMHO).

Hello @JCD, the mod isn't a plugin, if accepted by the Cura devs it will be part of the slicer. The mod lets you specify a slowdown for small outlines on the first layer and also for all other layers (could be 100% if you only want a slowdown on the first layer).

Possible solution could be https://github.com/Ultimaker/Cura/pull/3837 ?

Why is that?