Daid

Fixed for next version. Thanks for reporting this!

In our experience, all metal hotends don't work very with PLA. As they are prone to jamming with PLA. If you just want ABS and other materials, then all metal can work fine. But for PLA it's hell. (We've spend a LOT of time trying to get a all metal hotend to work for the UM2. Never worked up to our standards)

I think this was fixed in one of the 15.01 RCs: http://software.ultimaker.com/Cura_closed_beta/

Cura will only start on a edge between 2 polygons, so maybe there isn't a close edge to start and thus it needs to move over a bit for the nearest edge?

This is due tot the fact that the "sink into platform" is applied after everything else. It's pretty much a hack in the code, so most code does not handle this properly.

Thanks for the link. That's what I want to know as well. As I want Cura to process as many models as possible correctly.

Did you leave the print window open? And did you press print again on the main window or only in the print window?

Could be that the fix for: http://umforum.ultimaker.com/index.php?/topic/8611-precisely-overlapping-faces-fool-cura-slicer/ Is messing up this model. I'll do tests when I'm back at the office in the new year. Got a link to this model for me?

If you put the flow at 85%, it will show the width of the lines, and thus those infill lines, at 85% width. So that's why your top does not look filled in the preview.

Technical answer (Valcrows solution will work, just explaining a bit better what is happening) The problem is that STL isn't defined what the "unit" size is. And models are stored in "units". Now, most applications agree on the fact that 1 "unit" is 1 mm. But some applications work with 1 "unit" is 1 inch. Now, as whole of Cura works in mm, it's logical to have 1 unit = 1 mm.

Natural PLA, without any additives, is very brittle. So usually some tiny amount of additives are added to remove this property, but every supplier is using a different formula.

That's not the solution. This error happens when your heater needs to supply a LOT of power to get even a decent amount of heating (about 3x more power then required on average). This indicates a problem at the heater or temperature sensor. It could be that the temperature sensor or the heater is not properly inserted in the hotend. Which is what this new error (introduced in 14.12) is meant to protect against. As a partially inserted heater could mean the heater burns out, and a partially inserted temperature sensor could mean the hotend is a lot hotter then actually configured, causing burned up teflon parts and burned up printer materials.

We've tried the geared feeder route. It reliability quite a bit, but the axis still gets quite hot, causing flattened material problems that you can also experience in the UM2. Another problem was that in the current casing a geared feeder won't really fit. But the 5:1 ratio of the bulldogXL will really help. We're actually testing something in between the UM2 and UMO feeder right now. Which is looking quite interesting so far. (That's all I can tell) Note that the loading&unloading procedure of the UM2 needs adjustments when you use any kind of gearing system.

And how does that work then in Simplified3D?

Depends from which version you update. One of the first UM2 firmwares had a bug which saved the material profiles at the "wrong" spots, which caused strange problems when you made more then 4 profiles. If you updated from that, you would lose the profiles. But that was quite a while ago, I think before the pause function was introduced.

Yes. This is big difference between the UMO and the UM2. The UM2 oozes less, but because of that, it also as lower maximum flow right now. (UM2 usually has a limit around 6-8mm^3/s, while a well adjusted UMO usually handles 10-12mm^3/s)

Yes, and those help a bit, but these latest pictures where also taken with very slow printing and very low temperature. The UM2 hotend design also helps a bit on the oozing.

And fix is in place for next version (and next beta, current beta does not have this fix yet)

No no no no no. Please. Don't do 0.2 on an UM2. First off, it looks bad. Secondly, you'll run into extrusion issues quite easy. Please stay under 0.15, unless you're 100% sure your UM2 survives the extrusion test.

This is also true. But the 14.12.1 firmware adds a few features and fixes you might like. It also adds some extra safety which protects your printer a bit better against potential problems. Note that Cura is always backwards compatible, so newer Cura's always work with older firmware versions.

Never trust the globe dual color print: http://daid.eu/~daid/IMG_20121026_213054.jpg First ever print I did with dual-color at Ultimaker HQ. Looks ok from that side, horrible from the other. This print gives a very false impression from dual-color printing. You can also see some under extrusion problems in the Artifex globe as well. My globe above, was produced with the same dual extrusion UM (v1 hotend) as this print: http://daid.eu/~daid/IMG_20120514_091428.jpg Which shows more of how the reality was back then. (taken mid till end 2012) Right now, with the V2 hotend, in the UMO. We get results like this, fresh out of the printer, no cleaning: http://daid.eu/~daid/IMG_20130621_134822.jpg http://daid.eu/~daid/IMG_20130613_124107.jpg That's the reality of dual extrusion. Sorry.

Because the version names are [year].[month], and there where no official releases in those months, only test releases to make very sure the problems of 14.09 where gone.

This is due to how filenames are handled and legacy (8.3) filenames are actually used behind your back.

The USB connection is an USB-Serial connection. (Translation: SD as an USB storage device is impossible with the current hardware setup) While there is actually code in place to send the GCode trough the USB-Serial to the SD card, this takes almost as much time as actually printing the file. So the added value is not that high.

It's actually a viewing bug. I managed to trigger it a few time with testing. But I can see the plugin actually runs, but that I do not see the result in the viewer. But the pause is in the gcode when I save it. The way trigger this is by having the layer view open while slicing. If you go to the object view, slice, and then switch to the layer view, the result is shown properly, if you are in layer view before the slicing is finished, the gcode is loaded before the plugins are run and you'll see the wrong result.