Topics created by timschneider

@chrishamm

Ok - so it happend while I was using the filament-error to calibrate the E-Steps and non-linear extrusion. I set the error margin almost to zero +-0.5% and so there are a lot of events generated.

The following macro can trigger the bug
Content of 0:/macros/test-event-system.g

if !exists(global.ignoreMFMevents) global ignoreMFMevents = true else set global.ignoreMFMevents = true while iterations < 1000 M957 E"filament-error" D0 P4 S"tooLittleMovement - The movement is below the minimum set in the R value of M591"

Contnet of 0:/sys/filament-error.g

if exists(global.ignoreMFMevents) && global.ignoreMFMevents == true M99

Have at least one DWC session open.
Call the macro 0:/macros/test-event-system.g

Result in journalctl

Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [info] Starting macro file filament-error.g on channel Autopause Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [warn] M957: a similar event is already queued Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [info] Received file abort request on channel Autopause for the last file Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [info] Aborted macro file filament-error.g Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [info] Starting macro file filament-error.g on channel Autopause Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [warn] M957: a similar event is already queued Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [info] Received file abort request on channel Autopause for the last file Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [info] Aborted macro file filament-error.g Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [info] Starting macro file filament-error.g on channel Autopause Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [warn] Resending packet #1 (request GetObjectModel) Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [fatal] Abnormal program termination Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [fatal] Update task faulted Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: System.Text.Json.JsonReaderException: The input does not contain any JSON tokens. Expected the input to start with a valid JSON token, when isFinalBlock is true. LineNumber: 0 | BytePositionInLine: 0. Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: at System.Text.Json.ThrowHelper.ThrowJsonReaderException(Utf8JsonReader& json, ExceptionResource resource, Byte nextByte, ReadOnlySpan`1 bytes) Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: at System.Text.Json.Utf8JsonReader.Read() Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: at DuetControlServer.Model.Updater.UpdateModel(Int32 offset, Boolean last) in /home/runner/work/DuetSoftwareFramework/DuetSoftwareFramework/src/DuetControlServer/Model/Updater.cs:line 150 Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: at DuetControlServer.Model.Updater.Run() in /home/runner/work/DuetSoftwareFramework/DuetSoftwareFramework/src/DuetControlServer/Model/Updater.cs:line 296 Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [warn] Resending packet #0 (request GetObjectModel) Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [warn] M957: a similar event is already queued Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [warn] Failed to find query for object model response Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [info] Received file abort request on channel Autopause for the last file Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [info] Aborted macro file filament-error.g Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [warn] HTTP: Aborting orphaned macro file 0:/macros/test-event-system.g Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [info] Aborted macro file 0:/macros/test-event-system.g Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [warn] HTTP: ==> Cancelling unfinished starting code: M98 P"0:/macros/test-event-system.g" Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [warn] Daemon: Aborting orphaned macro file daemon.g Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [info] Aborted macro file daemon.g Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [info] Event logging stopped Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [fatal] Update task faulted Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: System.Text.Json.JsonReaderException: The input does not contain any JSON tokens. Expected the input to start with a valid JSON token, when isFinalBlock is true. LineNumber: 0 | BytePositionInLine: 0. Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: at System.Text.Json.ThrowHelper.ThrowJsonReaderException(Utf8JsonReader& json, ExceptionResource resource, Byte nextByte, ReadOnlySpan`1 bytes) Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: at System.Text.Json.Utf8JsonReader.Read() Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: at DuetControlServer.Model.Updater.UpdateModel(Int32 offset, Boolean last) in /home/runner/work/DuetSoftwareFramework/DuetSoftwareFramework/src/DuetControlServer/Model/Updater.cs:line 150 Feb 20 09:33:57 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: at DuetControlServer.Model.Updater.Run() in /home/runner/work/DuetSoftwareFramework/DuetSoftwareFramework/src/DuetControlServer/Model/Updater.cs:line 296 Feb 20 09:33:58 Meltingplot-MBL-480-vaswsq DuetControlServer[405]: [info] Application has shut down Feb 20 09:33:58 Meltingplot-MBL-480-vaswsq systemd[1]: duetcontrolserver.service: Main process exited, code=exited, status=70/SOFTWARE -- Subject: Unit process exited

EDIT: at the second attempt I was not able to reproduce it! Maybe it is related to [warn] Resending packet #1 (request GetObjectModel) as in the first try I saw many of these warnings and after a reboot, these warmings are gone and I can't reproduce the update thread bug.

@T3P3Tony @chrishamm @dc42
Hi Tony,
I think the bug is gone, to be honest.
I even deleted the overflow check as Chris suggested, and with the latest changes from Chris (OutputBuffer) and David (Stack of Main Task / M122) the bug is gone. I can construct a case where there is an SPI timeout – but that is far beyond normal use and a corner case. I tested it with this Git tag: https://github.com/Duet3D/RepRapFirmware/commit/4974c4cf3a4d1f1cd1fb1c28599e44ee2c412caa

I think the bug was related to the bug in OutputBuffer and filled the stack over time, causing the SPI timeout error from the RRF side – not WIFI. Now that the behaviour has been improved, I can no longer realistically reproduce the bug.

Although a M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 M122 can still sometimes trigger the timeout. If in doubt, do it twice and the printer is gone, but as I said this is unrealistic.

0 dc42 committed to Duet3D/RepRapFirmware Increased main task stack size

@timschneider I've logged this here: https://github.com/Duet3D/RepRapFirmware/issues/1074 But since you need to poll rr_reply for certain codes anyway, that solution probably isn't really applicable as a fix for your other problem.

chrishamm created this issue in Duet3D/RepRapFirmware open [FeatureRequest]: Add option to rr_connect request to prevent G-code replies from queuing up #1074

@timschneider yes please

I came up with the following solution:

content of driver-warning.g

; driver-warning.g ; driver warning - 51.0 : 1024 ,Driver 51.0 warning: position tolerance exceeded if param.B > 0 && param.D == 0 && param.P == 1024 && move.axes[0].homed == false && move.axes[1].homed == false M99 ; ignore warning when drives are not homed echo "driver warning - "^{param.B}^"."^{param.D}^" : "^{param.P}^" ,"^{param.S} if state.status == "paused" || state.status == "pausing" || state.status == "resuming" M99 ; ignore this event - it is already handled if !exists(global.event_driver_stall) global event_driver_stall = true ; check if a printjob is running ; if it is a can connected driver in closed loop mode with error position tolerance exceeded (param.B > 0 && param.D == 0 && param.P == 1024) if job.file.fileName != null if param.B > 0 && param.D == 0 && param.P == 1024 set global.event_driver_stall = true M25 ; pause print and rehome X and Y M207 Z{tools[0].retraction.zHop+0.2} ; raise z-hop 0.2mm to prevent further crashes set global.resume_deferred = state.upTime + 5 ; resume print after 5 seconds else set global.event_driver_stall = false ; do not rehome while pausing G91 ; relative positioning G1 H2 Z0.5 F600 ; lift Z relative to current position M568 P0 R0 S0 A0 ; disable hotend M25 ; pause print

content of driver-error.g

; driver-error.g ; called to home x and y after stall detection ; driver error - 51.0 : 3072 ,Driver 51.0 error: failed to maintain position if param.B > 0 && param.D == 0 && param.P == 3072 && move.axes[0].homed == false && move.axes[1].homed == false M99 ; ignore warning when drives are not homed echo "driver error - "^{param.B}^"."^{param.D}^" : "^{param.P}^" ,"^{param.S} if !exists(global.event_driver_stall) global event_driver_stall = true if state.status == "paused" || state.status == "pausing" || state.status == "resuming" set global.resume_deferred = 0 ; reset resume_deferred M99 ; ignore this event - it is already handled ; check if a printjob is running ; if it is a can connected driver in closed loop mode with failed to maintain position (param.B > 0 && param.D == 0 && param.P == 3072) if job.file.fileName != null if param.B > 0 && param.D == 0 && param.P == 3072 set global.event_driver_stall = true M207 Z{tools[0].retraction.zHop+0.2} ; raise z-hop 0.2mm to prevent further crashes else set global.event_driver_stall = false ; do not rehome while pausing G91 ; relative positioning G1 H2 Z0.5 F600 ; lift Z relative to current position M568 P0 R0 S0 A0 ; disable hotend M25 ; pause print

content of daemon.g

if exists(global.resume_deferred) && global.resume_deferred > 0 && global.resume_deferred < state.upTime if state.status == "paused" set global.resume_deferred = 0 M24 ; resume print

The magic is done by the global.resume_deferred. It is set to state.upTime + 5 which means 5 second delay.
The flow looks like the following

driver-warning event -> check if it is already paused if so, exit else set resume_deferred driver-error event -> check if it is already paused, if so, reset resume_deferred to 0 to disable it and exit daemon.g -> Check whether the delay for resume_deferred has already passed, if so resume the print.

@timschneider In case you are interested, this video offers insight to flow modulated temperature control:

Variable Temperature 3D Printing – The FUTURE of 3D Printing?

Thank you, this looks promising

@chrishamm ok, thanks! I've updated the printer to dev +8 and it is indeed fixed!

@chrishamm
Thanks for the great patch! Your work is outstanding! It's impressive to see the passion and dedication you and the duet3d team put into the software and hardware!

Now that all the show-stoppers are out of the way, we are going to switch completely to duet3 in the sbc setup. Starting with 4 closed loop steppers with 4 1HCL and 4 open loop steppers directly on the 6HC. Also two filament monitors and two IR probes per machine. This will be followed at a later stage by two tool boards and a distribution board per machine. I am excited to see the results.

@timschneider thanks. Please file an issue at https://github.com/Duet3D/RepRapFirmware/issues.

I think a related issue is that there will be a problem if the current machine Z height plus the Z hop amount exceeds the Z maximum defined in M208. You could mention this in your issue report too.

@timschneider Thanks, I've just pushed a bug fix for this. The only way I can see how it occurred was that an expression in a code parameter was being evaluated while M122 attempted to output it.

@timschneider We should no longer be subject to such a strict rate limit.

@timschneider thanks for this!

@timschneider I tried a RockPi SBC a while ago and never managed to get it working even though it appears to work for others, so I won't make a general recommendation about what SBC to use or not. The SBC type we've always recommended is the RaspPi (especially because it does not require custom wiring) but AFAIR nVidia Tegra SBCs have been reported to work just as well.

@chrishamm I can confirm, that I'm unable to reproduce the above error - so it should be fixed 🙂

@timschneider said in [Feature or Bug] Behaviour of M204:

@dc42
Thank you for adding the same checks as in M201 to M204 and the fast response!

btw. would you prefer to get forum posts/bug reports or PRs for these small things?

If the fix is simple and obvious (e.g. a typo in a text string) then a PR is fine. If it's not completely clear what the fix should be or there are multiple ways of achieving it, then I would prefer a forum post.

@timschneider Thanks for reporting this, it should be fixed now.

@chrishamm
I'll check the raspberry vs rockpi hint. And maybe you are right, my crashes are not related to the SPI bus - I'll check that.