Daid

That's right. When we where designing the UM2, there was going to be a 260W power supply available with the same connector. Which should have given us the power budget that we really wanted. However, this power supply got canceled at some point before release (due to American legislation). So the end result on our side was a bit like the scene from Apollo 13 with the power budget.

Well, I can tell you that it's calculated as you are suggesting. I made Cura, so I kinda know how it works. There could be multiple reasons why the other software is producing correct results. (but it's only guess work from our side, due to the lack of information from you, like, which software, which printer, same printers?) Could be just luck. Could be some heuristics (which I rather avoid due to the large range of material people are using)

It's these moments where I'm proud that Ultimaker managed to build itself without any investors (except for the 3 founders)

Actually. You are wrong. The software is doing what you note in the 2nd picture. (You can check this in the layer view) However, there are more factors from the material in play, which aren't compensated yet. Not sure how to call all effects. Shrinkage is a simple one. But there is also the tendency of hot material to "flow together" which causes inner circles to also be smaller then designed.

The warning is that you're going to get less pretty results. Which isn't a huge issue for the fast print, so the warning is right, and I think the fast print isn't wrong as well.

The UM2 uses the 3th decimal. Also, if you have an accuracy of 12um and you're only asking for positions with a 10um steps then you are losing accuracy, as 12 is not dividable by 10. However, I think it's more likely that changes in the polygonOptimizer code are causing this. This code is removing access movements and has seen some changes between 14.03 and 14.12.1 (to fix issues with super high polygon models)

Do you have combing disabled? If so, then this is expected behavior. (Sorry, should have thought of that first) The change of infill order is intentional in 15.01, it has to do with the new infill&top/bottom skin speed. This order simply gives the best looking results if you print the infill at higher speeds.

That's odd, everything looks normal there. Got any firewall software running? Also this line: "Failed to listen on port: 49674" Hints at that there is still another copy of Cura running. (Cura uses a local socket on port 49674 to communicate between the engine and GUI. However, if it fails to use that port it will use the next one)

You are awesome :-) You know that right?

You'll have to hack the plugin, but certainly possible.

While in theory this can be done, in practice however, is complex to add the code for it, and it has limited use cases.

While I have no idea if they all have been "found", there where a bunch of machines stolen about a year ago. (Traceable by serial number) But these could also be very well second hand machines.

You are wrong indeed. What we're looking at there and in your topic is "top/bottom" skin. Cura puts material there, because if you look from the top of the model, there needs to be a 0.8mm piece of solid material there. Which is why it is putting the yellow zig-zag lines there.

Got an experimental plugin which can lower the temperature of the inactive nozzle: http://software.ultimaker.com/testing/ Feel free to use it, but no garantee on how well it will work.

Well, the first 500 UM2s shipped did have 55mm gantry height (and 10mm less printing height). So forcing it to change would also be wrong. Easiest would be to go trough all the configurations, sorry.

Like a dual-color dual extrusion print?

How thin is the ring you are trying to print? (The only follow mesh surface is a "black magic" option. It's not intended for the use you are trying right now)

I'm not a fan of the Pi. Their core is slower then they claim, they have an exclusive deal (nobody is allowed to buy the CPU except the Pi people) it's using closed source drivers on Linux, which is against the spirit of linux. Also, SD cards as storage. Just look at the problems we're are having with those for just GCode storage. Now imagine your whole system runs from it. But the idea of small ARM boards in the printer is very appealing. Lots of possibilities there. More then you're thinking off right now ;-) I think cloud based slicing is backwards. For example, Cura does 80.000 slices a week. That's a slice every 7 seconds. Offload that to cloud servers and you have a serious cost picture on CPU cycles. Add the bandwidth requirements to that, as GCode files are very large. And I don't think it will be sustainable. Right now, I can only tell that I have claimed a few whiteboards at the office, which are related to ARM based boards and the things you could do with that. (I'm not sure how much I'm allowed to share yet. Project is at the infant state)

What's your minimal travel between retractions set on? (expert setting, default is 1.5mm)

This has been corrected to 48mm a while back. However, because Cura copies over old configuration you could still have the old values.

Be sure to use the 15.01 release: http://software.ultimaker.com/ As it fixes some things on plugin handling, that could potentially explain this rare problem.

It's hard to see from your photos, but you might have backlash issues. Are all your belts tight and pulleys fully secured?

Just give us a few days to roll this out to all areas. Not everything is automated yet on the new website. So some things need manual updates. There is also no update notification yet for this same reason.

Note, I've seen this happen with a few machines at R&D. What could have happened is that the M7 nut that holds the encoder in place has come lose. You can push the main white rotation switch out from the back if you use the standard hex screwdriver (there is a hole in the back of the transparent casing) then you should be able to see if the switch is still properly attached.

Never seen that happening before (naturally, I tested the 15.01 release on Windows7 a few days before the actual release) The lack of printing time info most likely means that the engine isn't starting properly. Can you post the contents of: C:\Users\[username]\.cura\15.01\output_log.txt That might give a hint in what is going wrong.