strange error en 3.5.1
-
@Tinchus Like you, I still have this problem. I thought this problem was fixed with 3.5.1 because yesterday, after updating from 3.5.0 I had no problem but today this error occurred again.
M122 output :
=== Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.5.1 (2024-04-19 14:30:55) running on Duet 3 MB6HC v1.01 (SBC mode) Board ID: 08DJM-956L2-G43S8-6JKD6-3SJ6M-KA06G Used output buffers: 1 of 40 (17 max) === RTOS === Static ram: 155208 Dynamic ram: 88272 of which 4960 recycled Never used RAM 93880, free system stack 117 words Tasks: SBC(2,ready,1.9%,422) HEAT(3,nWait 1,0.1%,321) Move(4,nWait 6,2.5%,218) CanReceiv(6,nWait 1,0.0%,940) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,334) TMC(4,nWait 6,21.2%,56) MAIN(2,running,74.3%,103) IDLE(0,ready,0.0%,30), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 02:53:43 ago, cause: power up Last software reset at 2024-06-04 19:34, reason: User, Platform spinning, available RAM 94168, slot 1 Software reset code 0x6000 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a Error status: 0x00 Aux1 errors 0,0,0 MCU temperature: min 19.3, current 44.4, max 47.4 Supply voltage: min 23.5, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.1, current 12.2, max 12.3, under voltage events: 0 Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/32/32, gc cycles 0 Events: 0 queued, 0 completed Driver 0: standstill, SG min 0, mspos 808, reads 13888, writes 23 timeouts 0 Driver 1: standstill, SG min 0, mspos 568, reads 13888, writes 23 timeouts 0 Driver 2: standstill, SG min 0, mspos 392, reads 13888, writes 23 timeouts 0 Driver 3: standstill, SG min 0, mspos 392, reads 13888, writes 23 timeouts 0 Driver 4: standstill, SG min 0, mspos 392, reads 13888, writes 23 timeouts 0 Driver 5: standstill, SG min 0, mspos 952, reads 13882, writes 30 timeouts 0 Date/time: 2024-06-06 11:36:48 Slowest loop: 61.33ms; fastest: 0.06ms === Storage === Free file entries: 20 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 === DMs created 125, segments created 34, maxWait 523887ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 1.00 no step interrupt scheduled Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0 === DDARing 0 === Scheduled moves 78338, completed 78338, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 13], CDDA state -1 === DDARing 1 === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 Heater 0 is on, I-accum = 0.3 Heater 1 is on, I-accum = 0.4 === GCodes === Movement locks held by null, null HTTP* is doing "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 assembling a command in state(s) 0 Autopause is idle in state(s) 0 File2 is idle in state(s) 0 Queue2 is idle in state(s) 0 Q0 segments left 0, axes/extruders owned 0x80000003 Code queue 0 is empty Q1 segments left 0, axes/extruders owned 0x0000000 Code queue 1 is empty === CAN === Messages queued 93723, received 0, lost 0, errs 49566204, boc 0 Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 52118/0/0 Tx timeouts 0,0,52117,0,0,41604 last cancelled message type 4514 dest 127 === SBC interface === Transfer state: 5, failed transfers: 0, checksum errors: 0 RX/TX seq numbers: 17770/17770 SPI underruns 0, overruns 0 State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x253c0 Buffer RX/TX: 0/0-0, open files: 0 === Duet Control Server === Duet Control Server version 3.5.1 (2024-04-19 16:20:35, 32-bit) HTTP+Executed: > Executing M122 Code buffer space: 4096 Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0 Full transfers per second: 7.46, max time between full transfers: 107.3ms, max pin wait times: 65.0ms/10.2ms Codes per second: 1.59 Maximum length of RX/TX data transfers: 4432/1352
-
@Tinchus @Erinell It sounds like M226 is not releasing the axes from the motion system. The "Error: in GCode file line 0" is a little odd, too. Could you try adding M400 to the beginning of pause.g?
I've highlighted this to @dc42 for him to take a look at, as I think pause.g should release the axes, but maybe the way it is called in M226 is a bug.
Ian
-
Dont ask me why, but in my case I found this: I lauched THE SAME gcode again and the only difference I tried was commenting the power failure configuration on config.g:
; M911 S21.0 R23.5 P"M913 X0 Y0"
MY resurrect-prolog.g file has this:
M116 ; wait for temperatures
G91 ;
G1 E-1 F200;
G1 Z5 F80;
G28 X0 Y0;
G90;
M83 ; relative extrusion
G1 E2 F3600 ; undo the retraction that was done in the M911 power fail script
M25 ; pauseI know: a M226 should not triggered this file right? so it makes no sense to me why7 would affect or cause this behaviour. Thing is: I commented out the M911 command on config.g, rebooted printer, launched the same gcode again, pause was made as expected, I changed the filament and print was resumed without problems.
-
@Tinchus Any time you pause a print from SD card, the state of the print is saved to sys/resurrect.g. It shouldn't actually run any command in that line, but yes, it may be a reason for the error.
When it ran the M226 before you made this change, did the print actually pause, ie move off the print, before the print was cancelled? Or was it cancelled straight away?
Ian
-
@droftarts said in strange error en 3.5.1:
Could you try adding M400 to the beginning of pause.g?
Just tried this and nop, same issue.
The problem is apparently appening randomly to me, sometimes it works and sometimes it doesn't.
the steps are :- M226 triggered
- printer go to pause position
- (do a manual filament swap or something else)
- resume print
- the printer go back to print position
- the print stop with the error and heaters (bed and nozzle) turn off
-
@droftarts The first try with M226 did the pause correctly as expected: it paused and moved off the print as pause.g instructed. I changed the filament, did some manual extrusion to purge the old color from the nozzle, and when I press resume, it was then that the error poped out and the print was cancelled.
Before that, I did another try , this time I was using kisslicer, the M226 was also executed well, filament was changed, and then the print resumed well too, but the print failed because of another problem (the resume script that kisslicer uses had a mistake of my responsability).
It was on between these prints that I noticed than from the print with kisslicer and the print attemp with superslicer, the only difference (apart from the gcode generator, but the M226 was in the same layer so...) was me introducing the M911 command on config.g ans so I decided last night to remove that command and try again.
But in short: M226 seems to be excuted correctly, pause.g is executed, the error pops out when resuming the print.
-
-
@Tinchus please install RRF 3.5.2-rc.1 and confirm (or otherwise) whether the issue still exists.
-
@dc42 I truied, did the sudo apt steps but that version is not released?
-
@Tinchus it is now! please give it a go.
-
@T3P3Tony ok, updating now. Any particular border suation instructions you may wanna me to try?
-
@T3P3Tony I got this:
Incompatible software versions
The installed software versions do not match. Please operate your setup only at equal versions to avoid potential incompatibilities and unexpected errors.
Please check out the docs on how to upgrade your Duet software components.
-
@Tinchus how are you upgrading?
also refresh the browser then check what versions are installed for the various components on the system tab of DWC.
-
Is this issue confirmed fixed with the update? I'm on 3.5.1.
I did an M600, where I had my printhead move into position for a filament change on my filament-change.g
For filament-change.g I have an M291 to resume, followed by an M24.
I tested it on a small 7 layer test print to verify, and it worked flawlessly.
On a very large and expensive print, after filament change, on resume it returned to 5mm above the resume point, then dove the extruder deep into the print and then stopped. Time and expensive material wasted.
Also got the "Error in GCode file line XXXX" and "Axis X is already in use by a different motion system. "
Those errors were not present on the test print either.
-
@T3P3Tony Sorry forr delay in answering Tony, I as out of office. Update seems to have corrected the failure. Im not sure 100% because I have done only 3 attemps and were partial attemps, I have not tried to amke it fail. For now I guess it is solved, but I have noticed during these test another problem, I will create a separate post for this now (it is an unload problem)