RepRapFirmware 3.2beta4.1 now available

dc42

Thanks for that. The code to print the queued GCodes assumed that the commands were null-terminated, but they are not. Fixed in next beta/RC.

BoA

@dc42 What about move number? They are not consecutive numbers. Is that OK? Was something executed Out-Of-Order ?

dc42

@BoA said in RepRapFirmware 3.2beta4.1 now available:

@dc42 What about move number? They are not consecutive numbers. Is that OK? Was something executed Out-Of-Order ?

No. A "queued GCode" is one that needs to be delayed until a command that has been put in the movement queue is executed. Only a few command types are queued, for example heat, fan and GPIO commands. Most of the time there will be no commands in that queue. The movement command queue is separate.

jay_s_uk

@dc42 anything else I can do with this?

dc42

@jay_s_uk said in RepRapFirmware 3.2beta4.1 now available:

@dc42 anything else I can do with this?

With what?

jay_s_uk

@dc42 sorry, wrong topic

delta1

Using Duet Wifi. Upgraded to 3.2-beta4.1. Bed heater disappeared.

Config heater info.
; >>>>>>>>>>>>>>>>>> Heaters
;Extruder
M143 S300 ; Set maximum heater temperature to 300C
M950 H1 C"e0_heat" T1 ;Extruder heater
M308 S1 P"spi.cs1" Y"rtd-max31865" R395 F50
;Bed
M308 S0 P"bedtemp" Y"thermistor" A"Bed temp" T100000 B4725 C0 R2200 ;Set thermistor + ADC parameters for heater 0
M950 H0 C"bedheat" T0
M143 H0 S110 ;Bed heat max 110 deg C
M307 H1 A385.0 C163.1 D3.3 V23.9 B0; PID ran on 01/12/2020 Heater 1 model: gain 385.0, time constant 163.1, dead time 3.3, max PWM 1.00, calibration voltage 23.9

Did the port change?

dc42

I guess you upgraded from firmware 3.1. You now need to declare the bed heater explicitly using:

M140 H0

after creating heater 0 with M950.

GTech

Yesterday I tried to update to 3.2 Beta 4.1.
After the update DCS lost all communiucation to the board.
I flashed the board a 2nd time via USB to ensure that firmware was installed properly, which did not change anything.

In the end I was forced to roll back to the last stable release by flashing the firmware via USB.

root@GPDMk1:/opt/dsf# /opt/dsf/bin/DuetControlServer -l debug
Duet Control Server v3.2.0-beta4
Written by Christian Hammacher for Duet3D
Licensed under the terms of the GNU Public License Version 3

[info] Settings loaded
[info] Environment initialized
[fatal] Could not connect to Duet (Timeout while waiting for transfer ready pin)
[debug] System.OperationCanceledException: Timeout while waiting for transfer ready pin
   at DuetControlServer.SPI.DataTransfer.WaitForTransfer() in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 1081
   at DuetControlServer.SPI.DataTransfer.ExchangeHeader() in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 1122
   at DuetControlServer.SPI.DataTransfer.PerformFullTransfer(Boolean connecting) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 164
   at DuetControlServer.SPI.DataTransfer.Init() in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 104
   at DuetControlServer.Program.Main(String[] args) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/Program.cs:line 113
root@GPDMk1:/opt/dsf#

My setup: Pi4, 4GB + Duet 3 6HC + Panel Duei7

dc42

The most likely explanation is that you didn't manage to install the correct version of RRF. After flashing via USB and rebooting, if DCS won't connect then you can send M115 from USB to check the RRF version number, and M122 to get a diagnostic report.

Phaedrux

@GTech It might also be worth getting a fresh Duet Pi image and redoing the Pi SD card and updating it from there, especially if you're using the same Duet Pi build that came on the card originally.