unstable movement in X/Y with latest beta

daavery

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

daavery

video of Y0 motor running test.gcode
y0 motor video

daavery

reverting to beta 12, movement is smooth again

daavery

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

dc42

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.

daavery

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

dc42

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

daavery

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

slot caused by skipped g0z8

slot again

daavery

@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

dc42

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

daavery

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

daavery

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

daavery

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

daavery

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

daavery

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

daavery

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

chrishamm

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.

daavery

@chrishamm Tested here - looks good - thanks