ghostkeeper

Yeah, that looks like it should work, actually. I am confuzzled! I would expect a ZeroDivisonError here if the bed temperature is 0, because then you'll evaluate 45 * 0 / 0 = 0 / 0. I think the error is happening underwater and it is just displaying the old value then. Try this: "' M190 S' + ('45' if material_bed_temperature else '0')"

Yeah, a couple but it depends a bit on your printer. For Ultimaker 3 for instance, we've set the line width to be a formula, equal to 7/8ths the nozzle size. So if you set the nozzle size to 0.35, you'd get lines 0.306mm wide, but if you set the line width to 0.35mm, you'd overwrite the formula and get lines of 0.35mm wide. Apart from that, we've also got some other things depend on the nozzle size, such as Outer Wall Wipe Distance (which is set by default to half a line width), but apart from Line Width it's all really minor. https://github.com/Ultimaker/Cura/blob/b00502d10fdfeac9b87465b693e055c6b6406673/resources/definitions/ultimaker3.def.json#L10 You can see this happen really well in the initial layer if you look closely. If you set the line width higher than your nozzle size you tend to get worse horizontal adhesion because the extruder can't handle the pressure pushing against the filament well. But you should get better adhesion vertically because you're really pushing the filament down hard then. This is why we're setting the initial layer line width to 120% by default, to get better bed adhesion. Personally, in most of my prints, I like to increase the skin line width a little bit and then enable ironing. Increasing the skin line width reduces the printing time a lot because you need fewer lines. Ironing then makes the top surface look nice regardless of the crude lines/underextrusion.

There is no guide to post-processing scripts, but I've always recommended people to take a look at the other scripts as example. The search and replace script is really simple and should be clear for adaptation: https://github.com/Ultimaker/Cura/blob/master/plugins/PostProcessingPlugin/scripts/SearchAndReplace.py

We were imagining that you'd type something like: {printer_name}_{model_name}_{date} where {printer_name} gets replaced by the name that you gave the current printer, {model_name} gets replaced by the file name that you loaded and {date} gets replaced by the current date. If you were to type 'Printer 01' then it would always give the same name to the print job regardless of what you're slicing.

Yeah, I was about to! Our final decision was to turn the current check box in the Preference window into a text box where you can fill in a formatting string, similar to media tagging software. It's not all that hard to use but covers everyone's use cases.

I think we have a big enough sample size. We'll discuss the results on Wednesday. This was sort of a pilot to see how people would react to involvement in this way. The issue itself is pretty small (trust me, we're tackling bigger issues first really), but it's interesting to hear how people organise their g-code files. We're hearing your feedback that it needs to be customisable and that it would be more useful to have a suffix instead. The suffix should be no problem (if people agree within the team). Customisable may be a bit too much detail for a preference but we'll discuss that Wednesday then. Thanks for participating in any case!

There is already a preference to disable it: "Add machine prefix to job name"

What if you add 2 extra lines to your brim? Does that then not function as a skirt?

We could have an incremented slice version number but that would reset if you restart Cura then or rename the file you're slicing. For clarity, with "An acronym based on my selected printer's name" we mean that if you call your printer "Ghostkeeper's Printer" then the acronym would become "GP".

This error happens in Windows when mixing up 32-bit and 64-bit applications. Two things you could try: * Don't install a new version of Cura on top of an old installation. So either select a different directory to install it to, or uninstall the old version first. * Make sure to install the Visual C++ Redistributable when the installer prompts you to. In short, I ask you to install Cura again.

Actually, for some of the settings, I'm sort of putting my foot in the door and try to steer it such that it doesn't become a setting. Because some of these settings are just so complex to use for the user that they will hardly ever be used at all. Or there is just one option that is in every case better than its alternatives (but takes 0.05s longer to compute in the engine or something).

There's more information here: https://github.com/Ultimaker/Cura/issues/3725 It's being investigated.

Almost. Cura calculates the total extrusion for the entire line. The print speed is irrelevant then. Correct! I don't know what Repetier does with it. They work with CuraEngine though so if that nozzle size directly drives line width they'll do some translating. Cura knows the nozzle size as well and does a few things with it. Here's a 100% complete answer for those who are interested: Most significantly: Set the default line widths to use. Our formula for this is that the line width should be 7/8ths the nozzle size. This seems to give best results, since it causes lines to slightly overlap, producing a stronger part. For some lines, such as infill, we use a bit thicker line width in some profiles. Determine how far inwards the nozzle wipe starts on a prime tower. You want to wipe off the whole nozzle. Determine how short skin lines can be before they get merged together. You can see this happening when you have a piece of skin inside a sharp corner: The last skin line in the pointy corner will sometimes not be parallel to the rest of the skin lines any more but will be aimed inward into the corner. This threshold depends on the nozzle size. I think the idea here was that the nozzle size is sort of the limit of the amount of detail you can apply in such a corner. Default value of several detail settings: Outer Wall Wipe Distance, Outer Wall Inset, Minimum Support X/Y Distance. Warning threshold for lots of settings in the interface are dependent on the nozzle size (like 50 settings or so).

Indeed Cura doesn't have any such modelling. And neither does the firmware. All things in Cura related to this, such as coasting, involve compensating measures to counteract the effects of the pressure differential in the nozzle at specific points in the print. Hand-wavy techniques, so to say. If your nozzle extrudes enough material to fill a 0.5mm wide line, then that material has to go somewhere. It goes sideways, producing a line of the desired width. Of course, this only works up to a certain point or the pressure in the nozzle is going to exceed the pressure that your feeder can exert on the filament. And it has some detrimental effects in corners as well. Cura models lines as being rectangular. It instructs the printer to extrude exactly as much material as is needed for a rectangular block of 0.1mm high, 0.4mm wide and 10mm long for a layer height of 0.1mm, line width of 0.4mm and line length of 10mm. 0.1mm * 0.4mm * 10mm = 0.4mm^3, so you'd see an increase in the E value of 0.4 for such a line. In reality, the line sags a bit so the line is slightly wider. And the line collides with the lines next to it and this increases backpressure which causes the material to slip a bit again. There's a million effects going on there... Some people have gone really deep into researching this. If you ask me, the most significant effect in dimensional accuracy is that lines get dragged along with the nozzle in corners after just being extruded. This means that the line will always sort of take a "shortcut" in a corner because the nozzle drags the fluid along with it in the corner a little bit before it's fixed on the surface. The effect is that inner corners are slightly too small and outer corners too. We sort of have a fix with the "Post Stretch Script" in Cura's post-processing scripts. It's a bit crude but with some models really effective. If you can think of a reliable solution in software that would be awesome.

Two workarounds, depending on how technical you are. Choose one: Download this file: https://raw.githubusercontent.com/Ultimaker/cura-binary-data/master/cura/resources/firmware/MarlinUltimaker2plus.hex And then upload it via Cura by going to the machine manager, click Upgrade Firmware then Upload Custom Firmware and select that hex file (also connect via USB first). Or go to the machine manager, click Machine Settings, and then paste the following text in the "end g-code" field:

No, this bug still exists as far as I know. Only I also know that it doesn't occur with the Ultimaker 3, meaning that it's something in the definition files that's different between the two. The bug was kicked off of our planning because they didn't think it was important enough. But if someone finds out what causes this then we might be able to fix it still.

No, this is applicable to all multi-extrusion printers, so also UMODE. It allows you to temporarily disable some extruders, preventing the profiles in those extruders from influencing your settings for the extruder you're printing with and allows you to print one-at-a-time.

This already exists. You can load your model in Cura and in Per Model Settings select your mesh to be "Don't support overlap with other models". In fact, that's what we started with. This new support blocker just places such an object in the scene with a pre-generated cube so that you don't have to go through CAD software.

That by itself is easy to implement. It's probably harder to then predict beforehand how wide the prime tower is going to be to determine where the user is allowed to place objects before slicing.

We now have a "fix" that'll likely be included with 3.3 stable that causes Cura to no longer crash on this but instead deactivate the printer and display a message. As for the actual bug though, it looks like someone renamed the "low" quality profile to "fast". I'll implement a version upgrade routine to fix that for other people, but for you your configuration will stay broken because your files have already been upgraded to 3.3. Thanks for testing and helping us debug your bug I don't think it was, actually. You like it better?

That's not a stupid question! You download one of these .hex files to your computer. Then you open up Cura and connect your computer to your printer with a USB cable. Then in Cura you click on your printer's name in the top-right, go to "Manage Printers...". Then click on "Upgrade Firmware" and select "Upload custom firmware". Then you should be able to select the .hex file you downloaded and it'll upload that firmware. I don't know if it's documented somewhere on this website. If not, there should be some how-to somewhere I guess (though uploading custom firmware is fairly advanced).

Not as far as I know. You can install an image from an SD card as per gr5's initial post, but it won't automatically run from the SD card itself by default. The printer is in many ways a full-fledged computer though so if you can still run the printer and get it into development mode you can access it via SSH (username and password: ultimaker) and then you may be able configure it differently by installing Grub or something. The printer normally accepts a Screen connection via USB with the two pins on the board next to the power input. You could also try that if it's not in development mode. I'm not very experienced on the firmware side of things though (or the internals of Linux for that matter) so maybe someone like @Daid can give you a better answer.

The way that this works (or should work) is as follows: If Support Distance Priority is set to "XY Overrides Z", then the X/Y distance between support and model should always be held, even if this causes the vertical distance to be larger than the Support Z Distance settings. The Support Z Distance is essentially just how far it must move the support downwards after computing the support with proper X/Y distance. If Support Distance Priority is set to "Z Overrides XY", then the Z distance between support gets precedence so it should always be correct. EXCEPT in parts with a fairly vertical slope, because then this would cause the X/Y distance to be very small. If the horizontal distance becomes very small, the Minimum Support X/Y distance kicks in and that gets precedence again so the vertical distance may still be larger than the Z distance. Support Stair Step Height is separate from all that. At the bottom of the support where the support rests on the model, the support is sort of stepped so that it doesn't rest on the model everywhere. This makes it easier to break off from the model, and improves slicing speed a bit too. The Support Join Distance is also separate from all that. If two pieces of support are very close together horizontally they get joined together. This prevents having lots of very thin pillars of support in favour of creating one bigger pillar which is stronger and prints faster too.

In the meanwhile we've also actually fixed this bug in the firmware. You can get a new hex file here: https://github.com/Ultimaker/cura-binary-data/tree/master/cura/resources/firmware Or you could use the previous workaround: Put at least 512 bytes of comments in the end g-code of your printer. Both should be in the Cura 3.3 release (the workaround is still in there for people who didn't update their firmware).

Indeed, I believe the Ultimaker 3 has it disabled for most materials (like PLA) but enabled for the more flexible materials like PP which ooze a lot during stand-by.