Looking for beta testers.

[lars86 42]

Thanks for the update Daid!

The triangle infill idea sounds cool. What if it laid down one set of parallel lines, followed by a set at 60* to those, then third third set. Whenever the print head gets to an intersection point (2nd and 3rd sets), it does a very short rapid across it to prevent an overextruded blob.

 

 

Thoughts so far on 13.05.1:

Outside quality is looking good

The new grid infill pattern end up being only a pattern of very narrow, free standing columns, where the lines cross. Works great as a low density inner support. But it is not a strong form.

In some areas of the print, it infill behavior is strange. It stays very near the perimeter and essentially vibrates. This causes the head to dwell too long near thin overhangs, heating them up. I think it is trying to produce an area of 100% infill, underneath a soon to be exposed layer. It just seems like adding more perimeter passes would accomplish this without so much dwell time and vibration.

https://dl.dropboxusercontent.com/u/60958586/VIDEO0052.avi

 

??

 

[illuminarti 18]

??, Lars?

 

??

 

[lars86 42]

I was hoping that Daid would have some feedback.

[Daid 306]

Retraction is working for me in 13.05.1 on a Mac. Indeed, if anything it's working too well...

I have a print that has a 10cm long, 2mm thick 'thin wall'. With a 30% infill setting (and my non-standard 0.65mm nozzle), I end up with infill sections that are roughly 0.75mm long, and spaced about 2.5mm apart. And it does a retraction between each of them.... the extruder gear goes crazy filing in the wall - constant back and forth....

The net advance of the filament in between retractions is only about 1.75 microns - enough to extrude about 1/10mm³. After a while, it just gets too much, and it starts to grind the filament.

 

Not exactly sure what to do about it - maybe infill in thin wall sections could be done differently - longer diagonal moves, maybe? Maybe there needs to be some sort of minimum incremental extrusion since the last retraction, before another one can happen?

A crude solution would be the ability to set the minimum move distance for retractions to happen - but that seems to be missing currently.

 

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.

 

[illuminarti 18]

Thanks for tracking it down, Daid! Will there be another incremental release soon?

Here's another thing I've seen with the new slicer, when slicing a large flat piece.... (say a rounded rectangle 20 cm x 5, diagonally oriented on the bed)...

The printer usually ends up at one end of the shape, and needs to do a long fast travel move all the way back to the opposite end, in order to start the next layer. I've found that sometimes - especially when printing the first layer or two, there can sometimes be a little roughness in the layers - due probably to the bed level being fractionally off, so that there's a bit of an excess pressure build up in the head, leading to a touch of over extrusion on the next layer... and particularly visible as the head slows and accelerates again at the end of infill passes. That's not the problem, though.

The problem is that those long travel moves can end up catching on the over-extrusion - at the least this damages the print surface, and sounds awful. At worst, I've had it cause skipped steps.

Even without the physical catching, in previous (SF) versions of Cura, I'd often end up with ugly scars across the inside bottom of cups and bowls due to travel moves over the surface - even with retraction. Not sure if that is still a problem with the new slicer...

Another less than perfect thing has historically been that if infill starts in the middle (longest diagonal of a square, for instance) and works to one corner, and goes to the corner, and then goes back to the middle to work to the other corner, you can often end up with quite visible differences where the two halves touch, due to gradual variations in filament color, temp, etc which then get positioned next to one another.

This all leads me to a couple of thoughts....

1) I think that for some moves at least, it would be good to consider raising the z - especially for moves over large areas of solid infill on the bottom of the print (where z-height issues might still be working themselves out) and for layers that represent finished horizontal surfaces. This will avoid catching and scars.

2) On finished horizontal surfaces, make sure that the solid infill is printed continuously wherever possible - work from one corner to the opposite one, rather than starting in the middle and working outwards. I.e., for exposed layers, pick a toolpath that emphasizes aesthetics over efficiency, if you have a choice.

 

[Daid 306]

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.

 

[illuminarti 18]

Ok, thanks! Look forward to testing it out.

One thing I've often wondered about is whether it might be worthwhile to have multiple different G-codes for different styles of printing: expanding the G0/G1 fast/controlled move idea, to allow for different G codes to indicate perimeters, loops, sparse infill, solid infill, exposed infill, etc.

Obviously this would have to be an optional feature in the slicer, and require firmware support. But it seems like it might make it easier to post process gcode, and also allow the firmware to make smarter decisions about how certain paths are drawn at print time, and/or allow for more fine-grained live-tuning by the operator.

 

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 traveling salesman problem 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.

 

[illuminarti 18]

And while I'm wish listing, I'd be really interested in being able to selectively slice/print the (second and subsequent) base layers at a different speed from the rest of the print.

It's typically one of the most time-intensive parts of a print, with lots of solid infill, but it's also super-easy to print since it's perfectly supported by the bed and solid layers below. And, apart from the very bottom layer, no one sees it anyway.

I find I can print these base layers very, very fast (subject to throughput volume limitations), but I wouldn't want to do all solid infill at that speed - for upper layers that are going to be visible and/or print over sparse infill, I'd want to print at more reasonable speeds to ensure a nice finish.

So, being able to control the speed of the base separately would be helpful.

[Daid 306]

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

 

[illuminarti 18]

I'd want to be able to do the first layer at one speed - probably slow, to get it to stick.

Then do the subsequent solid infill on the next layers really fast (because you can, and no one ever sees them). But keep the perimeters at a reasonably slow speed (because they are seen).

And then once the bottom thickness is done, change to the main infill speed for the infill in the rest of the print.

 

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

 

[gr5 2,167]

The last time I printed the "ultimaker robot" I did something similar. I usually use the UC to print but instead I used Cura. I set the perimeter speed at 50% and left the infill and other speeds at 100%. So the visible portions printed slower.

Also, if you print an iphone case you want the bottom layer to come out as the best layer. Sometimes you *do* care about the bottom layer more than other layers.

 

[illuminarti 18]

Yes, definitely. The very bottom layer is critical for quite a few of my projects. The solid layers immediately behind (above) it are usually less critical though, and just need to be there for strength.

 

Also, if you print an iphone case you want the bottom layer to come out as the best layer. Sometimes you *do* care about the bottom layer more than other layers.

 

[Daid 306]

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.

 

[Daid 306]

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)

 

[reeper 0]

Hey Daid,

Not to nag, but do you have a rough idea of when we’ll be able to peruse the code of your new slicer engine ? I’ve been eagerly awaiting the possibility since I had the chance to chat with you at the Erfurt conference.

 

[Daid 306]

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.

 

[illuminarti 18]

I pretty much never have first layer adhesion problems, and if I did, I'd probably start the print over anyway, so for me there would definitely be a use case for the faster solid infill layers on the base layer only, as I described. Sure, it can be done with plugins (are plugins working in the beta?) but equally, since I think it's a distinct (if often overlooked) area of the print where a different speed might be very useful, I'd urge you to consider adding it as a part of the slicing profile.

And regarding the new gcodes, I still think that there may be value in having a systematic way to tell the firmware what type of path it is printing... comments are an ok workaround for post-processing plugins (although not ideal), but you wouldn't want the firmware to have to parse comments. I think it would open up a lot of opportunities for print-time optimizations if the firmware knew what it was printing.

While slicing is a very quick and easy thing to do (now, thanks for the hard work on the new Engine - it's a huge improvement!) - printing still takes a very long time. For that reason, it's not the same as a 2D printer, where you don't have any reason to care about the language that the computer use to talk to the printer. Yes, they can all just be pixels to a 2D printer, because you don't tweak the print on the fly - it's all quick enough that if it doesn't come out perfect, you just start over, and can do all the refinement on the computer end of things.

As a result, I think it makes sense for the printer operator to have as much control over the print process as possible, and be able to change speeds, temps etc selectively as the print progresses, with more granularity than the all-or-nothing control that we currently have. Separate gcodes for different parts of the print would be a huge step forward in this regard.

 

[illuminarti 18]

Thinking about custom gcodes made me realize something... In the new slicing engine, I see that you are using G0 for the moves. Which is a good step forward in terms of the logic differentiation of different types of moves, so thanks... except...

Isn't it technically wrong to use G0 for these? Because while in Marlin they are the same as G1's, as I understand it the point of G0 is that in theory the axes don't have to move in lock-step with one another. This means the path doesn't have to be a straight line, right? Which means that all of your carefully planned travel paths may not be going where you think they are...?

 

[Daid 306]

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.

 

[illuminarti 18]

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.

 

Which is exactly why I'd like to have other G codes for other aspects of the print. :-)

And regarding the first layers... I was being polite. :-) Unless my z-height has just gotten grossly out of whack (which is obvious the moment the skirt starts), I get 100% first layer adhesion every time, and zero base warp. I do my first layers at 70mm/s usually, and only re-level the bed every week or two.

Which is not to say that you don't get different results with your use cases and hardware. But I still think that it would be very useful for those of us that can to have a bit more flexibility in the speed selection.

 

[thomass 0]

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)

 

That sounds very good.

Thank you.

 

[gr5 2,167]

This "layer 2 different speed" is such a simple plugin. In fact I think there is already one existing. This is the easiest kind of plugin to write or to take an existing one and modify it. This is a great case for a plugin.

 

[illuminarti 18]

Yes, it is.

But it's also a great way to improve the user experience for all UM owners by encouraging them to reduce print times, while maintaining while maintaining quality. Printing the base of most prints is a major pain and time drag, and I suspect that a lot of people could significantly speed up total print times if this bit could be optimized - and in my testing, there's a lot of room to do that.

 

This "layer 2 different speed" is such a simple plugin. In fact I think there is already one existing. This is the easiest kind of plugin to write or to take an existing one and modify it. This is a great case for a plugin.

 

[darrenm36 0]

Hi Daid,

Great work on the new version of Cura.

However with version 13.05.01 I'm having a few retraction issues. It's doing a lot more retraction than previously which is slowing things down a lot, and from following the thread hopefully your new changes will help here.

But I used to have my retraction setup really well, but in 13.05.01 I'm getting a lot of stringing. So I went back to one of my calibration objects and tried to recalibrate but found when I made changes to the retraction settings nothing changed, including the gcode file.

The process was.

-load model

- progress bar goes across

- save to SD card

- change retraction distance

- progress bar goes across

- save to SD card

- change retraction speed

- progress bar goes across

- save to SD card.

This give me three files.

When compared by Notepad++ the three gcode files are identical except for the date and time sliced.

So its generating a new file, slicing at a new time, but the retraction speed and distance aren't affecting the gcode.

Any thoughts?

Keep up the great work.

 

[Daid 306]

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)