RRF 3.5.0-b3 sporadically stops extruding

Exerqtor

@gloomyandy
The issue is that the bugger comes and goes sporadically, it's not at one single point each time.

My first thought was that it was related to RRF changing accelerations based on the feature type of the job (maybe in conjunction with the new PA/IS system, despite those vallues are the same throughout the whole print). I'm letting RRF handle this by emitting the feature type from the sliced gcode via a global and daemon.g changing based on that.

But since it seems to come and go all whilly nilly without a clear pattern i'm not so sure, I've got the accel control off on layer 1, and it's been happening on the first layer a couple times.

Exerqtor

Ok, so i finally managed to get a diagnosis when it wasn't extruding:

M122 B121
Diagnostics for board 121:
Duet TOOL1LC rev 1.1 or later firmware version 3.5.0-beta.3 (2023-04-13 18:44:05)
Bootloader ID: SAMC21 bootloader version 2.4 (2021-12-10)
All averaging filters OK
Never used RAM 4984, free system stack 38 words
Tasks: Move(nWait,0.1%,93) HEAT(nWait,0.5%,57) CanAsync(nWait,0.0%,49) CanRecv(nWait,0.0%,74) CanClock(nWait,0.0%,67) ACCEL(nWait,0.0%,53) TMC(delaying,3.0%,57) MAIN(running,91.3%,344) IDLE(ready,0.0%,27) AIN(delaying,5.0%,142), total 100.0%
Last reset 11:54:22 ago, cause: software
Last software reset data not available
Driver 0: pos 0, 568.8 steps/mm,standstill, SG min 0, read errors 0, write errors 0, ifcnt 40, reads 8529, writes 0, timeouts 0, DMA errors 0, CC errors 0, steps req 0 done 0
Moves scheduled 536, completed 536, in progress 0, hiccups 0, step errors 0, maxPrep 690, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0
Peak sync jitter -2/6, peak Rx sync delay 195, resyncs 0/0, no timer interrupt scheduled
VIN voltage: min 24.1, current 24.3, max 24.4
MCU temperature: min 40.5C, current 61.8C, max 61.8C
Last sensors broadcast 0x00000012 found 2 234 ticks ago, 0 ordering errs, loop time 1
CAN messages queued 367, send timeouts 0, received 208, lost 0, free buffers 37, min 37, error reg 0
dup 0, oos 0/0/0/15, bm 0, wbm 0, rxMotionDelay 310, adv 36379/74640
Accelerometer: LIS3DH, status: 00
I2C bus errors 0, naks 0, other errors 0

I find this a part a little bit interesting Driver 0: pos 0, 568.8 steps/mm,standstill,? If i run a diagnosis while it's working as intended it's saying ok instead of standstill 🤔

This was on the first layer of the print, where i'm not doing any funny stuff. It's locked too 500mms/3 acceleration through that whole layer.

Don't know if it's worth anything, but this is the job file.

Exerqtor

Normal operation:

M122 b121
Diagnostics for board 121:
Duet TOOL1LC rev 1.1 or later firmware version 3.5.0-beta.3 (2023-04-13 18:44:05)
Bootloader ID: SAMC21 bootloader version 2.4 (2021-12-10)
All averaging filters OK
Never used RAM 3952, free system stack 38 words
Tasks: Move(nWait,0.5%,93) HEAT(nWait,0.5%,57) CanAsync(nWait,0.0%,49) CanRecv(nWait,0.1%,74) CanClock(nWait,0.0%,67) ACCEL(nWait,0.0%,53) TMC(nWait,3.1%,57) MAIN(running,90.7%,344) IDLE(ready,0.0%,27) AIN(delaying,5.1%,142), total 100.0%
Last reset 12:21:31 ago, cause: software
Last software reset data not available
Driver 0: pos 0, 568.8 steps/mm,ok, SG min 0, read errors 0, write errors 0, ifcnt 40, reads 60968, writes 0, timeouts 1, DMA errors 0, CC errors 0, failedOp 0x01, steps req 0 done 1069416
Moves scheduled 18746, completed 18741, in progress 1, hiccups 1305, step errors 0, maxPrep 1907, maxOverdue 14034, maxInc 3271, mcErrs 0, gcmErrs 0
Peak sync jitter -4/10, peak Rx sync delay 278, resyncs 0/0, no timer interrupt scheduled
VIN voltage: min 24.1, current 24.3, max 24.5
MCU temperature: min 40.5C, current 81.8C, max 81.8C
Last sensors broadcast 0x00000012 found 2 104 ticks ago, 0 ordering errs, loop time 1
CAN messages queued 32031, send timeouts 0, received 33141, lost 0, free buffers 37, min 36, error reg 0
dup 0, oos 0/0/0/2340, bm 0, wbm 0, rxMotionDelay 614, adv 35814/74649
Accelerometer: LIS3DH, status: 00
I2C bus errors 0, naks 0, other errors 0

Exerqtor

I've ran that job file three times now with PA on, and it stops extruding each time it starts the first layer infill.

I'm printing another one of the same job now, with PA disabled, and it's just finished with the first layer WITHOUT the extruder halting. So it looks like it's something going on with the PA,

jay_s_uk

@Exerqtor i can also replicate an issue with PA and IS enabled using 3.5b3. Best to disable PA if you can for now as it seems to print ok without it enabled

Exerqtor

@jay_s_uk said in RRF 3.5.0-b3 sporadically stops extruding:

@Exerqtor i can also replicate an issue with PA and IS enabled using 3.5b3. Best to disable PA if you can for now as it seems to print ok without it enabled

Glad to hear it's not an isolated issue on my end at least. Yup, keeping PA of for the time being, while looking out for other bugs 😅

EDIT:

I retract my statement about disabling PA and keep trying it out. Since it's another bug that causes the whole printer to reboot at random (seemingly) intervals without any reason. So i'm reverting to 3.5.0-b2 again.

RIP 3.5.0-b3, you won't be missed🙈.

gloomyandy

@Exerqtor This may be too late, but if you get a reboot can you run M122 after it restarts and post the output. The info in there will help a lot with trying to solve the issue. It is probably worth checking the M122 output now (from whatever version you are now running) as the data from the previous crash may still be present.

Exerqtor

@gloomyandy
Yeah it's way to late at this point, after the third reboot i reverted to b2. Don't look like it's a prevalent issue either since it's not being reported by anyone else.

gloomyandy

@Exerqtor It may not be too late, the reset data is stored in flash that may not be erased when you reinstall. Worth checking to see what M122 reports.

gloomyandy

@gloomyandy Also even though others may not be reporting the problem, it may give clues towards other issues, so definitely worth reporting if you possibly can.

Exerqtor

@gloomyandy I can pull a M122 from both the mobo and toolboard as soon as this print finishes.
If it's anything worth looking at or not i have no idea 🤷‍♂️

gloomyandy

@Exerqtor This (and the stack trace that follows it) is the part of interest....

Last software reset at 2023-04-15 10:26, reason: HardFault imprec, Gcodes spinning, available RAM 10968, slot 0

Exerqtor

@gloomyandy
This is from the Mini:

Last reset 02:45:09 ago, cause: software
Last software reset at 2023-04-23 10:32, reason: User, Gcodes spinning, available RAM 5696, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00446000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a

And the 1LC:

Last reset 02:46:46 ago, cause: software
Last software reset data not available

gloomyandy

@Exerqtor Unfortunately it looks like the reset data has been wiped by the older firmware. Oh well, thanks for taking the time to check. If you do decide to try 3.5.0-beta.3 again and you get a reset please grab the m122 output and post it.

Exerqtor

This issue has been solved as of RRF3.5b3+!

RogerPodacter

i was about to start a new topic. i recently upgrade to 3.5.0-Beta3 and now i have extruder issues. I use 2 toolboards 1LC on an IDEX machine. It appears that my extruder motor stops extruding during printing. it seems to happen right after a toolchange to select the new extruder. The toolchange does some fast extrude retraction.

Once this behavior happens i have to reboot the printer to restore back to normal behavior.

I am reverting back to firmware 3.4.2 for now. hopefully my issue is part of this fix in the Beta 4 next release.