Jump to content
Ultimaker Community of 3D Printing Experts
  • Sign Up


Team Ultimaker
  • Content Count

  • Joined

  • Last visited

Community Reputation

15 Good

Personal Information

  • Country
  • Industry
    R&D / Exploration

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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).
  2. 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.
  3. 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.
  4. @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.
  5. Yes, you can download the 4.2-BETA here. Otherwise wait +- two weeks before 4.2 proper is released.
  6. 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!
  7. 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.
  8. @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.
  9. @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.
  10. 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.)
  11. 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?
  12. 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.
  13. @ultradryan If it's this issue, the upcoming 4.2 release will fix this.
  14. 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.
  • Create New...