Sovol SV08 Multiple Motion System Upgrade.

droftarts

@dwuk3d One of the first multicolour prints we did at RepRapPro with the Tri-colour Mendel, around 2013/14, was a Union Flag!

alt text

I don't have any pictures of the print, but the files are here: https://github.com/reprappro/Interesting-3D-Prints/tree/master/RRP Union flag2

Our other favourite was the multicolour frog: https://www.thingiverse.com/thing:329436

Ian

dwuk3d

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

dwuk3d

Front extruder now rebuilt with Nema11.

Had to cut some of the shaft off, and I think I can bring the motor down about another 13mm if I cut more of the shaft off.

All heads now being on Nema11's should now enable proper Z hopping and (with the aid of a post processor) some independent Mesh adjustment.

Also moved the front extruder off of sensorless homing on to Optical End stops.

With the X and B (Z Hopper) Axis sharing a single sensor.

Did find one tiny issue - I accidentally used the wrong filename homeb.g instead of homex.g when I was creating my new optical end stop file - I had previously renamed the homex.g to homex_sensorless.g

Instead of telling me the homeb.g file already existed I think it just wiped it out - so I had to recreate it from scratch.

Also - when switching endstops between different Axis I am finding that in order to release an end stop from the old Axis and need to give it another one - so I am using one of the unused io[x].in from one of the boards to swap that into the old axis end stop - so that it releases the end stop - so that I can assign it to the new Axis.

Not sure if this is the best way to do it - especially as I am gradually using more and more of the io[x].in's for things.

dc42

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

Also - when switching endstops between different Axis I am finding that in order to release an end stop from the old Axis and need to give it another one - so I am using one of the unused io[x].in from one of the boards to swap that into the old axis end stop - so that it releases the end stop - so that I can assign it to the new Axis.

Just set the endstop position to 'none' in M574, e.g. M574 X0 will release the IO input that was previously used by the X endstop.

dwuk3d

@dc42 Thanks will try that

dwuk3d

Still having issues with Multiple motion systems and layer shifts.

It went away for a while - but it has now moved from T0 to T1 - during parallel priming.

I thought it might be due to my priming being in a replacement command Macro - M801.

M801 moves the print head - and then it seems to return back to where it was before calling the macro - sometimes quite fast.

So I changed the Macro that calls M801 to pre-position the print head where it will end up after the M801 before calling it - and that has reduced the unexpected moves.

Still getting the issue though where on the 3rd perimeter of the T1 priming cycle (which is in parallel to T0) the print head rapidly moves to the wrong place.

I wonder if it is macro related.

Update - found a pattern I think

What is happening is the on motion system 0 - T1 is priming

On motion system 1
T0
--Park XY Macro
----M800 - which moves the T0 Z Hopper B Axis up
----T0
----Move X&Y out of the way
---M800 - which moves to T0 Z Hopper B Axis down.

If I change M800 so that it doesn't move the B Axis then I don't get the issue.
Or if I remove the M800's from ParkXY

I think the B Axis is somehow related to the problem I had with tool 0 also.

Tool and Axis definitions attached below

; Smart Drivers
M569 P0.0 S1 D2 ; driver 0.0 goes forwards (Z axis)
M569 P0.1 S1 D2 ; driver 0.1 goes forwards (Z axis)
M569 P0.2 S0 D2 ; driver 0.2 goes backwards (Z axis)
M569 P0.3 S1 D2 ; driver 0.3 goes forwards (X axis)
M569 P0.4 S0 D2 ; driver 0.4 goes backwards (Y axis)
M569 P1.3 S1 D2 ; driver 0.5 goes backwards (Z axis) - changed to 1.3 forwards
;M569 P1.0 S0 D3 V2000 ; driver 1.0 goes backwards (U axis)
;M569 P1.1 S0 D3 V2000 ; driver 1.1 goes backwards (V axis)
M569 P1.0 S0 D2; driver 1.0 goes backwards (U axis)
M569 P1.1 S0 D2 ; driver 1.1 goes backwards (V axis)
M569 P1.4 S0 D2 ; Z-hopper 2
M569 P0.5 S1 D2 ; Z-hopper 1
M569 P1.5 S0 D2 ; VH Axis Left
M569 P1.6 S1 D2 ; VH Axis Right
M569 P1.2 S1 D2 ; U AXIS Z Hopper

M569 P121.0 S0 D2 ; driver 121.0 goes backwards (extruder 0).  X
M569 P122.0 S0 D2 ; driver 122.0 goes backwards (extruder 1).  C
M569 P123.0 S0 D2 ; driver 123.0 goes backwards (extruder 2).  U

; Motor Idle Current Reduction
M906 I30 ; set motor current idle factor
M84 S30 ; set motor current idle timeout

; Axes
M584 X0.3 Y0.4 Z0.1:0.2:0.0:1.3 U1.0 V1.5:1.6 W1.1 A1.4 B0.5 D1.2; set axis mapping


; Tools
;     X:Y:Z:U: V:W:A:B:C:D
;     0 1 2 3. 4 5 6 7 8 9


M563 P0 D0 H1 F0 ; create tool #0.    XYB
M568 P0 R0 S0 ; set initial tool #0 active and standby temperatures
;M563 P1 D1 H2 F2 ; create tool #1

;Tool T1 - Left Nozzle - 2nd Gantry as X and Y.  UVD
;M563 P1 D2 H3 F4
M563 P1 D2 X3 Y4 H3 F4
G10 P1 X0 Y0 U0 V0 S0 R0
M568 P1 R0 S0 ; set initial tool #1 active and standby temperatures

;Tool T2 - Right Nozzle 2nd Gantry as X and Y.   WXA
;M563 P2 D1 H2 F2
M563 P2 D1 X5 Y4 H2 F2
G10 P2 X0 Y0 U0 V0 S0 R0
M568 P2 R0 S0 ; set initial tool #1 active and standby temperatures

dwuk3d

Quite good progress made today.

Managed to work around the G32 Bed.g alignment issue I occasionally have, and also got the probe alignment to be fairly reliable.

Decided to push the speeds up - from 100 to 300, and accelerations up from 2000 to 6000 - all working ok and looking quite impressive.

Am now trying to fix the just in time parallel prime synchronisation - to get all colour swaps sub second.

The pre-heats from OrcaSlicer that I have specified as 20 seconds - actually vary between 9s and 21 seconds- so even if my delay calculations were perfect it is still pretty much impossible to get perfect timing that way.

So plan a - for reprints is to capture the actual time in an array that is echo'd into a file, and then use it to get precise timings for reprints.
Am also investigating simulation - some macro's seem to run - but not sure if it is possible to capture actual times.

Might have to try and work out the segment print times myself in a post processor - but real printing or simulation likely to be the best solution.

Finally doing some comparison prints of the same model with an X1C - there are only 6 colour changes in my flag model, and my accelerations are still quite a lot slower (vs 10,000 on the X1C), but the good news is that my actual print is already about double the speed of the X1C print, plus also the prep time despite all of my alignment stuff is a fair bit quicker too.

Comparison video with the two prints side by side in the works.

o_lampe

@dwuk3d If you could find a way to prevent the idle tools from oozing, you wouldn't have to use reduced standby-temp. That'd save you from all the preheat hassle.
Delay calculations might give you a headache anyway if the idle tool hasn't reached standby temp when you call the preheat macro in a back2back colour change scenario.

dwuk3d

@o_lampe ooze prevention would certainly be handy - although quite tricky to implement on my sovol due to the fact the idle heads are still over the build plate.

I guess something like Bambulab H2D ooze protect arm would work.

Will order one of the H2D flow blockers and magnets - to see whether its practical to fit one on my toolheads

https://uk.store.bambulab.com/products/flow-blocker
https://uk.store.bambulab.com/products/nozzle-blocker-magnet-bracket

In theory it could be driven by the zhopper motor when it reaches the top of its travel - although on the h2d it is controlled be a separate small motor.

My overnight thinking on preheat is rather than getting preheat times exact I might change my reheat process to wait a little bit after the reheat to round up the reheat times to a fix number of seconds for ranges of start temperatures.

I think I am going to have to leave reheat / standby in - as some of my print heads could be idle for a long time - maybe several hours in some prints.

My current thinking on cooldown / preheat is

Ooz Shield and or wipe - if tool change time > x1
Cooldown - if tool change time > x2 seconds
Reheat - if cooled down
Extra post reheat delay to make later timings more predictable
Move out Ooz shield
Purge out burnt filament to prime tower - if tool change time > x3 seconds
Prime -to prime tower if tool change time > x1 seconds -

Ideally prime should finish exactly when the other tool starts moving out of the way - for sub second tool changes.
However when timings not exact it may be better to wait until the other tool head starts moving before doing the final prime wipe.

Most of the above would also apply for parallel prints - where a tool is going idle for a little while - to allow the other toolhead to catch up.
I plan if possible to slow down the printer of the faster segments to where practical remove most of the idle time, and therefore avoid the need for all of the priming/preheat stuff.

Other challenges I have are with prime towers - currently because I want each head to have its own independent prime tower I am creating them in macro's.

I think this will work - but it is quite a lot of work getting them to print properly - plus I also have the challenge of missed layers - where some tools are only used a few layers apart - do I keep the prime towers the same height in parallel - which for the IDEX heads might mean extra tool changes for the prime towers, or do I allow the prime towers to drop a bit lower, and then use Z Hoppers to lower down to them when needed.

o_lampe

@dwuk3d I came to the same conclusion regarding preheat macros:
Start them early, but don't preheat immediately. Add a delay, depending on the current tool temp.

The prime tower dilemma will be an even bigger issue when you start using a moving bed.
The tower for tool x might not be there where it used to be.
In my experience it is important to have the towers at the full height, even when the tool is idle for n layers.
I began to use a windshield instead, which is a single perimeter wall around the part created by PrusaSlicer.
Not sure if that'd make it easier or worse for your printer.

dwuk3d

@o_lampe thanks, have never tried using windshields - I guess they have the advantage of being close to the part, protecting the part from airflow. Disadvantages I guess are a) needing to be quite large for large parts, b) hiding the part while printing, c) if single shield only then it would be difficult to 'parallel' prime.

For single material / multi colour prints on my moving be designs I guess it might be possible to swap prime towers between the heads. However for multi material I am not keen on sharing prime towers - so I guess in this case I could end up needing an impractical number of prime towers.

Made reasonable progress yesterday on synchronising timings on reprints - without yet simplifying heat up times.
One issue I did encounter though is taking in account the knock on effect of delays on later tool changes, i.e. If I reduce the delay on a tool change to stop it finishing late, I sometimes have to increase the delay on the next one to avoid that one finishing early.

Still having issues with Z offsets and repeatable alignment, may have to rethink probing approach again, and probably also need to beef up the strength of my optical end stop holders and flag parts.

dwuk3d

@dwuk3d Might be time to deploy the Scanning Eddy Z Probe.

Think I will put it on the front Extruder.

Looks a bit tricky wiring up the Can connections and terminations - especially when I want to add another Mini5+ board - which also wants to be terminated.

dwuk3d

@dwuk3d touch mode on the SZP looks interesting.

Also only just noticed that the Roto tool board includes an SZP built in - so will probably upgrade other print heads to roto toolboards rather than adding further separate SZPs if the touch probing works out ok.

Roto boards also likely to fit better in an INDX.

Rather than adding the 2nd Mini5+ board to my printer for just the two more stepper drivers that I think I am going to need -
to avoid the complication of having to cut the track on the Mini5+ circuit board I think it might be easier to get a 2nd tool distribution board and use my existing !LC boards (that will be replaced by Roto boards) as normal stepper drivers.

So the 3 head setup would then be:
6 drivers on 6HC - should switch this over to U D v1 v2 W A
7 drivers on Mini5+ - should switch over to X Y z1 z2 z3 z4 B
2 more drivers using 1LC boards - rotary and ball probe/camera deployment
2 x tool distribution boards - with 3 spare slots
1x1LC + SZP
2xRoto with built in SZP

dwuk3d

@dc42 Thanks

The M574 A0 and M574 D0 seems to work ok

Also - for probes - I have replaced the following
M558 K2 P8 C"122.io3.in" H1 F300 T300 ; configure B Axis to temporary end stop
with
M558 K2 P0 ; configure B Axis to temporary end stop

and that seems to work too.

dwuk3d

Another Flag printing video.

This time comparing a print on my SV08x3 with an X1c - which was the printer used to print most of the parts.

Print quality improving and colour swap timing getting fairly good on reprints.

Due to sub second vs 60 second plus colour changes the print takes about 8 mins on the SV08, vs about 20 mins on the X1C.

X1C start up time also a fair bit slower - but start up processes not included in this video.

https://youtu.be/5FAYvt4uwtw?si=hTprxJtDPhnTmhrw

dwuk3d

Upgraded my post processor to change all of the ZHops to direct G1 A{global.aOffset+0.4} etc hoping that this might solve the layer shifting problem which I thought might be related to using the A,B & D axis within gcode override Macros M800.1.g that I was currently just using in the prime tower building processing- but it is a lot worse.

I also had an issue when I was manually moving the gantries around when I moved the A.B or D Axis sometimes the U axis would jump to a different place - so there is definitely some sort of incompatibility between my tools definitions and moving gantries or axis that are not overridden in the tool definitions.

I suppose I should try the latest firmware - as I am still on 3.5.4.

But I think that maybe I should try removing all of the tool usage/overrides - and change the X,Y and E movements to be the actual axis in the post processor - however it could get quite complicated with Fans/Heaters etc.

Current tool definitions here

; Tools
;     X:Y:Z:U: V:W:A:B:C:D
;     0 1 2 3. 4 5 6 7 8 9


M563 P0 D0 H1 F0 ; create tool #0.    XYB
M568 P0 R0 S0 ; set initial tool #0 active and standby temperatures
;M563 P1 D1 H2 F2 ; create tool #1

;Tool T1 - Left Nozzle - 2nd Gantry as X and Y.  UVD
;M563 P1 D2 H3 F4
M563 P1 D2 X3 Y4 H3 F4
G10 P1 X0 Y0 U0 V0 S0 R0
M568 P1 R0 S0 ; set initial tool #1 active and standby temperatures

;Tool T2 - Right Nozzle 2nd Gantry as X and Y.   WXA
;M563 P2 D1 H2 F2
M563 P2 D1 X5 Y4 H2 F2
G10 P2 X0 Y0 U0 V0 S0 R0
M568 P2 R0 S0 ; set initial tool #1 active and standby temperatures


; T3 - duplicate mode
M563 P3 D0:1 H1:2 X0:3 Y1:4 F0:1
G10 P3 X0 Y0 U0 V-150 S0 R0
M567 P3 E1:1
M568 P3 S1

dwuk3d

@dwuk3d

Managed to capture layer shift - see 14:18:02 on this video.
https://youtu.be/oijcrHmkybI?t=70

As far as I can see Gantry2 is idle - waiting for its next print phase. - I jumps back and the two print heads jump inwards - which might be due to the V motors only moving -
as the U & W gantries would then move in a bit - although the U axis does move a little bit after the other ones - so it might be moving too.

Gantry 1 does a ZHop (B Axis) and an actual Z lift - it may be either of these. - will try taking each one out next to see which one makes a difference

In this scenario I am using UVWDA Axis - for gantry 2 - none of which are redirected to X,Y or Z in T2 - but the layer shift is happening in UV & W as far as I can tell from the video.

I tried setting a trigger on the V axis end stop but it didn't fire for some reason. had to do an M122 a little while afterwards.

I've had this issue on the XY axis too.
If I take out the Z Hopping (using AB&D) I don't seem to get it - so I think it is more likely related to them than Z, or maybe a combination.

Update1 - put abort in here - and it didn't layer shift - so now trying it again with the abort just after the G1 Z0.6

G1 B{global.bOffset+0.4} F30000
M802 L2244; Check positions
G1 X137.83 Y191.812 B{global.bOffset+0.4}
M122
abort "before G1 Z"
M802 L2246; Check positions
G1 Z.6

M400 ; Release Z Axis
G1 B{global.bOffset}
M802 L2249; Check positions

Update2 - its the G1 Z.6 on T0 (XYB) - that is causing the layer shift on T1 / T2 (UVWAD) - have created dummy AXIS for X&Y on the T1 and T2 tool definitions - will try doing the same for Z next

This is the M122 immediately after the layer shift occurred.

=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.4 (2024-11-24 10:47:10) running on Duet 3 MB6HC v1.02 or 1.02a (standalone mode)
Board ID: 0JD4M-958L1-M2NS0-7JTDG-3SN6K-91FKZ
Used output buffers: 3 of 40 (40 max)
=== RTOS ===
Static ram: 155464
Dynamic ram: 130952 of which 28 recycled
Never used RAM 55292, free system stack 143 words
Tasks: NETWORK(1,ready,36.6%,153) ETHERNET(5,nWait 7,0.5%,116) HEAT(3,nWait 6,0.0%,323) Move(4,nWait 6,0.7%,211) CanReceiv(6,nWait 1,0.1%,792) CanSender(5,nWait 7,0.0%,329) CanClock(7,delaying,0.0%,348) TMC(4,nWait 6,9.6%,53) MAIN(1,running,52.4%,103) IDLE(0,ready,0.0%,29), total 100.0%
Owned mutexes: File2(MAIN)
=== Platform ===
Last reset 00:08:49 ago, cause: software
Last software reset at 2025-06-04 15:40, reason: User, Gcodes spinning, available RAM 58268, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x04
MCU temperature: min 45.6, current 46.2, max 47.0
Supply voltage: min 24.0, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.2, max 12.4, under voltage events: 0
Heap OK, handles allocated/used 198/80, heap memory allocated/used/recyclable 2048/1688/624, gc cycles 28
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, mspos 184, reads 57010, writes 0 timeouts 0
Driver 1: standstill, SG min 0, mspos 88, reads 57010, writes 0 timeouts 0
Driver 2: standstill, SG min 0, mspos 440, reads 57010, writes 0 timeouts 0
Driver 3: ok, SG min 0, mspos 488, reads 57010, writes 0 timeouts 0
Driver 4: ok, SG min 0, mspos 1000, reads 57010, writes 0 timeouts 0
Driver 5: standstill, SG min 0, mspos 920, reads 57010, writes 0 timeouts 0
Date/time: 2025-06-04 15:49:07
Slowest loop: 11.61ms; fastest: 0.05ms
=== Storage ===
Free file entries: 16
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 3.0ms, write time 3.1ms, max retries 0
=== Move ===
DMs created 125, segments created 25, maxWait 17980ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
next step interrupt due in 457 ticks, disabled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 1309, completed 1309, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 1079, completed 1074, hiccups 0, stepErrors 0, LaErrors 0, Underruns [186, 0, 0], CDDA state 3
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.0
Heater 2 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G4 P91" in state(s) 0 0, running macro
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is ready with "M122" in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x40000000
Code queue 0 is empty
Q1 segments left 1, axes/extruders owned 0x80000087
Code queue 1 is empty
=== CAN ===
Messages queued 7644, received 31143, lost 0, errs 0, boc 0
Longest wait 5ms for reply type 6013, peak Tx sync delay 358, free buffers 50 (min 48), ts 2207/2207/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 36.77ms; fastest: 0.03ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 3 of 8
= Ethernet =
Interface state: active
Error counts: 0 0 0 0 0 0
Socket states: 2 2 2 2 2 2 0 0
=== WiFi ===
Interface state: disabled
Module is disabled
Failed messages: pending 0, notrdy 0, noresp 0
Socket states: 0 0 0 0 0 0 0 0
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0
Cancelled printing file 0:/gcodes/TableLeg.gcode, print time was 0h 8m
after Z move - before M400

The M122 before it occurred should be this one - from. the previous test - where the abort was just before the failure.

	12 M802 L 2244
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.4 (2024-11-24 10:47:10) running on Duet 3 MB6HC v1.02 or 1.02a (standalone mode)
Board ID: 0JD4M-958L1-M2NS0-7JTDG-3SN6K-91FKZ
Used output buffers: 2 of 40 (40 max)
=== RTOS ===
Static ram: 155464
Dynamic ram: 130984 of which 20 recycled
Never used RAM 55268, free system stack 117 words
Tasks: NETWORK(1,ready,37.4%,137) ETHERNET(5,nWait 7,0.6%,316) HEAT(3,nWait 6,0.0%,323) Move(4,nWait 6,0.7%,211) CanReceiv(6,nWait 1,0.1%,771) CanSender(5,nWait 7,0.0%,327) CanClock(7,delaying,0.0%,346) TMC(4,nWait 6,9.6%,53) MAIN(1,running,51.6%,103) IDLE(0,ready,0.0%,29), total 100.0%
Owned mutexes: File2(MAIN)
=== Platform ===
Last reset 00:09:55 ago, cause: software
Last software reset at 2025-06-04 15:18, reason: User, Gcodes spinning, available RAM 60108, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x04
MCU temperature: min 45.2, current 45.8, max 46.1
Supply voltage: min 24.0, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.2, max 12.4, under voltage events: 0
Heap OK, handles allocated/used 198/80, heap memory allocated/used/recyclable 2048/1628/564, gc cycles 25
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, mspos 360, reads 35168, writes 0 timeouts 0
Driver 1: standstill, SG min 0, mspos 856, reads 35168, writes 0 timeouts 0
Driver 2: standstill, SG min 0, mspos 296, reads 35167, writes 0 timeouts 0
Driver 3: ok, SG min 0, mspos 193, reads 35167, writes 0 timeouts 0
Driver 4: ok, SG min 0, mspos 640, reads 35166, writes 0 timeouts 0
Driver 5: standstill, SG min 0, mspos 184, reads 35166, writes 0 timeouts 0
Date/time: 2025-06-04 15:28:15
Slowest loop: 219.49ms; fastest: 0.05ms
=== Storage ===
Free file entries: 16
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 3.1ms, write time 3.2ms, max retries 0
=== Move ===
DMs created 125, segments created 25, maxWait 21911ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
next step interrupt due in 1447 ticks, disabled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 768, completed 768, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 1078, completed 1073, hiccups 0, stepErrors 0, LaErrors 0, Underruns [186, 0, 0], CDDA state 3
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.0
Heater 2 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G4 P91" in state(s) 0 0, running macro
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is ready with "M122" in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x40000000
Code queue 0 is empty
Q1 segments left 1, axes/extruders owned 0x80000083
Code queue 1 is empty
=== CAN ===
Messages queued 7693, received 31652, lost 0, errs 0, boc 0
Longest wait 3ms for reply type 6061, peak Tx sync delay 92, free buffers 50 (min 48), ts 2247/2247/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 188.10ms; fastest: 0.03ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 3 of 8
= Ethernet =
Interface state: active
Error counts: 0 0 0 0 0 0
Socket states: 2 2 2 2 2 2 0 0
=== WiFi ===
Interface state: disabled
Module is disabled
Failed messages: pending 0, notrdy 0, noresp 0
Socket states: 0 0 0 0 0 0 0 0
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0
Cancelled printing file 0:/gcodes/TableLeg.gcode, print time was 0h 3m
before Z move

Looking at the two prints - the only difference between AXIS owned is that before they layer shift Q1 owns B,X & Z, but after the layer shift it owns B,X,Y & Z - It doesn't own UVW - so why they are getting moved I don't know - they are not even owned by the other currently idle in a G4 motion system - which is I think currently on T2

A few lines ahead in the file

 M596 P0
  
T2  






;M98 P"0:/macros/changeFilament.g" A previous_extruder  B new_filament_temp  L layer_num  N next_extruder   F first_layer_temperature2

M98 P"0:/macros/changeFilament.g" A0 B220 L2  N2  F220

Then within the macro it is looping around here - the the G4 P91 - which in this case is waiting for the pre-heat to come in on the other motion system and set the target temp to 200.
The one with the G1 Z.6 that seems to be causing the error.

if exists(param.N) && param.N == 2 ; WVA
    
    var delayTime = -1
    if exists(global.delays) && global.delayCount+2 < #global.delays && param.A == 0
        set global.delayCount = global.delayCount + 2
        set var.delayTime = global.delays[global.delayCount]+global.delays[global.delayCount+1]-1
        if global.delayCount > 2 && global.delays[global.delayCount-1] < 0
            set var.delayTime = var.delayTime + global.delays[global.delayCount-1]/2
        echo {state.thisInput},"delays",global.delayCount,global.delays[global.delayCount],global.delays[global.delayCount+1],var.delayTime
    ;M596.1 P0
    T2
    var startWait = state.upTime+state.msUpTime/1000
    if param.A != 0
            set global.startParkUV = -1
    echo {state.thisInput},"step 0 - wait for 200",{sensors.analog[2].lastReading}
    while (heat.heaters[2].active < 200 && var.delayTime == -1)  || (var.delayTime != -1  && state.upTime+state.msUpTime/1000-var.startWait < var.delayTime )
            if state.status == "cancelling"
                abort "step0 - cancelled"
            while iterations < 5
                G4 P91
            set global.p1state = "inWait"
            if mod(iterations,50) == 9
                if var.delayTime == -1
                    echo {state.thisInput},"step 0 - wait for 200",{sensors.analog[param.N+1].lastReading},global.p1state
                else
                    echo {state.thisInput},"step 0 - wait for ",{var.delayTime - (state.upTime+state.msUpTime/1000-var.startWait)}," more secs"

Now trying changing the Layer change sequence to be:

G1 B{global.bOffset+0.4} F30000
M802 L2248; 
G1 X131.989 Y190.411 B{global.bOffset+0.4}
M802 L2250; 
T-1  
G1 Z.6
M400 ; Release Z Axis
T0  
G1 B{global.bOffset}
M802 L2255;

The problem has now gone away again after that change - not sure if it has fixed it, or just changed the timing so that it will occur somewhere else.

dwuk3d

Since changing approach to layer changes I haven't had any layer shifts.

One issue I now have is with speeds.

For the first tool used it seems to be fairly slow speeds.

For the 2nd tool it goes very fast.

I've checked all of the speeds in the config file and job file and I can't see anything that is causing this odd behaviour.

For my original flag job - white was the first tool (T2) and it is fairly slow
Then blue as the 2nd tool goes very fast.

For me new test object - T0 Is the first colour and goes fairly slow,
Then White and Red go too fast.

I've changed my post processor to put federates on every G1 - but it doesn't seem to be making a difference - so I think there must be something else that is affecting this.

dc42

@dwuk3d most likely your slicer is outputting M203 commands to limit the X and Y speeds. Most slicers can be configured not to have this reprehensible behaviour.

dwuk3d

@dc42 Thanks - but its definitely not doing that - I've turned that off.
I've also put null M203's and M201's into every filament change Gcode - and am getting the following consistently
From queue 12 - the slow one in this case
Max speeds (mm/min): X: 21000.0, Y: 21000.0, Z: 600.0, U: 21000.0, V: 21000.0, W: 21000.0, A: 600.0, B: 600.0, 600.0, E: 1800.0:1800.0:1800.0, min. speed 30.00
Accelerations (mm/sec^2): X: 6000.0, Y: 6000.0, Z: 500.0, U: 6000.0, V: 6000.0, W: 6000.0, A: 500.0, B: 500.0, 500.0, E: 250.0:250.0:250.0

from queue2 - the fast one
Max speeds (mm/min): X: 21000.0, Y: 21000.0, Z: 600.0, U: 21000.0, V: 21000.0, W: 21000.0, A: 600.0, B: 600.0, 600.0, E: 1800.0:1800.0:1800.0, min. speed 30.00
Accelerations (mm/sec^2): X: 6000.0, Y: 6000.0, Z: 500.0, U: 6000.0, V: 6000.0, W: 6000.0, A: 500.0, B: 500.0, 500.0, E: 250.0:250.0:250.0

I have also monitored feed rates by putting a few
echo inputs[state.thisInput].feedRate into the Job, plus also watching the two values on DWC - and they both seem to range up to 500 - and I can't see any differences between the fast and slow ones.

So still a bit of a mystery to me - especially as it was Blue yesterday - vs white and red today - I thinks the order of first tool printing - but I have change to use the real axis rather than X&Y for all tools too - so that might be making some sort of difference.

I wonder if its accelerations rather than feed rates - I might try lowering all of the accelerations down to see if I can get both queues to at least be the same slow speed - as for my current test print the Red and White is going too fast for print quality.

If you look at one of my videos - such as this one - you will see how much faster the blue printing is once it starts doing inner walls compared to the white and red.
https://youtu.be/5FAYvt4uwtw?t=107

Also looking a bit further into the video - the speeds off the X1C and Sovol have both been set at 350x60 - but the acceleration of the X1C is set much faster - but on the X1C layer 1 the blue printing of the inner walls is a lot slow that it was on the Sovol Duet Machine - so it looks to me like it is fast tool exceeding the feed rates, rather than the slow tool being particularly slow.