Daid

The LCD communication is "fire and forget", no error checking is done. This causes a single communication error to give the above problem. Re-inserting the SD card fixes it (as it re-configures the LCD screen) but that's not a solution during printing.

Yes, that usually is the method. There are some general rules that usually work. Like 3mm screw holes, if you want lose 3mm screws in there you use 3.2mm holes, 3mm holes for "screw them in" and 2.8mm for "need to use threading tools" Generally "parts that need to fit together" you keep 0.2mm clearance. But these rules do not always work.

Yes, I have enabled the M907 command for future versions, but your description is wrong. It is M907 Z[mA], so M907 Z1300 sets the current to 1.3A, which is the default. I just had a quick talk with our electronics guy, and he finds it odd, as the UM2 was tested up to 45C ambient temperature. And we had UM2's running here in the Netherlands this summer, in a room that most certainly got over 35C. (Not saying that it could not happen, just that we did tests and that this problem did not come across in those tests) However, you could try keeping the electronics cover off, to see if that helps in losing some heat. If that does not fix it, there is also a 24V fan connector on the board. The disadvantage is that fans make noise, and there currently is not really a place to properly fit the fan in the casing.

Best way to compensate for it is in the 3D model. Shrinkage is a bit unpredictable and depends on the shape of the model. If you need submm accuracy you usually need to tune your model a bit. Just you need to tune an injection mold.

http://www.microsoft.com/mac/products

It's also what I use for the CuraEngine and the firmware (requires quite some setup to compile Arduino stuff, but the Engine requires no setup at all) You want the "codeblocks-12.11mingw-setup.exe" version, as it includes the mingw C++ compiler (the other download is only the user-interface, and does not include the compiler)

It does a retract and move up, to ensure it's above the print and no longer on the print. It does this also for multi-object prints, to ensure the hotend is above all the objects. (It's not really a random move, it's quite intentionally added)

I've been working on this the last week to get the time estimate of Cura improved (I'm down to 97% accuracy in the estimate) Acceleration is planned over 16 moves maximum. What it does it tries to figure out at which speed it should take the intersections, which depends on the changes in speed at that intersection. It's quite a bit of code, which has quite some details, it boils down to this: https://github.com/Ultimaker/CuraEngine/blob/master/timeEstimate.cpp

The wipe tower size is done in volume, as you want to extrude a certain amount of volume to get the extrusion going. If you put in thinner layers the wipe tower needs to be bigger to extrude the same amount of material. This setting does this without needing to adjust the setting. Note, this is the volume of material per layer, so 15mm^3 volume on 0.1mm layers results in a square_root( 15mm^3 / 0.1 ) ~= 12.25mm, 12.25mm x 12.25mm wipe tower. The wipe tower is indeed not yet calculated in the print area yet, I still need to fix this.

The sliderblocks use self-lubricating bushings, which slide quite nice on the axis on their own. But extra oil never hurts. (Do not use grease on the axis, this attracts dirt like crazy and cause lots of problems in the long run)

The wizard assumes you are at Z0.1, accounting for the paper. It should put the fan cap over the clip, but this cap should clear the cap just fine (some of the first machines have some minor bending issues with the cap) but I think I'll put the head back 5mm just to be sure it clears the clips always. Aborting and homing then is kind of a hit/miss sometimes, haven't looked into the details yet, seems to be some buffer-full problem. Aborting by pulling the SD card always causes homing as far as I know.

Pronterface is the most "low level" you can get, it gives you lots of control for moving the head and manual heatup and stuff like that. It's not as difficult as it looks, as you can ignore most features and only use what you need. I'm using an old version (2 year old or something) myself for when I'm testing. So I'm not sure what download you need.

Is your Z screw clean and shiny? As it should not, there should be grease on there... the top looks oddly clean...

I've put up a quick test build at http://software.ultimaker.com/Cura_closed_beta/ It contains a few fixes related to retraction and the wipe tower, so it might be of interest.

PrintRun/Pronterface can do what you are looking for.

Wrong device. Doodle3D vs 3Doodler. Confusing as they did a kickstarter around the same time, and independently came up with about the same name. But, on the wrong-device side. I hope to release "wireless printing straight from Cura powered by the Doodle3D box" before the end of the year. Should add some value.

On the UM2 it is quite easy to feed in the next material. On the UM-Original this can be a bit more tricky. But you'll have to be there at the right time. The material estimate of Cura is actually quite accurate. It usually allows me to judge if there is enough material on a roll. But then again, I do have a bit of printing experience already.

Uhm, yes, known problem. The actual 2nd diameter was never implemented in the engine only in the GUI (oops?) I'll see if I can add the brim to the wipe tower and build a test version. And I'll have to verify with the Doodle3D team if they do not mind having a test version out there that calls their API, they might want to do some testing of their own.

It should follow the Z height of the current print. It only shows if you haven't changed anything in the scene from the moment you started the print.

I'm not sure where the bumbs come from, and if it's a setting (large infill overlap value?) I'm not seeing them in my own prints here, but that does not mean they do not happen. Got an exact model and settings for me?

I'm hoping to do a new release before the end of the year. If you want, I can build test versions. There are more new things in my dev version, like Doodle3D wifi printing (needs some more work). Better "multiple objects" collision detection and handling. So you can tighter pack multiple objects. I've also fixed the object placement for dual-extrusion, so you can no longer print off the platform. Currently I still need to account for the wipe tower, but all other features are guaranteed to be printable in the volume now.

The full message is: It indicates a major problem with the temperature sensor of the heated bed. Which is why you cannot discard the message, as it would be a problem safety wise (heating up without proper temperature measurements is a fire hazard) As for removing the bed, you do not need to remove the top 2 screws near the wires. Those only keep the connector in place on the board.

Bug in the firmware, I made a mistake and this swapped the "wait for heating" to "wait for cooldown" on the bed M190 command. I've fixed it for the next version. I've been running into the same problem with my Doodle3D experiments.

The problem here is that there are no specs released for the X3G format from MakerBot, nor their communication protocol. I think there are firmwares out there that accept the GCode transfer protocol that we are using, but then you'll have to experiment with firmwares.

I've just made the wipe tower size configurable. And I'll have a look in adding a brim to it, shouldn't be too difficult.