Cura 4.0.0 - Z Seam Alignment "Shortest" doubt

[amagr0]

Application Version - CURA 4.0.0
Platform - Win 10 Pro, 64 bit
Display Driver - NVIDIA GeForce 840M

I thought this parameter will work in this way: the last extruded position on the previous layer will also be the position where layer change will occur (and so the print will quicker), but is seems that is not the case.
So how is suppose this feature to work? What is the meaning of "Shortest"? The description seems to not explain what is really happening.

And what's the influence of the Layer Start X and Y on the Z Seam Alignment?

In the image below you can see the last extrusion position and the long travel to a new position where the layer change will occur.

Thanks

[smartavionics]

Hello @amagr0 , since CuraEngine became multithreaded, the layers are computed concurrently rather than sequentially so when any one layer is being computed, the end location of the previous layer is unknown. So the layer start X/Y position is used to determine the position of the first item to be printed on the new layer. As you have found, that does not have to be near where the last layer finished.

[amagr0]

Hello @smartavionics,
Thanks for the clarification but I'm still not understand how the Shortest option will work if "the layers are computed concurrently and the position of the previous layer is unknown".

And what will prevail the position of the Z Seam Alignment or the Layer Start X/Y?
For example, if:
Z Seam Alignment: Sharpest Corner
Layer Start X: 0
Layer Start Y: 0
What will happening with the model in the below image (arrow: sharpest corner / square: X0 Y0)

Thanks

[smartavionics]

The z-seam shortest option is obeying "when you go to the next part's outline, choose the vertex that is closest to the current position". This decision is repeated for each part on the layer. For the first part on the layer to be printed, the current position is considered to be the Layer Start X/Y, for the subsequent parts on the layer, the current position is, well, the current position.

I would have thought that it will start at the position pointed to by the arrow although, the sharpest corner algorithm is naughty in that if there is a tiny sharp corner somewhere on the outline, it can choose that location rather than at the more obvious sharp corner. Personally, I very rarely use the sharpest corner z-seam preference. I nearly always use the User Specifiied z-seam X and Y.

[amagr0]

I'm also personally don't use the sharpest corner option, most of the times I manually choose x and y coordinates.
I'd like to see one day the Shortest option working as I described before - the last extruded position on the previous layer will also be the position where layer change will occur - this definitely will decrease the print time and will reduce some retractions, and also some under-extrusions on the beginning of the layers.

[smartavionics]

I can't see that happening unless there was a Cura option to not use multithreading and compute the layers from the bottom to the top sequentially like it did in the slow old days.

[amagr0]

They can use multithreading, they just need to know where is the start and the finish position of each layer, it will need maybe a second time slicing. With the first slicing they find the positions, and with the second one they will generate the final gcode.

[smartavionics]

I don't think so. To find the positions you need to generate the gcode to know where the final position is. For example, when a region of infill is printed, you don't know the end position until all the infill in that region has been computed so you can't work out where to go next without computing the infill.

[amagr0]

I'm just talking, I really don´t know the complexity of implement/optimize this, but this is how Simplify3D works since the beginning.

[smartavionics]

And it is how Cura used to work before it became multi-threaded. The Cura devs do tend to prefer to have faster slicing in preference to faster or better quality printing. Personally, as I only print small items, I prefer to have better quality prints and don't care too much about slicing time (within reason).

[amagr0]

Maybe they can find a solution and one day we will have both faster slicing and a better quality prints.
But quality should always came first.

[Ghostkeeper]

But quality should always came first.

To a certain extent, of course. Have you ever used Skeinforce you'll understand that this is a trade-off.

Hello @amagr0 , since CuraEngine became multithreaded, the layers are computed concurrently rather than sequentially so when any one layer is being computed, the end location of the previous layer is unknown. So the layer start X/Y position is used to determine the position of the first item to be printed on the new layer. As you have found, that does not have to be near where the last layer finished.

The multithreaded issue is only a problem if you're printing walls before infill (which is not the default) and then only for the first part of a layer and only if there is no support on that layer, no prime blob, no prime tower, no skirt, brim or raft, no ooze shield and no draft shield.
Selecting "Shortest" will choose the corner that is nearest to where the last line was drawn on that layer, or if no lines have been drawn yet the corner that is closest to the Layer Start X/Y position settings. So if you're printing infill before walls it will be close to the last infill line's ending. If you're printing walls before infill it will be close to the previously printed part or the Layer Start X/Y.

Due to the multi-threaded nature of CuraEngine working on a per-layer basis, the travel move between two layers can't be optimised. Shortest will only optimise travel moves within one layer.

[nallath]

I can still remember the time that we only had skeinforge. It was horrible. You had to start slicing your next print when starting your current print because the slicing took as long as the printing.

[al-65]

I had commented this elsewhere before, but here is that idea again.
If multithreading is such an important feature, could CURA not schedule ranges of layers to each thread? For example, let the 1st thread process layers 1 to 10, the next one 11 to 20 etc. If a thread finishes, it would be assigned the next 10 layers and so forth.
This means in 9 out of 10 layers the "shortest" seam would work again, without loosing processing performance (on models with enough layers).

[NitemareReal]

To be honest, I prefer (in 99 % of cases) that Cura takes 4 minutes in calculating sequential layer slicing versus 1 minute, but having a 7 hours printer time versus 8 hours...
Parallel calculations for layer slicing are supposed to be faster than sequential... Cura may have a serius problem with the algorithm because we all know about commercial software that do sequential layer calculations much faster than Cura's parallel layer calculations...
I have tested that commercial software and I couldn't imagine how much time Cura wastes when a layer ends in a corner of the bed and nozzle has to travel back to the opposite corner to start a new layer... that's simply crazy!!

[al-65]

Fully agree!!!! And as said above, a solution may be to assign not single layers but ranges of layers to threads, so that those extra travels would only occur every 10th or so layer...