Sovol SV08 Multiple Motion System Upgrade.

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.

dwuk3d

@dwuk3d
Ps/ the 500's relate to the fact that orca slicer is putting F30000 on zhops for some reason.-
With slower speeds like between F3000 and F13000 for the actual print moves.

I might try reducing the F30000 to say F600 in my post processor tomorrow to see if somehow that is getting picked up and overriding the later feedrates.

dc42

@dwuk3d are you using mesh bed compensation? If so, is it applied to both tools or only the first one?

dwuk3d

@dc42 no not yet.
All i am doing at present is tap probing two points per print head (one in the centre and one by the prime tower) and then switching the Zhopper motor offset to the appropriate height in my tool change/priming macros when switching between priming and printing.

Once I have sorted out to speed issue doing independent mesh compensation is what I plan to do - probably using a SZP on each print head.

In terms of the speed problem my next steps are:

Try changing the zhop speed down from F30000 (which should be being ignored by the zhoppers, but used for the xy / uv / wv moves, but not extrudes)
Update - changing ZHop + ZHop Travel speed from F30000 to F3000 - no impact.
There are still travel moves of F30000 - so next step to change all of those over to F3000
Update2 - Changing travel moves to F3000 no effect - 2nd tool, 2nd layer still too fast

Example Layer switch on T2 - where printing is very fast

M204 P2000
; printing object LegF VarL.stl id:0 copy 0
M204 T2000
M486 S0
echo "985",inputs[state.thisInput].feedRate
G1 A{global.aOffset+0.4} F3000
M802 L986; 
G1 F3000 W165.356 V196.864 A{global.aOffset+0.4}
M802 L988; 
T-1  
G1 F3000 Z.4
M400 ; Release Z Axis
T2  
G1 F3000 A{global.aOffset}
M802 L993; 
echo "995",inputs[state.thisInput].feedRate
G1 E.8 F1800
;TYPE:Inner wall
;WIDTH:0.449999
echo "999",inputs[state.thisInput].feedRate
G1 F13265.237
G1 F13265.237 W165.181 V196.373 E.01729
G1 F13265.237 W165.075 V195.878 E.0168
G1 F13265.237 W165.048 V195.177 E.02327
G1 F13265.237 W165.145 V194.667 E.01722
G1 F13265.237 W165.265 V194.165 E.01714
G1 F13265.237 W165.476 V193.669 E.01788
G1 F13265.237 W165.747 V193.233 E.01702
G1 F13265.237 W172.811 V200.297 E.33138

Output

1584 30.0
1592 50.0
1596 30.0

T0 Gcode - which is still normal speed

T0  

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

M98 P"0:/macros/changeFilament.g" A1 B220 L1  N0  F220 
M203
M201

M106 S255
; Filament gcode
G10 S220 P0 ; set nozzle temperature
;prev preheat:0:T0:**NO PREHEAT**
M116.1 ; wait for temperature to be reached
; printing object LegF VarL.stl id:0 copy 0
M486 S-1
M486 S0
echo "1584",inputs[state.thisInput].feedRate
G1 B{global.bOffset+0.4} F3000
M802 L1585; 
G1 F3000 X126.246 Y193.591
G1 F3000 B{global.bOffset+0.4}
M802 L1588; 
G1 F3000 B{global.bOffset}
M802 L1590; 
echo "1592",inputs[state.thisInput].feedRate
G1 E2 F1800
;TYPE:Inner wall
;WIDTH:0.449999
echo "1596",inputs[state.thisInput].feedRate
G1 F13265.237
G1 F13265.237 X126.244 Y193.59 E.00007
G1 F13265.237 X126.244 Y167.554 E.86366
G1 F13265.237 X126.621 Y167.427 E.01318
G1 F13265.237 X126.813 Y167.232 E.00908
G1 F13265.237 X126.97 Y166.902 E.01213
G1 F13265.237 X127.002 Y166.658 E.00817

Note they both specify the same feed rate

Try reducing the overall speeds and accelerations - firstly globally, but might then try changing it dynamically between travel and extrude moves to see what happens
Update - trying M203's before every feed rate change - examples

G1 F3000 X130.472 Y162.126 E.02147
G1 F3000 X130.91 Y162.539 E.02242
G1 F3000 X131.625 Y163.351 E.04029
G1 F3000 X132.131 Y163.869 E.02698
G1 F3000 X132.939 Y164.566 E.03976
G1 F3000 X133.353 Y164.796 E.01763
M203  X21000  Y21000 
G1 X133.718 Y164.469 F30000
;TYPE:Outer wall
M203  X3000  Y3000 
G1 F3000
G1 F3000 X134.388 Y165.376 E.04199
G1 F3000 X134.994 Y165.998 E.03233
G1 F3000 X135.427 Y166.324 E.02019

G1 F3000 U134.805 V165.063 E.02208
G1 F3000 U134.543 V164.743 E.01539
M203  U1800  V1800 
G1 E-.8 F1800
M203  U21000  V21000 
G1 D{global.dOffset+0.4} F30000
M802 L796; 
G1 F30000 U139.183 V165.424 D{global.dOffset+0.4}
M802 L798; 
G1 F30000 D{global.dOffset}
M802 L800; 
M203  U1800  V1800 
G1 E.8 F1800
;TYPE:Bottom surface
;WIDTH:0.582273
M203  U6000  V6000 
G1 F6000
G1 F6000 U130.293 V156.535 E.55254
G1 F6000 U130.293 V157.297 E.03352
G1 F6000 U138.38 V165.384 E.50263
G1 F6000 U138.077 V165.402 E.01331

Update - 2nd tool still too fast even with M203's before every feed rate change.
Next test - changing the limit on M203's to F12000 vs F21000 to see if that slows down T2/T1.
Update- still not working - T2/T1 still too fast.
Next test - changing config.g to lower all Axis speeds from 21000 to 12000 - so see If that at least slows down the layer2 extruder moves on T2/T1
Update - T2/T1 still too fast
Next test - changing config.g to lower all Axis speeds down to 6000, plus also change all G1 F30000 to G1 F3000
Update T2/T1 still too fast - no extruder moves are nice and slow - but extrude moves are still far too fast and don't seem to be respecting any sort of feed rates.
Maybe somehow to extruder federates are being respected rather than the motion ones,
Next test - Trying halving all extruder rates


; Extruders
M584 E121.0:122.0:123.0 ; set extruder mapping
M350 E16:16:16 I1 ; configure microstepping with interpolation
M906 E800:800:800 ; set extruder driver currents
M92 E492:492:492 ; configure steps per mm
;M566 E120:120:120 ; set maximum instantaneous speed changes (mm/min)
;M203 E{30*60}:{30*60}:{30*60} ; set maximum speeds (mm/min)
;M201 E250:250:250 ; set accelerations (mm/s^2)

M566 E60:60:60 ; set maximum instantaneous speed changes (mm/min)
M203 E{15*60}:{15*60}:{15*60} ; set maximum speeds (mm/min)
M201 E125:125:125 ; set accelerations (mm/s^2)

That didn't work either - but finally I think I am getting somewhere.
M203
Max speeds (mm/min): X: 6000.0, Y: 6000.0, Z: 600.0, U: 6000.0, V: 600.0, W: 600.0, A: 600.0, B: 600.0, 600.0, E: 1800.0:1800.0:1800.0, min. speed 30.00

I have slowed down all of the max speeds on the UV&W axis by a factor of 10 using M203's before every feed rate change - its now moving at a snails pace - but seems to at least be taking notice of the max feed rates now and going at a more reasonable pace for the extrude moves.

Interestingly it seems to be moving faster on the W than the V axis for these types of move

        G1 A{global.aPrimeOffset} F300
        G1 F2000
        G1 W{param.W} V{param.V} F2000
        ;M800 T{param.T} H0  ; ZHop down
        G1 W{param.W} V{param.V+param.S} E{var.E} F2000
        G1 W{param.W+var.S2} V{param.V+param.S}  E{var.E*2} F2000
        G1 W{param.W+var.S2} V{param.V}  E{var.E*2} F2000
        G1 W{param.W} V{param.V}   E{var.E} F2000
        G1 W{param.W-2} V{param.V+param.S/2} 
        G1 W298 V295 F2000

Example main printing GCODE that's finally running at a controllable pace - a bit slow - so will probably try just dividing the speed by 5 for extrude moves only next.

G1 E.8 F1800
;TYPE:Inner wall
;WIDTH:0.449999
M203  W600.0  V600.0 
G1 F13265.237
G1 F13265.237 W176.869 V198.669 E.01729
G1 F13265.237 W176.762 V198.174 E.0168
G1 F13265.237 W176.736 V197.473 E.02327
G1 F13265.237 W176.832 V196.963 E.01722
G1 F13265.237 W176.952 V196.46 E.01714
G1 F13265.237 W177.164 V195.964 E.01788

Try some simpler models with just 3 squares - and try various combinations of 2 or 3 in different orders to confirm whether it is the ordering of tool swaps that is impacting which gantry runs too fast.
Try later firmware as I am still on 3.5.4