Jump to content
Ultimaker Community of 3D Printing Experts

nallath

Team Ultimaker
  • Content count

    2,690
  • Joined

  • Last visited

  • Days Won

    19

nallath last won the day on May 14

nallath had the most liked content!

Community Reputation

552 Excellent

1 Follower

About nallath

  • Birthday 01/01/2015

Personal Information

Recent Profile Visitors

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

  1. Yeah. We will keep this available. I'd like to think that this is why engineers like our product. If you want to, you can "open the hood" so to speak, in order to mess with the internals. This is why we only give errors for settings that we *know* are impossible or will break the hardware. Really improbable values will just net you a warning.
  2. Ah, I think we're at the meat of the discussion here. We try (and because we can't do it yet, often fail) to provide with settings that should make the model work. But as our algorithms are far from perfect, it could well be that it might be wrong. This is why we at least give people the option to tweak it. In the long run, this shouldn't be required. We try to do as little with the engine for exactly these reasons, but it just doesn't always pan out that way. The setting changes that we had to do between 15.04 and 2.3 are probably the most impactfully change (together with the multi-threading) and they were / are must have features. As for the cooking analogy; I'd like to see it like as "We give you some pointers, but if you want to put chocolate paste on pickles, be my guest."
  3. nallath

    Support Features

    That is the idea. Right now the UI is far from perfect, but it's better than it used to be.
  4. Simply speaking; The Cura Engine must do these things. The idea that there is a simple model that fits everything is false. The solution space is vast. Not only are we talking about differences between materials (PLA, ABS, CPE, PVA), inter material variation (Blue PLA vs metalic PLA), Machine variation (Which is it's own fied; Accelerations are different, has bowden tube, different behaviors, you name it), model variation, etc. The notion of oxxams razor is a nice one, but fairly naive. Compare this problem with making an autonomous car. If you're only writing software for a single instance thereof, you don't need a lot of exposed settings. All cars you make it for will have the same type of sensors, the same engine and the same interface. We made it really difficult for ourselves by not doing that. We made a bit of software that should work for *all* instances. So we need to have those settings (eg; Sensors are different, speeds are different, even interfaces are different). We could make it simpler. It would be doable for us, but the price would be destroying the possibility to use it for other machines. So there isn't just "one" model. There is perhaps one model that can "Get most models working for PLA on an Ultimaker". Those parameters won't work at all for a machine that has a direct drive or when printing with ABS. Also note; Only the frontend was redesigned. The engine is one continued process to get to this state. As for optimisations; Yes, we mostly focus on stuff that helps ultimaker. Makes sense as they pay me. We're already doing a lot of work that helps others, so we kind of have to draw the line somewhere. As for overfitting on models; We don't. We fully understand what overfitting is and why it's bad. I also disagree with the idea that there are so much hacks in the engine. Is that code the best maintained code out there? No. There are architectural mistakes we made there. But i don't believe that there is a simpler model that will have the same results. The creation of models with different speeds is intentional. I've also seen vast improvements of g-code since the legacy version especially when using dual extrusion (and of course; When using ultimakers, because we provide the right settings). Now, I do believe that profiles can be smarter. Changing a setting is an action; It makes property X of a print better and property Y worse. But with 500 ish settings, that is a lot of knowhow to have in the head of a user (and thus is unreasonable). But users perform actions because they have an intent. If we can somehow capture intent and transform them into actions we can get what we want.
  5. nallath

    Easily Implemented Profile System Improvement

    Oh, the initial part won't be hard. But then there is also the whole upgrading & project loading that comes in to play. Some of out developers still go into shell shock at the moment you mention either one of them.
  6. nallath

    Easily Implemented Profile System Improvement

    The problem with making settings "grouped" like this, is that changing a setting can influence another. Take the following example; There are 3 settings; A, B, C Settings A's value = 1 Setting B's value = 2 Setting C's value = 3 if B == 2 else A The profile could do the following things; Only Change A, but this, by default has no effect on B. If you suddenly merge another profile that does change the value of setting B, the changed value of setting A does have an effect on C (which might not be known to the user). Other than that, i mostly see UX issues here. It's going to be hard to explain this to users.
  7. nallath

    Tool path planning in Cura

    If I were you, i'd check out the latest version of the engine. You're working on a version that is 5000(!!) commits behind master. Any changes you make to that version are very, very unlikely to be merged into master. I'm well aware of why solving the problem is important, but in all attempts i've seen so far, it took 5-10+ times as much slicing as time that was actually saved in printing. This might be interesting if you're optimising for production, but i think most people tend to print low volumes (and thus, this costs more time than it actually saves).
  8. nallath

    Easily Implemented Profile System Improvement

    I think you misunderstood what I'm saying. I'm saying that you can't make one profile that says "High quality" and a "ABS" one and add them together. You actually need a profile that is "High quality ABS". In the example that you state, how would you handle the situation where high quality would state a print temperature of 200 and the ABS profile would state one of 250 (This is of course a weird example, but situations like this do arise). It's not just about two numbers. Adjusting one setting is hardly ever possible. Take layer height for instance. If you *only* adjust that, you're going to have pretty poor quality, as others need to change with it. But not all of them need to change linearly, so predicting what they should be is rather hard (also; what do you do if one of the settings to change is an enum? Make a cut off point?) Right now we have the following system; For the UM3 we have 3 stacks (Extruder 1, extruder 2 and the global stack). Each of these stacks holds a number of so called "instance containers" with a "definition container" at the bottom. For the extruder stacks the order is: "user", "quality_changes", "quality", "material", "variant", "definition_changes", "extruder_definition". For the global stack it's "user", "quality_changes", "quality", "variant", "definition_changes", "definition". The basic principle we started of with was pretty simple. You just ask the top of the stack (eg; extruder) what the value of a setting is. The stack then asks each of it's containers (in order) what the value is. If the instance container doesn't know it, it moves down. The definition container in the global_stack has all the default values, so if no-one answers, that value is used. But then we quickly ran into a bunch of issues; What to do if a setting that is only globally settable can be influenced by the material (eg; Bed temperature; You can only have temperature, but materials influence this). We added a thing called "resolve" that then accepts values from both stacks (thus breaking the notion that questions only flow down stream) and resolves them in some way. We also found that in some cases, the value for a setting with PLA High quality needed to be different for ABS high quality, but only in the high quality of *those* two materials. You can't put them in a "generic" high_quality, as that would influence everyone and it also can't be placed into either of the materials (as that would influence the other qualities. We managed to fix this by introducing a "quality per material", which means that when selecting the right profile for quality, it first searches for a quality by type, material and variant (eg; print-core used) and then starts dropping those requirements if it can't find it (so it should end up with generic if no specific profiles are defined). So what happens if a user enters settings in Cura? All settings that are changed, get added to the "user" container, depending if they are "settable_per_extruder" or not. If a setting is not settable per extruder, they get parked in the "user" container in the global stack. If a user presses save, these settings get "merged" down one conainer (into the "quality_changes" container). This container is loosly linked to the quality container, but only by *type*. This means that if a user changes the material, the quality container of a stack changes, but it's type (eg; normal) stays the same (and thus, the quality changes also stay there). In some cases we have functions defined for settings, which get evaluated every time one of the settings it depends on changes. But this is also a can of frigging worms, because it can't "just" use the value, as it should first use the resolve value and only if this is not set, should it use the value (and then special case that stuff if the "user" and "quality_changes" container in global has the setting set, as that means the user wants to override it)
  9. nallath

    Easily Implemented Profile System Improvement

    You're both right and wrong 😉 The problem here is that you assume that quality has no interaction with material, but this is (unfortunately) not the case. The ABS normal profile is different from the PLA normal profile. It's actually so different that merely "stacking" quality + material together does not fully describe what needs to be done. Originally we started of with the exact approach you suggest, but we quickly had to diverge from that strategy as it simply wasn't enough.
  10. nallath

    Tool path planning in Cura

    I don't know the Cura Engine code that well, so I can't give you that much feedback. We "solve" the TSP by just attempting a best effort. We by no means even attempt to "truely" solve the problem. A lot of the improvements are due to various heuristics that we know work in our case (or work in most cases).
  11. nallath

    Cura stability - the argument for an LTS release cycle

    Also; We have 2 full time testers on Cura and 4-5 on system testing. I think you guys are severely underestimating the effort it will take to put more testing into a build.
  12. nallath

    Cura stability - the argument for an LTS release cycle

    I don't find that in the least bit exceptional. I think it rather proves why a strategy of open sourcing software works; you get bugs fixed faster & better.
  13. nallath

    Estimated Time Algorithm

    It doesn't make assumptions; It uses the exact values the machine definition provides. In the case of Ultimaker, we set those to the correct values. The quality of contributed definitions can vary, so they quite often have (blatantly) wrong acceleration rates.
  14. nallath

    YouMagine covered in spam

    I've prodded a few people in MT about this. It's going to get some attention.
  15. nallath

    problem with sliding 3D assemblies

    Find an online model fixer. You model is invalid, which makes Cura interpret the mesh different from how you would expect it.
×

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!