@Phaedrux Replacement board arrived today, straight forward swap out of the clone, once I jumped through the firmware v2 --> v3.0 --> v3.1.1 hoops, all working perfectly. Thanks for your assistance in resolving this.

@OwenD Just thought I'd offer my solution using M38 to check existence of the file and offer the user a chance to check the Hash??

M38 "0:/sys/PanelDueFirmware.bin"
if result == 0
    M291 R"PanelDue Upgrade" P"New firmware has been detected, hash has been output to the console. OK to update?" S3
    ; M997 etc...
elif result == 2
    echo "No PanelDue firmware detected"

Here's where I've got to now, adding this at the beginning of config.g and making sure it's AFTER network/HTTP is started, but before the rest of the machine config.

If a PanelDueFirmware.bin is detected a request is pushed to the PanelDue and DWC if connected at the time to update.

If DWC is connected, it also shows progress and results in console.

M552 S1										; Enable network
M586 P0 S1									; Enable HTTP
M586 P1 S0									; Enable FTP
M586 P2 S1									; Enable Telnet
M38 "sys/PanelDueFirmware.bin"				; compute hash of file if exists
if result == 0
	M291 R"PanelDue Update" P"Update available, checksum is available on console, OK to flash?" S3"
	M997 S4									; flash PanelDue
	if result == 0
		G4 S6 								; wait for paneldue reboot
		M30 "0:/sys/PanelDueFirmware.bin"	 	; delete update file
		if result != 0
			echo "PanelDue update file could not be removed following successful flash"
		M291 R"PanelDue Update" P"Update successful, see console for details" S2 T0
	else
		M291 R"PanelDue Update" P"Update ERROR, see console for details" S2 T0

If an update is declined, the file will need to be removed manually as cancel will abort further processing of config.g.

I did consider deleting the file on cancel and then rebooting, but I thought that if I'd declined the updated due to HASH mismatch, then I'd prob want the machine to stay as it is so I can troubleshoot. If you'd rather it deleted and rebooted, add the following after the last M291 making sure of the same indentation.

		M30 "0:/sys/PanelDueFirmware.bin"
		M999

Here's where I've got to now, adding this at the beginning of config.g and making sure it's AFTER network/HTTP is started, but before the rest of the machine config.

If a PanelDueFirmware.bin is detected a request is pushed to the PanelDue and DWC if connected at the time to update.

If DWC is connected, it also shows progress and results in console.

M552 S1										; Enable network
M586 P0 S1									; Enable HTTP
M586 P1 S0									; Enable FTP
M586 P2 S1									; Enable Telnet
M38 "sys/PanelDueFirmware.bin"				; compute hash of file if exists
if result == 0
	M291 R"PanelDue Update" P"Update available, checksum is available on console, OK to flash?" S3"
	M997 S4									; flash PanelDue
	if result == 0
		G4 S6 								; wait for paneldue reboot
		M30 "0:/sys/PanelDueFirmware.bin"	 	; delete update file
		if result != 0
			echo "PanelDue update file could not be removed following successful flash"
		M291 R"PanelDue Update" P"Update successful, see console for details" S2 T0
	else
		M291 R"PanelDue Update" P"Update ERROR, see console for details" S2 T0

If an update is declined, the file will need to be removed manually as cancel will abort further processing of config.g.

I did consider deleting the file on cancel and then rebooting, but I thought that if I'd declined the updated due to HASH mismatch, then I'd prob want the machine to stay as it is so I can troubleshoot. If you'd rather it deleted and rebooted, add the following after the last M291 making sure of the same indentation.

		M30 "0:/sys/PanelDueFirmware.bin"
		M999

@LB it will just error if there's no update file, so you could check the return of that alone, but I think @OwenD was meaning elegant in that there's no ERROR output in the console.

M997 S4 
Error: M997: File 0:/sys/PanelDueFirmware.bin not found

@OwenD Just thought I'd offer my solution using M38 to check existence of the file and offer the user a chance to check the Hash??

M38 "0:/sys/PanelDueFirmware.bin"
if result == 0
    M291 R"PanelDue Upgrade" P"New firmware has been detected, hash has been output to the console. OK to update?" S3
    ; M997 etc...
elif result == 2
    echo "No PanelDue firmware detected"

That's fine, I'm using a mosquito hot end which prefers a longer barrel.

Thanks for the info.

My PT1000 has decided it no longer wants to give accurate readings, so time for a replacement, but it seems there's no one currently stocking these in the UK.

My original one came from Precision Piezo, but it's no longer listed on the site or at ooznest or E3D.

Anyone know of a supplier?
Failing that, what is everyone using if not PT1000 currently?

I've just been reading some of the feature requests on RRF github page and a found this...

https://github.com/Duet3D/RepRapFirmware/issues/416

When we get variable support in conditional G-Code, we could set retract and wipe distances and have the slicer just reference those. Then we can have RRF filament definitions for each filament and also the ability to update them during a job (which is my main reason for preferring firmware retraction)

As an example you could set the retraction distance to 99.99, a little post-processing script to swap E-99.99 for E{retractionDistance} this would look like this in...
PrusaSlicer: /usr/bin/sed -e '/E-99.99/E-{retractionDistance}/g'
Simplify3D: {REPLACE " E-99.99" " E-{retractionDistance}"}

This would work until the slicers are updated to allow direct variable references for these values.

Thinking about it further maybe we could do this now already by swapping E-99.99 for E-{tools[0].retraction.length}??

This does only work if using relative extrusion though.

mkudzia84 created this issue in Duet3D/RepRapFirmware

closed [Feature Request] Wipe option for a firmware retract #416

@dc42 you're on a roll today

@dc42 Excellent! Thanks very much!

@dc42 great, thank you. I never looked in the boards section, assumed it was for expansion / tool boards.

Now I can leave out all of the logic and just include a config if it exists, which means I can have a single SD image for both machines.

M98 P{"MACHINES/" ^ boards[0].uniqueId ^ ".g"}

@bearer any idea why it's deferred? Only thing I could think of is to allow the firmware recovery of the WiFi module with M997, but then this is just a simple ordering of commands in the file. I could understand that if the config was not guaranteed to be processed in any order but we have commands used in config.g which must be in a particular order already. Add to that if files were processed out of order; 3D printing wouldn't be possible.

I noticed in another post M552 commands are deferred since you mentioned it, but in them posts they were interlaced with G4 wait commands, so how does it know to defer them too? This would lead to inconsistent behaviour.

If it's by design then it must have a reason; hardware implementation, some blocking I/O or a race condition?? I wonder if the WiFi module has direct access to the SDCard, this would make sense.