unstable movement in X/Y with latest beta



  • having movement issues with the current beta, X and Y movement is unsteady doing g0 circular paths. system is a lowrider cnc with XYYZZ motors. slewing moves seem fine but even at super slow feed rates on x/y the motion has jerks and pauses while following a 6mm circular path. not every circle but most have random hiccups. both Y motors are sync'd and jerk/hesitate in sync

    config.g
    ; Configuration file for Duet WiFi (firmware version 2.03)
    ; executed by the firmware on start-up
    ;
    ; generated by RepRapFirmware Configuration Tool v2.1.4 on Thu Dec 19 2019 19:08:09 GMT-0700 (Mountain Standard Time)
    
    ; General preferences
    G90                            ; send absolute coordinates...
    M83                            ; ...but relative extruder moves
    M550 P"Duet3"             ; set printer name
    
    ; Network
    M552 S1                        ; enable network
    M586 P0 S1                     ; enable HTTP
    M586 P1 S0                     ; enable FTP
    M586 P2 S0                     ; enable Telnet
    M453 S0
    ; Drives
    M669 K0                        ; cartesian
    M569 P0 S0                     ; physical drive 0 goes forwards
    M569 P1 S1                     ; physical drive 1 goes forwards
    M569 P2 S0                     ; physical drive 2 goes forwards
    M569 P3 S0
    M569 P4 S1 
    M569 P5 S1 
    M584 X0 P3
    M584 Y1:3
    M584 Z2:4 
    M584 U2
    M584 V4 P3   ; set drive mapping
    M350 X16 Y16 Z16 U16 V16 I1            ; configure microstepping with interpolation
    M92 X100.00 Y100.00 Z400.00 U100.0 V100.0    ; set steps per mm
    M566 X600.00 Y600.00 Z18.00 U600.0 V600.0   ; set maximum instantaneous speed changes (mm/min)
    M203 X7200.00 Y7200.00 Z1800.00 U7200.0 V7200.0 ; set maximum speeds (mm/min)
    M201 X400.00 Y400.00 Z100.00 U400.0 V400.0   ; set accelerations (mm/s^2)
    M906 X1000 Y1000 Z1000 U1000 V1000 I30     ; set motor currents (mA) and motor idle factor in per cent
    M84 S30                        ; Set idle timeout
    M564 H0 S0
    
    ; Axis Limits
    M208 X0 Y0 Z0 S1               ; set axis minima
    M208 X800 Y1400 Z75 S0         ; set axis maxima
    
    
    ; Endstops
    M574 X0 S1               ; set active low and disabled endstops
    M574 Y0 S1               ; set active low and disabled endstops
    M574 Z0 S1               ; set active low and disabled endstops
    M574 U0 S1               ; set active low and disabled endstops
    M574 V0 S1               ; set active low and disabled endstops
    
    ; Z-Probe
    M558 P0 H5 F120 T6000          ; disable Z probe but set dive height, probe speed and travel speed
    M557 X15:215 Y15:195 S20       ; define mesh grid
    
    ; Heaters
    M140 H-1                       ; disable heated bed
    
    ; Fans
    
    ; Tools
    M563 P0 S"Router"     ; define tool 0
    G10 P0 X0 Y0 Z0                ; set tool 0 axis offsets
    G10 P0 R0 S0                   ; set initial tool 0 active and standby temperatures to 0C
    G92 X0 Y0 Z0                   ; CURRENT LOCATION == 0
    
    ; Custom settings are not defined
    
    
    

    gcode file



  • @daavery said in unstable movement in X/Y with latest beta:

    M584 X0 P3
    M584 Y1:3
    M584 Z2:4
    M584 U2
    M584 V4 P3 ; set drive mapping

    https://duet3d.dozuki.com/Wiki/Gcode#Section_M584_Set_drive_mapping

    VERY IMPORTANT! Assigning a drive using M584 does not remove its old assignment. Therefore, if you assign a drive that defaults to being an extruder drive, you should also assign the extruder drives explicitly as in the above example. Failure to do so may result in unexpected behaviour.

    3 and 4 are by default extruder and are not reconfigured in your assignment. and because of that the default current is still being applied to them.



  • adding M584 E5 to config.g makes no difference - X and Y are still jerky and hesitating on short moves ( g0 circular interpolation)

    
    12/28/2019, 9:43:33 AM	M584
    Driver assignments: X0.0 Y0.1:0.3 Z0.2:0.4 U0.2 V0.4 E0.5, 3 axes visible
    
    M669 K0                        ; cartesian
    M569 P0 S0                     ; physical drive 0 goes forwards
    M569 P1 S1                     ; physical drive 1 goes forwards
    M569 P2 S0                     ; physical drive 2 goes forwards
    M569 P3 S0
    M569 P4 S1 
    M569 P5 S1 
    M584 X0 P3
    M584 Y1:3
    M584 Z2:4 
    M584 E5
    M584 U2
    M584 V4 P3   ; set drive mapping
    M350 X16 Y16 Z16 U16 V16 I1            ; configure microstepping with interpolation
    M92 X100.00 Y100.00 Z400.00 U100.0 V100.0    ; set steps per mm
    M566 X600.00 Y600.00 Z18.00 U600.0 V600.0   ; set maximum instantaneous speed changes (mm/min)
    M203 X7200.00 Y7200.00 Z1800.00 U7200.0 V7200.0 ; set maximum speeds (mm/min)
    M201 X400.00 Y400.00 Z100.00 U400.0 V400.0   ; set accelerations (mm/s^2)
    M906 X1000 Y1000 Z1000 U1000 V1000 I30     ; set motor currents (mA) and motor idle factor in per cent
    
    

    test g code ( stays within 240mm X and 100mm Y)
    TEST.gcode



  • video of Y0 motor running test.gcode
    y0 motor video



  • reverting to beta 12, movement is smooth again



  • or not... beta 12 looks a bit better but still has the problem - having run the whole file it looks like random lines of g code are being skipped. absolute position is still good . even after 178700 lines of code it returned home correctly

    the biggest sign that it is skipping gcode is it occasionally moves between holes without executing the retract to Z+8. running the job twice the moves that are skipped do not repeat


  • administrators

    Bear in mind that in CNC mode, the firmware attempts to execute G0 moves at the maximum feedrates permitted, as configured using M203. Also that when drawing circles expressed as G0 moves, the actual maximum possible may be limited by the maximum XY jerk speeds configured using M566, because jerk is needed when transitioning from one segment of the approximated circle to the next.



  • looks like its a DWC problem - running direct from SD on DUET3 and panel due the motion is flawless


  • administrators

    @daavery said in unstable movement in X/Y with latest beta:

    looks like its a DWC problem - running direct from SD on DUET3 and panel due the motion is flawless

    As you are using Duet 3, have you tried this using RRF 3.0RC1 and Duet Software Framework 1.2.1.0?



  • @dc42 the gcode looks fine - posted from fusion360 via reprapfw post

    slot caused by skipped g0z8

    slot again



  • @dc42 yep that's where i started - then reverted to b12 - then disconnected the pi ribbon cable and connected a paneldue and made up an SD card to run on. that combo is working flawlessly


  • administrators

    @daavery said in unstable movement in X/Y with latest beta:

    @dc42 yep that's where i started - then reverted to b12 - then disconnected the pi ribbon cable and connected a paneldue and made up an SD card to run on. that combo is working flawlessly

    Thanks, I'll alert @chrishamm to this as it looks like the issue may be in DSF.



  • @dc42 waiting on 55min job to finish a test pass then i will do a full panel with router on



  • @dc42 any debugging info I can get for you guys?



  • 1 panel - 450 bored holes - 55 min - no glitches - looks like i'm running without the pi for now



  • more detail - ran TEST.gcode 2 times from DWC - capturing M111 P3 S1 via duet3 micro usb port

    there are obvious differences - random gcode lines are out of order

    compare report



  • duet config

    Board: Duet 3 MB6HC (MB6HC)
    DSF Version: 1.2.1.0
    Firmware: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 3.0beta12 (2019-11-02b1)

    pi config

    Start-Date: 2019-12-26 09:07:20
    Commandline: apt-get upgrade
    Upgrade:
    duettools:armhf (1.1.0.5, 1.2.1.0),
    reprapfirmware:armhf (1.1.0.5-1, 1.2.1.0-1),
    duetwebserver:armhf (1.1.2.1, 1.2.1.0),
    duetcontrolserver:armhf (1.1.0.5, 1.2.1.0),
    duetruntime:armhf (1.1.0.5, 1.2.1.0),
    duetsoftwareframework:armhf (1.1.0.5, 1.2.1.0),
    duetsd:armhf (1.0.4, 1.0.5)
    End-Date: 2019-12-26 09:08:06



  • @dc42 @chrishamm did you see the compare i did - doing a M111 P3 S1 and logging the duet3 usb port while running TEST.gcode ( see above) I see random lines of gcode being swapped in order. the 2 runs in the compare were done by just restarting the running job

    i'm somewhat suprised others are not seeing the same issue.


  • administrators

    There was an issue in DSF > 1.1.0.5 and < 1.2.2.0 that could sometimes cause out-of-order execution of G-codes from a file print - sorry for that. It's fixed in DSF 1.2.2.0.



  • @chrishamm Tested here - looks good - thanks


Log in to reply