Daid

Also, which 400W powersupply did you use? Some PC powersupplies say 400W, but only deliver 150W on 12V.

Yes, and no. Cura 12.08 ships with revision b67dacdc8f1bd489e058e16d92ba29c364b2a8e5 of that branch. So the firmware shipping with Cura is older then that branch, you can still get the same Marlin version as in Cura by checking out the same revision from that branch. There have been updates on that branch, including long-filename support for the UltiController. But those changes are not as well tested as the firmware shipping with Cura.

No, it's a known problem. I actually had a talk with Erik about it today. And the problem is in the acceleration, the printing estimate doesn't account for acceleration. This can be solved, with quite some work, but it's not on the top of our priority list. (The Mac installer is)

You adjust both.

How about a pretty accurate "printed for X time" and "X time remaining in print" values? And a "Printing at height Xmm" value?

You might be happy to know that I set 4.5mm retraction as a default for the next release. And added a retraction on/off checkbox so you no longer need to set it back to 0 if you don't want retraction in a print.

Might be a problem at the X endstops, the sliderblock seems to get very close to the endstops.

Looks like you are having a huge amount of layershift to me. Maybe a pulley is lose, a belt is jumping over the pulleys, or the Y motor is underpowered?

can you show us the 3d perspective of the print model ? just to get a better idea. thanks. Ian You can also find it on thingiverse now: http://www.thingiverse.com/thing:31687

Print speed is the speed the head moves during extruding plastic, travel speed is the speed when moving from one place to another without printing. The default travelspeed of 150mm/s is quite low for an UM, and you can use 250mm/s for travel speed. I've set a default of 150mm/s because it gives good results, while higher can cause missed steps when you have some mechanical issues or a bit underpowered steppers.

Yes. Swapping just the motor cable from the X and Y connector (so X drivers moves the Y motor) and then test the motor, if the problem stays with the motor then the motor or motor wiring is the problem, else it's the driver, electronics or the Arduino.

Not yet final, but should show some changes.

The text in Cura 12.08 is fine. But it's sometimes a bit slow to react, up to seconds. So that could have been your problem.

Try entering 4.5mm of retraction distance, this really helps against stringing.

http://davedurant.wordpress.com/2011/10 ... of-prints/ Has a 0.02mm print from Paul Chandler. Who is like, the Ultimaker resolution wizard.

I'm reworking the checkup wizard. I'm almost done with it, and it will be a LOT easier to follow, with clear indications what is happening, better logging, and pictures to show which endstops to press.

If you swapped the motors cables around did the problem swap with the motor? If that's the case then you could have a cabling problem in your Y motor.

Does the backlight of the LCD lit up or does it stay dark?

It's not possible without some GCode editing by hand. The machine does not know where it stopped. So you have to manually figure that out, and delete all the GCode up to that point. It's difficult to get a good resume.

Depends on the user. I had a week where I left my UM in the Car every day when I got home, because I knew I would take it with me again the next day. For some it's an issue, for some not.

You resume by pressing the button on the controller. And Cura's GCode contains layer comments, so you can easily find the right layer in the GCode

Flexible drive shafts are not designed to handle reversal, that was the main problem with an idea like this.

I think you just need to remove the Z homing from the start code for this. Right the start code assumes the Z0 position is at the endstop. But nothing stops you from messing with the start code to remove this.

I've implemented M0/M1 for this in the firmware if you use an LCD panel. See: http://www.thingiverse.com/thing:23589# ... -655077513 The printing interface in Cura 12.08 also Pauses when it sees a M0 or M1. So it also works from there, but it won't work from PrintRun, as it will send the M0 or M1 to the printer, and the printer will wait for an LCD button push then. The plan is to add better support for this in Cura. But I haven't done that yet.

Yep, looks a bit like I'm working on. But it won't make it in the next release, as it is quite some work, and I want do fix some other things first. Dwindle will be removed in the next version. I always got worse prints with it enabled. It does string a bit less, but it makes the print itself worse. Setting "grouping" is done on priority. Stuff that you change the most is the easiest to access. Not sure if that's always done right right now, but that was the idea. The printing interface is getting some major overhauls. It still a bit messy, but it's the main thing I'm working on right now. I've re-done all the GCode sending code, and the auto-detection code. Which should provide a stabler interface. I'm also adding a LOT more debug logging so error cases are easier to track.