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.
-
Have been working on some realistic timings to gauge the benefits on additional gantries.
Findings for the benchy model segmented into 4, 6 and 8 - for 2, 4 & 6 parallel gantries.
Doing outer walls in a single pass drops the percentage saving quite a bit (14-17% additional savings in these examples) - but I still think it is probably going to be worth doing for models that need to look good.
-
@dwuk I have a question regarding your segment width: From your last screenshot I guestimated in relation to your buildplate grid, that your minimal segment width is about 20mm. If I undestand correctly, you print every other segment simultaniously (like darker grey, green, red and blue) and then switch to the other half of the segments (the white ones) to ideally never have to park a gantry. My question would be, if those 20mm are a realistic assumption: If you have only two gantries, you can probably design a extruder, that has the nozzle axis quite close to one side (like the J1 Extruders but rotated), allowing you to put the nozzle axis planes of two gantrys about 20mm apart with additional hardware sticking out further to the front and the back. But if you have more then two gantries, the whole gantry width is relevant including aluminum profile, linear rail and carriage, motor, fan etc ... So, do I misunderstand something, are you using stand in values or is the buildplate texture differently scaled?
-
@JVan Well spotted - in the example the minimum segment depth is as you surmised only 20mm on a 256mm Y AXIS which isn't really practical for anything above 2 gantries (where you could rotate them around to get the print heads fairly close).
To go above 2 gantries using this approach the Y axis is going to need to be quite a lot large - 768mm for example would mean you could multiply the 20x3 - to get 60mm - which is still pretty small for current designs of extruders I know.
I think I should probably stick to a maximum of 3 gantries in later examples - maybe with unequal segment sizes to take in to account the centre gantry being rotated to face one of the others.
For 4 segments - pushing up the minimum size from 20 to a more practical 50mm doesn't lower the saving percentage too much - this equates to 100 on a 500mm print bed.
-
This might work as a suitable first test platform.
The print heads are quite big - about 100mm in total depth on a total 350mm build plate - but there is a fair bit of space at the back to allow the nozzle to get right to the back of the bed - so there should be scope to fit 4 reasonably sized segments on. It might be possible to reduce the depth by moving the fan and circuit board that take up a fair bit in front of the nozzle.
Quite a lot of extra weight on the flying Z gantry - with 6 extra XY motors, 3 extra print heads and an extra Y gantry -
It might be feasible to expand the size in the Y direction - by moving the Z gantries back - ideally about 200-300mm, and extending the length the the Z gantry side parts and the top side frame.
-
@dwuk I'm concerned about the moving mass of the flying gantry. If I'd build such a printer from scratch, I'd choose a moving bed.
And I'd flip the front cross bar, so the green nozzles face the others
-
@o_lampe You might be right - I have been thinking about a Double Voron Tridex - but the price of the SV08 and the fact that it is mostly pre built is pretty attractive to me.
It might I guess even be possible to adapt it to have a moving bed instead of gantry.
I agree that swapping around the front heads would help with parallel printing - but then that would limit the ability to make the front heads tool changers - like @TeachingTech is trying to develop with the stealth changer people..
9 colours, 4 or which could be printed in parallel is getting close to the perfect printer for me...
Shame the SV08 print heads are so big.
-
@dwuk With a toolchanger the frame is pretty cramped. Imagine you want to replace the left green tool with the right-most parked tool or the other way round....
-
@o_lampe I think you are right - didn't think about both print heads needing to tool change at the same time.
Have reduced the numbers of racked tools to 4 - but then added a second row for the back gantry to use. - Would obviously need hardware and holders.
I think I could as you suggested flip the whole front gantry and racked tools around - too - so that all of the racked tools are in the middle - however for the purposes of aesthetics I'll leave them facing all facing in the same direction for the simulations.
