Build Not Starting - Diagnostics Automatically Dumps to Console?
-
Trying to start a build and this dumps to the console. Any hints? Can run other builds, this one just throws a wobbly!
09:38:17
M32 0056_em122_sp30.gcode
=== Diagnostics ===
Used output buffers: 2 of 32 (20 max)
=== Platform ===
RepRapFirmware for Duet version 1.19.2 running on Duet 0.6
Static ram used: 46844
Dynamic ram used: 39908
Recycled dynamic ram: 3360
Stack ram used: 1088 current, 6736 maximum
Never used ram: 1456
Last reset 00:19:42 ago, cause: power up
Last software reset reason: User, spinning module GCodes, available RAM 3248 bytes (slot 2)
Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00000000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 21.0MBytes/sec
SD card longest block write time: 101.8ms
MCU temperature: min 61.7, current 64.8, max 65.6
Date/time: 2018-01-19 09:38:16
Slowest main loop (seconds): 0.232910; fastest: 0.000000
=== Move ===
MaxReps: 4, StepErrors: 0, FreeDm: 100, MinFreeDm 54, MaxWait: 50942ms, Underruns: 1, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: mesh
Bed probe heights: 0.007 -0.093 0.027 -0.095 0.000
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.6
=== GCodes ===
Segments left: 0
Stack records: 2 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
Code queue is empty.
=== Network ===
Free connections: 15 of 16
Free transactions: 23 of 24
Locked: 1, state: 4, listening: 0x20071b40, 0x0, 0x0 -
Odd. Changed the file name and it ran!
Was called:
0056_em122_sp30.gcode
Changed file name to:
2.gcode
Oh dear… M122 is the diagnose function. Any chance you are parsing file names for gcode for some reason?
-
There was a bug like this fixed in 1.20. From the release notes it said -
- The code to detect M122 early also recognised commands of the form Mxxx122 where xxx were non-numeric
I wonder if upgrading to the 1.20 release would fix your issue.
-
It's on my list of to-dos to see what is the newest firmware that will go on the duet 0.6. Currently in the middle of some TPU trials so the work around is getting me by.
-
There was a bug like this fixed in 1.20. From the release notes it said -
- The code to detect M122 early also recognised commands of the form Mxxx122 where xxx were non-numeric
I wonder if upgrading to the 1.20 release would fix your issue.
Yes, the old code would have recognised the sequence "m122" anywhere in a command line (perhaps not in a comment).
-
Cheers for the clarification. Glad it's already sorted.
