Daid

Could be a bug... *checking* Most certainly a bug. I'm sorry. The start3.gcode is not in the profile.py, which causes it to be "ignored"

Feel free to do as you wish, but the latest RC as nice temperature controls in the PronterfaceUI plugin (select it in the preferences)

See the topic I linked, might be related to a bug in the latest official Cura

http://umforum.ultimaker.com/index.php?/topic/5007-surface-looks-a-lot-worse-in-cura-1403/

Haul your ass to FabCon this friday, and you'll get the chance to meet me ;-)

The UP! uses small motors like that. The UP! is a smaller printer, but it seems to work for them. No idea what the torque is on them. On the UM the motors are a bit "oversized" to prevent problems. You could most certainly get away with less, but would it be smart to do so for the tiny bit of extra cost you save?

No, you do not want to stream from the internet. You want to send the STL file to the Pi. Slice on the Pi, and during slicing, stream the GCode straight from the slicer on the PI to the printer. That's what I'm suggesting. This means it does not really matter if the slicing takes 10 minutes, as you can start printing as soon as you have the first layer buffered. (And with some tweaks in the CuraEngine you could have the first layer in less then a second) GCode files are usually a factor bigger then STL files. And if you convert the STL to CTM, you would have even less data to transfer. Cutting down on possible failures. Especially after seeing GCode files well over a few 100MB.

OpenSCAD can create great cylinders with any amount of faces you want.

The "layers outside of view" is a very old long standing bug. It might have been fixed in the latest RC: http://software.ultimaker.com/Cura_closed_beta/ (It has to do with an G92 in the start code)

The above articles are about LinuxCNC, in which someone linked the E acceleration and speed to the X/Y/Z acceleration and speed. Something that Marlin, Sprinter has been doing for years already. "Nothing to see here, move along" would be the proper title.

Or, you only run the slicing part on the pi, not the GUI? Then you can actually stream the GCode from the slicer to the printer, and so you can actually start printing before the slicing is finished. (Pi-slicing is possible, people with Octoprint are already doing this)

IMHO, when combing (staying inside the print area) no retraction is needed, as any oozing that will happen will end up inside the print and be invisible. With combing it still retracts when moving outside the print object boundary.

Octoprint is free... I'm wondering how they solved the major "network printing" problem, which is "is the printer free for use? or is there still a print in there?"

I fully understand your idea now. Would be incredibly technically difficult. On both Cura and firmware side. Pulling out the SD card while printing aborts the print in the current implementation. That's the safest thing to do.

Except for the BFB and Makerbot printers, all other supported printers run a form of Marlin or Sprinter, which can be upgraded. (If not, they are violating GPL, and you can sue the printer producer) It's not Cura's task to protect the hardware. That's my stand on it. You can always fork if you think otherwise. (It's also not trival code. As you need to kickstart for a certain amount of time. And, as the M106 is queued in the movement buffer timing is difficult)

Difficult to implement. But even harder to convey this feature to the user. What you could do, is just save the GCode files local on disk, and copy those over to the SD card later. (Or, buy a 2nd SD card :-) )

You would just need to modify the firmware. "Steps per mm"

I think you only need 2-5% infill for a model like this. Would save a lot of time.

You could give a shout here: https://groups.google.com/forum/#!forum/kisslicer-refugee-camp Might get you a KISSlicer profile for free. As I don't think it will differ much from an UM-Origonal profile.

Actually, you should be able to run KISSlicer, Slic3r and other options just fine on the UM2. You might need to do some extra configuration of the software, but it is supported to run other GCode files then from Cura.

IMHO, it's the firmwares job to protect the fan and kickstart it. The low percentages might be a bug? But be sure not to check during the first bunch of layers, as then the fan is slower.

Odd, as there are zero changes in that part.

T0 means "extruder 1" I made the "heat heads and bed at the same time" before I had experience with heated beds. Now I think there are better startup sequences. But I haven't got around to change it yet.

Pause and USB printing has been causing issues. Which is why the pause button in 14.xx has been disabled for now. (You can switch to a more advanced 3D printing interface in the preferences)

You can most certainly do this from a plugin (just search for the T0 and T1 and add your own pre/post codes there) In the future I'm planning to support this in the machine configuration of the new GUI. (holy shit, this new GUI is a lot of work. It's finally starting to get some shape. But the whole machine configuration dialogs are missing at the moment)