Daid

Wait, let me explain a few more things that could be messing things up here. Another fine example of my shitty code. If you have multiple objects on the printer bed, and you print those "all at once", the GUI code (does this on a thread, but the PIL could be messing with you here) will calculate the final 3D model before sending this to the engine. With multiple complex models, this could potentially take quite a load on your CPU. Especially as it's also doing all the transformations then and essentially storing the model twice in memory. Recalculating positions so the final position of the object matches with what you want. The plugins are run in the same Python instance as the GUI, so plugins will block the GUI (Due to the PIL once again) plugins can be a real slowdown if you have a lot of them enabled. The Engine communicates a lot of polygon data back, the GUI is storing this. This is used to speed up rendering of the toolpaths, but storing this data could potentially be causing slowdowns. When in toolpath view, GCode is parsed, result is stored, and then read again to be transformed into the shown toolpaths. This isn't as efficient as it can be. Totally rewrote this code for the PinkUnicorn. So...

All inis are stored at the same location. The uninstall should remove the installation directories, so this new location inis is kept, but the older are removed. However, the uninstall older does not seem to work for everyone. (or not at all, it's hard to test as my virtual windows machine broke)

deferring the processMatrix can cause hell in other areas, which depend on up-to-date model information to be available. But, yes, that's one of the main causes of slowdown. As for the delaying of slicing performance, I do not notice any performance difference. But it might be interesting to test to see if it's the starting of the slicing, or the receiving of data that is causing the slowdown.

1. Most likely it's hitting an endstop and slight shifting because of that. 2. Then don't do that, or make sure the X/Y stop position is far away enough. (but, yes, it could lift a bit higher to avoid the clips. I hated those clips from the start, gotta tell you that) 3. Are you sure? These 2 things have no relation with each-other. The minimal layer time knows nothing about the pause, and the pause knows nothing about the minimal layer time. 4. That's how it is currently implemented. But good point, I think this can be changed for the UM2. (UM Original is a different beast on this aspect)

I agree with him. This should not happen. However, does not mean I instantly will fix it. Especially as this odd behavior of invisible settings affecting the print is fixed in the PinkUnicorn re-write. (Not that that version already support dual-extrusion. But invisible settings is part of the architecture, and invisible settings fall back to defaults)

Is that sketch-up? Then most likely, duplicate faces and internal faces. Sketch-up is quite bad for solid modeling actually. It has a tendency to generate bad models, as it's mode made for visual modeling. I'm not sure what you are exactly designing, but I usually recommend DesignSpark Mechanical (or it's bigger brother, Spaceclaim) for part modeling.

I did those tests, with Siert. We mounted a precision dial on the bed to test this. So that was very stable. And we repeatedly homed, as, after all, that's where we want the repeatability. I think these measurements where in the 5-10micron range. UNTIL! We pushed hard on the wooden bed of the UM Original. Then it gets skewed and your homing position can be off by as much as 500 micron. This, indirectly lead to the UM2 bed design. Note that this was a one-time test, and thus does not account for bending of the switch lever or temperature fluctuations.

It moved to the "user's directory", in my case: C:\Users\daid\.cura This to see if it solves problems with some Windows8 installations. On MacOS it also moved (as the old location was also giving problems there for some users)

Problem with that is (we seriously looked at that option) that we need to re-engineer and test everything, feeder, tube, head parts, hotend. And we need to change our material supply chain. So we're not doing that (yet, not saying we never switch to 1.75. But not for the UM2)

Which machine? As that's clearly an extrusion problem (I've seen lots of those in my early days)

Actually, that's code of the GUI rewrite I'm working on, which supports a lot more extruders. The current code is limited to 4.

Good luck. I have a pretty good idea what is blocking the GUI, and fixing it won't be easy. (Disabling re-calculation does not remove the effect you are having, hench the reaction to these requests)

UM2?

Looks more like the normal Z scar?

Advantage of OpenSource, you can always verify what I'm doing. I have no secrets.

Doodle3D box auto detection (default LAN IP for Doodle3D) https://github.com/daid/Cura/blob/SteamEngine/Cura/util/printerConnection/doodle3dConnect.py

Note that straight tooth feeder wheels need cleaning from time to time as the will fill up with material. (One of the reasons why we like the angled tooths much more at Ultimaker)

Most (if not all) of the damages that you see are from shipping over-seas. I know the shipping department is looking into improving the packaging. And, I've heard sounds about producing in the US as well. Which would solve some of the shipping issues. And, in the far future, we'll most likely move away from DiBond, as this is a major factor in the damage. It scratches and bends too easy. But as Nallath also pointed out, the amount of damaged machines you see here is only a small fraction of what gets shipped. (luckly) So no big surprise that yours wasn't damaged.

Not sure, just don't tell anyone this yet. We better keep things silent and let them be amazed when they see it for themselves.

I hope you understand that we cannot give dates till we say "It's released! Order now!" I think you can go do this now pretty soon: http://i.imgur.com/QL4Vn.jpg (It's as good as done, engineering on it is finished, BOM and so on has been made, it's pretty much finishing up manuals, documentation, getting stock, and marketing from now on. So I'm kinda out of the loop in when it will be ready-ready.)

There is a whole simulation environment for the PC with the code. Takes a bit of work to setup, but after that you can do pretty quick iterations.

Blender can do what you want I think, with "displacement mapping".

Not yet, will do later.

could work, but could also stall for a while at the first M190 as it might wait for the bed to stabalize.

Not really, that's why in the example I gave I heat up the bed first and then the hotend.