Daid

Yes, I'm aware of the problem (combination of support and brim giving issues like this). I have not looked into the cause yet.

(As quick workaround, you can turn off or lower the brightness of the leds in the settings menu)

Heated bed on the UM-Original requires custom build firmware.

To add on the info from Illuminarti. I've done some test with this a year ago, with the USB transfer speeds that we have, it's not worth it. It can take anything from 20 minutes to an hour to transfer a gcode file.

Yes, it also effects the estimation of the UM2.

The slight flicker is actually the PWM of the heater. I haven't looked into it yet, but most likely by changing the PWM frequency of the heater a bit this should be invisible.

I looked into a test of triangles+hexagons as infill for Cura. However, there is a visual issue with this: http://imgur.com/jQBKaPu Would give you the strength of hexagons and triangles. Without adding the vibrations of the full hexagon infill. However, well, you'll most likely see the visual effect it creates. (Also, it does not solve the "top warts" problem, which I am actually investigating)

http://www.thingiverse.com/thing:26094 this is the printed version.

https://github.com/daid/Cura/blob/SteamEngine/changelog Is the only official changelog there is right now. There has been a lot of changes between 13.06 and 13.11, and now there is a 13.12-test, with even more changes (that are listed under development) 13.04 was the last version with Skeinforge instead of the CuraEngine, so there you could find a lot of differences.

UM2 has this fix, I'm unsure if I fixed it in the mainline marlin, I'll double check tomorrow. Planning to make a new UM-Original firmware for the next Cura release ;-)

You could do the math with the "price per meter" preference setting. As each meter of filament is 6.38cc, you could multiply your cc price by 6.38 and use that as "price per meter" setting in the preferences, and Cura will give you the exact cost of your print. Or fill in 6.38 as "price per meter" and Cura will give you the CC as price value.

Strange, does the output.txt says anything? It's stored in the Cura installation directory.

It's not bad to pay for KISSlicer, he deserves some money for his hard work. And without Jonathan from KISS I would not have been able to make the engine behind Cura. He has given me some very good tips on getting stuff done. While the actual final method of getting things done in KISS and Cura are vastly different. It's not a full-time job from Jonathan, it's just a hobby project which makes a tiny bit of money for him. Or, in his words "if it would bring in some more money, I could buy a better printer" as he is still using an old BfB machine. As for "different layer heights for infill and perimeter", I have some ideas on that how to do the old "skin" setting properly (just suddenly came to me!). So I might spend some time on it soon. Different nozzles for "quick" and "detailed" parts are a whole different story... oozing on large nozzles is a big issue.

STL files describe the geometry of your model. So how it "looks". GCode files describe how the printer should move to produce this actual model, and how much material to put where. Going from STL to GCode is a complex process (usually called "slicing", but I rather call it "processing", as slicing is actually only 1 of the steps you need to do) This process needs to be done on a PC, and currently cannot be done on the printer, due to the large amount of processing and memory requirements. Cura does this STL->GCode conversion for you. The Cura manual should help you here: https://www.ultimaker.com/pages/support/manuals

The 13.12 beta tries to open the file in an already open Cura window, if there is no window open then it opens a new window. Which works on my PC...

Uhm, yeah, Digikey also refuses to ship those fans to us... silly stuff, as we did not find a supplier for the exact same model. Anyhow, if the fan was broken to start with, you should get a free replacement from Ultimaker. After all, you payed for a working machine.

You could use the mounting aid I designed for dual-extrusion to create more damping between the frame and the feeder: https://www.youmagine.com/designs/dual-extrusion-mounting-aid But I do not think that can be the cause. I have seen this happen with varying thickness of filament, as well as with slipping filament on the feeder, by too much OR too little pressure on the spring.

Cura controls the requested speed. What is happening is that the firmware needs to accelerate and slow down depending on those speeds. And it needs to slow down for cornering for example. The Max speed limits the speed always to this value. So even if you ask for 1000mm/s the firmware can limit this to for example 300mm/s. Especially for the Z this is important, as Cura requests that the platform is moved at the travel speed (150mm/s) but the actual platform cannot move much faster then 40-50mm/s. Jerk is a sudden acceleration change, when cornering, the printer does not come to a complete stop, but goes to jerk/2 speed and then leaves the corner at jerk/2 speed, so it has a sudden change of speed. Increasing the jerk will print faster, but a too-high jerk can shake your prints apart or even caused missed steps.

Can you try changing the acceleration, opening the LED settings and closing that. After that reboot the machine to see if it has sticked. If that is the case then there is missing a "save settings" somewhere (I know the LED settings force all the settings to be saved)

cc? That's an odd value to use as cost, because objects are printed hollow. Cura calculates the amount of filament used, which is a much better figure to use as costs.

"PID functional range" The problem I fixed in the PID Marlin implementation had to do with the functional range on the PID controller. Normally the PID only starts to regulate when within 10 degrees, which is far to close if your hotend is over-powered and heats up fast. It's also silly to have a functional range in a PID controller, and the only reason to have it in there is to protect against runaway control. If your heating is stuck 10C above or below the set temperature, then the PID controller is not actually doing anything except pushing it out of the function range all the time. Anyhow, the bug I fixed had to do with the initialization of the D factor in the PID controller. The D factor was not "running" while the PID controller was not controlling the temperture. This caused the heater to go off for a while as soon as the temperature was in the function range, causing an odd temperature jump. Which in turn can "confuse" the PID controller a bit. Note, some overshoot is not that bad. On the UM2 I setup the PID controller so that it initially overshoots a bit once, and then stabilizes on the set temperate. This makes it reach the final temperature quite fast, some initial overshoot is not that bad, as the heater block needs some time to adjust itself to the new temperature anyhow.

In theory the order of printing the fill areas could be better. However, this is a traveling-salesmen problem. http://en.wikipedia.org/wiki/Travelling_salesman_problem Right now the code just goes to the closest line it can find to print next. Gives decent results with a limited amount of long moves. But not always optimal. Because I knew this can be optimized, I've put the implementation of this printing order in a separate file: https://github.com/Ultimaker/CuraEngine/blob/master/pathOrderOptimizer.cpp Now it's just waiting for some crazy person to optimize it. (I do not have the proper background in computer science)

Yes, I've been adjusting the default. When I added the setting it was not really tuned yet. I've been tuning it better as I got feedback. The new default is 0.02mm now.

No idea, just downloaded the model, put all settings on default, enabled brim, scaled the Z*2 and printed it.

Yes, next release (out next week if nothing goes wrong) will feature updated time estimates. Worst I had so far was that a print of 2 hours and 30 minutes was estimated as 2 hours and 40 minutes. Which is not too bad. The new estimate is usually pretty accurate or up to 10% worse then the actual printing time.