G29 required after every power down or printer locks up 3.1.1

Phaedrux

I've flagged this for @dc42 and @chrishamm to take a look at.

Can you also ensure that your pi/DSF is fully updated? And also please provide the results of an M122.

arhi

@luckyflyer said in G29 required after every power down or printer locks up 3.1.1:

height. csv and saving we can compare with the new, correct?

Not only to compare but to see new one is properly created and to check if new one will be properly loaded with G29S1 after reboot.

Probing on my printer is very slow so I run G29 once every few weeks only and G29S1 loads on every print start and works ok for me. But I'm on duet2 and no SBC so this might be a duet3+sbc bug that I can' confirm. Anyhow doing this simple test of renaming the file does remove a huge chunk of possibilities so should be done.

luckyflyer

.old.csv is after powerup=no print
.csv=print ok
heightmap.old.csv

heightmap.csv

luckyflyer

@Phaedrux
All pi and Duet files were updated within the last couple of days with

sudo apt-get update
sudo apt-get upgrade
sudo reboot

M122

6/2/2020, 7:00:52 PM	M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode)
Board ID: 08DJM-956L2-G43S8-6JTDA-3SN6M-1V0LG
Used output buffers: 1 of 40 (17 max)
=== RTOS ===
Static ram: 154604
Dynamic ram: 162832 of which 60 recycled
Exception stack ram used: 544
Never used ram: 75176
Tasks: NETWORK(ready,1968) HEAT(blocked,1188) CanReceiv(suspended,3820) CanSender(suspended,1412) CanClock(blocked,1436) TMC(blocked,60) MAIN(running,4952) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:37:54 ago, cause: power up
Last software reset at 2020-06-02 11:43, reason: User, spinning module LinuxInterface, available RAM 75384 bytes (slot 1)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 44.2, current 50.8, max 51.0
Supply voltage: min 24.1, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0
Driver 0: standstill, reads 1302, writes 27 timeouts 0, SG min/max 0/207
Driver 1: standstill, reads 1302, writes 27 timeouts 0, SG min/max 0/206
Driver 2: standstill, reads 1303, writes 27 timeouts 0, SG min/max 0/986
Driver 3: standstill, reads 1316, writes 14 timeouts 0, SG min/max 0/0
Driver 4: standstill, reads 1320, writes 11 timeouts 0, SG min/max 0/0
Driver 5: standstill, reads 1320, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2020-06-02 19:00:51
Slowest loop: 5.47ms; fastest: 0.14ms
=== 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 ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 369, MaxWait: 190518ms
Bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 838, completed moves: 838, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is ready with "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.
=== Network ===
Slowest loop: 0.96ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 0 of 8
- Ethernet -
State: disabled
Error counts: 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages sent 9286, longest wait 0ms for type 0
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 18ms ago
RX/TX seq numbers: 7752/7753
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.1.1
Daemon:
Finishing macro daemon.g, started by system
> Next stack level
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 30.63

luckyflyer

Short video, change .txt to .mpg
DuetLapse0602202057.txt

luckyflyer

@Phaedrux
I will be leaving on 6 or 7 day vacation tomorrow so I apologize for my poor timing on this. I was going to upload a copy of my pi image but there is a 4096 kb cap on file uploads. So if you feel that an sd card image would be helpful for troubleshooting I can upload it if you temporarily raise the upload cap. Image is 32,000,000kb

dc42

@luckyflyer, I think the problem is caused by a bug in the processing of G29 S1 on Duet 3 with attached SBC. Does the problem go away if you remove the G29 S1 call from your start GCode?

There is an early build of RRF 3.2 with a fix for the G29 S1 issue at https://www.dropbox.com/s/2shcm7gc975q94p/Duet3Firmware_MB6HC.bin?dl=0.

luckyflyer

@dc42 said in G29 required after every power down or printer locks up 3.1.1:

@luckyflyer, I think the problem is caused by a bug in the processing of G29 S1 on Duet 3 with attached SBC. Does the problem go away if you remove the G29 S1 call from your start GCode?

There is an early build of RRF 3.2 with a fix for the G29 S1 issue at https://www.dropbox.com/s/2shcm7gc975q94p/Duet3Firmware_MB6HC.bin?dl=0.

The problem does indeed go away if the G29 S1 is removed from the start script.

I'll probably just wait until the first RC or so of 3.2 because as it is I usually leave the printer on for days at a time.

jay_s_uk

@luckyflyer when you run G29 mesh probing, are any of the probe points skipped due to them being unreachable by the probe?

luckyflyer

@jay_s_uk

Yes as it is the complete last row is skipped. I have a cast bed plate ordered, when it's installed I'll reduce the number of probe points.

jay_s_uk

The bug only comes in to play when probe points are skipped (when the heightmap is loaded, a junk value is being inserted rather than interpolated value, resulting in super slow movement which makes it seem as though a print as frozen).
In the short term, if you still want to use G29, make sure that the mesh to be probed is fully reachable and no points are skipped.

luckyflyer

@jay_s_uk I'll give that a try when I get back from my trip.