Unsolved Firmware downgrade
-
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 -
@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 foundWhatever number I put in "reprapfirmware=3.1.xxx" it always displays that version was not found. What am I doing wrong?
-
@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 -
@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.
-
@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 -
@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.
-
@jay_s_uk Thanks, but something went wrong and now I it doesn't work at all.
-
@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
-
@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
-
@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
-
So which of the gcode files you've uploaded is one that had the problem?
-
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.
-
@Phaedrux said in Firmware downgrade:
So which of the gcode files you've uploaded is one that had the problem?
Those with relative extrusion.
-
@Phaedrux said in Firmware downgrade:
make sure you remove any M82 commands
Unfortunately, Cura puts M82 anyway:
And, before upgrading it worked without issues.
-
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.
-
@Phaedrux said in Firmware downgrade:
Regardless, getting back to the tool boards. Did you confirm that they were also running 3.2?
Confirm.
-
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.
-
@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.
-
@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
-
And when sliced with absolute extrusion it works fine?