Duet 3 + SBC cant handle files above 60mb
-
Hi all,
having an issue with my Duet 3 witch connected SBC. when ever i upload a gcode file larger then around 60mb DWC will display the file as loading and it will lock up and not respond to any gcode commands. rebooting will reset it but file will still show loading.
here is m112 and m39
code_text m39 SD card in slot 0: capacity 31.00Gb, free space 26.00Gb, speed MBytes/sec m122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.01-RC4 running on Duet 3 MB6HC v0.6 or 1.0 Board ID: 08DJM-956L2-G43S8-6JKD2-3SS6M-1A16H Used output buffers: 1 of 40 (6 max) === RTOS === Static ram: 154084 Dynamic ram: 161232 of which 44 recycled Exception stack ram used: 520 Never used ram: 77336 Tasks: NETWORK(ready,2076) HEAT(blocked,1196) CanReceiv(suspended,3820) CanSender(suspended,1436) CanClock(blocked,1436) TMC(blocked,80) MAIN(running,2620) IDLE(ready,80) Owned mutexes: === Platform === Last reset 00:08:10 ago, cause: power up Last software reset at 2020-03-29 05:18, reason: User, spinning module LinuxInterface, available RAM 76880 bytes (slot 3) Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441c000 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 28.9, current 31.0, max 31.2 Supply voltage: min 0.1, current 27.0, max 27.0, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 0.1, current 12.1, max 12.2, under voltage events: 0 Driver 0: ok, reads 13241, writes 18 timeouts 0, SG min/max 0/1023 Driver 1: standstill, reads 13242, writes 18 timeouts 0, SG min/max 0/1023 Driver 2: standstill, reads 13242, writes 18 timeouts 0, SG min/max 0/1023 Driver 3: standstill, reads 13242, writes 18 timeouts 0, SG min/max 0/1023 Driver 4: ok, reads 13247, writes 14 timeouts 0, SG min/max 0/213 Driver 5: standstill, reads 13243, writes 18 timeouts 0, SG min/max 0/1023 Date/time: 2020-03-29 05:37:07 Slowest loop: 3.32ms; fastest: 0.13ms === Move === Hiccups: 0(0), FreeDm: 372, MinFreeDm: 350, MaxWait: 48980ms Bed compensation in use: mesh, comp offset 0.167 === MainDDARing === Scheduled moves: 1153, completed moves: 1149, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: 3 === 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.0 Heater 1 is on, I-accum = 0.2 === GCodes === Segments left: 1 Movement lock held by null HTTP* is ready with "M122" in state(s) 0 Telnet is idle in state(s) 0 File* is doing "G1 X179.604004 Y167.274002 E129.318695" in state(s) 0 USB is idle in state(s) 0 Aux is assembling a command 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 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 1.92ms; 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: disabled Error counts: 0 0 0 0 0 Socket states: 0 0 0 0 0 0 0 0 === CAN === Messages sent 1882, longest wait 0ms for type 0 === Linux interface === State: 0, failed transfers: 0 Last transfer: 16ms ago RX/TX seq numbers: 13877/13878 SPI underruns 0, overruns 0 Number of disconnects: 0 Buffer RX/TX: 2728/20-4092 === Duet Control Server === Duet Control Server v1.2.5.0 File: Buffered code: G1 X179.604 Y167.274 E129.3187 Buffered code: G1 X179.715 Y167.216 E129.3216 Buffered code: G1 X231.002 Y218.503 E131.0101 Buffered code: G1 X231.088 Y218.390 E131.0134 Buffered code: G1 X231.213 Y218.180 E131.0191 Buffered code: G1 X231.251 Y218.098 E131.0212 Buffered code: G1 X180.159 Y167.006 E132.7033 Buffered code: G1 X180.191 Y166.992 E132.7041 Buffered code: G1 X180.507 Y166.876 E132.7119 Buffered code: G1 X180.641 Y166.835 E132.7152 Buffered code: G1 X231.429 Y217.623 E134.3873 Buffered code: G1 X231.498 Y217.353 E134.3938 Buffered code: G1 X231.547 Y217.088 E134.4001 Buffered code: G1 X181.162 Y166.703 E136.0589 Buffered code: G1 X181.556 Y166.613 E136.0683 Buffered code: G1 X181.702 Y166.590 E136.0717 Buffered code: G1 X231.611 Y216.499 E137.7149 Buffered code: G1 X231.634 Y216.266 E137.7203 Buffered code: G1 X231.646 Y215.880 E137.7293 Buffered code: G1 X182.284 Y166.518 E139.3544 Buffered code: G1 X182.692 Y166.475 E139.3640 Buffered code: G1 X182.881 Y166.462 E139.3684 Buffered code: G1 X231.658 Y215.239 E140.9742 Buffered code: G1 X231.653 Y214.580 E140.9896 Buffered code: G1 X183.506 Y166.434 E142.5747 Buffered code: G1 X184.138 Y166.412 E142.5894 Buffered code: G1 X231.648 Y213.922 E144.1535 Buffered code: G1 X231.643 Y213.263 E144.1689 Buffered code: G1 X184.771 Y166.391 E145.7120 Buffered code: G1 X185.403 Y166.370 E145.7267 Buffered code: G1 X231.649 Y212.617 E147.2493 Buffered code: G1 X231.654 Y212.436 E147.2535 ==> 1408 bytes Code buffer space: 2708 Configured SPI speed: 2000000 Hz Full transfers per second: 17.13 File /opt/dsf/sd/gcodes/1.gcode is selected, printinghere is my config
config.gi have tried printing 60mb+ gcodes from a USB drive plugged into pi but that has the same problem.
Cheers, Aaron
-
Interesting; there is no immediately obvious limit at 60MB, could you post a sample file?* (I'm thinking number of lines or length of individual lines might more likely than the size of the file).
if you're not on the latest version (currently
duetsoftwareframework/unstable,now 1.2.5.0 armhf [installed]) enable the unstbale package repository and updatepi@raspberrypi:~ $ apt list duetsoftwareframework Listing... Done duetsoftwareframework/stable,now 1.2.4.0 armhf [installed] pi@raspberrypi:~ $ echo "deb https://pkg.duet3d.com/ unstable armv7" | sudo tee /etc/apt/sources.list.d/duet3d-unstable.list deb https://pkg.duet3d.com/ unstable armv7 pi@raspberrypi:~ $ sudo apt update && sudo apt upgrade Get:1 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB] ... Setting up duetsoftwareframework (1.2.5.0) ... pi@raspberrypi:~ $ apt list duetsoftwareframework Listing... Done duetsoftwareframework/unstable,now 1.2.5.0 armhf [installed]Also the log and versions from duetwebcontrol and duetcontrolserver could be of interest
version:apt list 2>/dev/null | grep duet | awk -F'[/ ]' '{print $1" "$3 }'short logs:
service duetwebcontrol statusandservice duetcontrolserver statusor if nothing interesting there longer logs:
journalctl -u duetwebcontrolandjournalctl -u duetcontrolserver*) if you don't want to share the file try running these commands against it to get some statistics (longest line, and number of lines):
pi@raspberrypi:~ $ wc -l /opt/dsf/sd/gcodes/1.gcode 1249500 /opt/dsf/sd/gcodes/1.gcode pi@raspberrypi:~ $ wc -L /opt/dsf/sd/gcodes/1.gcode 198 /opt/dsf/sd/gcodes/1.gcode pi@raspberrypi:~ $ -
@bearer
Here is a gcode that will not load cup.gcodeYes i am currently on the latest unstable release
code_text Board: Duet 3 MB6HC v0.6 or 1.0 (MB6HC) DSF Version: 1.2.5.0 Firmware: RepRapFirmware for Duet 3 MB6HC 3.01-RC4 (2020-03-16b1)code_text pi@duet3:~ $ apt list 2>/dev/null | grep duet | awk -F'[/ ]' '{print $1" "$3 }' duetcontrolserver 1.2.5.0 duetruntime 1.2.5.0 duetsd 1.0.5 duetsoftwareframework 1.2.5.0 duettools 1.2.5.0 duetwebcontrol 2.0.7-1 duetwebserver 1.2.3.1code_text pi@duet3:~ $ service duetwebcontrol status Unit duetwebcontrol.service could not be found. pi@duet3:~ $ service duetcontrolserver status ● duetcontrolserver.service - Duet Control Server Loaded: loaded (/lib/systemd/system/duetcontrolserver.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2020-03-30 04:04:12 BST; 3h 35min ago Main PID: 319 (DuetControlServ) Tasks: 16 (limit: 2200) Memory: 51.3M CGroup: /system.slice/duetcontrolserver.service └─319 /opt/dsf/bin/DuetControlServer Mar 30 04:04:12 duet3 systemd[1]: Started Duet Control Server. Mar 30 04:04:15 duet3 DuetControlServer[319]: Duet Control Server v1.2.5.0 Mar 30 04:04:15 duet3 DuetControlServer[319]: Written by Christian Hammacher for Duet3D Mar 30 04:04:15 duet3 DuetControlServer[319]: Licensed under the terms of the GNU Public License Version 3 Mar 30 04:04:18 duet3 DuetControlServer[319]: [info] Settings loaded Mar 30 04:04:19 duet3 DuetControlServer[319]: [info] Environment initialized Mar 30 04:04:19 duet3 DuetControlServer[319]: [info] Connection to Duet established Mar 30 04:04:19 duet3 DuetControlServer[319]: [info] IPC socket created at /var/run/dsf/dcs.sock Mar 30 04:04:55 duet3 DuetControlServer[319]: [info] System time has been changed -
I think i just found the problem. upon viewing the gcode in notepad++ it apears right at the end of the file there is a line that has "nullnullnullnullnullnullnullnullnullnull" after deleting that line DWC loads the file.
Now what could be causing this? I'm using simplify3d
-
i'd start by look at something in the lines of post printing scripts maybe, not familiar with s3d
-
@Aztazticz said in Duet 3 + SBC cant handle files above 60mb:
I think i just found the problem. upon viewing the gcode in notepad++ it apears right at the end of the file there is a line that has "nullnullnullnullnullnullnullnullnullnull" after deleting that line DWC loads the file.
Now what could be causing this? I'm using simplify3d
I had that problem with S3D once a very long time ago. In my case, if I remember correctly, the probably went away after I upgraded to the next minor version. (4.0.0 to 4.0.1, I think.)
-
In fact, look here: https://forum.duet3d.com/topic/5572/it-s-out-reprapfirmware-2-0-and-1-21-1-released/81
...which leads to: https://forum.simplify3d.com/viewtopic.php?t=8459
-
@Aztazticz Thanks for providing this file - I could reproduce this problem and will fix in the upcoming DSF 1.3.0. This particular file has a really long block of invalid characters ('\0') at the end which slowed down the G-code parser.
