Daid

Volume per second is definitely something that's in my head right now. As it's currently one of the most important parameters and not really shown anywhere in Cura.

Actually, it's funny that you mention that... want to know the history of Cura? Anyhow, handling of big models is something that has grown in importance a lot the past year. Before that if you said "I have 1 million polygons and I want to print this!" everyone would call you crazy. Machines and software is getting better and this starts to become possible. I have a few extreme models to test with. So I know there are a few problems that only pop up on big models. However, it's not actually the auto-slicing that is slowing you down, it's the boundary box calculations. The PinkUnicorn experimental code handles this a lot better, but I had to change a lot of this to work. (Details, this piece of code is currently a clusterfuck, and because of that it needs to do lots of math on the gui thread, blocking the gui)

Pretty sure this bug has been around for a long time. But with the fix for double clicking on files, it suddenly became more visible. http://software.ultimaker.com/Cura_closed_beta/ RC10 is up.

Can you show an example where this is happening? Because there are some conditions in the code to prevent insane amounts of combing when a quick retract would be faster.

Generating a lot more data right now, data of all settings (and it's taking very long time to process now) I do not have print time information. But that's interesting to add for future stats, as well as filament used.

I gave you exactly what you had before in the PronterfaceUI plugin. Except for the old speed controls, which was an ugly hack and I did not want to support anymore (added lots of complexity) and told us to learn how to code ourselves to get back what we had. There is "code" and "code". The complexity of changing the new dialog is quite low. And if you're not willing to put in some effort, then why should I? Note: Providing old versions for download is very important for me. So you can be sure that old versions will be available for features that I scrap. You're free to use whatever version you want. All the way back to 12.08

1) No. 2) Odd, never seen that behavior. How many polygons does the model have? 3) RC9 has improved on this a bit more, if you use plugins. (Also, the MacOS and Linux versions do use a 64bit python) If you're forgetting them, then most likely they are not that frustrating... (You do present a real challenge here. Asking for fixes without telling what the problem is. Maybe I should consult a mind reader)

Actually, in my experience, retracting on the first layer is usually bad, as it increases the chances you rip off the print. (note, my experience is mostly on tape) due to the fact that it leaves a tiny blob and that blob can be snagged with the nozzle. You could just disable combing and most likely get the result you are after.

Cura development isn't a democracy. It never was. You shall all bow to my will! WHUAHAHAHA. Anyhow, my opinion on this remains solid. No matter the outcome of a poll.

Ah, I see what's causing the bug now. It's updating the plugin panel from a different thread, which is not allowed. Easy fix. (I'll build a new RC)

Yes. Been sick. Just better now. About the UM2 firmware bugs. Yes, those crawled in there with some changes I did. Fixing them right now. Going to check the odd plugin tab behaviour right now. As that should not happen, and can really cause issues.

Cura does not really like single shell objects. The algorithms behind Cura where not really designed with single wall shells in mind. So that's why you run into problems like this. It's easier to model it as a single sold block and disable the infill and top/bottom to get the same result as you want.

I didn't remove it. It's just the same as it's always been. UltiGCode forces Cura into "SD only" mode. To prevent problems with USB printing. If you set the "GCode flavor" to "RepRap (Marlin)" then you can print trough USB with the UM2. But, you might run into stability problems. Note, seeing how many problems we had with the UMO on USB printing, and seeing the volume in which the UM2 is being sold. I'm very happy that we decided to do this. (And yes, it's not ideal, I know)

Your model has no volume. That's why this is happening. Cura looks from the side of the model, and then looks trough the model, for every polygon it passes, it "fills" until it passes another polygon. "Manifold mesh" is another keyword you would want to look at.

Nope. Everything in the machine settings isn't send right now due to a mistake from my side. Also not possible right now to see this. I can see which model was sliced, if I have an exact copy of that model. So for example, I can see how many of these where the Ultimaker robot, as I have that model. But I cannot see the model if I do not have a copy of that model. So I could check for known dual-extrusion prints. And I can check if people have the "dual extrusion support material" setting active. But that's it.

http://software.ultimaker.com/Cura_closed_beta/ Updated RC, quite possibly fixing the plugin problems.

I've made a minor adjustment to how the brim is looking at support, possibly fixing the above problem. You can test this with the latest RC at: http://software.ultimaker.com/Cura_closed_beta/

More likely, youmagine was down for a while and could not save all data. The data is per saved slice. So it's only send when you press the "save/print" button, not when you change settings. Version information looks like this: You can clearly see new releases happening. And this is the layer height graph ordered by layer height: Note that the "other..." contains a lot of different values. Both large and small. For example, for layer heights, I got 412 different values. Everything used less then 1% in total is grouped into "other". Same for Cura versions. 88 different values (yes, that much, due to RC builds and 3th party builds) For other parameters I need to re-run my script, which takes a while to parse the 1.6gb of data. Nozzle size I do have: (Yes, I messed up the ordering again. Sorry, data comes out ordered like this right now)

As some might know. Cura can send usage stats to a server somewhere. This data is totally anonymous, and does not contain model files. This is send as soon as you press save or start an USB print. When you start Cura you are notified about this and have an option to opt-out. And you can always opt-out later from the preferences menu. I've been processing this data a bit today. And there are some nice graphs because of this. For example, the total number of gcodes generated by Cura, per week, in that week: This tells us that Cura's usage has grown a LOT the last half year. This is also an interesting graph. It shows that MacOS usage has been pretty constant. But Linux use has diminished a while back. Windows dominates the use of Cura (Where the usage of Windows 8 alone is just as much as the whole range of all Apple OSes. As the info I have is more detailed, but makes the graph hard to read) Another nice graph to show is the filament diameter. Not just because it shows what people enter in this setting. But also because it shows the division between 1.75 and 3mm filament. As you can see, it's about 50% 50% between 1.75 and 3mm options. The "other" is every other value entered. Note that these are the exact numbers used. Not a rounded number. So the vast majority of users never really sets this other then the default or measures the filament diameter. It also shows a rise in 1.75 use in the past. (The large amount of "Other..." around that time is most likely the old Cura "2.89" default, but it also contains some 1.72 and 1.74 values) Few other interesting things. About 10% of the slices are done in "Quickprint" mode. Of that, 80% seems to use the normal quality profile. Due to a mistake in Cura, I cannot see what kind of machine was chosen in this data. So I do not know which machines are used with Cura exactly. But I can see that about 50% of the slices use a 0.4mm nozzle and around 3mm filament. Which are most likely Ultimakers. It's hard to classify as Original or 2 after that. And, best for last. Most often used layer heights: Which was kinda a surprise to me. 0.2 is used about as much as 0.1mm. I might post some more data later. Anything particular that you might want to see? (As already noted earlier. Due to a bug in how the data is send to the server, no machine configuration is added. So I do not know which machines are used with Cura, everything in the machine settings is currently unknown to this data set) (Note, this is the result of processing raw data. There might be huge mistakes in here. As this is all raw data processed, while normally in statistics you throw away data to remove statistical outliers)

I think I found the problem and fixed it. It's still the memory error which happened because I kept a reference to the old and new gcode when running plugins (doubling the memory requirements)

Most likely that's the problem then. I got some more reports from internal tests that plugins cause random hangs. So that's something I'm investigating.

Scale does no magic. It just scales the model. Just as any 3D application would scale it.

You should be able to get it from: https://www.youmagine.com/integrations/cura/authorized_integrations/new

This is no longer possible from the commandline. (This was an internally used interface which has changed)

File -> Reset profile to default