ghostkeeper

So then reducing the Minimum Wall Line Width will allow it to print with two walls then, using thinner lines. Does that not solve your problem? Effectively, you could see the Minimum Wall Line Width simply as the threshold at which it starts using more, thinner lines.

I can clarify that a bit. Default X-Y Jerk is indeed used for two things: Getting correct time estimates, if jerk control is disabled. If Cura doesn't control the jerk, the firmware has its own defaults. To get correct time estimates, Cura has to know what the firmware's default is then. Resetting the printer to its firmware-default X/Y jerk value at the end of the print (if jerk control is enabled). That way, your prints don't influence later prints done on that same printer even if it's printed with a different slicer. The second usage is what Ahoeben found there.

This discussion is about a geometric term called the "miter limit". If you perform an offset or inset of a shape, very sharp corners may move a long distance, so the sharp inner corner of your layer would move a long way inside. The miter limit adds a cap on that. If the corner is further away than a certain number of insets, it'll get capped off and turns into two shallower corners. I think the original model was just on the edge of this miter limit, and got capped off on one side due to rounding errors. MDN has a nice explanation of it here (since it's also a CSS property): https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Applying_styles_and_colors#a_demo_of_the_miterlimit_property Cura uses a miter limit of 1.2 for most things (including wall insets), meaning that corners get cut if the inset vertex would go beyond 1.2 times the offset distance: https://github.com/Ultimaker/CuraEngine/blob/6fc5f512f2d0dfe602a3d1b71d61853578cb8b42/src/utils/polygon.h#L128 A miter limit of 1.0 would mean that corners are exactly as wide as the normal wall. This is not always desirable though, since corners are also weak points of the print. We went for 1.2 as a balance. Arachne produces round joints instead of miter joints, by the way. The miter limit is removed from the walls there.

Admittedly, it's hard to get right. This is where the scale is determined (in particular the unit_w and unit_h variables, determining how big each unit length of the SVG will be IRL): https://github.com/Ghostkeeper/SVGToolpathReader/blob/b12fc84aad90f2d4a9dac00d1c676b47dda4b0d8/Parser.py#L1352-L1372 In effect, the viewBox property determines how big the image should become, in millimetres. The image width and height determine how it should scale the image to be in that viewbox. It doesn't do any clipping. Looking at this now, it does seem to be somewhat different than how SVGs are normally rendered on a screen. This may need some fixing, if you can post an example in Github Issues of an SVG that goes wrong: https://github.com/Ghostkeeper/SVGToolpathReader/issues

GR5's initial response is also the only one that Cura itself explicitly creates; the folder in Application Support. Other side effects of using Cura that I can think of are: MacOS creates a system log for every application. That's the one you deleted. MacOS itself created that one so it's probably best to not mess with that (though in this case it probably doesn't damage anything). You may have made file associations, e.g. for STL files to open with Cura. Since version 4.9, Cura also adds a keychain entry upon logging in to store the log-in token more securely. However since 4.8 didn't have a library to read the keychain yet, it shouldn't be influenced by this. A perhaps more likely cause for the problem is that your operating system itself has changed. For instance, Cura 4.8 didn't have support for Big Sur yet. If you updated to Big Sur since the last time you used 4.8, that might explain why it's no longer working. If you fill in an issue on Github it'll have a template where it asks for relevant information such as the operating system. This helps to narrow down the issue. And we're also quite curious as to why 4.9 won't run...

The setting Remove Mesh Intersection prevents meshes on multiple extruders from extruding in the same area. If you disable that, you can achieve toolpaths that cover the same area. Getting it to produce exactly the same paths could be tricky though. Need to make sure it has exactly the same settings everywhere, at the very least. With a post-processing script this is pretty doable. That would be the preferred solution in the end at least, but requires programming skills. If you really want to get into the code where this collision prevention is implemented, it'll be here: https://github.com/Ultimaker/CuraEngine/blob/master/src/multiVolumes.cpp . However implementing a post-processing script is likely going to be easier than making modifications there (and compiling CuraEngine afterwards).

Need to look into Firefox add-ons like uMatrix and NoScript, since this upload is made directly to the Google Cloud Platform, so you'd need to allow access to those domains.

No, the initial layer is also sliced through the middle of its Z range: https://github.com/Ultimaker/CuraEngine/blob/991cd026ffccc6def5e5b6a937edd6ae1b7cc8bf/src/slicer.cpp#L957

The real answer is that it depends on the Slicing Tolerance setting. But going by the default of "Middle", it would create a cross section from the middle of the Initial Layer Height. So if your Initial Layer Height is 0.2mm, it would create a slice at Z=0.1mm. Thus, you'd need to make sure the bottom of that sphere protrudes by less than 0.1mm.

Indeed, as ahoeben already said, the changes to CuraEngine can't be implemented from a plug-in. You might be able to make changes in a post-processing step that works on the g-code string, but anything involving the polygonal shapes of support, slice layers, etc. will probably be impossible because it's very hard to retrieve the original shapes that were intended to be printed from just g-code. So you can't just perform a polygon offset or anything. Since you need to modify things in FffPolygonGenerator and FffGcodeWriter, I'm pretty sure that you can't do those things from just post-processing and will need to modify CuraEngine itself. Cura has always just had the scope of FFF printing by design. There is however one SLA printer in Cura's printer list (Peopoly Moai) which is in a similar situation as you. They interpret Cura's g-code to generate the structures that will be solidified, if I understand correctly. The names of these files have been this way since CuraEngine was started by daid (they were renamed at some point from "fdm" to "fff" only) and even then I think his only intention was to make it work for FFF. For instance, a polygon generator for SLA or something would be very similar in many ways, so that would need a more generic architecture anyway. In any case, don't wait on us to implement things outside the scope of FFF ;) Of those, Nallath, Fvrmr, Rburema and I are in the Cura team (along with Jellespijker, Konskarm, Vandrasc and Evtrados who aren't active on this forum as far as I know). SandervG works for Ultimaker but not directly in the Cura team. We generally have fairly little to do with each other but we communicate about blog posts for Cura's releases. Ahoeben and Burtoogle are active outside contributors and know a lot about Cura in general.

Hey. I can share what I know of the X3G conversion. Thanks for the ping, Greg. The X3GWriter calls upon an executable called GPX to convert g-code to X3G: https://github.com/markwal/GPX The X3G files work slightly differently than g-code files and they need slightly more information. Sometimes this is where mistakes sneak in. GPX accepts extra settings as parameters and Cura translates most of those to machine settings that you can modify through the Printer Settings plug-in on the Marketplace. This means that *machine settings may affect the X3G conversion*. In particular, the Maximum Feedrates and steps per mm are important. The full list of conversions between Cura's settings and GPX settings are here: https://github.com/Ghostkeeper/X3GWriter/blob/1386edb609b467b7457a98f99cd693095bf22a61/X3GWriter.py#L219-L281 Aside from that, GPX also has a number of pre-defined profiles. In Cura you can choose one of these via the machine_x3g_variant metadata entry. The list of pre-defined profiles doesn't include the Duplicator 4 though. Here's the complete list: https://github.com/Ghostkeeper/X3GWriter/blob/1386edb609b467b7457a98f99cd693095bf22a61/X3GWriter.py#L168-L187 So to create support for the Duplicator 4, you need to somehow find out what settings are necessary in GPX to convert g-code to X3G. I don't know those and can't really help you testing them. Then you need to fill those into the machine settings in Cura. If you get them to work, perhaps we can add a profile to the GPX application too.

The last real change to the Marketplace was in July when the rating system was removed. Our main focus lately (the last 3 months) has been the variable line width algorithm. But that all doesn't matter since the prime blob routine is implemented in the printer's firmware, and focus/resources in Cura development do not detract from what happens in firmware. All Cura does is output the "G280" command. We have absolutely no control over how the printer moves the bed then. For that reason it'd be better to post this in a place that is more frequented by firmware developers: https://community.ultimaker.com/forum/109-firmware/

I don't think I should die for this error 😄 At least not as long as the Settings Guide shows it correctly: https://github.com/Ghostkeeper/SettingsGuide/blob/master/resources/articles/support/support_xy_overrides_z.md I'll ping the website content people if they can fix it. They are the maintainers of those pages. Thanks for paying attention!

The 15.04.06 Debian archive specifies that it requires the following packages: python-wxgtk2.8 or python-wxgtk3.0 python-opengl python-serial python-numpy I don't know in how far those are still maintained for modern Ubuntu or Mint versions. You'll probably still be able to find them online somewhere but maybe not in apt. These are for Python 2, mind you, which has reached end-of-life.

I generally respond to those pings, although I don't track issues on the forum itself. If you seek to modify the layer heights, look for the buildLayersWithHeight function of the Slicer class: https://github.com/Ultimaker/CuraEngine/blob/51ee4b7adf6dfd112241cdf3fd5681e87cf6370c/src/slicer.cpp#L929 In this function it determines the Z coordinate of each layer, either by calculating from the layer height and initial layer height, or by asking the AdaptiveLayer class.

> What should do the users with printers with shared heaters? From our understanding, those users, if they choose to stay with 4.6 or modify that QML file to show the checkmark, should disable the Shared Heater checkbox and only print single extrusion prints. Because if they print dual extrusion prints, the filaments will collide in the nozzle. If you think this is not an issue, please share your opinion here: https://github.com/Ultimaker/Cura/issues/8148 . You can read an explanation of the issue here: https://github.com/Ultimaker/Cura/issues/8148#issuecomment-674429133 . We've tested this behaviour and verified that indeed both filaments will always be brought to the nozzle tip at the same time, and thus mechanically collide in the nozzle. That issue thread would benefit greatly from some proof of how the feature can work correctly.

Sorry, deze vertaling is automatisch gemaakt met vertaalsoftware. Het zit vol met fouten. De leukste vond ik: (Vertaald van "Cura's mould generation is not perfect.") Ik kan een automatische vertaling niet toestaan. Ik heb hier een uitgebreide uitleg gegeven waarom vertaalsoftware dit nooit gaat kunnen vertalen: https://github.com/Ghostkeeper/SettingsGuide/pull/27#issuecomment-671659031 Het is natuurlijk heel wat werk om een echte vertaling te maken, dus de plug-in staat het ook toe om niet alle artikelen vertaald te hebben in alle talen. Het mag incompleet zijn.

I think you need to look at where the DLL is located relative to Cura's working directory. Cura's working directory is the user home unless executed from the command line. So it's probably better to just give it a full path. Look into PluginRegistry.getPluginPath to get the absolute path to your plug-in's directory, and combine that with the filename of your DLL. I must say though that I've never worked with loading DLLs using CTypes. My SVGToolpathReader works with a DLL (FreeType) that has Python bindings, so that behaves just like any normal module and I can just import it.

At these very low layer heights, aliasing plays a big role. For instance with the 0.0075mm step resolution, it can't step in increments of 0.04mm. It can only step in increments of 0.0375mm or 0.045mm. So for some layers your flow rate will be 11.1% too small and for other layers your flow rate will be 6.7% too much. The Z axis doesn't normally do microstepping (which would reduce the holding force necessary to keep the bed in place).

To be clear, what you're asking doesn't increase or reduce the capabilities of Cura. If you want the layer height to vary in the range of 0.04 to 0.2mm you would currently use a layer height of 0.12mm and a variance of 0.08mm. With your suggested change, you would use a layer height of 0.2mm and a variance of 0.16mm. We've also had suggestions saying that Layer Height should be the minimum layer height: https://github.com/Ultimaker/Cura/issues/7770 With this, you'd set your Layer Height setting to 0.04mm and the variance to 0.16mm to get the same effect. Or that we should have both a Maximum and a Minimum layer height and the normal Layer Height setting shouldn't be used any more: https://github.com/Ultimaker/Cura/issues/2895 With this, you'd set your minimum layer height to 0.04mm and your maximum layer height to 0.2mm to get the same effect. All of these suggestions have the same effect: You can specify a range of possible layer heights. The only difference is in how it's presented to the user. In that regard I think having both a max and a min would be the easiest to understand, at least for an advanced/expert user. Perhaps the current situation is maybe easier to understand for a novice but the novice user probably won't use Adaptive Layers anyway unless there is a profile built-in for it. However we're also constrained by the fact that profiles are optimised for a certain layer height and a lot of settings can't be adjusted to scale with the layer height. Existing profiles are made for a certain layer height (say 0.2mm) so if you want a variance of 0.04mm to 0.2mm you're going to be printing at e.g. way to high temperatures to be extruding 0.04mm layers, and you'll burn your filament. So the best we can do is to use the profile meant for 0.12mm (or whatever is closest) and use that for the range of 0.04mm to 0.2mm. It'll be too hot for the 0.04mm and too cold for the 0.2mm, but it'll be better overall. So letting the layer height be the median of the range is important in order for the profiles to be correct, and you'll get a much better print out of it.

Indeed if you have 0.2mm layer height with 0.16mm maximum variation, it will vary between 0.04mm and 0.36mm. If instead you'd like it to vary between 0.04mm and 0.2mm, you should set the layer height to 0.12mm, and the maximum variation to 0.08mm. We've chosen to hold the current layer height as median on purpose, because all of the other settings will have been optimised for this median layer height when you enable it. It will then stay closer to this optimised/preferred layer height overall. It's easier to transition to Adaptive Layers that way.

Tree support is moved to the support section for the next release. The other experimental settings are there for a reason: We know significant issues with (most of) them. For instance the Adaptive Layers feature messes up all of the Z distances because CuraEngine normally calculates Z distances by counting layers. So the Support Z Distance is too small or too large, skin is too thick or too thin, etc. Those two settings you mention, Spaghetti Infill and Wire Printing, are actually also the two features that I proposed to delete recently, to reduce maintenance burden and confusion of the user. Spaghetti Infill has now been deleted for the 4.7 release upcoming. Wire printing not (yet).

Yeah I'll be a bit more thorough, also including 2.3.1 which was the latest 32-bit release: http://dulek.net/work/Cura-15.04.06.exe http://dulek.net/work/Cura-15.04.06-Darwin.dmg http://dulek.net/work/Cura-15.04.06-Linux_amd64.deb http://dulek.net/work/Cura-15.04.06-Linux_i386.deb http://dulek.net/work/Cura-2.3.1-win32.exe http://dulek.net/work/Cura-2.3.1-win64.exe http://dulek.net/work/Cura-2.3.1-Darwin.dmg http://dulek.net/work/Cura-2.3.1.AppImage

In case GR5's download ever goes down, I've made a mirror here too: http://dulek.net/work/Ultimaker_Cura-15.04.06.exe

The setExtraOverhang function creates a buffer on which to draw. Think like MS Paint. You're actually drawing just with a black pen on a white canvas. While you're drawing (the mouse is holding down) Cura's rendering system will draw everything that's black on that buffer in red if it's on the object. When you let go of the mouse, Cura will look up all of the black pixels from that buffer and spray tiny cubes on your object by drawing rays from the camera through the centres of those pixels. I don't think it should be replaced, really, although it would need to be moved to the correct plug-in somehow. The bear on the road I was facing was to make the overhang erasable again. I think it would need to be implemented through some unique ID for each cube which gets translated to a colour on the render buffer, so that we can look up which cubes to delete from the scene by looking at which colours are within a certain circle in that render buffer. On top of that, you'd want to also erase the original overhang that Cura normally already renders red, although that may be considered optional. Aside from that, I was also just changing the theme to make support meshes render red as if they are overhang on your model. That would also affect normal support meshes that the user places, which is not nice. This is probably not so difficult to fix in Cura but may be difficult from a plug-in. The plug-in was created during a research sprint several years ago, where we got 2 weeks to develop something which we thought was progressive. I had this proof of concept, but due to lack of research time on Ultimaker's planning I was never able to finish it. Well, turns out I was indeed progressive; 2 years ahead of Slic3r PE, which just added a similar feature to their latest release (and did manage to finish it).