unstable movement in X/Y with latest beta

[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

[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