Duet 3/Rpi + toolboard on 3.2b3 - G29 fails

chrishamm

@oozeBot Thanks for the logs. I'm afraid I could not reproduce any of the out-of-order replies or stack underruns that I could discover in your log - please make sure the Duet 3 firmware is 3.2-b3+2-ch and NOT 3.2-b2+1 or older (check on Settings -> Machine).

The reason for your problem is probably a combination of these issues but I was unable to provoke them on my setup with the latest firmware.

oozeBot

@chrishamm crap - it appears I am on 3.2-beta2+1. I just ran sudo apt update / upgrade again but nothing new was installed. I also ran M997 from DWC to make sure I updated the firmware.

What am I missing? I'll try to upload it directly to DWC. I'm sorry to have wasted any of your time on my mistake..

oozeBot

After downloading the firmware from the following link and uploading it through DWC, it has now been properly updated. I don't know how that was missed or even installed as I was on 3.2b1 and upgraded to 3.2b3 (skipping 3.2b2) - none of the 3.2b2 resources should have been available to install..?

https://github.com/Duet3D/RepRapFirmware/releases/tag/3.2beta3

It is now properly homing. I am moving forward with a few more mesh bed leveling tested before calling this complete.

chrishamm

@chrishamm said in Duet 3/Rpi + toolboard on 3.2b3 - G29 fails:

@oozeBot I've updated my experimental Duet 3 MB6HC binary again because I found one more potential problem in it.

Please upload this file on the system page and confirm the update prompt.

oozeBot

@chrishamm Sorry - it is very early here and I haven't had any coffee.. I now recognize I've been manually updating RRF at your request.

I just updated the file directly at the link you've provided - it reverted to:

Board: Duet 3 MB6HC (MB6HC)
DSF Version: 3.2.0-beta3
Firmware: RepRapFirmware for Duet 3 MB6HC 3.2-beta2+1 (2020-10-02b1)

oozeBot

@chrishamm OK, I'm now properly caffeinated. I just tested everything again and can confirm the RRF firmware you've linked to is 3.2B2 - not 3.2b3. Any thoughts on this? Was the wrong file uploaded?

chrishamm

@oozeBot Sorry, I uploaded an old file - the build configs have changed recently. Please try to download the file again.

oozeBot

@chrishamm thanks. I'm now on RepRapFirmware for Duet 3 MB6HC 3.2-beta3+2-ch. I'll run through several tests and report back..

edit - homing Z is now functioning properly.. on to mesh bed leveling.

oozeBot

@chrishamm 400 probe mesh completed without issue! System is back to idle. Going to run through it once more and then print something, but overall, it appears the issue is resolved..

oozeBot

@chrishamm I have run through this several times now and feel I can safely report it has been corrected. Mesh Bed Leveling is now successfully completing and returning to an idle state. Thanks

oozeBot

@chrishamm @dc42 - I probably should start another thread for this, but will you please review the attached log to see if anything stands out? I have a job to test bed leveling that I've attempted to run five times now after completing the mesh. The log captured two of those attempts.. something is happening where it randomly loses position very rapidly during non-print moves. I don't know how better to explain it.

I can say with certainty that I've never seen this type behavior before 3.2b3.

Thanks

log6.txt

oozeBot

I just rolled back to 3.2B1 and ran the same job. It completed successfully the first time. With 3.2B3, it couldn't make it past the first layer before drastically losing it's position in X&Y.

@chrishamm - Please let me know how I can help test and identify this issue if it was not captured in the log I just provided.

chrishamm

@oozeBot Can you please explain what you mean by losing its position during non-printing moves? At first glance I couldn't spot anything significant in the logs but I'll have another look tomorrow.

In any case it would help to get a step-by-step instruction on how your problem can be reliably reproduced.

oozeBot

@chrishamm Here are three videos taken back to back after upgrading again to 3.2B3 and installing your latest RRF firmware (3.2-beta3+2-ch). This is the same gCode, which works just fine on 3.2B1, but failed all three times at different places - none making it past the first layer.

https://vimeo.com/478187300
https://vimeo.com/478187348
https://vimeo.com/478187395

oozeBot

I rolled back to 3.2B1 again to get this machine in operation. The first thing I did was run the same job that was failing on 3.2B3. It succeeded the first time. I recorded the first few layers, but don’t think it’s necessary to upload.. however, here is a photo of it after it completed.

oozeBot

@chrishamm is there any other testing or logs we can provide to assist with this issue?

chrishamm

@oozeBot I just updated that binary once again, please feel free to try it with DSF 3.2-b3. There is a good chance that it will fix the reported issue from @SAtech as well.

oozeBot

@chrishamm thanks. I'll be able to test this in about an hour and will report back afterwards..

oozeBot

@chrishamm This is looking promising! It's now 1/3 the way through the same routine that couldn't get past the 1st layer with the previous build.. It should be complete within the next 15 minutes or so. ~~I can report back afterwards.~~

edit - it just successfully completed. I think it's fixed..

oozeBot

Edit - unless something is obviously wrong in the M122, please dismiss for now. I've rerun this several times and have not been able to reproduce.

@chrishamm @dc42 - this just occurred (or something like it) on 3.2B4.1.

I received the following error:

Error: M280: Response timeout: CAN addr 20, req type 4012, RID=1163
289 points probed, min error -0.065, max error 0.470, mean 0.162, deviation 0.079

M122

=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2-beta4.1 running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode)
Board ID: 08DJM-956L2-G43S4-6J1DD-3SJ6S-TB62H
Used output buffers: 1 of 40 (40 max)
=== RTOS ===
Static ram: 123292
Dynamic ram: 138720 of which 148 recycled
Never used RAM 130032, free system stack 128 words
Tasks: Linux(ready,83) HEAT(blocked,297) CanReceiv(blocked,837) CanSender(blocked,344) CanClock(blocked,352) TMC(blocked,18) MAIN(running,669) IDLE(ready,19)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:43:58 ago, cause: software
Last software reset at 2020-12-09 08:22, reason: User, GCodes spinning, available RAM 130032, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0xffffffff Task Linu
Error status: 0x04
MCU temperature: min 29.2, current 40.4, max 40.5
Supply voltage: min 1.5, current 24.2, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 0.2, current 12.1, max 12.2, under voltage events: 1
Driver 0: position 30480, standstill, reads 51957, writes 38 timeouts 0, SG min/max 0/982
Driver 1: position 0, standstill, reads 51973, writes 22 timeouts 0, SG min/max 0/0
Driver 2: position 1030, standstill, reads 51958, writes 38 timeouts 0, SG min/max 0/1023
Driver 3: position 0, standstill, reads 51949, writes 48 timeouts 0, SG min/max 0/474
Driver 4: position 0, standstill, reads 51976, writes 22 timeouts 0, SG min/max 0/0
Driver 5: position 0, standstill, reads 51950, writes 48 timeouts 0, SG min/max 0/1023
Date/time: 2020-12-09 09:06:06
Slowest loop: 999.73ms; fastest: 0.08ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
FreeDm 375 (min 370), maxWait 446390ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 2007, completed moves 2007, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 5], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = 2 -1 -1 -1
Heater 0 is on, I-accum = 0.5
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue* is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== CAN ===
Messages queued 15276, send timeouts 44, received 37057, lost 0, longest wait 2ms for reply type 6031, free buffers 47
=== SBC interface ===
State: 0, failed transfers: 0
Last transfer: 18ms ago
RX/TX seq numbers: 34609/34610
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x209ac
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.2.0-beta4
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 38.07

M122 B20

Diagnostics for board 20:
Duet TOOL1LC firmware version 3.2-beta4.1 (2020-12-03)
Bootloader ID: SAMC21 bootloader version 2.1 (2020-11-03b2)
Never used RAM 4208, free system stack 72 words
HEAT 50 CanAsync 89 CanRecv 83 TMC 54 MAIN 216 AIN 64
Last reset 00:44:32 ago, cause: power up
Last software reset data not available
Driver 0: position 0, 830.0 steps/mm, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 12, reads 25496, writes 12, timeouts 0, DMA errors 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0
No step interrupt scheduled
VIN: 24.2V
MCU temperature: min 32.5C, current 56.5C, max 58.1C
Ticks since heat task active 237, ADC conversions started 2661831, completed 2661830, timed out 0
Last sensors broadcast 0x00000002 found 1 241 ticks ago, loop time 0
CAN messages queued 37596, send timeouts 0, received 28817, lost 0, free buffers 36