burtoogle

Hello @pieri70, please make the gcode available so I can see what you are unhappy about - please note that there is a regression in 3.3 that can make combed travel "go the long way round" which can cause excessive travel moves (LOL, even worse than normal!)

Thinking more about @ahoeben's scheme above, why does it have to be any more complicated than introducing an LTS branch into all of the repos and then having UM commit to testing not only the normal (buggy!) releases but also testing the LTS bug fix releases which would occur when bugs have been found in the LTS release. When sufficient progress has been made on new features/improvements in the non-LTS branch (every 6 months or so), a new LTS release is scheduled. The non-LTS branch would go into feature-freeze and, say, 2 months later, could be pushed into the LTS branch with a reasonable degree of confidence (assuming the community stepped up and helped with the testing).

Hmm, don't understand that, perhaps @ahoeben can help?

What I do when it is difficult to click on the underside is simply to click on the side wall of the part and then use the move tool to quickly move the cube to where I want.

I know of 3 regressions in 3.3 that were not in 3.2. Stuff that used to work but currently doesn't. This should not happen.

Hi @ahoeben, that's a nice summary of how it could be (dream on Mark, dream on!)

The numbers are used cyclicly so in my example of [ 0, 60, 120 ] the first layer would have lines drawn in a N-S direction, the second layer would have lines drawn in a NEE-SWW direction and the third layer would have lines drawn in a SEE-NWW direction and then the sequence would repeat. [0, 180] would actually print all lines in a N-S direction as the angles are used modulus 180 so 0 and 180 both give 0.

So put some in like this: [ 0, 60, 120 ] (or whatever).

No, top/bottom aren't walls, the're top/bottom (aka skin). The top/bottom can have different line width and speed to the walls.

Hi @thopiekar, yes, having the -next branches would be good because then anyone could see (and, ideally, build) what is coming up in the future. Your scheme for auto-building test releases from bug fix branches that are subsequently merged if the users confirm success is interesting but, perhaps, it doesn't really need that much infrastructure. If fixes are merged into the -next branches and the auto-builds (linux/mac/win) of those branches are always available for testing then it would achieve a similar aim. I'm sure a workable scheme could be devised if UM have the will to do it. There are so many regressions appearing in Cura at the moment, something has to be done!

Issue raised -> https://github.com/Ultimaker/Cura/issues/3806

I discovered an interesting thing tonight. I loaded simple_vase.STL and the file name in the lower right corner was empty - I twigged that this was down to the upper case file extension and so renamed the file to simple_vase.stl and got the file name appearing as expected - is this just a Linux thing? Anyway, I shall post an issue on github.

Really? To me, they appear as two very distinct groups. No, I haven't yet given it much thought but off the top of my head I would probably favour LTS releases say, every 6 months. Once released, they would only have essential bugs fixed as sub-releases with no new features. Development releases could continue at whatever rate is manageable but there would need to be a cut-off say, 2 months before the next LTS release where only bug fixes and polishing would be allowed. All users would need to be encouraged to try a test release within, say, 1 month of the LTS release. A very important part of the testing would be to ensure that profiles, etc. from one LTS release would be acceptable to the next LTS release. There would need to be strict enforcement of cut-off dates and other deadlines but I think once people get used to the regime, it could work very well. Personally, I would much rather any contribution of mine was tested by myself, the Cura devs and members of the community for at least two months before being unleashed on the wider world. A regime such as described above would require, at most, 3 major branches in the repos. The LTS branch and the branches for the next two releases. You would need two because once the next LTS branch is in feature-freeze, any new features/major changes would need to be on another branch. So not much different from what is done now, really. Just a little bit more relaxed!

I don't doubt that the time/effort required to move to an LTS (or other suitable regime) would be substantial but I think the payoff would also be substantial. Think of it as an investment for the future. As I don't use the normal Cura releases and can work around most problems that arise, I am personally not upset by the bugs so, really, my concern is for others who are not able or willing to build the software themselves. And why should they have to build it themselves just to workaround a serious problem that wasn't there in the previous release? Bug reporting in Cura is already fairly easy, either people come here to the forum or the more technical types go to github and open an issue. But getting new releases tested sufficiently is a very real problem because a lot of users obviously don't try the betas and then when the actual release comes along and they find a problem it's a bit late. As a contributor to Cura, I know only too well that the contributions that I make, no matter how much I test them, are possible sources of problems which won't get detected until the community gets their hands on the release. That is why all new code and major fixes that go into Cura need a much longer incubation period then they get right now and those in the community who are willing to try out new stuff should step up and give the betas a good testing because they are probably the most important people in the chain.

Hi @thopiekar, thanks for your input. I understand what you are saying but I think that a lot of Cura users would be happier if they knew that the major version (3.5, 3.6, etc.) they are using is only going to receive bug fixes (3.5.1, etc.) and, most importantly, will continue to receive those fixes until the next major version that is designated as "LTS" is released. Also, the users should have confidence that the next version that they may choose to upgrade too has received a decently long testing period. Months, not weeks or even days as it is at the moment. As you know, at the present time, bug fixes and new features are all rolled together in each release and bug fixes are never made available for previous releases. i.e. once 3.3 was released, there will never be a 3.2.2 (or whatever). Recent events have proven (once again) that the current release regime is highly unsatisfactory. I feel that unless UM gets to grip with this issue, they will, ultimately, suffer commercially due to lessening customer satisfaction and confidence.

OK, the speeds are similar so it's not that. Could you please post some gcode that you know has this problem and I will see if I can spot anything else that could make a difference.

Hi, what speeds are you using for the infill and the walls? Most extruders tend to underextrude as the speed increases so if you are printing the walls much faster than the infill then they will come out thinner.

OK, well I just loaded those two projects into the appropriate Cura versions and the total time is slightly less for 3.3. One has more travel time but less retraction time than the other. If you add the retraction and travel times together for each version of Cura, you will see that the results are very similar. I think the difference is simply how the time was added up?

Thanks for the project files. Are you sure this is for the same project as shown in your images above, the time and filament usage is completely different?

Hi @J3J3, if possible, please attach your project file so I can explore this for you, thanks!

Just printing one myself - using PETG, 0.3mm layers, retraction with z-hop, no combing (as it's PETG) - very little stringing observed. BTW support blocker really useful for quickly zapping support as shown below, thanks again @ahoeben!

Thanks for the .3mf. All I can suggest is maybe use some z-hop and also reduce the temperature if the filament is happy. That should reduce the stringing.

Could you please post your project file (.3mf) so that I can see exactly what you are describing - thanks.

Hello @Lemaru, I don't really have an answer for you just an observation. When you look at the lines that are used to print the chimney, you can see that one of the inner lines is very broken. This is due to the line overlap compensation which is trying to fit a line into a space that isn't wide enough for it. The overlap compensation has some problems and can often produce ugly crap like that. Unfortunately, apart from turning off the compensation, there's not much you can do. BTW, do you know what the resolution of your printer's extruder (in steps/mm) is? What type of printer is it?

Hi @varazir, in that example, the whole part is supported - what was being discussed there was the idea of using 100% fan when printing skin over support to help the support removal - it's not using bridging in that example. Yes, for a part like that, you could use the support blocker to remove some of the support away from the edges.