Sovol SV08 Multiple Motion System Upgrade.

T3P3Tony

@dwuk It would be good to work out why homing was not working as expected in 3.6beta4. Where have been a lot of changes between 3.5.4 and 3.6 so the release notes may explain why. If not then please share your U and V homing files so we can have a look at those.

dwuk

@T3P3Tony I think as you suggest I will go back to 3.6.0b4 and investigate the homing issue a bit more.

I guess I could also try doing the homing of the two axes in parallel too - to see if that helps.

Homing files attached below:
homeall.g homeu.g homev.g

T3P3Tony

@dwuk

Your homeu for reference (please use code blocks for these file, it makes it easier for people, especially on phones):

;echo "homeU disabled"
;M99
; homeu.g
; called to home the U axis
M569 P1.0 S0 D3 V500 ; driver 1.0 goes backwards (U axis)
M569 P1.1 S0 D3 V500 ; driver 1.1 goes backwards (V axis)
;
; generated by RepRapFirmware Configuration Tool v3.5.10 on Thu Jan 23 2025 15:02:10 GMT+0000 (Greenwich Mean Time)
;M913 U40 V40
;M400

; increase Z
G91 ; relative positioning
if exists(param.Z)
    ;G1 H2 Z{param.Z} F6000
else
    G1 H2 Z5 F6000; move Z relative to current position to avoid dragging nozzle over the bed
G1 H2 V10 U-10
M400
G90 ; absolute positioning

; home U
G91 ; relative positioning
var maxTravel = move.axes[0].max - move.axes[0].min + 5 ; calculate how far X can travel plus 5mm
G1 H1 U{var.maxTravel} F8000 ; coarse home in the +U direction
G1 U-5 F6000 ; move back 5mm
G1 H1 U{var.maxTravel} F3000 ; fine home in the +U direction
G90 ; absolute positioning

; decrease Z again
G91 ; relative positioning
;G1 H2 Z-5 F6000 ; move Z relative to current position
G90 ; absolute positioning

;M400
;M913 U100 V100
;M400

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)

you are setting U and V configurations in home U. I would remove the references to V in home U.

This is an issue:
var maxTravel = move.axes[0].max - move.axes[0].min + 5 ; calculate how far X can travel plus 5mm
given U is not axis 0. It probably working if U and X are the same length though.

Also you are lifting Z but not returning it (that may not be an issue)

I see you are switching the speed of switch from stealthChop to to spreadCycle mode during homing. and the U and V are in stealthchop while the other axes are in spreadCycle so i expect thats the route of the issue/different behaviour.

Try getting everything working in spreadCycle and then explore sensor less homing

dwuk

@T3P3Tony Thanks for the comments.

Had another go on 3.6.0.beta4

With the following motor settings:

;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)

And the following homeU

G91 ; relative positioning
if exists(param.Z)
    ;G1 H2 Z{param.Z} F6000
else
    G1 H2 Z5 F6000; move Z relative to current position to avoid dragging nozzle over the bed
;
G1 H2 V10 U-10 F6000
M400

;

var maxTravel = move.axes[0].max - move.axes[0].min + 5 ; calculate how far X can travel plus 5mm
G1 H1 U{var.maxTravel} F8000 ; coarse home in the +U direction
M400

G1 U-5 F6000 ; move back 5mm
M400

G1 H1 U{var.maxTravel} F3000 ; fine home in the +U direction
G90 ; absolute positioning

And homeV

G91 ; relative positioning
if exists(param.Z)
    ;G1 H2 Z{param.Z} F6000
else
    G1 H2 Z5 F6000; move Z relative to current position to avoid dragging nozzle over the bed
var maxU = move.axes[4].max - 5

G90 ; absolute positioning
G1 U345


; home V
G91 ; relative positioning
var maxTravel = move.axes[0].max - move.axes[0].min + 5 ; calculate how far V can travel plus 5mm
G1 H1 V{var.maxTravel} F6000 ; coarse home in the +V direction
G1 V-5 F6000 ; move back 5mm
G1 H1 V{var.maxTravel} F7000 ; fine home in the +V direction
G90 ; absolute positioning

; decrease Z again
G91 ; relative positioning
;G1 H2 Z-5 F6000 ; move Z relative to current position
G1 V-10 U-10
G90 ; absolute positioning

Results were:
On 3.6.0b4 the U and V axis (which are on the toolboard mode Mini5+) are moving - but are unresponsive - they don't move instantly like they do on 3.5.4 (went back and rechecked), and the two stage homing takes quite a while to get to the 2nd stage. (unlike 3.5.4 where it is instant).

Also the V Axis homing sometimes misses the end stop (which is at the back right) - probably due to slow reaction too - when I use HomeAll.

Also when you just use the button's to move the U & V - they don't react instantly - so I am wondering where there is some sort of comms issue in 3.6.0b4 - as I don't notice this in 3.5.4

X&Y (which are directly connected to the 6HC) still seem ok on 3.6.0b4

Also I am still getting the issue with not being able to access the U axes within M596 P1 - which doesn't occur in 3.5.4

Tried doing the homing within M596 P1 for U&V. and M596 P0 for X&Y - and that failed because Z was then stuck in P1 - and couldn't be accessed in P0.

In response to your points:
"you are setting U and V configurations in home U. I would remove the references to V in home U."

Would be good if I could - the main reason it is there is that in my current microswitch based design the V axis switch gets knocked sideways if the U axis tries to home when V is too far to the back.

"This is an issue:
var maxTravel = move.axes[0].max - move.axes[0].min + 5 ; calculate how far X can travel plus 5mm
given U is not axis 0. It probably working if U and X are the same length though."

Agreed that is an issue which I will correct - however as I have set the minimum for U at 30 - then it is slightly shorter than X - so the end stop will still hit.

"Also you are lifting Z but not returning it (that may not be an issue)"

Agreed need to tidy up Z lifting

"I see you are switching the speed of switch from stealthChop to to spreadCycle mode during homing. and the U and V are in stealthchop while the other axes are in spreadCycle so i expect thats the route of the issue/different behaviour."

Removed the settings in config.g - tried both modes - but still got the slow reaction problem in 3.6.0b4 - and still works fine with the new settings in 3.5.4

"Try getting everything working in spreadCycle and then explore sensor less homing"
I've switched back to 3.5.4 again for now - as the slow response of U and V on 3.6.0b4 are I think too much of an issue. I could try a different version - to which beta version it starts to appear.

dwuk

@dwuk Further update; @T3P3Tony

Tried with 3.6.0b3 - same issue with slow response of U&V
Tried reverting just the Mini5+ to 3.5.3 - that seems to remove the issue.

So for me both 3.6.0 beta versions are not working with a FD connected Mini5+

Also on 3.6.0b3 (with 3.5.3 Mini5+) I get the same issue with not being able to access the U axis within M596 P1. - where's with exactly the same macro's and homing sequences I can with 3.5.3

Will go back to 3.6.4b4 again (with both 3.5.3 on the Mini5+) to see if I can work out a sequence that allows me to access the U axis from the 2nd motion system.

dwuk

@dwuk Further update - got access to the U axis in 3.6.0b4 by surrounding all accesses to it - including in the homing with M596 P1 before and M596 P0 after.

M598 still not working though, plus my Mini5+ is still on 3.5.4.

dwuk

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

dwuk

Jay and Andy - this is the thread with more detailed info about my issues @gloomyandy @jay_s_uk

I've got a converted SV08 with a 6HC main board (for Z,X,Y) and Mini5+ as tool board (for UV and Z Hoppers), and then 1LC boards for the extruders.

The system currently has 2 gantries and 2 extruders - but I am aiming to make both of the gantries IDEX once I have got the basic system working.

I'm aiming to parallel print with up to 4 heads at the same time - initially using a GCODE post processor to split each layer into segments that can be printed in parallel.

dwuk

Horrible print quality I know because I didn't get the Z height quite right on the back gantry, plus it seems to have come loose a bit, plus had to comment out two lines of Gcode out due to Multiple Motion System gantry conflicts - which is why I think the front gantry print messed out.

Also had to manually set temperatures as haven't properly programmed them into the tool changing macros.

But still this is my first dual head, 4 segment print.

With the post processor created segment boundary crossing the 45 square on the back gantry.

o_lampe

@dwuk Still looking good for a first attempt. I guess you had mesh levelling off?
Maybe try to dial in each toolhead independently with unaltered single-head gcode. When both work OK on their own, let them cooperate.

dwuk

@o_lampe thanks. It was a pretty poor quality first test I agree, but it was nice to see both heads actually printing something independently.

The rear head had come quite loose which is why the lines are a bit curved- so I have upgraded the bolts that hold the two linear rails together.

Also I had specified ABS instead of PLA in the material profile in Orcaslicer which explains why the extruders kept wanting to go up to 260 and the bed was hotter than it usually is.

Will look at mesh levelling fairly soon.

Will do another attempt in the next couple of days once I have made some corrections to the parallel print gcode post processor.

Won't be able to get beyond layer2 though until I have resolved my RRF MMS M598 sync issue.

I tried working around it with conditional rrf gcode with loops and dwells - but haven't found a reliable way to get the motion systems to wait for each other yet.

dc42

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

Also when you just use the button's to move the U & V - they don't react instantly - so I am wondering where there is some sort of comms issue in 3.6.0b4 - as I don't notice this in 3.5.4

There are known synchronisation issues in 3.6beta releases including beta 4 when a main board is used in expansion mode. These have now been resolved.

dwuk

@dc42 great - look forward to getting access to the fixed version.

The biggest issue that leaves me with is that I can't seem to get M598 to work in any version I have tried.

I am sending commands in the sequence

M596 P1
G1....setA
M596 P0
G1...setB
M598
G1...setC (with or without M596 P0)

When SetB is faster than SetA - I am finding setC moves start before setA moves are complete -which is not the behaviour I was hoping for.

dwuk

@dc42 Update - solved my M598 not working issue hopefully.

So far (apart from the poor quality test print) I have been running all my tests with the gcode. M569/G1/M598 sequences in macro's - that I have been executing standalone.

I noticed that in the documentation it mentions something about macro's only using one stream.

Thought I would try downloading the macro, and then re-uploading it as a job.

Doing this completely changed the behaviour - and in my first few tests it looks like now the M598's seem to be doing what I wanted - i.e. Gantries waiting for each other, things that shouldn't be running in parallel waiting for each other.

So will change to using jobs rather than macro's for all of my future tests.

Also using this approach I have been able to get M597 to accept numbers as high as 30 without the motion all getting messed up - like it did in earlier tests when I went above 6.

However I am not sure whether this is due to the macro vs job differences, or the fact that my system is currently set as V3.6.0b4 on all boards (other than the Mini5+ - that is still on 3.5.4 due to the slow motion issue).

droftarts

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

I noticed that in the documentation it mentions something about macro's only using one stream.

Do you mean this setion? https://docs.duet3d.com/en/User_manual/RepRapFirmware/Multiple_motion_systems#macros-and-motion-systems

I'm not sure if this is changed behaviour between 3.5 and 3.6, or at least how it deals with multiple motion within macros may have changed, as you say it was working in 3.5. I'll check with @dc42.

Ian

dwuk

@droftarts Yes I think it was that section.

What I think is happening is if you run a macro from DWC then it seems to ignore M598's - this happens I think on 3.5.4 and 3.6.0b4. M596's work as expected though in this mode.

The difference I have noticed between 3.5.4 and 3.6.0b4 - is relating to releasing Axis.
In 3.5.4 Axis seem to not be held after M400's (or the ignored M598's I presume).

Whereas with 3.6.0b4 I can't so far find a way of releasing an Axis once is has been allocated to motion system by a M596. Neither M598's run from DWC or from Jobs seem to release the Axis - which I am managing to work around for now by doing the homing within M596's.

But this will probably be a problem when I want to do things like layers with part IDEX duplicate mode and part independent Axis printing.

I haven't investigated M400s - but I suspect I have the same issue with them.

I am wondering whether I can work around it somehow by swapping motors between Axis,

dwuk

Having quite a lot of trouble with getting parallel moves working - on 5.6.0b4

If I only have a small number of G1's then they run in parallel ok, but as soon as I introduce more than 5 moves then only the last 5 seem to run in parallel.

For example if I send 10 moves to motion system 0, plus 5 to motion system 1, then it seems that the motion system 1 moves will not start until there are only 5 moves left on the motion system 0 queue.

I have tried lots of combinations of P,R and S values M597 values on both queues - but it doesn't seem to make any difference to when the queue 1 start to run in parallel.

It also doesn't seem to be a speed or time related - because changing the speed of the last 5 moves in queue 0 also exhibits the same behaviour.

I guess I could do some complex processing on the two streams to work out their likely move times and then try and present them in tiny little blocks - but that is not the way I was expecting things to work.

What I have like to be able to do is ideally have a whole 'segment' (probably about 1/4 the size of the print bed) sent to motion system 0, in parallel to another 'segment' sent to motion system 1 - which could be 100s of G0/G1/G2/G3s running in parallel.

Have tried to understand the code - but it is quite complicated.

My only discoveries so far is that it looks like the M597 P value defaults to 60 on both queues - not 3 on queue1 as per documentation. Also I can't see anywhere that the S value is processed.

Example very simple job attached.

if move.axes[0].homed == false || move.axes[1].homed == false || move.axes[2].homed == false || move.axes[3].homed == false || move.axes[4].homed == false  
  G28



T0

G1 Y20 X100 G5000
M400


M596 P0


G1 Y10 F500
G1 X100 F500
G1 Y20 F500
G1 X150 F500
G1 Y30 F500
G1 X160 F500
G1 Y40  F500
G1 X170 F500
G1 Y50 F500  ;First Parallel Move
G1 X180 F500
G1 Y60 F500
G1 X190 F500
G1 Y70 F500

M596 P1


G1 U100 F5000
G1 U200 F5000


M596 P0


G1 Y20 F10000
G1 Y50 F10000
G1 X200 F5000
G1 X300 F5000


M596 P1

G1 U120 F5000
G1 U200 F5000
G1 V300 F5000

M598
M400



M596 P0

I this example Gantry0 does the first 8 moves by itself, with gantry1 only starting to move in parallel to the last 5 moves. If I change the number of moves in the first block then the parallel start moves back or forward - so that only the last 5 moves are done in parallel.

The 2nd two small blocks of moves run in parallel ok.

dwuk

Demo of slightly parallel print.

https://youtube.com/shorts/02D4zS33ymk?si=yqVuzbFA2yzvwQvO

The red and white segments should be both printing at the same time - but as per 1m50s into video - the white only comes in about 5 moves from the end of the Red.

The GCODE file consisted for M569 P1, Red Segment 1, M569 P0, White Segment1 etc.

Work needed I know on parking and restart priming - but still fairly pleased with the slightly overlapping segments.