burtoogle

Hello, There's an experimental setting that turns it on, it has the normal help blurb if you hover your mouse over the setting. Just have a play with it, it's not tricky. It doesn't replace anything (other than one of my previous releases), my releases can live alongside the UM releases. I don't see why not. Yes. But for the PI 4 you need the armhf appimage, not the windows exe. With the appimage, once you have downloaded it onto the PI, make it executable by typing in a terminal chmod +x FILE, where FILE is the name of the AppImage file you downloaded. You should then be able to execute that AppImage from the command line or clicking on it. In a terminal window type the following to download and install it: sudo apt-get install libgles-dev Hope this helps, have fun!

"Watertightness" doesn't require the model to be completely solid, you are allowed to have holes. What it does require is that all the surfaces join up with no gaps. It should be possible to fill the internal volume of the model with liquid without it leaking out between the model's polygons.

Completely sub-conscious. I'm not sure that a single finger is considered that offensive in the UK, we've always preferred the two-finger version.

Thanks, this is what cura mesh tools says about it... You need to fix the model in the region where those pins are.

The most likely reason is that the model is not valid. Could you please attach the stl file to this thread?

Hi, my Cura builds are based on the most recent code from UM and you can install my builds alongside the UM releases. If you are interested you can find them at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0 Please read the README.md file there before using.

Hi, I have built for Linux and Windows 64 bit, will do the MacOS release tomorrow.

My Cura builds now provide this feature. It is new and somewhat experimental. You can find my builds at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0 Please read the README.md file there before using.

Here's the gcode with the limit support retractions turned off.. WD9_Body18.gcode I will build a release today.

I think it's because you have limit support retractions enabled, compare these two images... With limit support retractions enabled... Without...

Great, thanks for the feedback. I will submit the mod to the Cura devs so that it can be in future releases. In the meantime, my next Cura build will contain the mod. I expect I will do a build over the weekend. You can find my builds at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0 Please read the README.md file there for more info.

Hello again, please try this gcode instead of the last. Thanks. WD9_Body18.gcode This gcode is almost 50% smaller than the gcode you were getting before. It should print faster!

Hi, I have sliced your project after doing a mod to Cura, can you please print at least a part of this to see if the slowdown has gone away? Thanks. WD9_Body18.gcode

It makes sense to be wary. The safest way to use my (or any other) release would be to build from source because then you could check for "evil code" and be confident that what you build is not going to lock the contents of your hard drive until you pay a king's ransom. Building Cura is not rocket science but it's tedious enough to put most people off.

Thanks for the project file. My guess is that the slowdown is caused by the very large number of line segments in the curved area of your support object. Not sure if that can be altered using the Cura settings, it could be a slicer problem that needs fixing.

Please do File -> Save and attach the .3mf file to this thread. Thanks.

Hi, I don't know about the font issue but for the other thing, could you please attach the gcode file to this thread so we can see what it contains. Thanks.

Yeah, IMHO, using Python for the Cura front end was a big mistake along with Qt/QML.

But only after a fashion because a lot of the stuff that I offer to UM gets rejected which is why my fork is now so different from UM Cura.

The github source links are in the README.md file. You will also need my versions of the cura-build and cura-build-environment repos.

Thanks for the model. Firstly, ignore the seams shown in the Cura layer view as it doesn't really do spiral mode correctly. It often shows the seam even when the model shows nothing. I sliced that model using my Cura and I can't see any seam looking at the gcode. This is the Cura layer view, seam is visible... And this is the gcode visualised in S3D, seam not visible... However, it may be that UM Cura doesn't do such a good job as my Cura so you may wish to try one of my releases. You can find the releases at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0 Please read the README.md file there before using.

Could you please attach the model to this thread so I can take a look? Thanks.

Sorry, that model is broken. Here's what the Cura mesh tools say...

I think those regions are at the top of the print because the horizontal lines that connect them look like they are bridge lines. I would say the cause is most likely a large difference in extruder rate between the bridge lines (low extruder rate) and the lines between the bridge lines (fast extruder rate). The solution is likely to be reduce the difference in extruder rate. That could be done using a higher bridge wall speed and/or flow and a lower non-bridge wall speed and/or flow.

Look, unless you provide the asked for info, there's no real evidence that this problem is really being caused by a bug in Cura 4.5. It could just as easily have been the result of bad settings or (less likely) a bad model.