widden

So I've tried the new 5.0 beta and it works like a charm, thanks. I've had some problems with the program crashing and resetting all settings a couple of times, hopefully these will pass. Thank you, Greg! I can see the 5.0 is now "available", so I'll download that to continue https://ultimaker.com/software/ultimaker-cura?utm_source=cura&utm_medium=software&utm_campaign=cura-update-download

Actually, I can't work out where to download the 5.0, and I'm a bit time poor to try and learn how to build, so I'll give this one a miss. Thanks anyway.

Thanks, I'll have a looksie at 5.0 Yes, it's 4.13, and the reason I'm printing with 0.6 wall is speed. This box does not need to be a beaut; it needs to be light and print quickly.

Hi Greg, thanks for your response. I'm a bit confused - but I'm very tired, so apologies. Fistly; I meant to put the part about "rounding error" after the zig-zag - since it does not make *all* walls a zig-zag, even the same wall is only partly zig-zagged . Second; so are you saying that this is all good? Should I just print it? Btw I've restarted my configs from absolute scratch since I had problems last with cura giving me very weird time estimates, about a month or so ago. It seems to work OK till now - not sure what to make of it. Do I need to re-create configs regularly for cura not to mess itself up?

After slicing my model is full of gaps in the walls near the ends, around a mm wide, seemingly dispersed a bit randomly. But sadly, enough to make the resulted print a 'failed' one. This is a 0.6mm thick wall, printing at 0.6mm line width. So in theory it should be a simple continuous line. Really weird, looks like a floating point rounding problem if anything. Please see the screenshot and project attached. I've tried this object earlier making the wall 0.61mm, but then the printer starts zig-zagging on *some* of the walls. Still leaves gaps in other places. Attached images, the two objects, and the project. v13 of the ammo box is with the 0.61mm , v14 is with the 0.6mm wall thickness The project file is with the 0.6 wall thickness again. While this looks like a bug, I'd love to know if you guys have an idea for a work-around? Is there's any way to get this to work and have a single line laid down (from wall to wall)? Thanks! yAmmoBox.v13.50cal.stl yAmmoBox.v14.50cal.stl yAmmoBox.v14.50cal.3mf

Thanks for looking at this. I've now created a new profile, just copied the speed and accel settings into it, tried a few things and yes, they are indeed a lot more accurate now. Nearly spot on. Very interesting. I'll simply on from this new profile.

I've tried asking this on reddit, but not much came out of it. I thought I'll try my luck here. I've got an advice to install "printer settings" extension, which I did and set up, however it did not seem to fix anything. I'm sure I'm doing something wrong. But what? Here's is the original post below. --- I've always been aware of a bit of a discrepancy in the estimate vs real time, and I can put up with it as long as it's not too bad. Eg ~30 minutes off on a 5-hr print I can live with. However, it seems since I've upgraded my Ender-6 with a Biqu H2 and started building up speed, things have gotten a lot worse. Latest one is an articulated snake, printing at 100mm/s walls & 150 infill; this was estimated to complete in 5:28 - took 2:56. That's massive. 3 hrs vs 5:30 ! That's 50% extra estimated on top of the time. Is there anything I don't know of? Is there anything that can be done to improve these estimates? Interesting that putting the gcode file into https://gcode.ws/ results in an estimate of 2:28:49 - while this is under by half an hour, it's still a lot closer. --- And I've got a new one, since. A test cylinder, a very simple thing, the project is attached. Estimates 4:22 and takes 1:04. gcode.ws estimates 1:27. I've attached the project for this. Can someone please shed light on how to set up Cura to provide estimates a bit closer to reality? TestCylinder.3mf

Yeah, ok - so they do come in pairs, and hence copying just some of the files does not work. When I've copied the whole shebang, it worked. My fault was that I thought I can just copy a few and it'll work. Thanks, mystery solved.

Here's a couple, they aren't all important, mostly incremental changes, but I'd like to be able to keep the last 10 or so to be able to go back if I find that the latest is terminally ill. I did not copy *all* of them back into the live folder, either - maybe I should do that? Btw also, looking at the whole thing with this 'pairs' in mind; could it be that I should order by date and copy a large bunch instead of cherry picking? Yeah I think in light of what you wrote, I'll test these later. cura profiles.zip

Hi, thanks for looking into this. The stderr and stdout are empty in the cura folder, so I'll not bother. Attaching the cura/4.13/cura.log I've just done a copy files in and restart right before (and the files are gone again) . Is there anything else you might need? cura.log

I've upgraded to 4.13. In the process my profiles were deleted (uninstalled the old version) - I thought; not a biggie I keep a local backup (of the folder quality_changes). But now I'm copying these files into the quality_changes folder, cura empties the folder on program startup. Weird. So how can I get my profiles back? Please tell me there is a way? I mean no sane person would build a program where an upgrade means user profiles are garbage...right?

I thought it might be a case, and it's not doing any harm in this case, but it seems to be erroneous; I thought cura devs might pick it up 😉

Roger, I've re-created the situation, here is the 3mf file. The funny bit of support is still there. Dalmatian.3mf

May be a bug? Please have a look here guys, I've tried to create a bunch of screenshots to illustrate the problem. It seems that cura has generated a bit of support within a support blocker. Normally the program only does this if the support is required above. However, this bit is not connected to anything above - it ends on the model. https://ibb.co/wKzFLpw https://ibb.co/C8FcmrF https://ibb.co/gw3XVRc https://ibb.co/n0kv79j https://ibb.co/R9Gfbng https://ibb.co/qByskTp https://ibb.co/884TwwC https://ibb.co/2WJkW08 https://ibb.co/GHf4Y9g On a sidenote; I can't print this bloody dog. The dog's right ear just does not print, I've added extra-wide supports, plus extra manual supports now, printed with 0.12 line height, and that right ear moves out of place every single time. The end seems just too pointy to be printed.

Hah, heard the story that Armstrong has fixed the Apollo 11 during their moon mission with a ball pen? It's possible to get there in nearly anything, but needs a bit of luck 🙂