Daid

Not to think less of your efforts. But remember there is more in play here then meets the eye and the simulations. You won't know how your hotend really works with PLA in it, and how it responds to retractions and backflow, until you test it.

I usually use a heavy vice. But another option is putting the gear flat on the table and pushing the motor on top of it. But I thought these came pre-fit on the motors? Or maybe that is no longer done.

Don't forget to let me know if there are any issues. I can hardly test everything and some bugs might slip under my radar. However, I do think this 13.05.2 version is excellent. First I need to do a true release now I think. Then I can work on things like: * Selecting multiple objects, to apply scale/rotation/deletion to all of them. * Better support for dual-extrusion (oh yes, this is happening!), lots to do here. * Proper "duplicate outlines" support, not the half baked SF implementation. Keep on printing!

I've just uploaded 13.05.2 for both Windows and MacOS. This version fixes the large amount of retractions on infill parts. It changes lots of small infill moves into a smooth line with the proper amount of extrusion. It doesn't load GCode until you switch to GCode view, which keeps the GUI responsive in model view after slicing. And most likely I fixed a few other small odds and ends. I sometimes forget to note down small fixes. And finally: It adds 3 new "Fix horrible" settings in the expert menu. These settings modify how the slicing works in some odd ways and can help in properly print "bad" models which are not manifold. As the all effect which parts are seen as solid and not. I'm working on another setting for this, which can also produce better results on some models. All these settings are at your own risk and always look at the final GCode, as odd things could happen. The new setting that I'm working on will be called "extensive stitching", and will take some time to implement. I just tested the retraction settings on this version, and there they worked. (Illu, your comment about faster printing has been noted, and I'm thinking about how to improve it)

The new 13.05 beta improves this, as it fill fill up the gaps that are left empty in the old version.

You could also slice with top and bottom fill and remove the first X layers from the GCode.

In my experience, z-hop makes everything worse as it leave nasty blobs unless you print slow and at a low temperature.

You're asking for a top/bottom of 0.0, that's just asking for holes like that.

I was also thinking about that. But, if there would be an issue with using G0 for the move, then I can quickly change it back. Exporting the GCode commands as GCode is really the final step. There is only one "G0" in all of the code, an 3 "G1" commands (1 for extrusion, 1 for retraction, 1 for pushback) Changing them would be easy. Why did I use G0 for moves? Well, because I see the option to have different feedrate modifiers for G0 and G1, which would make it possible to influence the print speed separately from the travel speed. EDIT: Oh, and getting a good first sticking layer without retries is important for "project planner" prints. You might see a failed first layer and restart, I fire&forget quite often.

Note, it's not extruding during the blue moves. Those blue lines are just moves without extrusion. But, yes, they do scar the surface. The new engine does a bit better, but there will always be moves on the top surface, no way to prevent it without teleportation.

When I make a full public release the source-code will also be released. I know it's kinda annoying, but I also have manuals and marketing to think about now. The downside of Ultimaker paying me really. But if you have a github account, I could grand you access already. All the code is already on gibhub in a private repository. Once I release it's just a switch from private to public.

On the update front. I've just made some code which optimizes the small zigzag lines into a smooth line. So no more massive vibration on thin walls. I still need to print with it, but the GCode looks correct. This should also save some print time and make the print time guess from Cura a bit more accurate (less small moves is less acceleration error)

I noticed in some of my "less then perfect" prints, that if the bottom infill is not put down properly the next layer becomes critical. Going too fast there will rip off the print due to curled up edges. It's also important to still go slow on the 2nd layer if your bed is too high, as you can get ridges because of "overextrusion" then. But, due to the comments I put in the GCode, it should be quite easy to write a post-processing plugin for Cura that does what you need. No need for separate G commands there.

You mean like, the "initial layer speed" from the advanced settings?

I'll make an incremental release somewhere this week. As for the order at which things are printed. This is a separate piece of code. It's called the "pathOrderOptimizer", this piece of code is given a whole bunch of polygons or lines for the infill, and then figures out in which order to print them. Each line of the infill is seen as a separate entity for printing order. The current implementation just picks the closest next thing to print. This could be made a lot smarter, but it currently works pretty nice. (In the end, it's a http://en.wikipedia.org/wiki/Travelling_salesman_problem ]traveling salesman problem[/url] which is difficult to solve properly) Note that sparse and full infill lines are handled the same and as 1 group. There is no special code in place for the order of any of the infill lines, everything is handled by the same piece of code which has no knowledge of the infill routine.

I'm pretty sure Martijn (original designer and current maintainer of the design) wouldn't like a big ugly hole in the side like that. Vacuuming or turning your machine upside down does a pretty good job of cleaning it.

Most likely it's a problem with the darlington transistor on the board. It's near the fan connector and when it breaks the fan is always on or always off.

I think I managed to fix this. I had an example which did exactly the same (I visualized retractions to help me find this). Some details, what is happening, there is the combing code. Which tries to avoid holes by moving inside the model. Now, this code isn't 100% perfect but works 90% of the time. And in the other 10% of the time, it detects that it failed to comb properly and will retract. This combing used to move exactly on the outside of the model in numbered betas and 13.05. In 13.05.1 I moved the combing path mode inside the model. However, the added effect of this was in thin walls, the combing code thought it failed to comb properly and thus retracted. As for Lars, I think the infill might be printed too fast or some other physical effect. I've seen it before, but not 100% sure what's causing it.

There is always the possibility of a bug, I thought I implemented the slowdown correctly, but I could have been mistaken. Best way would be to compare resulting feedrates of different sliced versions.

Saying it's good but not tested the hotend... which is a highly criticle part. 0.1mm resolution isn't that greate for accurate FDM printing, and achievable with any RepRap build. If you wanted a quality build X/Y/Z system, you could have gotten an OrdBot for 1/4 of the price.

Ah, I see the "lots of retractions on thin walls" now. I see what is happening, and I did introduce it in 13.05.1 (due to a change in the combing code) I'm not 100% sure on the proper fix yet, but I have some ideas.

Mmm, yes, retraction enable tickbox... ok, fixed for the next version (silly me) Not sure about those small moves with retraction, I'll have to look. It shouldn't be doing that. I'll see if I can make a test case.

It's also a box, with an X/Y gantry system. That's about where the simularties with the Ultimaker stop. Closed system, with mostly stuff that looks like being copied from the Replicator and UP! printers. But I'm glad that my work goes pretty much unnoticed by you. If you are still using a Cura from November that you are missing some things.

This is mostly an software issue. Which is improving quite quickly. The current released Cura has problems with large models (100k polygons? not sure) But the next version of the Cura software handles much larger models. For example, I'm working with a model right now which has 1 million polygons. But I would say keep it around a few 100k maximum unless you need the extra details for some reason.

Someone at Ultimaker came with the perfect test piece, it took 5 minutes to slice, which I reduced to 22 seconds for the next version.