Small top layer finish with bore - solved

[Dim3nsioneer 558]

Hi there

Various people had difficulties with printing a very small top layer without getting a blob at the end. A good way around that problem usually is to reduce speed and temperature.

I now have a print to do with a small dome on the top and exactly in the center of the dome is a vertical bore which must not be closed.

As it is very difficult to see it from the actual print, I show you a screenshot of the layer view.

The problem now is that after printing the last bit of the last layer, the print head stops, retracts and then lifts. The time the hot nozzle spends there is enough to melt enough material for at least partially closing the central bore.

These are the constraints:

- the central bore has to be there with this size

- the print has to be oriented like that

What would you do to solve this situation? Any idea for tweaking, by plugin, manually in the Gcode or by hardware is welcome, especially if it based on your personal and practical experience.

For me, the long term solution is clearly a distinguished implementation of the G0 commands in Marlin which allows direction change in one axis (extruder) without changing the speed on other axis (x/y). But that's something for the future... and not the work-around I'm looking for right now.

 

[illuminarti 18]

What are you printing this on?

Z-moves are always pretty slow, and retractions are slow-ish, too. Why not just manually coding a movement of the head away from the print at the end? Perhaps a fast lateral move, optionally with a small/fast retraction first? Or maybe even jsut move the head straight up at the end a few mm, so that the head gets off the print as fast as possible? That will probably leave a string, but that should be pretty easy to clean up.

 

[Dim3nsioneer 558]

You're absolutely right. I thought of that as well. The 'problem' is the synchronization of the axes in Marlin for both G0 and G1 moves. :huh:

Within the very last G1 cmd of the print itself, there is a small lateral movement and a positive e movement. If I now add another G0 or G1 cmd with a lateral movement and a non-positive e movement (i.e. no e or negative e) then Marlin stops not only the e axis but all other axes as well due to synchronization.

However, only the shortest stop on the top makes the material (_XT, that's the reason why I didn't show an image as you would see nothing due to partial transparency) melting again, at least enough to partially close the bore.

The only way around I see right now is to add another G0/G1 lateral movement with a positive e step, i.e. keeping the extrusion going on as long as the nozzle is close to the top, e.g. for a few mm and then retract the filament and so on...

But there may be other options I haven't thought of... :???:

 

[illuminarti 18]

I'm still not sure I understand. If you do a multi-axis move, then the speeds and accelerations used on all the axes will be blended to ensure that no axis exceeds its limits. And in fact there's a bug in how accelerations are blended that might reduce the acceleration even more than needed.

But the only consideration when moving the head away from the print is the jerk setting. if you move the head away at a sharp angle, then it is going to slow down a lot to satisfy jerk limits. But if you move the head away more or less inline with the last printed segment, then that should allow the move to happen more quickly I think? Don't bother trying to retract initially, just move away, and deal with the string later. Once you're off the part, then you can retract, raise, and home.

Another possibility might be to try increasing the jerk setting via gcode - e.g., right after the last segment prints - again to allow a more fluid movement away with less slowing.

 

[Dim3nsioneer 558]

But the only consideration when moving the head away from the print is the jerk setting. if you move the head away at a sharp angle, then it is going to slow down a lot to satisfy jerk limits. But if you move the head away more or less inline with the last printed segment, then that should allow the move to happen more quickly I think? Don't bother trying to retract initially, just move away, and deal with the string later. Once you're off the part, then you can retract, raise, and home.

 

Hmmm... could be I added a movement perpendicular to the last printed segment...silly me... :roll: I have to check. The x/y jerk should be big enough as the last segment is printed with 10mm/s (I think I have it on 20mm/s). Immediate retraction certainly is a no-go as Marlin then makes the print head stop after the last segment (due to what I call synchronizing; it's the trapezoid thing in planner.cpp; do you mean this with 'blending'?). btw: would the fw retraction (G10/11) also cause this...?

 

[illuminarti 18]

The velocity where two planned trapezoids join is just whatever is needed to satisfy the jerk setting on any and every axis that moves in either of the joining segments. The e axis has a very low jerk setting by default - 5mm/s (and z is even lower). So maybe going from slow forward to immediate fast backwards on e is violating that jerk limit and slowing things down.

That said, merely stopping extruding while continuing to move the head in the same direction should allow smooth movement without a pause I think?

What you probably don't want to do is move in z at the same time as any other axis, as the jerk and acceleration settings on that axis are very very low. And when the planner 'blends' the requirements for each axis (adjusting speed and accelerations to ensure that no axis exceeds its own limits, while all axes still move in lockstep (synchronized), it actually gets the acceleration part wrong, and may use an excessively low acceleration. (See https://github.com/Ultimaker/Marlin/pull/7, if you're so inclined).

 

[illuminarti 18]

If I find the time, I might do some tests of the different cases with some sample line segments, just to see exactly what the behavior is at the corners...

 

[gr5 2,269]

I recommend you use the cura setting "cut off object bottom" under quality and do a few tests where the "top" of your part is now only 1mm off the bed.

 

[Dim3nsioneer 558]

That's more or less what I've done so far. I will not print the whole part before I get reasonable results for the top.

And I even found a tiny bug in Cura by doing so. And Daid already fixed it...

 

[IRobertI 521]

Didn't cura do what Illuminarti is describing in the past? Later versions of cura leaves an ugly string that can go all the way from the top of the object back to the parking position of the head sometimes. I'm pretty sure the behaviour in the past was very quick sideways move at the end of the print before retracting and moving out of the way fully. It left the top of the object pretty much perfect.

If editing the file manually after slicing is too much of a pain I'd switch to reprap-flavour and do this in the end code instead.

 

[Dim3nsioneer 558]

it sometimes leaves a string, yes. But in most cases this string can be cut away easily.

Putting a standard behaviour in end gcode seems a bit risky to me as if forgotten there, it can do more harm than good with other prints. btw: I don't have to switch the flavour as I have an UM1...

 

[Nicolinux 288]

@Robert: Aha, I noticed this behaivour too and wondered if it was always like this. I wonder which Cura version introduced it.

 

[Dim3nsioneer 558]

illuminarti was right once more...

After being away from my UM1 for more than a week I finally found the time this morning to find a proper solution for the central bore closing issue. The last time I added a lateral movement I indeed caught the wrong direction and produced a perpendicular movement... :wacko:

This time I added a movement in exactly the same direction as the last printing move. I skipped the velocity and the extrusion argument (F and E). Obviously, the E jerk was large enough to allow the additional G0 movement to be performed without decelerating the print head.

And this is the result:

 

So the issue is solved. It's now printing the whole thing including the 133mm I cut off for the test...

 

[illuminarti 18]

Great! I'm glad you were able to get it working!!