Ultimaker / Cura

3D printer / slicing GUI built on top of the Uranium framework
GNU Lesser General Public License v3.0
6.17k stars 2.07k forks source link

PVA raft + PVA supports results in the model being printed with an airgap of 1 layer instead of directly on PVA #6488

Closed SanderM2 closed 1 year ago

SanderM2 commented 5 years ago

example.3mf.zip example.3mf.zip

Cura 4.3.0

Mac OS X

Ultimaker 3 Extended

Please check the included 3MF file

When printing this, the first layer of PLA is underextruding on top of the PVA raft. Very noticeable while printing. That's why I started looking at the preview and noticed the problem.

It should print the first PLA layer on top of the PVA raft at layer 5 already instead of layer 6.

When you look at the 3MF project. Look at layer 4, 5 and 6. At layer 4 it's printing the last PVA raft layer, just a flat layer, nothing special. At layer 5 it's printing PVA supports for one model At layer 6 it starts printing PLA while this should already happen at layer 5. It's now printing PLA one layer too high, above the PVA raft, in the air.

SanderM2 commented 5 years ago

Just to clarify the problem:

I added two models in the 3MF file. One that needs supports and one that prints without it.

With both models in the project Cura starts printing PLA at layer 6 while it should start at layer 5. If you remove the model with supports it starts printing the other model (without supports) at layer 5 (as it should).

So it looks like the bug is related to the supports in combination with a raft. Disabling the raft (printing directly on the buildplate) or not using any supports works without issues. The problem is, I need both options for one specific model to print so I hope there is a workaround for this now? Or a quick fix?

smartavionics commented 5 years ago

I think that is a bug. As a workaround, I found that setting the initial layer z overlap to 0.1 makes the models both start on layer 5. The support starts on layer 6.

Screenshot_2019-10-06_08-55-40

SanderM2 commented 5 years ago

As a workaround I removed the raft and moved the model 0.4mm above the build plate. This way cura is generating support for the whole model and I don't need the raft.

Yet, it's still a bug that needs attention in my opinion.

SanderM2 commented 5 years ago

I think that is a bug. As a workaround, I found that setting the initial layer z overlap to 0.1 makes the models both start on layer 5. The support starts on layer 6.

While this does indeed make the models print at the correct layer, it's printing the supports one layer too late possibly causing issues with the supports.

smartavionics commented 5 years ago

While this does indeed make the models print at the correct layer, it's printing the supports one layer too late possibly causing issues with the supports.

That's true but it's the best workaround I can offer, sorry.

Ghostkeeper commented 5 years ago

I think it's an issue with visualisation. If you look closely at layer view, the model seems to be printed directly onto the raft without any air gap. Saving the g-code and viewing it in a different viewer (Repetier-Host) also shows the model printed directly on top of the raft. You can also see there that the order in which the layers are printed is also correct from bottom to top.

The problem with the layer numbers is probably because we didn't make an exception for having 0 Raft Air Gap when support is enabled. When support is enabled, we still make support through the air gap. Because of the edge case this support ends up on its own layer instead of merging with the first object layer. I don't think that's really enough of a problem to spend time on.

Unless you can show that there is actually an air gap going on in the print?

smartavionics commented 5 years ago

Yes, @Ghostkeeper's right. I just checked the gcode file that is produced and the raft stops at z = 0.7 and the support and the first layers of both models start at z = 0.8. So it should print OK, sorry I didn't check the gcode earlier. It does look like a problem with the layer view in Cura. If it's not actually printing OK then there is some other reason.

github-actions[bot] commented 1 year ago

Hi 👋, We are cleaning our list of issues to improve our focus. This bug seems to be older than a year, which is at least three major Cura releases ago. It also received the label Deferred indicating that we did not have time to work on it back then and haven't found time to work on it since.

If this is still a problem for you in the current version of Cura, can you please leave a comment? We will have a fresh set of eyes to look at it.

If it is not a problem anymore, you don't have to do anything, and this issue will be automatically closed in 14 days.

github-actions[bot] commented 1 year ago

This issue was closed because it has been inactive for 14 days since being marked as stale. If you encounter this issue and still experience this to be a problem, you are welcome to make a fresh new issue with an updated description and screenshots.