Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Sovol SV08 Multiple Motion System Upgrade.

    Scheduled Pinned Locked Moved
    My Duet controlled machine
    8
    232
    25.4k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • dwuk3dundefined
      dwuk3d @dwuk3d
      last edited by

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

      droftartsundefined 1 Reply Last reply Reply Quote 1
      • droftartsundefined
        droftarts administrators @dwuk3d
        last edited by

        @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

        Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth

        dwuk3dundefined 1 Reply Last reply Reply Quote 0
        • dwuk3dundefined
          dwuk3d @droftarts
          last edited by

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

          1 Reply Last reply Reply Quote 0
          • dwuk3dundefined
            dwuk3d
            last edited by dwuk3d

            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.

            1 Reply Last reply Reply Quote 0
            • dwuk3dundefined
              dwuk3d
              last edited by

              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.
              IMG_7030.jpeg

              1 Reply Last reply Reply Quote 0
              • dwuk3dundefined
                dwuk3d
                last edited by dwuk3d

                Update - found a command by looking at the RRF code - M606 S1.

                This seems to be needed to get the parallel printing to work - it is not mentioned in the Multi Motion System documentation - but is in the Gcode dictionary.

                I got a few out of memory errors and head crashes (update - this was due to me still trying to increase the queue sizes to 100 which is no longer required) so might need to refine homing - but did manage to get my gcode post-processed segmented print to run in parallel by adding this command to the top of the file.

                But did manage to get some proper parallel printing going - see attached video.

                https://youtube.com/shorts/Qsu6LDXJ0Pc?si=creqKv_9-WN14i2Z

                droftartsundefined 1 Reply Last reply Reply Quote 1
                • dwuk3dundefined
                  dwuk3d
                  last edited by

                  Made quite a few improvements to Z height setting between the two gantries.

                  So far only using the two inductive problems - but will add in the front Gantry Voron Tap capability, plus the ball probe.

                  Also made a start on Z Hopping - initial Macro here.

                  ;M800.g
                  if exists(param.P)
                      if param.P == 0
                          if exists(param.H)
                              if param.H > 0
                                  M596 P0
                                  G90
                                  G1 H2 B0.8 F300
                                  M84 B ; Turn off IDLE current on B
                  
                              else
                                  M596 P0
                                  G90
                                  G1 H2 B0.4 F300
                                  M84 B ; Turn off IDLE current on B
                           
                          else
                              echo "Hop parameter H missing"
                      if param.P == 1
                          if exists(param.H)
                              if param.H > 0
                                  M280 P1 S60  ; Set Servo
                  
                              else
                                  M280 P1 S120  ; Set Servo
                  
                          else
                              M42 P1 S0
                  

                  At present I have a stepper on Axis B for the front gantry (P0) and a servo for the rear gantry (P1).

                  Not sure how well the servo movements will work with the motion queue - so lots of testing to do.

                  1 Reply Last reply Reply Quote 0
                  • dwuk3dundefined
                    dwuk3d
                    last edited by

                    Having a bit of trouble getting a consistent first layer across both tools when I have tried a large single model printed by both print heads - so decided to start investigation mesh compensation.

                    First stage is probing the bed - I don't think it is too bad based on this initial test - I was expecting it to be worse than this.

                    D9095B61-AB20-4F40-82A9-7B7B692682D1.png

                    Because the mesh compensation in the firmware is not aware of my 'mini Z axis/ZHopper' - then I am going to have to do the mesh compensation off-line in a post processor.

                    I will have to split each long move into segments the size of the grid.

                    First thing I will do is just try and get printing working really well on the XY axis (without the ZHopper), but with mesh compensation on.

                    Will then investigate whether I can do anything with tool mapping - by switching the Z axis between the main gantry Z axis at layer changes, and within the layer my ZHop (B) Axis - to see if I can convince the firmware to apply the compensation to my miniZ axis instead of the real one.

                    If as I expect this doesn't work -

                    Then will try to get the same results with no mesh compensation on, but instead doing the compensation in a post processor - - that takes in the Gcode and the heightmap.csv - then replicates what is done in Move::ComputeHeightCorrection. - and then does actual moves using my B axis.

                    Then once I have got it working for the XY axis, I should be able to do the same for the UV axis, plus later the 2 other IDEX print heads.

                    o_lampeundefined 1 Reply Last reply Reply Quote 0
                    • dwuk3dundefined
                      dwuk3d
                      last edited by

                      Update - changed my probing approach and tried some prints with and without mesh levelling and didn't notice a lot of difference, so will leave it for now.

                      Managed to get a fairly good quality dual tool IDEX print working - see attached.
                      3BBEC533-392B-47F8-ABA1-3A0600CF07A3_1_105_c.jpeg

                      Just need to sort out oozing while tool is parked, and some sort of wiping.

                      Now moving on the Z Hoppers.

                      At present my XY Zhopper is attached the the Mini5+ board (with the UV Gantry) - which I expected to cause problems when using multiple motion systems - which it did.

                      So I have swapped one of the Z Motors over to the Mini5+, so that the Zhopper is on the main 6HC board.

                      Initial tests are showing better results - with the Z Hopper moving at the correct time in the sequence.

                      The Servo based Z Hopper is a bit of an issue too.

                      I was expecting to run it on Motion System 1 - with the UV axis - but I am finding the servo movements are not happening as expected, where as if I run the UV Axis and the Servo on Motion System 0 is seems to work better - so might have to operate in that way - will probably have to swap the rest of the Z Axis over to the Mini5+ too - so will use Motion System 0 for UVZ + Servo, and Motion System 1 for X,Y,B(Z Hopper).

                      I don't really need to run the Z in parallel so will what happens for a while leaving it spread across the two boards - as unfortunately the stepper connectors are different between the 6HC and Mini5+

                      1 Reply Last reply Reply Quote 0
                      • dwuk3dundefined
                        dwuk3d
                        last edited by

                        Parallel printing working demo Video

                        Fully aligned - single object parallel print

                        With alignment using Ember Prototypes CXC

                        B26CC7A5-3913-4BFC-9C6A-8967F7BC1E4C_1_201_a.jpeg

                        https://youtu.be/tCq9kTjkhn4

                        1 Reply Last reply Reply Quote 2
                        • o_lampeundefined
                          o_lampe @dwuk3d
                          last edited by

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

                          I will have to split each long move into segments the size of the grid.

                          IMO, that won't be that easy. Mesh adjustment is continuous between grid points.
                          And for tool No2 you'd have to know where tool No1 is to compensate No2's adjustment accordingly.

                          dwuk3dundefined 1 Reply Last reply Reply Quote 0
                          • dwuk3dundefined
                            dwuk3d @o_lampe
                            last edited by

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

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

                            I will have to split each long move into segments the size of the grid.

                            IMO, that won't be that easy. Mesh adjustment is continuous between grid points.
                            And for tool No2 you'd have to know where tool No1 is to compensate No2's adjustment accordingly.

                            I'm thinking that if I do external adjustments I will get the printer to probe the mesh, but not enable mesh compensation of any print head - and would do all of the mesh adjustments manually.

                            Therefore in the example you gave Tool No1 would have its own independent adjustment (using the Z Hopper stepper), and therefore would not affect the adjustments that would need to be made for Tool No2 (using its Z hopper stepper) I think.

                            From looking at the code - it looks like long moves are segmented up for various reasons - including mesh compensation grid size - and then if mesh compensation is turned on it interpolates what the Z position of the moveTo point needs to be adjusted by - then effectively adds a Z up or down move to the XY move - which then I am guessing adds tiny linear steps to the Z move as moves between the two XY points.

                            Therefore in the case of my XYB and UVC design - I would only use Z for layer changes, with all other Zhops and mesh adjustments being done independently with the B and C Zhopper axis.

                            Every XY or UV move would where required firstly be segmented into grid size chunks, and then have a B or C move up or down added to every XY or UV move.

                            It may as you say be more complicated than this - but it should do something to help.

                            Once I have resolved my flushing/oozing issues will do some more tests to confirm where meshing issues show up, and then try to fix them with my proposed approach.

                            Once I get to IDEX I would have something like - with XxYBb UuVCc Z - where BbCc are the 4 Z Hoppers - which would all need to be added to the moves for manual meshing.

                            PS/ I think the Z hopper approach to small fast moves - rather than using the now quite heavy (and soon to be even heavier) Z gantry might end up working quite well.

                            o_lampeundefined 1 Reply Last reply Reply Quote 0
                            • dwuk3dundefined
                              dwuk3d
                              last edited by

                              Quite a frustrating day.

                              Hit an issue with Sensorless homing in motion System 1 on main 6HC board. But found that on 3.5.4 it is possible to release Axis from motion systems with this sequence - from the current motion system

                              T-1
                              M400 (or probably M598)

                              So switched the axis between Motion system 0 and 1 to get the homing to work,

                              Made some good progress on flushing, but then hit an issue with speeds.

                              On 3.5.4 motion system 0 move speeds seem to match the GCODE/config.g ok - but on Motion System 1 they seem to be a lot faster - even on layer 1 - and the web interface doesn't report the speeds.

                              So switched to 3.6.0.rc1 to try and solve the speed issue.

                              The good news is that the Axis on the Mini5+ doesn't seem to be slow now - like it was on 3,6,0b4

                              On 3.6.0rc1 sensorless homing seems to work ok on motion system1 - but the problem with these versions is that it seems to be impossible to release an axis from a motion system once it has been used - including the first time - as per the @Alva thread.

                              Tried getting 3.6.0.rc1 homing macro's working - but it was getting steadily more complicated - especially with bed probing - where I need to specify Z,X & Y in the same command - but it won't let me - as they are stuck in separate motion systems after homing - so have switched back to 3.5.4 again for now

                              The only way I can think to get 3.6.0rc1 working for me is:
                              a) Switch XYZ to be back to all be on motion system 0 - and forget the servo based Z Hopping on the UV axis (which only works on Motion system 0).
                              b) Switch Bed probing over from the XYZ to UVZ Axis.

                              1 Reply Last reply Reply Quote 0
                              • o_lampeundefined
                                o_lampe @dwuk3d
                                last edited by

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

                                I would only use Z for layer changes, with all other Zhops and mesh adjustments being done independently with the B and C Zhopper axis.

                                👍
                                That's what I proposed to implement in RRF while I played with the hashPrinter.

                                I wonder if it's possible to use G10/G11 for FW-retraction with zHop in your case? You'd have to link it with your BbCc motors. @dc42 ?

                                dwuk3dundefined 1 Reply Last reply Reply Quote 0
                                • dwuk3dundefined
                                  dwuk3d @o_lampe
                                  last edited by

                                  @o_lampe Interesting - I hadn't thought about firmware retraction - its turned off in my printer profile - but if I turn it on - I get this as a typical sequence

                                  G10 ; retract
                                  ;WIPE_START
                                  G1 X140.121 Y84.188 E-.24
                                  ;WIPE_END
                                  M486 S-1
                                  M486 S1
                                  G1 Z.6 F15000
                                  G1 X152.303 Y279.456 Z.6
                                  G1 Z.2
                                  G11 ; unretract
                                  

                                  I've created my own ZHOP command - M800 - I guess I could use being inside a G10/G11 pair to know to change the Z moves to my M800 commands.

                                  I will also try just commenting out the Z moves (or turning off Z Hopping in the slicer), and try setting the Z axis to my B/C axis in the M563 tool definition as you suggest- and then specify Z Movement in my M207 to see what happens.

                                  Will also try turning on meshing with my BC axis defined as Z to see if it does any auto adjustments using my axis, rather than the proper Z Axis.

                                  1 Reply Last reply Reply Quote 0
                                  • dwuk3dundefined
                                    dwuk3d
                                    last edited by

                                    After snapping off the V gantry end stop for the 2nd time, decided to move the end stop off of the print head onto the flying gantry, and also changed to optical.

                                    Also took the opportunity to redesign the rear gantry holders to allow them to slot in between the idlers at the back - to give about 15mm of extra Y movement.

                                    FE074872-10B0-4DA5-9F1B-FB932389056B.jpeg

                                    Got a nice bit of exposure for my project (and its Duet electronics) from Micheal Laws on the Teaching Tech YouTube channel today - see the brief mention in first 2 minutes of this video.
                                    https://youtu.be/F5lyLPyndTU?si=zS3x0FlBM8Jj7b65

                                    Made a start on the IDEX belt design. My current thinking is having the two Y belts on the side of the flying gantry - with both motors at the front - to help balance the whole gantry.

                                    The design will be mirrored on both sides of the gantry.
                                    Screenshot 2025-03-07 at 17.11.58.png

                                    o_lampeundefined 1 Reply Last reply Reply Quote 0
                                    • o_lampeundefined
                                      o_lampe @dwuk3d
                                      last edited by o_lampe

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

                                      Made a start on the IDEX belt design.

                                      Not sure if I get it right: the two Y motors positions indicate a different kinematic model, it seems you want to use a H-bot design mixed with CoreXY? Or is it some markforge stuff?

                                      Another problem might be the M800 macro. IDK if it's smart to use macros while printing dual stream...IMHO you should replace G10/G11 commands with the macro-content by your postprocessor

                                      dwuk3dundefined 1 Reply Last reply Reply Quote 0
                                      • dwuk3dundefined
                                        dwuk3d @o_lampe
                                        last edited by

                                        @o_lampe I think it is called Dual Markforge - its the same as the Ratrig Vcore4 idex - doubled up.

                                        Attempt at demo here - although when I re look at it I think there are some errors in the animation - as it should be top belt for one X axis and bottom for the other
                                        https://youtu.be/CjgITPc4vNg?si=SDhkxPcVuqdtXxy6

                                        Re G10/G11 - changed post processor to be aware of them and switch the Z movements to my M800's, which handle both servo and stepper based Z hopping.

                                        Also added in G10/M800 M800/G11's around long added G0 moves due to segmenting that seems to work quite well.

                                        Have decided to drop the servo and switch both gantries to stepper based Z hoppers - which might allow me to remove the M800's and let the G10/G11s to do the Z hopping.

                                        Also my little Z hopping stepper isn't really up to the job I think as it is a bit slow and gets hot on idle. I'm currently turning off idle current after every move - but that makes it lose its homed status which I doubt G10/G11 would be happy with.

                                        Tried lowering currents down to 1% instead of- but that seems to mess with parallel printing as I don't think the current changing code works well on motion system 1.

                                        Have ordered two more motor options to try - lead screw Nema8 and lead screw Nema11 - hopefully one or both of those will be faster and have less heatup issues.

                                        dwuk3dundefined 1 Reply Last reply Reply Quote 0
                                        • dwuk3dundefined
                                          dwuk3d @dwuk3d
                                          last edited by dwuk3d

                                          @dwuk3d !IMG_8703.jpeg IMG_8702.jpeg
                                          https://www.aliexpress.com/item/1005008402852335.html

                                          https://www.aliexpress.com/item/1005004769535321.html

                                          1 Reply Last reply Reply Quote 0
                                          • droftartsundefined
                                            droftarts administrators @dwuk3d
                                            last edited by

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

                                            Update - found a command by looking at the RRF code - M606 S1.

                                            This seems to be needed to get the parallel printing to work - it is not mentioned in the Multi Motion System documentation - but is in the Gcode dictionary.

                                            Thanks for pointing this out, this may be the reason that multiple motion systems haven't been working for people. Unfortunately, it mostly beyond my test rig (and comprehension) to test! However, from your description, I think I understand how it should be used. I've a couple of the paragraphs in the documentation to highlight M606:
                                            https://docs.duet3d.com/en/User_manual/RepRapFirmware/Multiple_motion_systems#enabling-and-selecting-a-motion-queue
                                            https://docs.duet3d.com/en/User_manual/RepRapFirmware/Multiple_motion_systems#command-streams-from-file

                                            Can you check they are correct from your understanding, please?

                                            Ian

                                            Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth

                                            dwuk3dundefined 1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Unless otherwise noted, all forum content is licensed under CC-BY-SA