Unknown error status code
grizewald last edited by
I just finished a successful print and was doing some testing. I've just created a new height map and was testing repeated bed levelling probes. I wanted to check if mesh compensation was in use, so I fired off an M122.
In the report, the error status is 24.
4 would appear to be "output buffer starvation", but I don't find 2 in the wiki.
There's a few other interesting things in the report, so I've pasted the whole report below:
=== Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 2.03 running on Duet WiFi 1.02 or later Board ID: 08DGM-917NK-F2MS4-7JTD0-3S86S-KYTND Used output buffers: 3 of 24 (14 max) === RTOS === Static ram: 25680 Dynamic ram: 93716 of which 344 recycled Exception stack ram used: 540 Never used ram: 10792 Tasks: NETWORK(ready,524) HEAT(blocked,1236) MAIN(running,1568) IDLE(ready,160) Owned mutexes: === Platform === Last reset 02:05:28 ago, cause: power up Last software reset at 2019-08-04 19:40, reason: User, spinning module GCodes, available RAM 10792 bytes (slot 1) Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d Error status: 24 Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 391.3ms, max retries 0 MCU temperature: min 21.2, current 38.1, max 40.0 Supply voltage: min 23.9, current 24.1, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: standstill, SG min/max 0/141 Driver 1: standstill, SG min/max 0/150 Driver 2: standstill, SG min/max 0/48 Driver 3: standstill, SG min/max 0/1023 Driver 4: standstill, SG min/max 0/55 Date/time: 2019-08-08 17:45:19 Cache data hit count 4294967295 Slowest loop: 113.63ms; fastest: 0.07ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Move === Hiccups: 6, FreeDm: 169, MinFreeDm: 105, MaxWait: 1041342ms Bed compensation in use: mesh, comp offset -0.069 === DDARing === Scheduled moves: 747, completed moves: 747, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 Heater 0 is on, I-accum = 0.2 Heater 1 is on, I-accum = 0.2 === GCodes === Segments left: 0 Stack records: 3 allocated, 0 in use 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 daemon is idle in state(s) 0 queue is idle in state(s) 0 autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 393.69ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0) HTTP sessions: 1 of 8 - WiFi - Network state is running WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.23 WiFi MAC address 84:f3:eb:42:a3:23 WiFi Vcc 3.45, reset reason Turned on by main processor WiFi flash size 4194304, free heap 25512 WiFi IP address 192.168.1.29 WiFi signal strength -47dBm, reconnections 0, sleep mode modem Socket states: 0 0 0 0 0 0 0 0
I'm assuming the errors come from my print. The parts look OK - they were three copies of an IN14 Nixie tube spacer printed at 0.1mm layer height. Print speed was 60mm/s with 100mm/s travel. The printer is a large CoreXY.
grizewald last edited by
After looking through the source code for the firmware, I don't find 0x20 in the ErrorCode enumeration either.
So why would errorCodeBits ever get that bit set? @dc42
Also, any ideas what would cause the output buffer starvation? The model being printed is tiny, but it does include lots of circles. Then again, I'm only printing it at 60mm/s and the circles don't have that many facets. I've attached the model for reference.