burtoogle

Could you please save a project file (File -> Save) from a sample print and attach the .3mf file to this thread, thanks.

Thanks for the file. The problem is that the model consists of 6 meshes. You need to merge those separate curved side pieces into the main model to make a single mesh. Here's a close up of the meshes, you can see that the triangles that make up the curved side piece are not integrated into the main mesh. And here's Cura's display with one of the sub-meshes highlighted. You should install the Cura Mesh Tools plugin from the marketplace to get the ability to check meshes and split them. Unfortunately, I don't know if Cura can merge these non-overlapping meshes so it would be best if you did that before loading the model into Cura.

Hello @gwarokk, it would help greatly if you could provide the project file. Please do File->Save and attach the resulting .3mf file to this thread. Thanks.

Just set all the bridge wall/skin speed/flows/density to 100% and the bridge wall coasting to 0%. Turn off bridge has multiple layers. I think that should be sufficient, I don't have cura in front of me right now, sorry if that's not quite right.

Sure, just use the multiply model option, that produces what appear to be random positions (just kidding but there's a grain of truth in there!)

Thanks for the files. As they don't include the models it's hard to say if there is a problem or not.

Hello @castlenut, please save the project file (File -> Save) and attach the .3mf file to this thread. Thanks.

On Linux, holding the space bar down and using the left mouse button rotates, YMMV.

For at least some of the UM printers, the default is 0.875 * the nozzle dia, so for a 0.4 nozzle, they use a line width of 0.35. I guess they must have evaluated different line widths and decided that is what works best for them. On my non-UM printers I still use a line width of 0.5m (with a 0.4mm nozzle) unless I really need a thinner line for some specific model.

I need the VNC server because none of my Pi's have screens attached, I access them using VNC.

Hello @saxonpaul92, what I mean is that tar file should be unpacked with a command like "sudo tar xf mesa-20.1-date.tar.gz". As mentioned above, there's a problem with running that 32 bit AppImage because it requires some 32 bit system libraries to be present. It's probably possible to gather all the required libraries from a 32 bit Pi but that is an experiment that I am not going to do (yet) because I don't have any Pi 4's running the 64 bit OS and I won't be bothering until it becomes more mature. At the very least it has to support VNC server which I don't believe it does yet. I expect that I will do a 64 bit release for the Pi 4 but it won't be for a while. Finally, as all the source code that my releases are built from is freely available (of course), it doesn't stop anyone else from building a 64 bit release using that code.

Thanks for trying, sorry it didn't help.

Hi, I don't seriously expect it to behave any better but you could try one of my Cura builds for MacOS as they are built a little differently from the UM releases (different Qt version, built on later OS). It would be useful to know if they run OK. You can find my releases at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0 Please read the README.md file there before using.

Hi, I don't seriously expect it to behave any better but you could try one of my Cura builds for MacOS as they are built a little differently from the UM releases (different Qt version, built on later OS). It would be useful to know if they run OK. You can find my releases at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0 Please read the README.md file there before using.

Sorry, my mistake, the setting is called Support Distance Priority Here's what I get when I set that to Z overrides X/Y.

Do you have z overrides x/y enabled ? I think you would need that. Can you provide a project file? Do File -> Save and attach the .3mf file to this thread. Thanks.

Hi @kentisevil, I may make a 64 bit release in the future but right now I don't have a 64 bit OS installed and I think I will wait a little for it to mature before I try. Is it worth copying all the files in the /usr/lib/arm-linux-gnueabihf directory on a 32 bit installation to the 64 bit machine and adding that to the LD_LIBRARY_PATH? Maybe also need some from /lib/arm-linux-gnueabihf as well?

Thanks for the gcode file. Near the bottom of that file it has this: G1 Z250; Move bed to 250 AFAIK, RepRap/DWC calculates the number of layers in the print by looking for the highest Z value and dividing by the estimated layer height, hence the 2499 layers. Perhaps someone on the Duet forum can provide a solution?

Hi, thanks for the file but it's the gcode file I wish to see, not the model. Thanks.

The UI has a weirdness in that settings are often hidden until you close the group (in this case Material) by using the arrow button in the group header and then re-opening it again. This often coaxes shy settings out of their hiding places.

I understand that SketchUp is notoriously bad for creating models that have problems. Install the Cura Mesh Tools plugin from the marketplace and use that to check your model for watertightness.

Could you please provide the gcode file? Thanks.

The bad vertical alignment of the text in the printer settings dialog has recently been fixed for a future release. The squares in the gcode text areas are an ongoing issue as discussed recently in https://github.com/Ultimaker/Cura/issues/2452

Reduce the Minimum layer time.

Hello @netminder, thanks for your feedback, it's nice to know one's efforts are not wasted. Now, bridging. I think it's always a compromise in the sense that it is difficult to get super tidy bridges with minimal artifacts introduced. The fundamental cause of problems with bridging I think stems from the fact that in the bridge region (walls and skin) you often need to use quite different speed and flow and fan than is used for the rest of the model. Big changes in print speed and extrusion rate are always going to introduce artifacts into the print. e.g. if the bridge wall is printed slower or has a lower flow rate than the non-bridge wall there will be a tendency to over-extrude at the start of the bridge which can cause a loop of filament drooping down right at the start and then at the end of the bridge, the wall that follows will tend to be under-extruded which will leave a visible indentation which may extend for many cm around the model. The default values that you get when you enable the bridge settings should produce reasonable bridges, at least with PLA. What exactly are the problems you are seeing? Got any photos? Perhaps you could attach a sample project file that isn't working as well as you would like?