IDEX BOTH ON CORE XY
-
@o_lampe. Interesting, I am intending to include some example print time comparisons with nozzles of different sizes in the same print. Is infill every N layers something that is available in any of the prusaslicer based slicers - as when I tried some comparisons (by using prusa XL profiles) it looked that you have to use the same layer height for the different nozzle sizes - which still brought some good savings.
-
@dwuk Its this setting. Setting it to 2 will result in double height infill lines:
On Orca and (probably) Bambu its this. Here you set infill layer heigth directly. Either as mm or as % times nozzle diameter:
-
@JVan Added an option to colour each segment differently so that that they are easier to see.
Then for the parallel print segmentation I have simply offset all of the segments on alternate layers by a specified amount and I think it works quite well - so great idea thanks.
Screenshot with outer walls segmented - so that it is easier to see the offset joins
Or with the outer walls non segmented -
Will do the same to the mirrored segmented version next - will need to grow the width of the non mirrored section in the middle on both sides on alternate layers to get the same effect.
-
@JVan thanks - will try those options out.
My Blender simulator doesn't currently support multiple nozzle sizes - but should be fairly easy to add.
-
@dwuk said in IDEX BOTH ON CORE XY:
but should be fairly easy to add.
In the meantime, for simulation you can reduce infill to 25% of the actual value when you plan to use double layer thickness and twice the nozzle diameter.
-
Trying to improve my algorithm for sizing the Y Axis segments when a) Up to 4 gantries are available and b) where the amount of extrusion time is unevenly spread across the print area.
In the first instance there are fairly big constraints on the minimum size of the segments due to the need to avoid head clashes.
Only when segments have reached their minimum sizes is there any benefit in using additional gantries in parallel.
And also it is only feasible to vary the start points and sizes of the segments to match better with where the extrusion is happening once the minimum sizes are all reached.
The attached is my attempt at working out (based on a minimum gap in the example of 3 or xxx) when it is worth starting to use extra gantries - which is highlighted in yellow.
The pink highlighted segments are then marked as the ones that can be varied in sized in order to better spread them over where the most work is needed on each layer.
I have changed my post processor to in its first pass collect an approximation of how much work is needed in each Y integer dimension in terms of raw extruding time - by dividing the length of the extruded move by the rate ( I know this is not completely accurate due to acceleration and deceleration) - and then dividing this by the Y movement and spreading these extrusions out evenly over each integer dimension in the range.
Will then try to use these calculated figures to help decide how the segments can be shifted around in order to make them as balanced as possible in each of the two passes.
Will then also consider slowing down the rates slightly in the segments that have the least work - so that ideally all print heads are in use for most of the time - rather than being intermittently idle and therefore causing oozing.
-
@dwuk It seems the post processor is pretty busy. Munching through GBs of gcode is much harder than splitting an .stl file of several MB.
Do you use an SBC or external CPU? It would be cool, if you could process layer by layer, while already printing.
You don't want the whole processing take longer than reducing printing time ...PS: Maybe you'll find a ready to use "center of gravity" calculation code? To me this is a close enough approximation for the best coordinate, where to put the cut.Would only work when cutting the .stl file I guess.... But maybe that's the right way of processing:- decide where to place and cut the object , based on the stl file
- then do the cut in the gcode file
-
@o_lampe Yes the code is getting a fair bit more complex. So far I don't think there any cross layer calculations so it could potentially be done just in time layer by layer, however ultimately I think it would best be done on the CPU that is doing the slicing (or as part of the slicer).
A present I am doing the processing on a MacBook Air in python.
I found an error in the segmentation of the early examples where I was using an X rather than Y coordinate - correcting this is making the segmented models look a look more evenly split.
Just now need to address the slightly shifting around of segments for more efficient splitting - or for example the front (Green/Grey/Orange) and back (Black and Blue) of the cab in the attached 8 way segmented example (Shown without outer wall single threaded)
Version with layers alternately offset (probably a bit too far) for improved strength.
Will consider whether working the segments out from the centre (or most dense area) has any benefits when I am working on tweaking the segment boundaries for more efficient splits for parallel printing.
-
@dwuk Illustrated a bit better on this version with pass1 4xgantry nozzles all in white, with pass2 in multi colour - the issue I would like to address is the really thin (and therefore inefficient) green and red sections at the bottom front of the cab and white and the back of the cab.
-
@dwuk Going down a bit of a rabbit hole with the tweaking - decided to try accurately calculating the time for extrusions - including acceleration and deceleration etc - not sure if these calculations are correct - but probably doesn't matter too much at this stage.
Then used this to select passes with segments in them which quite a big print time difference and then have simply taken the segment with the longest time and either reduced its size down to the minimum size it can be for head clash avoidance, or halved its size. I have then added this adjustment onto the segment with the shortest time.
It didn't select the layers I expected - probably because the segments in the cab are already at minimum size.
It makes the print look a bit more messy - but at least I can pick out the adjusted layers quite easily,
Will run some prints through my simulations with and without the adjustments to see if the layers that have been adjusted print any more efficiently.
Example 3 gantry print shown - with pass1 heads shown in white and pass2 multi colour.
-
@dwuk I'm impressed, you came quite far with simulating all the different splitting algorythms.
But isn't it time to make split versions for one tool head? Just to see the real world output of your mods with inner layers overlapping and tons of retracts...I can think of several things that can go wrong trying to print the first layer. It's already nerve-wracking with a single object, although print surface and bed-adhesion has improved a lot.
We know from former dual tool printers, how hard it is to find the sweet spot regarding z-height (and without mesh levelling)
Somehow the second tool always scratched off the freshly laid tracks of tool one... -
@o_lampe Thanks and agreed - will be interesting to see some actual single print head test prints to see what I need to do in terms of retractions and zHopping etc. to get them to work. Printers currently out of action due to house guests - but hope to be able to get access again at the back end of the week.
