Daid

The E value is a legacy thing, just leave it at 0.

You're missing rounding errors :-)

Which printer are you printing this on?

https://github.com/daid/Cura/blob/SteamEngine/Cura/util/profile.py#L1117

The 15.01 release is a bit softer on it. If it still triggers with the modified fan duct now, you better make adjustments to the duct as you will be causing other issues. (And not adding a runtime configuration setting to switch off safety features. That would defeat the goal of the feature)

Never seen this before. Are you using any plugins?

Could be that the export is set to meters instead of mm. You should export in mm.

No idea in which mode those drivers where used at that point. It was on experimental hardware with experimental firmware. (It did have a high frequency pitch when the motor was not moving. But I'm sure that can be solved by lowering the power on stopped motors)

You'll hardly notice that it's actually printing. (With the TMC260 that is) The fan will be the noisy part.

A pause should be triggered with an M0 or M1 in the gcode. Are you sure you don't have the "pauze at height" plugin enabled?

Print speed depends on: * Material * Temperature * Machine So while there are general guidelines. It also depends a lot on the machine. Which means you'll have to find info from someone with the same machine, or, find it out yourself by experimenting.

Also note that this was without material in the machine. As there are lot of variations on printing materials, with not much known about flammability, I would not recommend repeating this experiment in your home. As the printer head did get 500C during this test. Which could be above the auto-ignition temperature of various printing materials. Not to mention the horrible smell. But, on a safety level, I fear the toaster a lot more then our rooms full of printers.

Actually I only re-seed the RC counter when a release is done. 14.11 also rolled into 14.12 before release. But, going to do final tests today, and then upload the release if I do not see any firmware issues. And the best way to fix the UMO display problems is by buying an UM2 ;-) as it has room for exactly 1 more character.

Yes. I better disable that. Sorry Nallath. But I agree on the fact that the feature is less valuable then the annoyance it causes when the error pops up.

The raft certainly triggers this. As it has some problems figuring out the actual layer height on the first layer after the raft.

There is a whole range of protections in place to prevent any burning from happening. We take safety very serious as we know a lot of people run their printers over night or unattended.

In the future I will improve the configuration on it. But right now it's not a priority (sorry)

Well, I'm talking to Gina (Octoprint) about printer communication at the same time. The combination of a few discussions let to the conclusion on how to fix it. Simple fix. Added right now. The "Printing: e" is fixed for the next update. Simple oversight on my side. Material change is a bit more complex one. I'll see if I can fix that (it has to do with the fact that the material chance can also be done from the print now, which makes it a more complex interaction in the code)

Up and down might mean a different thing for your printer. It means "bed up" and "bed down" in Cura (as the Ultimakers have moving beds that go up and down) Just a naming thing on those buttons.

1) Fixed that for the next version. 2) Strange, the change material and pause functions are not touching the fan at all... I'll try to reproduce it first. Also fixed that the abort now almost instantly aborts instead of executing 16 more moves (think Tinkergnome managed to trigger me on how to do this) And the flow tooltip is a very old suggestion that got lost at some point. Pretty sure there was a custom patch for it at some point.

We do have an experimental design that works on the UM2 with the UM2 hotends. But, it does not provide the best quality prints, and you run into big problems when the 2nd nozzle is cold. Pretty sure Martijn will share the small addon you need to print for this soon. To get proper dual extrusion, you need to re-design the whole printer head. And dual-extrusion is a step towards PVA printing. And PVA printing, that's where the holy grail is. So that's where you need to design for. As on the software side, as Nallath says, software has dual-extrusion already (it has for years actually). But lots of things can be improved there. However with the lack of proper working dual-extrusion machines, there is little work done on this area.

Just hit me. What we can do is add a M401 command which clears the planner buffer. And then queue this command on abort. As this command is ran from the "process_commands" loop, it should not have the sync problems that the current abort has.

Could be a bug in Cura, or something related to the settings. The flow setting has effect on this for example.

Some versions of FreeCAD install a global python path, which screws with Cura.

We might just do that, we've been pondering about limited volume beta kits for certain bits&pieces. EDIT: This is not about dual extrusion, but other experimental kits that we are thinking about. Apparently I'm not allowed to say anything about dual extrusion at all. As Marketing wants to handle all communication about dual-extrusion. So, from this point on, you won't get any meaningful technical info about dual extrusion.