ghostkeeper

If you decrease the line width too much the corners don't become very nice. If you decrease it even farther the extrusion becomes irregular. Even farther and you get just beads instead of a steady line.

There are settings for increasing the overlap between skin and walls, and the overlap between infill and walls, but not for the overlap between skin lines among themselves. So if you adjusted some overlap setting, it must be the overlap between skin and walls or the overlap between infill and walls. Reducing the line width creates no overlap in theory. But in practice, because your nozzle size is larger than your line width, the line gets "blurred" a bit which causes them to overlap and adhere better.

The extrusion is "recalculated". That is to say, it extrudes just as much as is needed for the 0.35mm line width and shouldn't overextrude. And the lines are closer together too.

Still seems to work fine. Here's how it works: As you can see, it moves the nozzle to the side of the prime tower, which is supposed to wipe the stand-by nozzle off.

It depends a lot on what you need. If you need to transform the g-code into something that's better understood by your printer, then a post-processing script could do the job. But if you need to do something different depending on, for instance, whether you're printing overhang or not (to maybe tilt the platform a bit to get better overhang), then you're almost certainly stuck with modifying CuraEngine itself, or you'll have to try and reconstruct from the g-code which areas are overhang. But if you're actually going to try to print curved layers and such to print something from inside out, well, I don't think that Cura will be of much use at all.

It's under Preferences -> Configure Cura... -> Viewport Behavior -> all the way down at the bottom of the category.

Ideas are welcome, sure. The bad overhang quality on flat horizontal surfaces is one of the biggest concerns right now. There is a sort of hard-coded shape in the tree support at the top of each branch: As you go up towards the tip, the circular branch gets flattened in one direction so that the circle becomes an ellipsis which approaches a line towards the tip. We can make that any shape we want. Currently we reduce the width of the circle with an angle of 45 degrees. We could make the ellipsis longer at the same rate or something (one idea that I've been meaning to try out some time).

I'll write it down. We have a separate option for brim around support right now already, but that might not work properly for tree support.

I know why this could happen, but it still seems a bit glitchy to me. Normally the branches try to connect the surface that needs supporting with the build plate as quickly as possible. And if the build plate is unreachable, it tries to connect the overhang area with the model itself. However when there are multiple branches at the same height, it also wants to merge these branches together, so as they are generated from top to bottom they bend inwards towards each other. So in your print of a single column, each little window created a small branch that would go straight down. But when you have multiple of these they go towards each other and end up in the middle, trying to go straight down from there. What I don't understand, and is probably a bug now, is why it didn't manage to evade the object and go down alongside the column when there was one object, but it did manage to evade the object when there were multiple.

That should be enough. The new layer view requires OpenGL 4 because it needs geometry shaders. Your graphical card supports OpenGL 4.5 according to this spec sheet: https://www.geforce.com/hardware/notebook-gpus/geforce-gt-740m/specifications So I think you just need to update your graphical drivers. Once you've done that, Cura should be able to detect that you have OpenGL 4 support and allow the fancier rendering of layer view. Also be sure to disable the "Force layer view compatibility mode" option in the preferences.

We get a lot of questions about this actually. We use about 7/8ths of the nozzle size in Ultimaker's printers because adjacent lines tend to adhere better together then. Because the nozzle is a bit wider, the adjacent line gets partially printed on top of the previous line. 7/8ths of the nozzle size seems to be the sweet spot (so we also use 0.7mm lines for 0.8mm nozzles). This works completely different for different nozzle designs, so if you have a different sort of nozzle then the sweet spot will probably be somewhere else.

To me it looks like the Uranium checkout is more modern than your Cura checkout. You're getting an error because the Uranium function addResourceType() requires two arguments: def addResourceType(self, resource_type: int, container_type: str) -> None: In the current Cura front-end code, our call to this function is a little different from what you seem to have: ContainerRegistry.getInstance().addResourceType(self.ResourceTypes.QualityInstanceContainer, "quality") So maybe update the Cura repository? Though the Cura repository must be pretty old to not have that container_type parameter.

Honestly, I know very little of BSD-family operating systems. While the front-end is written in Python and the back-end (and auxillary libraries) is written in portable C++, I suspect that the binaries for our libraries are not compiled with BSD in mind. I'd expect Qt to be the most difficult one to get right. Besides that there might be some libraries we depend on that could be missing. And some resource paths that we have hard-coded, such as the config path being ~/.config/cura. In our code we've always been talking about "Windows, MacOS and Linux" as our supported platforms; never "Unix" or "BSD". You're the first person I know of that seems to have tried.

It is now! This is a known bug right now. See also https://github.com/Ultimaker/CuraEngine/issues/544 It's caused (as far as we know) by the Support Use Towers setting in combination with Support Horizontal Expansion. The support area is still passed down to lower layers but it's too slim to print. It should get removed in that case but it isn't. Eventually it somehow becomes wider again (maybe due to the towers?) and then it can be printed again.

We're repairing the feature for 3.3, because: We were getting lots of feedback from people that were using it to sort of be able to reslice their prints. Our customer service department was using it to check if people were really really really not setting their settings to something weird. It was causing a bug in the UM2 firmware to surface that caused a big blob at the end of the print. It was caused by a bug in the first place.

But while printing, did it make an unnecessary circle with 0.1% flow rate along the wall, like a phone dial? I'd expect that to happen (even though it's not desirable).

No, I think it's rather a matter of not enough time to test with all combinations of printers, nozzles, etc. Because of this we're seriously re-evaluating our plan for testing products in the maintenance-state of development (such as currently UM2+). That shouldn't have slipped through.

No, spiralize is global only. Doing it per-extruder or per-object introduces risk of hitting the previous layer that was already printed, since you'd be going down in Z direction sometimes.

Feel free to call upon @ghostkeeper to get my attention any time I love answering such questions. I know that Nallath regularly keeps up with the goings on here and Msuurmond sometimes too. And many of us keep a close eye on the Cura Beta and Release threads. Cura has been able to import profile settings from g-code for a very long time. Like, 2.1 or so? It was one of the first things that I implemented for the Cura front-end. The purpose of this was to be able to debug when a user has a problem with their g-code. We can sort of track down what settings were changed from the defaults, even though it doesn't save which default profiles were selected (only the custom profile and the unsaved setting changes). The settings are stored at the end of the g-code in a few comments. Only in release 3.2 there was a bug that caused the settings to no longer be stored there. I suppose importing them is still working fine (didn't try) but the settings aren't saved to the g-code any more. Recently there was an attempt to fix it, but today I tested that fix and had to fail that test because it didn't save the current (unsaved) changes. It should (if memory serves) also work across versions of Cura. That is, if it encounters settings that have been renamed or metadata in an old format, it should attempt to update those, like any other profile importer.

This is known. It's a limitation of how Cura calculates these things: Your model outline is inset by half the line width. If anything remains, it is printed with the normal line width. If nothing remains, only the "Print Thin Walls" option may still save you. If two lines overlap a lot, then one of the two will have its extrusion rate reduced to prevent overextrusion. You'll ooze some filament there but hopefully not too much since there is a backpressure from the earlier printed line. In the future I hope we'll implement some sort of minimum extrusion after overlap compensation, such that lines that are reduced to less than 30% of their normal extrusion rate or so will just be left out. That would fix stuff like this.

When starting Cura with a system command, you can provide the option --single-instance. This will not launch a new instance of Cura if one is already open but instead re-use the old one (replacing the build plate with the newly loaded file if a file name is also provided). I don't know exactly how Fusion 360 calls Cura with its "make button", but I'd expect it to be some sort of macro that calls Cura via a system command. It should add the --single-instance parameter to its call.

Workaround for now is to put at least 512 bytes at the end of the file (in comments). Because the firmware reads 512 bytes at a time from the file, so if you put that at the end of the file it'll think that the print hasn't finished yet...

I talked to Daid and he did some very impressive debugging and tracing from my description and found 2 bugs in the firmware that led to this together with a bug in Cura. There's a bug in Cura 3.2 that it doesn't output the custom settings in the g-code any more. We knew about this one and it'll be fixed for 3.3. In the firmware, it would check for the file being completely read and the g-code buffer being empty. If both are true it would call an abort function on the print that would stop the print and set the correct status flags and such. However, there are still moves in the motion planner, and it didn't check for those. So it would abort too early. The abort function still completes the current move. It computes the necessary motion to complete the move, however there is a compensation factor to account for the filament volume vs. length and this wasn't applied in the abort function. Daid fixed 2. and 3. and they're now investigating how to test this.

Yeah, we've heard about this more often. Something is up with the way that fonts are rendered on some MacOS computers, but it doesn't seem to be related to specific MacOS versions. It's quite hard to reproduce and we haven't found a solution for it yet. We're switching to a different font face for 3.3 (Noto Sans instead of Open Sans) so maybe that is better, but we won't know until these people can try it out when the beta for 3.3 is ready. I'd like to refute this. The firmware delivered with Cura 3.1 is exactly the same as the firmware delivered with Cura 3.2. Byte-for-byte. But maybe the mere act of re-flashing the firmware might fix things since the NAND chip in the UM2 was sometimes a bit glitchy. I'm now slicing a cube using 3.1.0 and 3.2.0 and seeing what the difference is in their g-codes. This is the result: So to summarise: The Cura_SteamEngine version changed, the comment for M82 has a space less, and the settings at the end are missing. That last bit together with @ndimensional's findings gets me thinking that maybe the UM2 firmware isn't flushing its g-code buffer at the end properly. There is a buffer of 8 (?) lines of g-code in Marlin's memory that allows the printer to read and parse the g-code in advance so that it's ready on time for when the printer needs to execute it. Maybe the g-code parser says that the file is done already, the print stops, and the last few lines that were in the buffer aren't executed any more. Just a hypothesis. This is the sort of thing that only @Daid still knows. If this is the case, we could fix it by outputting some arbitrary comments at the end for UM2-family printers, though it would of course be better to fix it in UM2's firmware. Perhaps you could try ndimensional 's fix. But just to be sure, instead of adding 4 lines, add 8.

The firmware delivered with Cura hasn't changed in 8 months (since Cura 2.6): https://github.com/Ultimaker/cura-binary-data/tree/master/cura/resources/firmware The firmware repositories themselves did change, for instance this one: https://github.com/Ultimaker/Ultimaker2Marlin/commit/aa496a8f3b09ed7333b162deb21de5a9d154898a However the changes made to the source code was only documentation so we didn't make a new build of the Ultimaker 2 firmware for that. If there was a bug with the firmware of the Ultimaker 2, I wouldn't expect it to change with Cura 3.2. I would think that it was Cura at fault, so then it would appear in the g-code.