nallath

It's even better; We will also start adding charts (eg; donut charts to show configuration, bar charts for material type usage, etc)

You see the list of all printers / configurations connected to the Cura Connect instance you are connected with, not all printers on the network.

It's quite intuitive; The material is not "tight" in the bowden tube. It's a bit like a breaking cable from the bike. If you put pressure on it, it's first moving the bowden tube, putting pressure on it. Only when that pressure is maxed will the material start to move. The same happens if you stop moving. This effect is called hysteresis. The main advantage of direct control is, as the name implies, direct control of whatever is going on. The closer you can apply influence to what you want to do, the easier it tends to be to control. The major disadvantage of direct control is that the head tends to be much heavier, as it needs to have an extra motor on it. This means that you need to decrease speed / acceleration in order to prevent artifacts (ringing)

I make quality profiles (aka; not quality_changes, but the "real' qualities that you need to add by hand). As for Ultimaker machines, i hardly ever change recommended settings. Even after 5+ years of working with Ultimaker printers, our materials & processing team is far better at making good profiles than I am. I'd also would never print out papers with profiles. It's not a good way to back up profiles at all. Cura already is capable of being backed up without having to resort to paper.

If you're only interested in the changes, you're looking for the "quality_changes" & "user" profiles

It depends if a machine has a bowden tube. Machines that don't have direct drives (aka; Ultimakers) tend to suffer more pressure being built up. So yeah, the default parameters are not designed for other machines, they are explicitly there for bowden style machines.

The stuff that an OS does is so complex and big that there is no single person that understands what every bit of it is actually doing. So there *is* no turning back to that time. That being said; Linux does get you a long way with regards being able to tune / adapt features.

I have a clone (identical twin) and even he does different stuff ?

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.

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."

That is the idea. Right now the UI is far from perfect, but it's better than it used to be.

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.

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.

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.

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).

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)

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.

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).

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.

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.

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.

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

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

/var/spool/cluster/ For every file that it has, a folder is created (named after the UUID of the print). That folder contains the .gcode / .gcode.gz or .ufp file. Note that once a print is done it gets deleted. In the 5.0 release, we've added an option that stores the last 10 completed prints so it can be re-printed.

Are the surfaces thinner than your nozzle width and how does the model look in x-ray view?