Managed to get 2nd gantry working.

Had a lot of trouble with Motors - the ones I saved from a WeedoX40 wouldn't work.

Eventually I discovered that they have different pin connections to Sovol motors - with have the coils connected on pins 1+4 and 3+6. My motors were 1+3 and 4+6.

So found some other motors - from my MPCNC - which are more powerful - 1.7a - and they eventually worked.

Then had a lot of trouble withy homing and setting values for TMC drivers - will probably switch to end stops for the final build - but eventually got it working.

Then next problem was prints keep losing position - eventually worked it out that I was moving too fast for the MPCNC motors - F36000 was too fast for them - so slowed down to 18000 (300mm/s). And that sorted out the problem.

Decided to try a print - despite plastic bearing posts, and plastic linear rail carriages - ran the print at half speed - but it worked.

Did an initial print on the from gantry - then swapped over the extruder and stepper connections - and reconfigured Klipper for the different motors.

Demo of print on 2nd gantry here
https://youtu.be/7ar74Ne5ryI

Have learn't quite a lot about configuring steppers which will come in useful once I try the Duet migration - which is probably now the next step.

First successful Duet Dual Gantry IDEX test. - ( Phase 1 part 3)

https://youtu.be/A485TMKhmV4?si=gRNhVj0sPUrHJKw3

First layers not perfect and running a bit slow for some reason - but overall a big step forward.

Next step - multiple motion system...

@T3P3Tony Ah - I see you can select the output voltage as being VIN (I didn't spot that initially) - so I think that way I will be able to get 24v on Out1 and Out2 - so that should solve my fan issue. thanks

All belted up.
Short a few parts before I can do a proper test - most important of which is the linear rail carriages for the 2nd gantry, plus some idler posts.

Some belts quite close to each other - will try both gantries out next - will have to swap the carriages.

Rear left

Rear right

Front left

Front right

Top with rear top halves on

@oliof Appreciate that this is a fairly old topic - and sorry for the long post - just wanted to get a few ideas down together.

I have been investigating some options for a multi headed / multi colour printer for printing large multi coloured models.

I think the RatRig VCore 4 / With Hybrid Motors and IDEX 'Dual Markforge' is something like what you were describing in your post back in May.

What I am thinking along the lines of is something like a RatRig VCore4 IDEX RMMU, with a 2nd IDEX Gantry, which also has the ability for limited Z movement too.

I think it is going to need to be powered by Duet/Reprap firmware though - rather than RatOS/Klipper

My ultimate target is a machine/set of machines with the following capabilities:

1. Large build area - at least 300X x 500Y x 250Z - With at least two independent gantries for parallel printing of large objects - probably using the Reprap 3.5 Multi Motion System parallel printing capability
2. Each gantry being IDEX - to allow for fast colour changes for most commonly used colours, and for some models - mirror mode or duplicate mode parallel printing within the IDEX gantry.
3. Filament Multiplexing - probably using something like the Reprap RMMU or BambuLab AMS - as I need up to around 12 colours in total per object.
4. Parallel background colour feeding and purging etc. - which is hopefully supported by RepRep 3.5 (but not by Klipper/RatOS I believe). - See part 2 video for more details of this.
5. For the multiplexed colour changes - The ability for very efficient 'flush-into object' printing to be done - with the flush-into objects potentially being printed at a different Z heights to the main object.
6. Ideally in cases where fairly simple small prints are already in progress on only one of the gantries - the ability to separately start a simple 2nd print on the spare gantry.

I have created a few videos demonstrating a few ideas - the most relevant to my current thoughts is Part3 of this IDEX series.
IDEX Part 3 - Dual IDEX

'IDEX Part 6 - Motors and Belts'
Youtube link

What I would like to do next is add the ability for the 2nd Gantry to have a small amount of Z axis movement ability - so that it can be completely independent of the first gantry. I will probably add a few of the Reprap 3.5 Multi Motion System Gcode commands to my Blender add-on to drive the fully independent simulations.

Will probably also add some animations along the lines of the diagrams posted by @droftarts in this thread to the simulations too.

The next problem is then splitting up models into sections for Multi Motion printing.

I have done some reading of this forum of posts about Multi Motion printing - mainly by @dc42 and can't find a lot of details of any slicer developments.

So unless work is already underway in this area I am thinking about creating a GCODE post processor that does a basic split of single head multi colour prints (probably sliced for a BambuLab X1C) into up to 3 or 4 separate areas per layer if they are big enough be warrant parallel printing on the two gantries at the same time. The reason for the 4 areas is to avoid head clashes - see this diagram.

Plus probably a 2nd post processor that does some more automated mirror mode splitting - I am currently do this in my simulations by pre-splitting up the mirrored / duplicated and single threaded parts prior to slicing into different 'virtual colours' - am then using the tool change commands generated by the slicer to switch the 'virtual' printer between IDEX modes.

Starting to plan for expansion boards - looks like there is room,

Tool Distribution board and first Mini5+ needed for Dual Gantry, with further Mini 5 probably needed for IDEX - unless I can reduce the stepper requirement - by using less for IDEX and Servo's for Z Hoppers.

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

Homing working -

See short video demo

https://youtube.com/shorts/oHtVsdHTPQc?si=w-lnOgmzNzxqfvRK

Lots of refinements to do - but basic homing and 4 AXIS levelling done

@dwuk Servo wired up and tested. On the 1LC board io_0.out, with an LM2596 DC to DC convertor to bring down the 24V input to 5V for the servo.

Prototype parts printed - just need to install them and test them - might be a few days due to other commitments.

Short Video showing both heads in motion.

I can't get synchronisation working yet - so not ready to print more than one layer - but nice to at least see the print heads moving independently.

https://youtu.be/gQX2zZGmyh8?si=oEQOxusDIuququso

@droftarts Cool - looks like that 3 colour printer predates the Prusa MMU1 by quite a lot.

Z offset Tapping now working quite reliably as long as the print heads are clean.

Lots more work to do on timings and speed, and print head design - but printer starting to come together.

Printing getting better. I don't think the original problems with the flag in the video a few months ago were dimensional inaccuracies or alignment issues - rather the fact the it was cutting off some of the colours due to Axis limits.

Back to printer -

New Z Hopper motors arrived - bought full linear actuators - which I will take apart - as seems to be most cost effective way to source Nema 11 lead screw motors

Tap sensoring now working.

Logic is
1.Home All
2. G32 Z motor alignment
3. Then for each print head
4. Move other print heads 2mm up so that they are out of the way
5. Align Z hopper to just trigger optical sensor
6. Move head down about 0.02 mm to just past the trigger point.
7. Switch probes/endstops so that the Z axis now has the Z hopper end stop as its trigger. (inverted)
8. Move Z down until print head hits to bed and then pushes up slightly within the play of the print head to disable the triggered optical sensor.
9. Repeat for various points of the print bed,

Short demo - showing tapping and play/flex - which might end up being a problem
https://youtu.be/5FGALqWV4t8

Example Tap test macro.

;tap A.g
M98.1 A"B On"
;reset probes to correct values

M574 Z1 S2 K0; configure Z axis endstop
M574 A1 P"122.io2.in" S1 ; configure A axis endstop


G90
G1 Z3 F1000
G1 D{global.dOffset+2} F1000
G1 B{global.bOffset+2} F1000

var speed = 400
;var w = {224, 224, 324, 324}
;var v = {310, 210, 210, 310}
var w = {160, 200, 200, 160, 324}
var v = {160, 160, 240, 240, 310}
var point1 = -1


while iterations < 5
    var iGrid = iterations
    G1 W{var.w[var.iGrid]} V{var.v[var.iGrid]} F10000
    ;echo "W",var.w[iterations],"V",var.v[iterations]
    while iterations < 2

        M574 Z1 S2 K0; configure Z axis endstop
        M574 A1 P"122.io2.in" S1 ; configure A axis endstop
        var aMax = 0
        var aPos = 0
        var aMin = 99
        while iterations < 1
            G1 A3 F{var.speed}
            M400
            var aProbe = sensors.endstops[6].triggered
            if var.aProbe
                abort "A Probe already triggered"

            G1 H4 A-2 F{var.speed}
            set var.aPos = move.axes[6].machinePosition
            ;echo "D trigger pos",var.dPos
            if var.aPos > var.aMax 
                set var.aMax = var.aPos
            if var.aPos < var.aMin
                set var.aMin = var.aPos

        var aProbe = false
        if var.aMax-var.aMin > 0.03
            echo "variation",var.aMax-var.aMin,var.aMin,var.aMax
        while iterations < 4
            ;echo "i",iterations
            G1 A{var.aPos-0.01*iterations} F{var.speed}
            M400
            set var.aProbe = sensors.endstops[6].triggered
            if !var.aProbe
                abort "A Probe not triggered"
                
            else
                if iterations > 1
                    echo "lowered head ",0.01*iterations,"mm"
                break



        M574 A1 P"122.io3.in" S1 ; configure A axis to temporary Endstop
        M574 Z1 P"!122.io2.in" S1 ; configure Z Axis to A end stop inverted
        var zPos = 0


        G1 Z{var.zPos+2} F500
        M400
        set var.aProbe = sensors.endstops[2].triggered

        if var.aProbe
            abort "AZ Probe already triggered"
            
        G1 H4 Z-7 F{var.speed}
        set var.zPos = move.axes[2].machinePosition
        if var.point1 == -1
            set var.point1 = var.zPos

        echo "A zPos",var.zPos,"W",var.w[var.iGrid],"V",var.v[var.iGrid],"point",var.iGrid,"var",var.zPos-var.point1
        G1 Z3 F1000



;restore probes
M574 Z1 S2 K0; configure Z axis endstop
M574 A1 P"122.io2.in" S1 ; configure A axis endstop 
;    122.io3.in - dummy endstop when A swapped out

@dc42 Thanks will switch to that version

I am having some trouble with layer shifts in motion system 1 on layer 2 - which I think is relating to something happening in Motion System 0.

I introduced some delays in motion system 0 at various points so that I could try pin pointing exactly which command in motion system 0 is causing motion system 1's X&Y gantry to shift 10/5 mm's and cause the issue.

This resulted in some strange behaviour - where motion system 1 seemed to get stuck for a while.

I think I have figured out that all of the G4 delays I have put into motion system 0 are also being executed by motion system 1.

Some of the delays are in loops - but I assume the loop logic is probably being ignored and just the G4's are being picked up and executed - or maybe G4's in loops are being ignored.

When I reduce the length of the delays in motion system 0, then motion system 1 seemed to get delayed less.

I think I can work around this by using much smaller delays and putting them in loops - but it does help to explain a few strange delays.

Update: Putting delays into iterations didn't change the behaviour

So I have instead added an if statement to exit out of every macro that is likely to be called when multiple motion systems are active, plus in my general macro caller

if state.thisInput != null && inputs[state.thisInput].active == false
    M99
    
if exists(param.A)
    var P ="0:/macros/"^{param.A} 
    if fileexists(var.P)
        M98 P{var.P}
    else
        var P2 =var.P^".g"
        if fileexists(var.P2)
            M98 P{var.P2}
        else
            echo "M98.1 Macro file not found",{var.P}
            

else
    echo "M98.1 Macro Parameter A not found"

@droftarts Yes I really like Fusion 360 too.

I did try doing a whole ship model in Blender - mainly due to the perspective corrector add-on - which is a really good way of tracing 3d objects when they are at an angle or have perspective distortion.
Ultimately though I gave up when print quality wasn't as good, plus having the spend ages wrestling will the models to correct model mesh errors.

I'm still using a 2020 MacBook Air 8gb M1 - and it works pretty well - although it really started to struggle with this combined model - which I know would work easily in Blender. - I might upgrade to an M4 at some point with a larger screen for when I am away.

I got a PC too mainly for rendering of animations - which are about 60x faster on the 4070 Super/Ryzen7950X3D/32GB - vs the M1 GPU. Blender runs slightly quicker on Linux - but I usually do my rendering in windows 11.

Put up a couple more videos with a bit more detail, one of which got retweeted by Sovol - so fame building further. What would be really good though is if Sovol (or someone else) gets together with Bondtech to release a fully built, tested and supported INDX printer.

Free stuff might be nice - but I think it changes it from being a hobby - and starts putting pressure on to deliver. I haven't applied for the Bondtech Beta Programme as don't want to be sworn to secrecy.
PCBway have been in contact too about the triple headed printer videos - I guess having their logo on would add a certain amount of Kudos - but I don't think I need any custom PCBs - might need some CNC stuff though when I got to the rotary bed phase - but probably won't pursue it.

Makerworld Boost points are pretty handy though for filament, plus Bambulab are selling quite a lot of parts too now. Plus might partially pay for an H2D if I decide to go for one. It's not until you try and create a printer do a major upgrade that you realise how much work must have gone into the X1C to make it so good.

https://youtu.be/3ecm2H41xLM?si=iIreYIUxHuVA6TiY

https://youtu.be/7MPa1tk-rNc

@o_lampe thanks - do you mean G92's.

I don't think I have any of those in my macros that would be invoked mid print - the problem occurs mid layer 2 = when the printing switches back between T1 to T0. But I will check.

I think though that something is changing the endstop offsets for the Y and Y axis and then jumping them quickly to the new position.

I have noticed some unexpected behaviour when moving around between tools and mapped axis - but haven't really found a way to recreate the issue.

If I don't manage to resolve the problem I suppose I could try removing the X and Y mapping completely from the T1 and T2 tools definitions , and instead post process the G0-G3's to specify U,V & W instead when using T1 or T2.

Ps - the sequence is
Homing.z offsets
Motion system 1 - layer 1 - print T0 section ok
Motion system 0 - layer 1 - wait for pre-heat, delay, preheat, T1 print prime, wait for print T0 to finish, T1 print layer 1, move Z up to layer 2, T1 print layer 2.
Motion system 1 - layer 2 - wait for pre-heat, delay, preheat, T0 prime for layer 2, wait for T1 to finish, T0 head jumps to incorrect position, T0 print layer 2 - with layer shift

Started making some progress on the Trindex SV08 printer again.

Did some simple size test prints - and started getting issues with Z offsets.

I think I will have to improve my Z alignment - either by using 'voron tap' on all of the tools, or possibly using the ball probe Z offsets.

Plus a more serious issue.

When serial 3 headed printing - but with parallel print priming and colour switching between T1 (UV) and T0 (XY) - T0 consistently layer shifts about 10mm in the X and 5mm in the Y - and the layer shift if quite fast.

I had this issue a while ago and thought it was related to the Z hopper - but I have turned the Z hopping off on XY and are still getting the issue.

If I do similar prints with T2 (WV) and T0 (XY) - both of them print fairly well.

I have seen some oddities in normal alignment testing with X and Y sometimes jumping when I switch between tools - so not sure if it is an issue with my config, macros, slicer GCODE or a 3.5.4 problem.

Will continue investigating to try and get the problem to occur in a more simple gcode file without parallel printing.

Or might just try setting up another tool - T3 - and assign that to the UV - to see if I get the same issues.

@dwuk3d said in Sovol SV08 Multiple Motion System Upgrade.:

@droftarts Will be interesting to see if the video gets much pick up as it is certainly a very elegant design and could completely remove the need for me to add single nozzle multiplexing on top of tool changing - plus also remove the need for lots of electronics and motors etc. for the extra tools and multiplexer

Might do a better version of the video with a few animations of the different options next.

Finally got round to starting on some INDX/SV08 animations - which will eventually include my currently planned 2 Gantry, 3 Toolhead, rotating bed version - with some full multi colour ship print simulations.

Blender is very powerful - but I find it very hard to use compared to Fusion - I find I have to google at least half of the commands, including ones I have used only a few minutes ago - due to the odd keystrokes with combinations of modifier keys.

Doesn't help too that I am using a Mac - whereas most of the documentation and explanation videos use the windows versions of the keystroke modifier keys.

The INDX on SV08 renders I did last week got retweeted by both SOVOL and BONDTECH which was good.