Cura fails to slice properly when loading more than one part?

[HugoW 1]

Hi,

 

I've just bought a printable plane from 3DLabPrint and something funny happens. When I load part F3 (part of the fuselage) and slice it, Cura tells me it takes about 2.5 hours. When I load F8, it takes about 2 hours. When I load both, it also takes 2.5 hours for the whole print and all ribs and such inside the part are not converted to G-code! I used a G-code viewer to check. I don't change any settings when loading one or both parts. It also happens on other parts. Load one all is OK, load two or more and the inside of the parts is 'forgotten'. Any ideas what to check / look for?

 

Thanks,

 

Hugo

[miniquandt 0]

Just curious, what are your print settings. Do you use a Cura Standard or are you doing custom? (you don't have to type out all of your settings if your using custom)

 

I know that on a few of my prints if the part is very small it will trim off the small bits because it is too small to print. I don't think this is your issue because it will print fine one at a time.

 

Maybe you could try the print setting under [Special Modes] the "Print Sequence" switch it from "All at once" to "One at a Time". Maybe that would trick the slicer into printing the ribs.

[HugoW 1]

Thanks for the reply. I use custom settings, that is those came with the stl files from 3DPrintLab in the package. All I did to it was raise print temp to 230 as this is what they recommend, and I switched off combing as it produced a lot of stringing inside the parts. I took a look at the print sequence as you mention, and it is partly the solution. I just put 4 parts on the virtual bed, each about an hour and a half, and after slicing at "one at a time", I do get 6 hours of printtime. Putting the setting back to "All at once" it is reduced to 3 hours and it misses all internal structure. However, I just started the print sliced at the "One at a time" setting but quickly cancelled; it does indeed print one at a time, which means it completely finishes one part before it starts the next. This causes serious collisions between the print head / machine rails and the first part when the machine starts on the second part. This is not desirable. So, question still open!

 

BTW, I would like to attach the .ini file I received from 3DPrintLab and use on these parts, but this is not an accepted format.

 

Cheers,

 

Hugo

Edited April 15, 2018 by HugoW

[tinkergnome 929]

https://community.ultimaker.com/topic/20748-cura-deleting-pre-modeled-supports-for-a-print/?do=findComment&comment=194799

[HugoW 1]

Close, but no sigar. Toggling this on and off with one part on the bed indeed switches the internal designed supports on and off. But mine were on, they only switch off (without changing this setting) when I load a second part. Deleting one of the two parts off the bed makes Cura restore the part that is left. It's like adding a second part (order of adding or whatever part is not relevant) enables the  "Union Overlapping Volumes" without ticking the box. Really strange...

 

Hugo

Edited April 16, 2018 by HugoW

[tinkergnome 929]

I think the strange thing is that 3DLabprint takes your money for 3D-models that are broken, or better: not printable out of the box.

 

The models are not manifold, have overlapping volumes or not connected faces or other annoying defects.

If you read some articles in the 3DLabprint forum: basically they rely on the repairing (black magic) capabilities of specific slicer versions to make their models printable...

 

But as long as no one complains, we will see these questions here over and over again...

 

I would load the models in (e.g.) Meshmixer and check it (Analysis -> Inspector). The result could be interesting.

[ahoeben 2,047]

Try with "Merged meshes overlap" set to 0 (and with the Union Overlapping Volumes setting unchecked *in the sidebar*)

 

(same issue as https://github.com/Ultimaker/Cura/issues/1077, same origin of the model)

Edited April 17, 2018 by ahoeben

[HugoW 1]

YES! Thank you, that is it! At least, on the virtual gcode viewer all is visable and the print time makes sense. I will run a large 4 part print tomorrow to see!

 

Thanks,

 

Hugo