Cura 3.3.1 Takes longer to print than Cura 3.2.1

[Lesorton]

3.3.1

Windows 7 Pro 64 bit

Folger FT5

* I used the same part and settings in Cura 3.3.1 and Cura 3.2.1*

According to Cura 3.3.1 the print will take an hour longer

*The print times should be more or less equal, or better for the later version
Top-Bezel-Percy-30-April-2018.curaproject.3mf.zip
*

Additional Information

[modem7]

You probably need to provide some useful information. Settings, examples etc

[Ellecross]

I was going to say the same thing. Thanks @modem7.

@Lesorton you can also attach a saved project file from 3.2.1 so it will be easier. :)

[Lesorton]

I had put the info in, just in the wrong place, sorry, first time I have used this.

[diegopradogesto]

Confirmed, around 8 hours in 3.2.1 and 9 hours in 3.3.
I have investigated deeply and it is because of the combing. In 3.3 we introduced an "improvement" in the calculation of the combing moves that speeds up a little bit in the majority of models. Maybe your model is a counterexample.
We have analysed this feature and it works really well for most of the models and so we will no address your particular case since it seems to be a model dependent case.
Maybe @smartavionics has something to say.
I just post both project files if we want to go back into it later:

• 3.3.1: Top-Bezel-Percy-30-April-2018.curaproject.3mf.zip
• 3.2.1: FTFT5_Top-Bezel-Percy-30-April-2018_v3.2.1.curaproject.3mf.zip

[smartavionics]

Hi @diegopradogesto , I've looked at that and the difference is entirely accounted by the fact that 3.3 is doing a lot more travel than 3.2. As you say, it's related to the combing - I will look into this further and find the changes that have made the difference.

Furthermore, the mods to the combing code recently done by @jackha increase the print time again so we need to get to the bottom of this.

[smartavionics]

Incidentally, those projects are not using the wall order optimization which does save a fair bit of time if enabled.

[Lesorton]

I have added Wall order optimization and it cut the time done to 8 hr 44 mins in 3.3.1.
Thanks for that tip.

[smartavionics]

i have made some progress on this in that I have identified that the major slowdown occurred when the new zigzag infill changes were merged - after those changes, the travel paths used for infill got a lot longer which is why it's so slow. Still trying to understand exactly what's happened, I'll keep working on this...

[smartavionics]

I now know which commit is causing the slow down but I don't yet understand why! Continuing to scratch head...

[smartavionics]

I've fixed it, see https://github.com/Ultimaker/CuraEngine/pull/759

This took far longer to find than it should have done, proof that I'm getting old and slow witted.

[diegopradogesto]

Nice, @smartavionics . I think you were really quick on that. I will create the related ticket in our board to analyse your PR.

[diegopradogesto]

@jackha already created a ticket: CURA-5333

[smartavionics]

Did you know that all bugs are trivial - once you have found them!

[jackha]

It's all about the journey ^^

[diegopradogesto]

I will close this since it was successfully fixed by @smartavionics . It's now being tested by our QA team.
Thanks again!

[Lesorton]

Thanks everyone for sorting this out, and so quickly.

[gr5]

What version of Cura will this PR make it into? It's really slowing down most of my prints. It seems to go the wrong way around so often it's crazy. Here is a 6 second unlisted video showing the problem.
https://youtu.be/D6L6U9ZFsz8

I did a 2 day print on the S5 and it was doing a lot of this as well (going typically 40cm around to another spot that was only 1cm away).

[ChrisTerBeke]

Once a PR is merged in master, it will always appear in the first version released after that (except for when there is already a version branch when we're close to release). In this case, it will be 3.4.

[smartavionics]

It's a very bad bug, there really should have been a 3.3.2 that incorporated the fix.

[ChrisTerBeke]

Making a release takes quite a bit of effort (building, QA, system testing, signing for Windows, and so on). We hardly make releases to fix just one bug, especially because the time between releases is usually less than 10 weeks.

[smartavionics]

Making a release takes quite a bit of effort (building, QA, system testing, signing for Windows, and so on). We hardly make releases to fix just one bug, especially because the time between releases is usually less than 10 weeks.

And there you have as strong an argument as possibly could be made for having an LTS branch (or stable branch, or whatever it's called) alongside the development branch which is currently used for all releases. This appalling regression would have been spotted long before it made it into a stable release. As it is now, everybody has to either stick with 3.2.1 or not use combing for a few months.

[ChrisTerBeke]

I think an LTS branch would be out of sync with master super fast (as in a matter of days). Back-porting bug fixes to this branch would take a lot of effort because of this. We already have issues sometimes with feature branches that are a few days or weeks old. In the end this would slow down development and getting the bug fixes out there.

[smartavionics]

I don't agree - there's SW out there that is far more complex than Cura that uses a multi-branch release regime quite successfully. The current manner in which releases are made in Cura is, IMHO, one of the main reasons that users have poor experiences. All the programmers who work on Cura are fallible (obviously, I include myself) and we all make mistakes. The current release regime is not sufficiently robust to stop those mistakes having a big impact on the users' experience. I cannot see how it is going to improve without change.

[ChrisTerBeke]

Oh, I agree the process could be improved, I just don't think an LTS branch (or an LTS in general) is the way to go. We get positive feedback on our aggressive release cycle (as opposed to Simplify3D which only releases like once a year).

I'm using the following strategies quite successfully in other projects within Ultimaker:

• Create a 'develop' branch for all daily development.
• Lock master & develop branches for direct committing, only PRs are allowed.
• Enforce code review and automated testing (CI) on all PRs (requires sufficient code coverage to be meaningful though).
• Merge 'develop' to master once in a while when develop has proven to be stable (tested from automated daily builds by QA).

I'd love to see this (or a similar) branching model come to Cura, but the majority of devs in the core team don't agree I guess (note: I'm not in the Cura core team atm).

[smartavionics]

You hit the nail on the head, unless the people sign up for a new regime, it's not going to work. What I really can't understand is how the people who make the decisions can be satisfied with the current state of affairs. Anyway, that's enough said, for now.

[Dim3nsioneer]

+10 for a bugfix release 3.3.2. Please release this bug fix a.s.a.p. It's essential for the S5. And very annoying for all other machines. If the fix is fine (which I have no doubt considering who it comes from), i.e. if you tested it, please make it happen.

[gr5]

I'm a programmer. At work we use GIT. So do you guys. Git has a lot of features you aren't taking advantage of. Programmers are scared to use them at first but once you've used it a while you wonder why you didn't always do it that way. The obvious way to do what we are talking about here is that when you find a bug that exists in the release that the public have access to (the "latest" release) you create a branch from the version that you released and you put your edits in that old branch and then merge that fix into mater. That way the fix (not new features!) get into a bug-fix branch which is out of sync with the new-feature or master branch. I've described this very simply. I could explain in more detail with actual git commands and views of git branches to see what I'm talking about if you want.

[gr5]

But basically - you do NOT have to do the bug fix twice. You do it once on the older branch and then merge that older branch into master. Git handles this very well!

[gr5]

In rare cases (surprisingly rare) the same line of code was involved in the bug that was also involved in a new feature. in those very rare cases (less than 1% of bug fixes for the company I work for) then yes, indeed, it sucks a bit because you are basically doing the same fix twice.

[ChrisTerBeke]

@gr5 I'm very well aware of what Git can and cannot do, I'm using it professionally for over 7 years now. And not the desktop UIs, but the hardcore command line version.

I think what you're trying to explain in your 1st comment is GitFlow?

The problem though is when branches divert too much, a change in one branch cannot be automatically or easily merged into another, you'd get conflicts. This happens a lot with Cura as it's under active and fast development by many people at the same time. That might be because of how Cura's code is set up (a lot of lengthy classes and methods), the fact that we're doing quite some refactoring lately, or something else entirely, but that's just how it is at the moment (from hands-on experience of working in the team). It's also true that a better branching model can fix some of these conflicts.

Again, I'd be all for this, but others in the team are not. Had this conversation a dozen times, and I don't see it changing anytime soon.

[gr5]

FYI - I hear lots of complaints about this - it's the main reason I often go back to cura 15.x despite features I really love (like initial layer horizontal expansion) in Cura 3.x. This particular bug is relatively minor but still annoys a lot of people. The PR could have been pulled into an older version of cura. I know - there is no process to create and test a single-bug-fix "older" version of cura but there should be.

[ChrisTerBeke]

It could technically be pulled into an older version, but Ultimaker would still need to go through the release process of such an updated, older version, as only having it from source in that version branch wouldn't do much for the normal users. This release process, as I indicated before, is not just simply making a build (if that even works on the older version as our dependencies in the build system also change), but having to QA, system test and release it. We only do this with extreme bugs that prevent total usage of Cura (like 3.2.1 and 3.3.1), but it's definitely not something we'd like to make a habit.

[gr5]

I know - there is no process to create and test a...
but having to QA, system test and release it.

I understand that QA is part of the process. I understand the process isn't simple. One shouldn't have to do as thorough a QA on a bug-fix release as a normal new release. Certainly when one line of code is changed related to combing, one shouldn't have to retest 200 different profiles.

but it's definitely not something we'd like to make a habit.

Here is the crux of the matter. This is the great disagreement. It should be a common thing - to make a bug fix release. It should be expected. If there is no bug fix version management should say "why not?" Are we too busy to make it? These should be just as important. It should be part of overall goals. It should be one of the key metrics. I mean if there is a "new features" metric then there should be a post-release bug fixes metric or something. The point is there needs to be motivation by everyone from management to qa and developers to come out with versions of Cura that are bug-fix only.

This is to stop the seemingly never ending sequence of every single release fixing one bug but introducing another one.

[Ghostkeeper]

For some statistics, 3.4 currently contains 145 bug fixes over 3.3. As in, actual tickets that people reported for us and filled in a bug template for. This is mostly a bugfix release. We continuously fix bugs. We don't want to put them in 3.3.1 releases as well because that means that we need to make the bug fixes on an outdated branch (which is either "3.3" using the cactus branching model or "stable" on the other) and then pull those into a modern branch which will have undergone some refactors.

We do make patch releases if we find a bug that is important enough. Important bugs are typically those that block the workflow of users. In this case the performance of the printer was reduced for a (very) few models, or it would have been found by our QA and integration testing teams. We'd like to avoid going through the process of releasing again then.

[smartavionics]

In this case the performance of the printer was reduced for a (very) few models.

That is simply not true, the bug would have affected a significant number of models. You're not fooling anyone, you know.

[gr5]

We don't want to put them in 3.3.1 releases as well because that means that we need to make the bug fixes on an outdated branch (which is either "3.3" using the cactus branching model or "stable" on the other) and then pull those into a modern branch which will have undergone some refactors.

See this is the basis of the disagreement. I think it's fine to create most (all?) of those bug fixes against 3.3.X (or 3.3.1 or 3.3_stable or whatever you want to call the patch release branch(es)) and then merge into master (or 3.4 or whatever you call it).

It sounds like you think you will get tons of merge conflicts but I suspect you will get very few. I suspect of the 145 bug fixes only 3% will have merge conflicts and most of those will be straightforward.

into a modern branch which will have undergone some refactors.
What kind of refactors? Are these refactors to prep the code for new features? Are these just making the code more readable? Or do you mean "undergone significant changes to add new features"?

[gr5]

I have to tell you, in the past, as a programmer, I was also reticent. Reluctant. Not looking forward to this work flow (fix bugs in older version then merge to master).

But after trying it I think you will realize it's not so bad.