Jump to content

rburema

Member
  • Content Count

    50
  • Joined

  • Last visited

Community Reputation

10 Good

About rburema

  • Birthday 06/02/1983

Personal Information

  • Field of Work
    R&D / Exploration
  • Country
    NL
  • 3D printer
    Ultimaker 3

Recent Profile Visitors

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

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

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!