rburema

I think there are at least 3 different issues on display here, which is part of what creates the confusion. Like people already mentioned: Cura expects models themselves to be 'watertight'. (I think this is a reasonable requirement for anything working volumetrically, like a slicer.) This isn't really guaranteed out of the box by some modelling software. Cura will do its best nonetheless but might mess up even in seemingly simple cases when things aren't watertight. (Conversely, it might also largely succeed for what seems like a pigs breakfast of a model...) In the initial preview visualisation of Cura (so right after slicing, as opposed to re-loading in the gcode), there is a hard to track-down bug that sometimes occurs causing the appearance of missing layers. We have had the hardest luck reproducing this, even though we very occasionally see it ourselves, and thus have had no luck fixing this. (And as a visual only thing that doesn't actually mess up prints and mostly goes away on its own, it doesn't get a ton of priority...) -- A tell-tale sign is a should-be higher layer seemingly appearing on the build-plate though! Thirdly, there may or may not be an actual big with the slicing tolerance. (This is one of those waterbed features that's hard to balance in the sense that if you fix one thing, another is likely to regress...) Hence why it's still in experimental after all these years. (Or at least one of the things that actually has a good reason to still be in that category.) You can (apparently) fix the first issue by exporting and reimporting in Cura, in this case at least. You can see if the 2nd thing is an issue (if it keeps happening), by reloading the already sliced .gcode in Cura -- it uses a slightly different method of visualisation then (with some info missing), but it doesn't have the bug either. The last item is 'fixed' (well, workaround'ed) by setting the slicing tolerance to middle (as said).

If that doesn't work, please try 5.3.1, we fixed this problem (hopefully for good) in the patch. Disarm-timeout is back too -- it was disabled as it was mutually exclusive with an option to hold steppers on, that was properly hidden for 'griffin' flavour printers, that should not use it -- but then also enabled by default. You should already be able to download that one from Release UltiMaker Cura 5.3.1 · Ultimaker/Cura (github.com). (We're delaying the pop-up message/announce a bit, to give marketing time to adjust the 'official' website, which has become harder than in the past for some reason.)

That depends, altering the output of the engine on the spot where gcode is generated in the first place isn't possible at the moment via plugins, as the plugin system doesn't cover the engine (yet, and even then, it would probably lack the capability to go 'per layer'). A way to post-process gcode is way easier to add. You don't even have to write a full plugin for that, but 'just' have to add a python script to the already existing (bundled) post-processing plugin. That might get messy in it's own way (especially since a model might've different top-layers) but since we output when layers start, you mostly just want to alter the speeds, it should be possible. It would depend on the precise application how easy that would be.

Sorry, but I doubt this is a software issue (though it can be influenced by software), as this print looks almost textbook like one of the axis' slipping. Though you could try printing slower, to see if it then doesn't trigger the behaviour. As for why the bolt is ok: It seems to have lots of small, round shapes, which won't cause the printer-head (or any other axis) to build up the speed necessary to slip. Lastly, Cura 4.0.0 is from the start of 2019, so over 4 years old at this point. You'd be better of with 5.2.2 or the shortly upcoming 5.3.1 -- if the profile is still compatible at least. Looks like we have that profile out-of-the box now. Not sure why the company still requests you'd use 4.0.

If you continue with the manual solution, alter and save the file via notepad or notepad++ instead of word, then save it over the original file. Alternatively, you could also probably add a G29 either in a post-processing script (accessible from the plugins top bar menu in Cura), or even in the start gcode, in machine-settings (accessible via the printer/preferences).

Not as such no. There are the 'Top Surface Skin ___' settings (which are a bit separate of the `Top/Bottom` settings) but I don't think those affect speed or walls (as opposed to skin). I suppose what you could do is make a modifier mesh that only intersects the very top layer, and set those settings in the 'modify settings for overlap' side menu, but that can get tedious, especially if the model doesn't have all of its top on the same layer. If you're just after a better quality finish top-layer though, you could also look into ironing & iron only top layer.

Support interface thickness might be what you're after (and support interface needs to be enabled for that of course). As for whether it's wise I don't think I'd recommend it, although I haven't tried it. PVA is finnicky material, and might not adhere well to the other support material that you're using.

The 'Generic' materials are bundled with Cura, so you wouldn't see those in Marketplace. Well, more than just bundled, because so are the UM materials, and you can see those just fine in that spot, but the 'generic' ones are the bedrock everything else is based off of, and so are treated in special ways. (And for the other way around, when you don't see any materials in the dropdown that you installed, that might be because some materials are 1.75mm or 2.85mm only.)

Hi! What type of printer do you have, and what version of Cura Enterprise did you download? If you're an Enterprise user, you might (also) want to contact support: Contact Support (makerbot.com) (I know it says makerbot, we're still merging the sites. The 'support' part of the site runs on the old makerbot domain for now.)

I don't think this is related to the plugins if it's an engine slowdown. Does this happen with Cura 5.2.x as well for that laptop? Using only so little CPU (while it's slicing right?) is indeed odd, as the engine uses multi-threading for a lot of the sections. Is this happening with and without support on?

This is a know issue, and I think it's one of the things we fixed it in the (very) short upcoming patch release of 5.3.1: - Fixed a bug where part of the model would not have fuzzy skin

In general, for such problems, search for 'under-extrusion'. I'm not entirely sure what you mean here: Is it just the first layer and was this printed sideways, or is this through the entire model? If it's just the first layer, then there are a bunch of settings that only influence those. You can find those by searching for 'initial layer' in the custom settings. Otherwise, if the exact model came out fine before, then it's likely to be a hardware issue. For example, the material might be slipping when it's extruded.

The grey'd out borders indicate which part of the build-plate is unavailable to put a model on with the current slicing settings and printer. For example, most UltiMaker printers have clips to hold the bed, so those are grey'd out. Another reason why borders where grey'd out at least in previous versions, was brim-settings (so the brim wouldn't go over the edge of the buildplate). While that is now fixed elsewhere, there are still similar reasons as to why you might be seeing greyed out areas on the bp. In other words, if your glass plate has the exact same dimensions as your old plate, without any extra clips, you don't need to do anything. If your build-plate is smaller, and/or has clips, but you don't need the extra space, just go into the machine settings to make the dimensions of your build-plate into a smaller square. If, however, your glass-plate does have clips, but you _do_ want to print in-between the clips (because you need that bit of extra space), then it gets more complicated, as you'd have to make a new machine, or alter existing definitions. Lastly, if you're wondering why the build-plates of some machines look differently regardless (with logo's and models of the machines) -- you'd also need to create an entire machine definition manually for that.

I'm afraid that's hardcoded at the moment. # Initialize camera root = controller.getScene().getRoot() camera = Camera("3d", root) diagonal = self.getBuildVolume().getDiagonalSize() if diagonal < 1: #No printer added yet. Set a default camera distance for normal-sized printers. diagonal = 375 camera.setPosition(Vector(-80, 180, 700) * diagonal / 375) camera.lookAt(Vector(0, 0, 0)) controller.getScene().setActiveCamera("3d") The values fed to the `setPosition` function seem somewhat arbitrary, to create a view that would look 'dynamic' to a designer maybe. In theory, you'd probably be able to make a plugin to set the camera to a more canonical position on start-up.

Your second request is already possible: Just turn on 'Alternate Wall Directions' from the 'Experimental' settings. (If I understand your meaning correctly.) As for your first request; that would require a lot of rework in the engine and frontend. We're aware of the potential of handling settings that way, but, sorry to say, it's not likely that this feature will appear soon.

Thanks for posting this, I'm sure it'll help someone when they search for it. However; - It might be possible to do this from within 'vanilla' Cura with a bundled post-processing script, namely (multiple instances of) search-and-replace (one for each substitution). You can get to the post-processing scripts by the top-bar menu: Select 'Plugins' > 'Post Processing', and a window will pop-up. - The order of the S/T/.., etc. parameters for an M/G gcode line shouldn't matter. Though it appears that it does for your machine. Have you thought about reporting this to the manufacturer?

I don't have any experience with Enders, but since they use Marlin, G28-G29 combo as described should work. Is your firmware up-to-date?

What version of Cura are you using? Which printer was this sliced for? Did you change any of the settings?

@cdr-automatisierung What is happening exactly? Could you show the cura-logs? We might be able to diagnose the problem. @nickramsey It could be that you're running into this: - Fixed a bug where the machine definitions could not be updated This is a line in the changelog for the upcoming 5.3.1 patch, which will be out this week hopefully. (Which took a bit longer than patches in the past, due to issues with our translations.)

The rest of my team indicated that they think this is a fix we did for the upcoming 5.3.1 -- When testing from latest source I indeed can't reproduce this anymore. That version should (have) be(en) out ... already actually, but we've run into some translation related troubles. We still expect April though.

Hi! Dev here (Community manager is on holiday atm). Can confirm that this happens on our side as well. I've put it on the list of things to discuss with the team w.r.t. future fixes. It seems that the mechanism that saves the data is blocked somehow, the loading still works, that means that there is a workaround. If you change this frequently, then the following isn't much of a solution, but here it goes: You can still change it outside of Cura by manually adjusting the config file. Turn Cura off first to avoid potential confusion. It should be in %appdata%/cura/5.3/definition_changes (so probably something like C:\Users\U.Sername\AppData\Roaming\cura\5.3\definition_changes\awsomeprinter.inst.cfg or similar). In that file, make a new line that reads machine_gcode_flavor = Griffin (substitute the exact string in the dropdown menu you need to be selected). Save the file and it should work. If this causes trouble, don't reset, but close Cura and remove the line (and/or try again w.r.t. spelling errors and the like).

Lightning infill 'reacts to the surface'. Though it doesn't optimize for strength. As for being surprised... There are a lot of useful things we can and could do, of which this is but one. We are only a small team to serve the entire community, and partially dependant on what comes in as pull requests from that community. (Not saying we aren't interested, but we have a lot on our plate.)

First: We _really_ don't recommend the method CHEP is advocating here. Especially since we cache the definitions these days in an on disk database for faster loading. Further more, exchanging files between users may be compromised, since we expect the same definitions to be the same between the same versions of Cura. (... and we send some profile values along if a project is saved as a .3mf, so if you've opened an older file from before the edit via that method, I'm not sure what expected behaviour is then.) Instead, if you (aren't developing a new profile/for Cura and) want to change those definitions for a specific machine, instead of editing the existing machine (def.json), copy it to `<appdata>/cura/<version>/definitions/` (you may need to make the definitions folder and don't confuse it with definition_changes) -- Within the copied (and suitably renamed) file, rename the printer-defintion itself (change the value of the "name" key). So in essence, make a new machine. After all, this is the one of the purposes of this mechanism, to not open up files on printers that can't handle it (or have a different way of handling things). Don't forget to not just disable adhesion (in the recommended settings), but _also_ set it to 'None' (in the custom settings view). Otherwise skirt will still be printed, and will be added to the disallowed areas (which is a more general thing than the machine ones of course) -- The complexity of this last bit (how adhesion interacts with disallowed areas) will fortunately be largely solved with the upcoming 5.3.

We think this might be a 'not putting it in the right folder' issue rather than a 'real' security issue. If it is indeed the same problem, one of our IT people found a workaround: EDIT: Just want to add; the error is indeed on our side, and we hope to fix it in 5.1

Hm, I didn't _think_ we'd need pthread on Windows for the nmake bits (though mingw compiled stuff will need it). It might just be checking if the file exist though. (Since I also see you're in debug mode, but I don't think we ever build libnest2d in debug mode on Windows since it's mostly an external dependency.) Since you're building full Cura, including the engine though, you probably have at least the pthread header on your system though. Alternatively (depending on what you're trying to achieve), if neither switching to Release or including the pthread header works, you could also continue without py/libnest2d (for now). Cura won't be able to arrange stuff on the buildplate properly, but the rest should work.