rburema

I think the 2015 should be removed, it's been a long time since we actually build with that. From the article: Microsoft Visual Studio 2019 (recommended install) When I tried to build with 2022 I had therefore to install MSVC v142 -- 2019 which you have unchecked.

The fix that @burtoogle made for the OP has been deemed low risk enough that we'll try to get it in 4.7, a beta of which should be out relatively shortly.

We have made the explanation a little more clear for 4.7 (not out yet), see this topic: https://github.com/Ultimaker/Cura/issues/7592 The new explanation is a little longer, and mentions the switched-to profile. The column names are also changed from 'Default'/'Customized' to the switched-to profile name and 'Current Changes'. If you want to save the changes (to a new profile), you can select 'Create Profile From Current Settings/Overrides ...' in the drop-down menu, before changing (there is another menu-item for updating one you made earlier).

Not directly, but something like this can be done. It's a bit cumbersome though. You can get the face-id of the face under a screen-position with SelectionPass.getFaceIdAtPosition, then work out the intended object, then get the normal from the/that mesh. (For example as happens in SelectionTool._pixelSelection) As an alternative; if your plugin has it's own stage (like next to Prepare, Preview, Monitor) then I think it becomes an option to write your own RenderPass and shader to get the normal out that way.

Sadly this is the stair-stepping again (somehow). I think we should look into rethinking that whole piece of code, given the amount of trouble it causes us and how hard it is to debug. It does, most of the time, give a nice workaround though: Just put 'support stair step height' to 0.0 mm and the missing support will appear.

@Reverse_Engineer The 'action' button (the big blue one that says slice) changes to a print-over-network/save-to-USB/save-to-file button, this can be changed with the arrow next to it once sliced. Alternatively, after slicing, select 'Export...' and select '*.gcode' in the 'Save as type:' dropdown in the save-window. As a last resort/workaround (for most printers), unzip the .3mf and find the .gcode file within.

Yes, you can download the 4.2-BETA here. Otherwise wait +- two weeks before 4.2 proper is released.

Confirmed this behaviour in version 4.1 for the UM5 file at least. I also tried to slice it in the 4.2-BETA (I remember something we changed for a bugfix) which _does_ seem to have the first layer support 🙂 ... so, it seems unlikely the problem was on your end!

If you want relatively easy to remove supports, you might want to try the (sadly still experimental) Tree-support: Disable normal support, and enable 'Tree Support' in the experimental tab (you might need 'show all settings' first). It'll take a longer time to slice (but not nescesarily print), but most of the time its worth it. Other than that, it's a bit of a trade-off between what'll actually print well and your particular model.

@Astrofreak85 We did pull in something that was previously available as a mod by one of our community members (the 'Creawesome' mod) that could have changed the Ender definitions, but I'm not sure those are the intended changes.

@andy3820 It's automatic.

@andy3820 While it isn't under any active development any more, we do support USB connections for at least some printers. The USB detection may or may not work for certain models, but it is there.

The only part that is really inconsistent is the Line Type - Color Scheme legend (also the Skin Overlap settings should be in the Shell catagory I guess.) Concerning the settings (not the Line Type as shown in Preview): - Shell is all outer parts / (near the) outside of the model. - Walls are the vertical (enough) parts of the shell, and thus part of the shell. (They're red and green in the preview.) - Skin is the horizontal parts of the shell, and also part of it. Not just the top, but also the bottom! Yes, this also means that the lowest layer of a bridge is skin. This also (sort of) answers the questions (together with the hover-over explanations), Shell is the catagory, there the wall-overlap settings are for walls overlapping _each other_. In the Infill catagory, there is the infill overlap settings, which handles the overlap between the infill and the walls. Then there's (also in the Infill catagory, which it probably shouldn't) the skin overlap settings, which handle overlap between wall and skin (since the walls take precendence over skin, unless you set the nr. of walls to 0, there's going to be walls on each layer there's skin as well). There is a default skin overlap to make the shell look a bit better, but that's normally not needed for the infill (though 'looking better' is not the only reason you could want overlap). As an aside, in the 'Color Scheme' legend in the Line Type menu of the Preview screen: - It says 'Shell' here, but it's really just the outer wall that's red. - It says only top/bottom and infill is yellow (infill will be orange from 4.2 onwards b.t.w. ... or more orange I sould say since it already was a _slightly_ different shade of yellow. Also support interface will be darker blue than the rest of support.) but due to technical reasons, wall-filling (not to be confused with infill) is also yellow. Wall filling is used when a wall can not be made thicker, and there's still a gap to the next wall that should also be part of the wall and not infill. P.S. What is 'outside' or 'close to outside' can be a bit counterintuitive sometimes though. There are cases where skin shows up in what can be argued is the middle of the model. Let's not get into that since it requires me to make drawings, and this is already taking quite long. P.P.S.: Thanks for the question, it revealed two hopefully easy to fix issues. (Unless there are _reasons_ I'm unaware of, which tends to happen as well.)

Concerning the height: What happens there is that the height of the layer(s) doesn't change the model, it only changes where the layer intersects the model. The (1st) layer is still reduced in height, but the next layer will start sooner. Setting the number of top/bottom layers to 0 should have worked, and works if I try to reproduce it here. Also you expect there to be walls on the 0th/1st layer as wel, even if there is Could yout attach the saved project (Save As, not Export) so we can see what's going on? Ypu might need to zip it to attach it here. Alternatively, depending on what you mean by "don't print very well" (but are otherwise OK with the bottom skin being there) there are different things you could try. Do those lines not adhere well to the build plate (in which case you could try adhesion methods such as printing a brim or sticking glue to the buildplate) or is there something else going on?

Cura (as a whole) is open source, the component that does the slicing is called CuraEngine, the relevant portion of the docs that explains this can be found here. This is only a very short exaplanation, and valid for the normal support, but we also have the experimental tree-support. Other slicers have different methods of generating support.

@ultradryan If it's this issue, the upcoming 4.2 release will fix this.

How people/users experience things is an important component. We're lucky to have an UXer on the team as well. As for the PR: We've now made a ticket out of it, so we'll get to it eventually. And like we mention there, it's been on our wishlist 🙂 To other readers: the PR can be found here.

Hi @nubnubbud, We get PR's from out of the blue all the time, we decide if we want them and then reject or accept (or ask to rework, or do some ourselves, depending on the situation). So please submit! It will then take us a bit more than a day to get to your PR though, just to prepare you (it can take quite a long time in fact, since we're a bit backlogged...) That said, accessibility is a noble cause. Just last week I had a discussion about possibilities for colour-blindness adjustments with another dev. 🙂

Yes, you just move the executable to the Cura-folder. More importantly, I reply because a contributor has decided to clean up the Windows build instructions, and we've added them to the wiki over here. (A small note is that these instructions work for VS2015 and possibly VS2019, but VS2017 has a regression that requires some extra work to get it done.)

I could have sworn I saw one of the other dev's commenting on my change, but I see that hasn't happend yet: Long story short, there was a reason we started cutting it off at 3: The engine only works with (integer) microns, so x.xxx millimeter is the best precision you're going to get out of it. Anything else would just (in effect) deceive the user. Therefore, I've had to revert the change 😞 ... and this is why we usually make tickets 🙂

We're aware of this issue: It happens for most printers that don't have maximum z speed explicitly defined in their profile. What happens then is that we instruct the printer to go 'as fast as possible' ... meaning light speed. This confuses a lot of printers (moving the extruder at relativistic speeds is probably not within normal operating parameters...), which then either pauze or just stop, instead of just moving at the maximum speed they're capable of. The workaround is either to explicitly specify max z speed, manually change the profile, or disable z hopping. This will be fixed in 4.2

Allright, fair enough. I'll bring up the build-instruction clarity with the other dev's sometime soon.

It's not _just_ to babysit you, it's also nice for future reference, if anyone else stumbles on this thread 🙂 One of the reasons I didn't recommend this route in the first place is that the migration to our new system(s) isn't fully done yet (I don;t even know if the branch is already merged ... it should be), and the documentation might be out of sync with what we currently have. What you _could_ do, I suppose, is see what we did in the docker-files and replicate that without docker? That's a whole other rabbit-hole though...

Good point @burtoogle @nubnubbud Those repo's are here: https://github.com/Ultimaker/cura-build https://github.com/Ultimaker/cura-build-environment if you want to try it that way.

Yeah, Cura + CuraEngine is not exactly the easiest to build. We're ramping up our efforts with C.I. as well, so eventually people (at the very least on Linux) should just be able to use cura-build / cura-build-environment. The CuraEngine file should the one. The file-size difference is maybe becasue we optimize for speed, not size? I think you might be able to unpack an AppImage, then sneak it in, then repack it. See https://superuser.com/questions/1301583/how-can-i-extract-files-from-an-appimage for inspiration.