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 -
@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 mappinghttps://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 visibleM669 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 centtest 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
-
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.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
looks like its a DWC problem - running direct from SD on DUET3 and panel due the motion is flawless
-
@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?
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
-
@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
-
@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
-
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.
-
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
