Topics created by timschneider

@timschneider
maybe its just extruder skipping. I downgraded the unit to 3.5.4 and reprint the file - same clong sound in z=3.8 and PA and IS enabled. strange at that slow flow rate ... and without beeing noticed by the filament monitor ?!

e145cb40-69d6-4f90-bf7f-3c0a50598d3f-grafik.png

flowrate is just about 3-4 mm³/s, while the rest of the print is upto 20 mm³/s and there is no such clong sound.
306cf7fc-1b72-489c-83c3-c38fca135bd2-grafik.png

Moved the extruder reversing to a seperate thread!

https://forum.duet3d.com/topic/37655/3-6-0-rc-1-unexpected-extruder-reversing

@chrishamm

i made a video showing the suspect back emf generator - and maybe the cause of the esd events which may cause the mcu to reset.

You see that the printer is moving normal until 0:28 the first loud clong, and at 0:29/0:30 the second.
PA and IS are active.

Ill reprint this file with PA and IS disabled to check if the clong is caused by one of them.

2025-03-07-16-56-27-499(2).mp4

/Edit:
Ok, today I was listening for that sound, and I can also hear it on the Duet2 printer. It sounds like there is a move without acceleration.

/edit 2: checked it with PA and IS disabled - the movement stays the same, the extruder is reversing but there is not a single E- in the whole file. The printer uses firmware retraction, but the reversing is mid move - so not while retracting.

attached is the gcode file.
T013_ACM_Angle v1_L0.3mm_N0.8_NYLON_MBL480_2h12m.gcode
The clong sond is predominand at Z=3.8 the internal bridge infill layer.

@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.

@yoshimitsuspeed said in [feature] Adaptive / Feedforward Temperature setpoint:

As I suspected I think the biggest evolution from here would be to use a nominal temp and printing speed in the middle somewhere and then run hotter for faster, cooler for slower.

first find a S value that fits your setup!

you can already archive this by tuning the algorithm with the lowest possible temperature for the filament T_nom at nominal speed, e.g. F30 ( the speed you use to calibrate the e-steps). Now go to the upper end, set the hotend temp to the highest possible temperature T_max you want to extrude the filament. Now determine the maximal througput for T_max at speed F_max (use the determind maximum flow rate as flow limit in the slicer). Set the temp in the slicer to T_nom. Determine the T parameter for the temp increase from T_nom to T_max with F_nom to F_max - thats it.

An Example for PETG
T_nom: 190 °C
F_nom: 30 mm/min -> 0.5mm/s
T_max: 275 °C
F_max: 960 mm/min (40mm³ for 1.75mm FIlament) -> 16mm/s

T = (T_max - T_nom) /(F_max-F_nom) = 85°C / 15.5 mm/s = 5.48 °C / mm/s

e.g. for 24 mm³/s (1.75mm filament) it will correspond to around 245°C which is like common sense for petg.
Bare in mind that you need to tune Non Linear Extrusion after appling heater feed forward! I disable NLE for heater feedforward tuning, and tune NLE after that.

for calibration, you always have to move one non extruder axis with the extruder axis e.g.
G1 E100 F30 for e-step calibration (do not apply NLE / or feed forward)
G90 G1 X0 F2000 G91 G1 E100 X100 F960 for flowrate at F_max (apply feed forward)

the lookahead from dc42 will take care of the average and will keep the temp high for normal crusing speeds 🙂

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.