burtoogle

Just the cura-themed parts, the preferences dialog appears to use the same size fonts as before.

Understood. However, a big problem with the PPA is that it is a snapshot of the development version of Cura so it is pretty much guaranteed to be unusable every once in a while due to bugs and inconsistences in the repos. If you can't use the appimage and the PPA cannot be relied on for production use, I guess your only option is to build Cura from source and then you will be in 100% control of what you are using. Building from source is not hard (not hard for Linux, that is, I don't know about the other platforms).

I have noticed that recently all the text in the Cura UI has increased in size by something like 50%. This is on a Linux screen: dimensions: 1920x1080 pixels (508x285 millimeters) resolution: 96x96 dots per inch For me, the text really doesn't need to be as big so it would be great to have a preference to scale the fonts.

Please answer the question, have you tried using the appimage which is the official release? If no, please try that. If yes, how did it fail? Logs, etc.

Ah, confusion - there is a new slider in the UI that adjusts the infill density but I think that @darkdvd is referring to the feature that allows you to move (aka slide) the infill WRT the part's origin. As I mentioned above, the work is done, it's in the master branch but it isn't in 3.0. It's out of my hands.

Hi, the infill offset feature is in the master branch but doesn't appear to be in 3.0. A Cura dev will need to answer the question as to why it isn't in 3.0.

Great, please ensure that the new beta includes the latest engine code as we squashed a bug in the wall ordering optimization code. Thanks.

So it is not possible for you to use the official release? The other alternative is to build the program from source.

Hi, I tried using octaprint on a RPI driving a Marlin Kossel over USB and it would always stutter when the number of segments was high (i.e. going round smooth corners). To be honest, I don't think USB and 3d printers is a good combination especially when the host is slow (like a RPI).

Well, yes, that's sad. But I don't think the PPA is an official release, it's just a snapshot of the development version that has been kindly provided by an individual. Have you tried using the official 2.7 release?

There has been some recent crashes with the PPA installation caused by the back end slicer version being out of sync WRT the UI version. Does it crash while loading Cura or when you ask it to slice? If the latter, then it's probably the problem with inconsistent software versions.

Thank you. Please keep testing so we can squash as many bugs as possible before 3.0 is released. We have already found one problem with the optimization that causes a crash when optimization and infill first options are both used together. Not all models trigger the crash.

But this does not happen automatically! Have same error with UM2 + profile normal Here is my log If you disable "Infill Before Walls" then it works. Yes, it does not happen automatically because it should work OK with infill before walls but due to a bug some models will trigger the crash. I have fixed the bug but it will take a while for the fix to make it into the master source and I do not know whether they will issue another beta with the fix in place.

As a workaround, turning off Infill Before Walls will avoid the crash.

Using the UM3 profile, I can get it to crash and I think I have found the problem. Just testing a solution now....

I can slice that no problem - what profile are you using please? Can you post the bit of the log file that shows the crash?

Cura 3 adds a new option in the Experimental section, Optimize Wall Printing Order. When enabled, it will try to print the walls using an order that reduces the amount of travel required. It does not affect the order in which infill or skin is printed. The benefit you will see obviously varies with the number of walls your part has and the number of holes in the part. The more walls and holes, the greater the benefit. I would be grateful if you could try out this feature and provide some feedback in this thread. Obviously, if a print suffers in quality when using this option it would be good to hear about that. Success stories too are welcome.

Hi. Thanks for the model, it loads fine into the current development version of Cura and the brim is around the outside as you would expect so I do not know what the problem was.

OK, understood, but that doesn't actually prove the model isn't flawed, can you post a link to the STL, please?

Hi, the next release of Cura adds a setting to choose either relative or absolute extrusion mode. By default, it will stay as absolute for all gcode flavours except RepRap which will be relative mode by default. Be aware that not all printer firmwares can cope with relative extrusion (the Ultimaker machines being an example!)

Hi, yes this can occur for at least two reasons: 1 - the bottom of the model isn't flat and so there's a gap underneath - if you move the model down to sink it into the build plate does the brim now go around the outside rather than under the model? 2 - the model is invalid - not much you can do about that apart from fix the model.

Hi shadowfiend, thanks for the offer but I know that as far as the combing is concerned there is much that could be done to improve the paths. It's really quite a task (I think) to make the combing optimal and I'm not going to take that on. I've tinkered with it and made some useful improvements but I don't have the time or energy to do more right now.

Also, according to freecad, the model is buggy.

Hi, I just tried slicing this with the current development code and it's fine. However, if I click on the object and slightly raise it above the build plate by setting Z to 0.2 then I see exactly the same result as you show above. Perhaps, your object isn't actually resting on the build plate?

I put some more time into this and have submitted PRs that improve various other things including the combing. Here's an example: Before: After: The travel time reduced from 11 to 9 minutes which is an 18% reduction and 2 minutes of less dribble!