Duet 3 stops in the middle of a print, thinks its finished

cack

Hey!

I'm sorry if I'm writing in the wrong category, I'm new here.

So I have set my new Duet 3 to run a big 2 meter by 1,5 meters printer. The purpose of the printer is to print on flat materials so the z-axis is only about 90 millimeters.

Im currently using the printer to paint on acoustic panels. I have set up a stepper to press the valve on a spray can as extruder. Z axis is disabled in this scenario.

Sometimes the whole print prints fine, but a few times in the past and today especially the printer just halts in the middle of the print. It thinks it's finished, at least it says 100% on the progress bar. I have finished this file before with no problems.

The file that im running is a custom file that we compiled in python. It moves to a coordinate and then uses extruder, moves to another etc. To my knowledge there shouldnt be any problems in the file. The file has been attached to the message.

After this happens and i try to run a modified file where i skip the already printed bits, duet gives a M32 error claiming it cannot parse major gcode numbers. And after this when I try to run any files duet says its already printing while it is not.

Before I can print anythin i need to reset the duet and upload the file again, modified. It wont run if I dont upload it again.

Is this a known problem? Could there be problems in my file?

I ran an M122 before reseting the board.

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.01-RC3 running on Duet 3 MB6HC v0.6 or 1.0
Board ID: 08DJM-956L2-G43S4-6J1FG-3SJ6S-KB6LH
Used output buffers: 1 of 40 (7 max)
=== RTOS ===
Static ram: 153948
Dynamic ram: 158816 of which 36 recycled
Exception stack ram used: 512
Never used ram: 79904
Tasks: ETHERNET(blocked,844) NETWORK(ready,1972) HEAT(blocked,1200) CanReceiv(suspended,3820) CanSender(suspended,1436) CanClock(blocked,1436) TMC(blocked,76) MAIN(running,5372) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 01:03:15 ago, cause: software
Last software reset at 2020-03-03 23:31, reason: User, spinning module LinuxInterface, available RAM 80008 bytes (slot 0)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 33.8, current 34.9, max 35.2
Supply voltage: min 12.3, current 12.5, max 12.6, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 11.4, current 11.6, max 11.7, under voltage events: 0
Driver 0: standstill, reads 26976, writes 11 timeouts 0, SG min/max 0/0
Driver 1: standstill, reads 26932, writes 55 timeouts 0, SG min/max 0/385
Driver 2: standstill, reads 26960, writes 28 timeouts 0, SG min/max 0/1023
Driver 3: standstill, reads 26925, writes 63 timeouts 0, SG min/max 0/647
Driver 4: standstill, reads 26925, writes 63 timeouts 0, SG min/max 0/630
Driver 5: standstill, reads 26930, writes 59 timeouts 0, SG min/max 0/552
Date/time: 2020-03-04 00:34:59
Slowest loop: 3.12ms; fastest: 0.14ms
=== Move ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 371, MaxWait: 1138591ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 7, 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 = -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
http* is idle in state(s) 0
telnet is idle in state(s) 0
file* is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
trigger* is ready with "M122" in state(s) 0
queue is idle in state(s) 0
lcd is idle in state(s) 0
spi is idle in state(s) 0
daemon is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 1.10ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 0 of 8

Ethernet -
State: 2
Error counts: 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages sent 15196, longest wait 0ms for type 0
=== Linux interface ===
State: 0, failed transfers: 71
Last transfer: 19ms ago
RX/TX seq numbers: 20385/57538
SPI underruns 211, overruns 201
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v1.1.0.5
Code buffer space: 4096
Configured SPI speed: 2000000 Hz
Full transfers per second: 32.43

Thanks for your help and sorry for the inconvenience.
prime_numbers_2.gcode

cack

Hmm, could it be that empty lines are not good in gcode? It would seem that the parsing problem was solved by removing them.

Shouldnt be the cause for the stalling tho.

dc42

The version of DSF you are running is somewhat older than the version of RRF, so I suspect an incompatibility between them. I suggest you upgrade DSF to the latest unstable version which AFAIR is 1.2.4. Alternatively, wait for RRF 3.01-RC4 and DSF 1.2.5 which we hope to release tomorrow.

@dc42 said in Duet 3 stops in the middle of a print, thinks its finished:

I suggest you upgrade DSF to the latest unstable version which AFAIR is 1.2.4. Alternatively, wait for RRF 3.01-RC4 and DSF 1.2.5 which we hope to release tomorrow.

just checked the current DuetPi-lite.zip it tracks the stable repo, will the RC4 be pushed to the stable repo or does OP need to add the unstable repo in any case?

echo "deb https://pkg.duet3d.com/ unstable armv7" | sudo tee /etc/apt/sources.list.d/duet3d-unstable.list

dc42

3.01-RC4 has now been pushed to the unstable feed.

Tinchus

This post is deleted!