G29 required after every power down or printer locks up 3.1.1
-
@luckyflyer I'd suggest not deleting heightmap.csv but renaming it to xyz.csv and then running G29. Logic is to remove faulty / corrupted SD card from the list of things to check.
Are you running
G29S1after you power on to load and turn on heightmap.csv? (from s3d startup it looks like you do) -
@arhi said in G29 required after every power down or printer locks up 3.1.1:
@luckyflyer I'd suggest not deleting heightmap.csv but renaming it to xyz.csv and then running G29. Logic is to remove faulty / corrupted SD card from the list of things to check.
Are you running
G29S1after you power on to load and turn on heightmap.csv? (from s3d startup it looks like you do)I have tried a G29 S1 from dwc after a power up and the result is the same as the G29 S1 from the start script. Only a complete G29 cycle will make the printer work correctly.
So by renaming the old height. csv and saving we can compare with the new, correct?
-
I'll do that but will be about an hour before I'm able to.
-
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.
-
@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.
-
.old.csv is after powerup=no print
.csv=print ok
heightmap.old.csv -
@Phaedrux
All pi and Duet files were updated within the last couple of days withsudo apt-get update sudo apt-get upgrade sudo rebootM122
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
-
Short video, change .txt to .mpg
DuetLapse0602202057.txt -
@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 -
@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.
-
@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.
-
@luckyflyer when you run G29 mesh probing, are any of the probe points skipped due to them being unreachable by the probe?
-
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.
-
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. -
@jay_s_uk I'll give that a try when I get back from my trip.
