Firmware downgrade

Phaedrux

If you're using the SBC, you can specify the versions to use during an upgrade. I think this might work similar to how updates are performed after using a beta version.

Users running an unstable firmware version (for example, any 3.2beta or 3.2RC version) on Duet + SBC, run sudo apt-get update followed by sudo apt-get upgrade duetsoftwareframework=3.2.0 duetcontrolserver=3.2.0 duetwebserver=3.2.0 duettools=3.2.0 duetruntime=3.2.0 duetsd=1.1.0 duetwebcontrol=3.2.0 reprapfirmware=3.2.0-1

Instead of 3.2, use whatever version you wish.

You can then check the installed firmware versions with M122, M122 B1, M122 B2, etc.

If they are still not downgrading the tool board firmware you can place the firmware version you want to use in the sys folder and use M997 B1, etc.
https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M997_Perform_in_application_firmware_update

Meltex

@Phaedrux Hi! Thank you for reply.

I tried but without success:

pi@Voron3D:~ $ sudo apt-get upgrade duetsoftwareframework=3.1.1 duetcontrolserver=3.1.1 duetwebserver=3.1.0 duettools=3.1.1 duetruntime=3.1.1 duetsd=1.1.0 duetwebcontrol=3.1.1 reprapfirmware=3.1.1
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Version '3.1.1' for 'reprapfirmware' was not found

Whatever number I put in "reprapfirmware=3.1.xxx" it always displays that version was not found. What am I doing wrong?

jay_s_uk

@Meltex use danall script to get a list of the most up to date packages.
Use the regress and specify the version you want.
https://github.com/DanalEstes/DuetVersions

dc42

@Meltex said in Firmware downgrade:

Hello!

Recently I have upgraded my Duet 3+RPi4+Toolboard to 3.2 firmware. Now I have issues (they are uder discussion here already) and would like to downgrade to 3.1. I have that old image of DuetPi and obviously can download 3.1 firmaware but I'm not sure how to downgrade the Tooldboard. Is there any instruction how to do it in proper way?

What issues are you having? Right now I can't think of any issues present in firmware 3.2 that are not also present in earlier versions.

Meltex

@dc42 said in Firmware downgrade:

What issues are you having?

Right after upgrade I face abnormal extruder (toolboard) behavior. I could not print jobs that were successfuly printed before - it looked like extruder doesn't extrude filament, so just tiny strings of plastic were on the bed. I have this priming procedure before start of the print:

T0
G92 E0                ; Zero extruder
G0 X30 Y0 F12000
G0 Z0.3 F9000         ; Move down

G1 X230 E30 F500       ; Extrude 30mm offilament over 200mm X axis
G1 X240 F500           ; Move 10mm without extracting
G92 E0                ; Zero extruder

This code works well, I have straight line of plastic perfectly laid on the bed. But after that there was no extruded plastic at all and during printing extruder motor did strange jerking moves with long retracts so filament just didn't come out of the nozzle. After some tests I found out that it depends on slicing software - jobs sliced in Cura didn't work but sliced in S3D did. Then I realized that if I uncheck "relative extrusion" in 3 tries out of 5 I had normal extrusion and could have successful print. But right now I cannot print at all. The first layer is a total mess. Even those jobs that were printed before.

I have disassembled the extruder and changed gears in it so now it is as new one. And to be sure that my issue is related to firmware I want to downgrade to 3.1 and double check because before 3.2 I have never had any problems. I think that it could be CAN communication issues.
Config and print_start macros in attachment: prime_extruder.g print_start.g config.g

Phaedrux

@Meltex said in Firmware downgrade:

jobs sliced in Cura didn't work but sliced in S3D did. Then I realized that if I uncheck "relative extrusion"

Please share an example gcode for each.

If the slicer produces relative extruder moves, but the firmware is set to absolute extrusion moves it would maybe produce the odd movements you are seeing.

It's best to use relative extrusion in the slicer, but there may be an erroneous command somewhere in your start gcode that changes it to absolute instead. Sharing the gcode files will let us see what is going on.

Meltex

@jay_s_uk Thanks, but something went wrong and now I it doesn't work at all.

Meltex

@Phaedrux unfortunately, I do not have saved Cura files because I used Duet plugin that sends gcode directly to Duet. I have S3D only. Test cube relative.gcode Test cube.gcode

Phaedrux

@Meltex said in Firmware downgrade:

I used Duet plugin that sends gcode directly to Duet.

Then the gcode files are still on the SD card, or in the case of the SBC mode, the virtual SD card located at /opt/dsf/sd

Meltex

@Phaedrux I know, but the folder is empty - I have cleared all jobs a couple of days ago just to be sure that nothing causes any interferention (like file was not overwritten properly). Attached you can find the same test cube sliced right now.V350_20mmTestCube_repaired.gcode

Phaedrux

So which of the gcode files you've uploaded is one that had the problem?

Phaedrux

M82 ;absolute extrusion mode
M98 P"/macros/Printing/print_start.g"
M83 ;relative extrusion mode

In your slicer start gcodes, make sure you remove any M82 commands and make sure the slicer is set to relative extruder moves and you should be good to go.

Meltex

@Phaedrux said in Firmware downgrade:

So which of the gcode files you've uploaded is one that had the problem?

Those with relative extrusion.

Meltex

@Phaedrux said in Firmware downgrade:

make sure you remove any M82 commands

Unfortunately, Cura puts M82 anyway:

And, before upgrading it worked without issues.

Phaedrux

Yes it will start with an M82 regardless, but will add the M83 as well after the start gcode.

;FLAVOR:RepRap
;TIME:11752
;Filament used: 24.7369m
;Layer height: 0.2
;MINX:115.035
;MINY:60.6
;MINZ:0.2
;MAXX:188.995
;MAXY:213
;MAXZ:38
;Generated with Cura_SteamEngine 4.7.1
T0
M190 S50
M104 S210
M109 S210
M82 ;absolute extrusion mode
M98 P"0:/sys/PrimeNozzle.g"
M98 P"0:/sys/StartGCode.g"
M83 ;relative extrusion mode
G10
;LAYER_COUNT:190
;LAYER:0
M107
G0 F3600 X115.806 Y62.782 Z0.2
;TYPE:SKIRT
G11
G1 F1800 X116.063 Y62.396 E0.02314

In your prime_extruder file you should specify if you want to be in relative or absolute extrusion mode.

prime_extruder.g

G92 E0                ; Zero extruder
G0 X30 Y0 F12000
G0 Z0.3 F9000         ; Move down

G1 X230 E30 F500       ; Extrude 30mm offilament over 200mm X axis
G1 X240 F500           ; Move 10mm without extracting
G92 E0                ; Reset extruder
G1 Z1 F9000

It looks to be formatted for absolute, and has the G92 E resets, so it should work either way.

Regardless, getting back to the tool boards. Did you confirm that they were also running 3.2?

You can then check the installed firmware versions with M122, M122 B1, M122 B2, etc.

Meltex

@Phaedrux said in Firmware downgrade:

Regardless, getting back to the tool boards. Did you confirm that they were also running 3.2?

Confirm.

Phaedrux

Would you be able to capture a M122 for the mainboard and tool board after experiencing the print problems? And to share that gcode file.

Meltex

@Phaedrux said in Firmware downgrade:

Would you be able to capture a M122 for the mainboard and tool board after experiencing the print problems? And to share that gcode file.

Need some time. I'm reinstalling the software on RPi right now.

Meltex

@Phaedrux said in Firmware downgrade:

Would you be able to capture a M122 for the mainboard and tool board after experiencing the print problems?

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2 running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956BA-NA3TJ-6J9D8-3SN6T-1AAYV
Used output buffers: 1 of 40 (10 max)
=== RTOS ===
Static ram: 149788
Dynamic ram: 63740 of which 92 recycled
Never used RAM 145212, free system stack 128 words
Tasks: Linux(ready,77) HEAT(blocked,296) CanReceiv(blocked,834) CanSender(blocked,344) CanClock(blocked,352) TMC(blocked,19) MAIN(running,671) IDLE(ready,19)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:05:17 ago, cause: power up
Last software reset at 2021-01-22 21:45, reason: User, GCodes spinning, available RAM 147812, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task Linu Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
MCU temperature: min 29.1, current 34.4, max 36.4
Supply voltage: min 24.0, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.2, max 12.3, under voltage events: 0
Driver 0: position 52000, standstill, reads 532, writes 27 timeouts 0, SG min/max 0/1023
Driver 1: position -50400, standstill, reads 531, writes 28 timeouts 0, SG min/max 0/1023
Driver 2: position 12253, standstill, reads 526, writes 33 timeouts 0, SG min/max 0/941
Driver 3: position 0, standstill, reads 526, writes 33 timeouts 0, SG min/max 0/1023
Driver 4: position 0, standstill, reads 526, writes 33 timeouts 0, SG min/max 0/1023
Driver 5: position 0, standstill, reads 526, writes 33 timeouts 0, SG min/max 0/703
Date/time: 2021-01-22 22:01:36
Slowest loop: 165.12ms; fastest: 0.04ms
=== Storage ===
Free file entries: 10
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, maxWait 105941ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 420, completed moves 420, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 5], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 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, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by 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 idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== CAN ===
Messages queued 1449, send timeouts 0, received 3694, lost 0, longest wait 2ms for reply type 6049, free buffers 48
=== SBC interface ===
State: 4, failed transfers: 0
Last transfer: 1ms ago
RX/TX seq numbers: 10985/10985
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x2c8a8
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.2.0
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 13.87
Maximum length of RX/TX data transfers: 2792/1512

M122 B121
Diagnostics for board 121:
Duet TOOL1LC firmware version 3.2 (2021-01-05)
Bootloader ID: not available
Never used RAM 4032, free system stack 52 words
HEAT 90 CanAsync 89 CanRecv 83 TMC 54 MAIN 218 AIN 64
Last reset 00:06:26 ago, cause: power up
Last software reset data not available
Driver 0: position 1900, 415.0 steps/mm, standstill, SG min/max 0/304, read errors 0, write errors 0, ifcnt 15, reads 62126, writes 15, timeouts 0, DMA errors 0
Moves scheduled 145, completed 145, in progress 0, hiccups 0
No step interrupt scheduled
VIN: 24.1V
MCU temperature: min 40.9C, current 46.9C, max 48.4C
Ticks since heat task active 212, ADC conversions started 384990, completed 384989, timed out 0
Last sensors broadcast 0x00000002 found 1 215 ticks ago, loop time 0
CAN messages queued 4534, send timeouts 0, received 3665, lost 0, free buffers 36

Nothing was extruded at all. My priming script was off. V350_20mmTestCube_repaired.gcode

Phaedrux

And when sliced with absolute extrusion it works fine?