Daid

The current code only removes half of the duplicate faces (so it removes till there are no more duplicates). Previously this was needed on very high resolution models (UM robot for example). But with the code behind it being more rubust, it looks like this is no longer needed. I'll build a test version today or tomorrow.

Wait till you discover that Ultimaker a secret cover-up for world domination... The name will most likely be "Cura - Something". As Nallath says. PinkUnicorn is a work name. We've started to use "bad" names. So marketing won't copy our names. For example, the UMO+ was named the "Kelpi" internally.

And polygon count? Got that for me? I'll most likely have an experimental tomorrow.

No, the SD bug fix was much older. Somewhere in the 13.xx range. 13.06 was the first full release with the new engine, and thus the auto-slicing. But also a lot of other changes where made in that release, so there where quite a few bug fix releases after that. There is a 14.12 out now. But I don't think it will fix your issue. As your major issue is with the GCode preview. Which is a difficult and complex monster. There will be a new experimental soon, which might help on some of the issues that people are having with auto-slicing. But I did not trust those changes enough to put them in a full release yet. (Major changes just before release usually result in horrible bugs).

Directly touching faces (100% overlap) currently confuse Cura. As it removes duplicate faces. Which is most likely why your model goes wrong. If I disable the face removal code (direclt in the engine). I get this result: (with default settings) I'll have to check what other side effects will be from not removing duplicate faces. But I'm surprised how much difference this made!

Latest release is actually done yesterday, as official new release. But, I am looking into the slowdowns when starting a slice. An important bit of information here is, specs of the computer, and 3D model user, especially the amount of polygons. I've been testing with the "horror" model I have (3mil polygons). And there I have a measurable 0.9 seconds delay when the slicing starts. I've identified the code, already made some changes, but I found them too experimental to put then in the full release of yesterday. However, I will build a test version soon so people can check if this improves their performance.

You can copy the directory "C:\program files (x86)\Cura_14.12" to somewhere else, and run it from there to have 2 installations, one you can mess with and another one that runs fine. Cura will run side by side, with different versions, and will run if you just copy it (no real install required). As those are two important things for me when I started to build Cura.

Clearly the bed temperature line should not be in there: "M190 S70.000000" You might want to set the bed temperature to 0 to see what happens. Note that BFB support is highly experimental, and fully relies on feedback from users that are willing to experiment.

What could be happening. And this is a guess, as the data I have is not from a printrbot. What we see on Ultimakers, is that the material amount you are getting depends on the material flow rate. For example, if you are asking for 10mm^3/second, we're seeing for example 10% less extrusion then expected. While if we extrude without a hotend attached (so just the feeder) we see exactly the amount we're requesting. When we request 15mm^3/s, we're seeing 20% less material. The faster we feed, the less material we are actually getting. And this all depends on the feeder, hotend and material used. This isn't really new information (as some of these measurements where done quite a while back) but because expectations of machines and software is going up, this is starting to become an issue. So, I'm suspecting you calibrated everything properly for a certain flow (in mm^3/s), and by adjusting the parameters, the flow changes, and thus the actual flow changes. You could easy check this by doing the same print twice, but only change the print speed.

1) Set the "Printer interface" to "Pronterface UI" in the perferences. 2) Load a cube 3) Hook up your printer with the USB cable 4) Press the "print button" 5) In the dialog that opens, press print. 6) During printing, adjust the temperature with the up/down controls, or by entering a temperature. 7) Speed controls are absent. But, if you really must. M220 Sxxx to control the speed. (Or optionally, get the more advanced printer interface plugin, which is somewhere on the forums and has buttons for this) But, in the end. If you are printing with USB, you're putting yourself at risk of unfinished prints.

But you live downstairs, instead of us, upstair office people ;-) Anyhow. To explain this a bit better. First off, with speed controls, I mean some very old code that was in Cura. It allowed you to control the speed for different sections. For example you could set the outer perimeter speed to 50%, during printing. The code that did this was horribly hacky and I removed it when cleaning up and fixing other bugs. As for the printing dialog itself, the rest of it. These changes came with inclusion of Doodle3D printing support, and some more cleanup of the printing code. This code is all quite old, and hangs together with ductape. Making it very hard to maintain. By removing features I have less to maintain and I can spend more time on stuff that is more important. I know it sucks for people that used that feature. For the more advanced usage, there is still the stand-alone printrun/pronterface (from kliment). The "per type" speed controls however, went on the same chopping block as the timelaps feature (something I hear nothing about, as I actually removed that as well) It's a simple case of every feature requiring extra work to maintain. (Nallath is sometimes a bit better at explaining this)

I think you might be over-extruding then, which will give different results on different parameters.

So. This post is a bit overdue. As there is a lot happening right now. A lot of these things are invisible for you. So. Here is my attempt to explain a few things that are happening inside Ultimaker around Cura right now. First off. The magical Pink Unicorn. There has been a lot of talk about this already. It will be the new updated shiny version of Cura with lots of improvements. However. It's currently not really set in stone which features will be present in this first version. What the Pink Unicorn is right now, is a total re-write of the GUI. First, I started to work on this, with a new GUI toolkit. This failed to work properly and was too much effort for me to do on my own. So I switched back to wxWidgets (toolkit which is used to build the current Cura GUI) and I made a new PinkUnicorn, the version of which a select few have seen a preview. This version has a lot of improvements below the GUI, where the general structure of the code is better organized, but it's still a bit of a mess. However, with this code, I also restructured the CuraEngine. This newer updated engine supports settings per object, and per part of the object. This will be vital later on to build on, as it will provide features for multiple extruders, as well as features to improve support material. (And dual-extrusion with support material) However, progress on this was still not as fast as I would want it. Everything is a lot of work for a single person who still has other duties within Ultimaker. Bring in the Arjen So. About a month ago. A new guy started at Ultimaker. Called Arjen. Arjen actually worked on the https://krita.org/ project on his previous job. Has a bigger beard then I have (That's a plus right?). And is quite deep into OpenSource. This means he will be handling most of the GUI development at this point, which will give me room to work on the engine and firmware. Now. There has been little to no activity in the PinkUnicorn Cura repositories. This is because we went full circle, and actually changed toolkits. Instead of wxWidgets (which is extremely buggy on MacOS) we're switching to Qt. As Arjen has great knowledge of this part. He also has a lot more knowledge on how to build a proper architecture for a GUI application. So he has been hacking a lot of code, in a different repository. So that's why there is no progress seen. He has been building a plugin-architecture based GUI. Which will be easier to maintain, but this also means that in the future, Cura can be extended with plugins way beyond what the current plugins can do. For example, all tools are plugins already. Rotation/scale tools? Those are plugins. Want a measurement tool?, could be a plugin. Just about anything implemented in Cura will actually be a plugin, and most plugins are just delivered by default. We're actually calling this one "plug-able Unicorn" internally :wink: The sad part about this however. Is that it means that it's nowhere near ready. There is still lots to be done. (For example, currently, it does not even slice, or has proper settings) And it won't be ready for a while. I hope to have a beta test ready around January. But that will be a version which is the same as the current Cura feature wise. Don't expect the new shiny things that people hope that will be in there will be actually in there. Except for lots of code improvements, which will also mean that the "background slicing" issues will most likely be solved, which are currently causing some people to hate me again :smile: (Hopefully solving the never ending "I want a slice button" discussion) I'll do more tech details later. Current Cura I will continue to maintain the current Cura releases till the PinkUnicorn is ready. And there is actually a release just about ready. 14.12 is around the corner, in the last phase of testing. It's the same as the RC10 from http://software.ultimaker.com/Cura_closed_beta/ With a fix for the double-click-on-files on windows. (silly bug that crawled into RC10) January will most likely also see an update, with some more fixes. As I've been looking at some of the code which is causing the "small delay when starting a new slicing action", and I think I can fix this. However, I did not want to delay 14.12 (which was originally planned as 14.10) even more. Yes, the wining about the manual slicing actually has effect. But it would be nicer of people actually explained problems instead of throwing solutions in my face. As it seems this problem is only visible if you go beyond 1 million polygons, bit of information that was hard to find in all the bitching' from both sides. Ownership of Cura This is something I also want to highlight. Cura is currently owned by Me and Ultimaker combined. Which is not a huge issue for the users, but is causing some friction on some areas inside Ultimaker. We're working on solving this, where full ownership will end up with Ultimaker. So Ultimaker has full "control" on what ends up in the mainline Cura. In practice this means little, as I'm still the one who's doing the main releases. But it's something that we never wrote down when I started to work at Ultimaker. So it was never clear if my work was a contribution to Cura or if Ultimaker owned Cura. This does not mean that it can be made closed source (due to contributions). But that is no problem, as Ultimaker is dedicated to keeping it open. It's just an administrative thing. So why am I telling everyone? Just to prevent outcries and confusion later on. As I will be moving the main repository to Ultimaker on github once everything between me and Ultimaker has been settled. TIP for everyone: If you ever get into the situation where I was 2 years ago. Where suddenly a company wants to hire you to continue to work on your hobby project. Then make arrangements then, not later! Doing this afterwards can be a lot of trouble. And even tough I have no trouble with Ultimaker, and Ultimaker has no trouble with me. I have excellent relationship with the CEO. But it's still a bit of a headache story now. Due to the long time between the hire and the arrangements. Yes, we are learning from stupid mistakes. And this is one of them. So..... There will most likely be about 2 pages of replies tomorrow...

External dimension are defined in the STL file. So what you are seeing has to be some other effect...

Right now, if you want 64bit on windows, you'll best use a VM. In the future, I want to provide a 64bit windows release as well. I can see that 80% of the users have a 64 processor. So that group is large.

This is a bug with the current release of Cura and USB printing. There is a fix in the latest RC, however, I do not guarantee that USB printing is stable. (There have been general problems with driver stability, which is why the UM2 does not support USB printing by default) http://software.ultimaker.com/Cura_closed_beta/

It's a known problems with the Mac version. You might need to resize the side panel a bit (you can drag the split between the 3D and settings area)

That. Pretty much has nothing to do with slicing. And more with the small clusterfuck that is the gui code right now. It's pretty much the part of the code that's on the chopping block and totally redone for the PinkUnicorn. Yes, that code is slow. But that has nothing to do with slicing, and all with python code doing way too much processing.

Most likely the gui needs 64bit then, which is complex. As it uses python and a lot of libraries. Not sure if all libraries are available in 64bit right now. Note that the latest few RC releases improve on the memory usage a bit. But it is a growing problem as people are printing more and more complex objects.

Takes a look at the values entered in different fields the past 6 months. Spots a view good ones, like "q" for layer height. "M105" for temperature, and "slow" for shell thickness. I don't have to assume it. I even have data to back it up!

The Mac SD card bug was fun. Random 0.2 second hangs every 5 seconds. (Fixed that one) The virus-scanner on windows bug was also fun, up to 1.5 seconds of GUI hang when the slicing started (also fixed) The firewall problems are mostly fixed, except for some awkward version of zone-alarm that blocks local sockets by default. (And there is a deep down "configuration setting". It's called the code. There is actually a patch somewhere on the forums that does manual slicing)

You may be right. But I'm the ruler, and I seem to care little about your rightfulness. Already ready for the history lesson? I made Cura for myself. As the software options where bad back in the days. And I needed something to print my ever more complex designs quicker, needed to be able to view the gcode quicker for defects, needed to change parameters quicker and easier. Now, when I started, I got quite a few remarks about my work being "unneeded" (due to slic3r and repetier), people like you, who thought they where right about things. I pretty much choose to ignore that, and set my own path. As I made the software for myself, I also put up free copies of it on the internet. And, due to open source parts being in it, it always has been open source. Later, this landed me a job at Ultimaker to continue and improve the software I was already working on in my free time. This didn't put a full time Cura job in my hands, as there was/is a lot to do at Ultimaker. But it did gave it an awesome boost in development. When I introduced the new C++ engine, which is about 60-100x faster then the other options at that time, I also switched from manual to auto slicing. And that felt great. Sure, 2 weeks of bitching for everyone at the office. After that 2 weeks of everyone else in the world. But I sticked to it. And now most people agree with me that it was a good move.

How dare you call my throne a horse! Minions?! Off with his head! I'm starting to question your logic and reasoning skills, now. Feel free to question me. I question myself a lot. Or not. Anyhow. I know I'm not a reasonable and nice person. The awesome thing is, I don't have to convince you. You cannot convince me, just like the people before you couldn't convince me. So you're pretty much stuck with my rule, or go somewhere else. Other software, or fork it, it's open-source after all. (And, awesome thing for me that is) As for the pink unicorn. I will post an update on that later. Just don't expect anything from me for Christmas this year. Is that your loss or mine?

Then, let me consult the first ever user of Cura, from before it was even called Cura. Because it saves you pressing a button. It saves time, effort, confusion (for new users). And is pretty much the result of logic, why add a button when you can start this process in the background? For small prints it pretty much means Cura is ready before you are sure that you want to print the object like this. And it actually waits 0.5 second before it starts slicing. And, we had this discussion a few times before. What makes anyone think I will change my mind now? (Finally, extra points. You didn't pay a cent for Cura. Nothing. Ultimaker users have a bit more right to complain, as a small piece of the money they payed for their printer went into Cura development. You on the other hand got it all for free)

https://www.youmagine.com/designs/case-for-dc-boost-12v-24v