Posts made by o_lampe

@dwuk said in IDEX BOTH ON CORE XY:

It looks like the Voron Tap might be a possible solution - although it might not be accurate enough to take into account mesh adjustments if it just uses a servo.

Yes, a servo wouldn't be the best option for mesh levelling. But there is another problem: You'd have to calculate the z-adjustment of the "mini-z axis" based on the current XY position of the other tool (which uses the classic mesh leveling) or have a mini-z axis on every tool.
Unfortunately RRF allows only one z-plane and it doesn't provide "realtime" XY coordinates.
You could direct the real z-motion to the main steppers (during layer change, homing etc.) and redirect the z-adjustments to the mini-z axes.
Your post processor can easily detect, which is which:
If there's no E(xtrusion) value in the gcode line it's a real z-move
If you see a retraction/unretraction gcode with z-hop or a gcode line with extrusion, it's a mini-z thing.

@dwuk There are two different methods:
G32 = calibrating the bed tilt, by probing next to the leadscrews
G29 = using a probing grid or continuous probing to create a mesh

@dwuk Regarding Z-hop: I made a dovetail(ish) hotend mount for a different project and it was meant to adjust z-height for each toolhead individually. A motorized version with a small geared N20 motor was in the making, but the FW didn't have means to poll the heightmap for dual head printing (2021). Also driving dc motors with encoder was experimental, now it would be much easier with the step/dir interface of simpleFOC.

@dwuk said in IDEX BOTH ON CORE XY:

I usually only enable bed levelling very occasionally - and didn't for those test prints

The camera gave a different impression? I could clearly see the edge of the bed moving up/down. But maybe it's the cameramount moving....

@dwuk Seems to work already!
But around 32:00 I saw a potential improvement. Your post processor seems to print some tracks "from the far end" which adds unnessesary travel moves. A small routine that checks for shortest travel move would help here.
Other than that, I think the result will look even better with two tools. It would avoid oozing during travel moves.
Maybe add the option to do the top infill layer in one go?

A bit of concern is the mesh-bed compensation: That printer seems to be aligned badly. Just for fun you could try to print without mesh leveling. It'll give you a good taste of things to come with 2+2 tools. (not being able to use mesh levelling was the major reason I disassembled my hashPrinter)

@moocowsia said in Tevo Little Monster - 80 mm + Direct Drive and Remote Fans:

I couldn't figure out how to assemble it.

You could print an adapter plate that holds the heatsink-nut and fits under the LGX.
Then screw the heatsink in before you mount the hotend/heatbrake.
You might have to rotate the nut in the adapter a few times, before everything is tight and aligned nicely.

@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....

@moocowsia I guess you had to raise the LGX so much, because of the extruder motor sticking out?
I know these Orbiter and LGX extruders are en vogue but I still prefer my "tall and slim" sherpa mini

@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

@magnets99 The gantry is pretty interesting: They use the smooth rods for linear motion and as rotating shaft.
I wonder how well that works with these linear ball bearings? Especially on pure X or Y moves (i.e. homing) they will suffer.
I'd replace them with IGUS bearings if they seem to be worn out.

@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...

@titusou said in EasyIDEX:

Not exactly "compact" but that's the cost of IDEX.

That was also my first impression, but it's build for better maintenance...
Maybe put the linear rail of the x-axis on top of the extrusion: That way you'd have easy access to the screws that hold the toolheads.

@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

@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.

@dwuk Talking about interleaving infill reminded me of my regular CoreXYU, where I had one small nozzle for perimeters and a big nozzle for infill. I safed a lot of time doing "infill every n layers"
A four-head printer could have one big infill nozzle and three finer nozzles with different colours, I guess?

@dwuk I remember now, I've discussed the striped sections before on this forum. Was it you, who came up with it?

It was the same time I started using resin printers and immediately saw their advantages against FDM printing.
Opposite to the rounded corners you get with FDM, the resin-print edges are sharp and easy to glue together.
Unfortunately no multicolor prints, but ~10x smaller surface details possible. Plus: no problem with overhangs.

@gtrider I don't think 3D printing is in the main focus of this new regulations, although we could print illegal stuff.
But that's more a concern of the sites who host these designs.

@dogboy If you really need high accuracy, you can add positional sensors on the motor shaft(s) and the joint(s).
Closed loop is still pretty new in RRF, but once tuned in seems to iron out all accuracy problems.
Homing the arm once in a while will have a similar effect.

@dwuk I'm not sure if I understood.

• You want to split a single object into separate sections
• you'll print them simultaneously on the same bed
• ...but your collision avoidance strategy is to spread the parts further apart?

If that's the case, why don't you build (4) individual printers and each one prints a section of the object?
You'll have to puzzle the sections together anyway, but that way it'll be way easier to setup mesh bed and all.
Plus, you don't need a huuuge bed, just to keep the toolheads clear

@dwuk Splitting the gcode file?
I never thought of this as an option when I built the hashPrinter in 2021.
In my mind it was always the slicer who had to split the object, but that approach had it's own issues.

Your approach looks very promising, although I see lots of retracts/unretracts where the tracks were chopped apart. That can end up ugly, like tons of blobs everywhere.
And of course you'll run into tool collision situations and waiting for the other tool to finish the current layer while the waiting nozzle drools dry. (just as I did)
My idea to the latter problem was, to synchronize both tool speeds, so they finish work at the same time.
Maybe you want to add that in your splitting post processor?

BTW, my hashPrinter only required 4 steppers for the whole motion system ( plus 3 for Z and 4 for extruders) and all the belts where short and straight. Not such idle roller nightmare...
But lets not start a pi$$ing contest. There are pros & cons in both designs