unstable movement in X/Y with latest beta

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