RepRapFirmware 3.3beta1 now available

Stephen6309

@dc42 On my 6HC with a PI 4, did a update/upgrade and 3.3beta1 didn't install.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law.
pi@CXY-MSv1:~ $ sudo apt-get update
Get:1 http://archive.raspberrypi.org/debian buster InRelease [32.8 kB]
Get:2 http://packages.microsoft.com/repos/code stable InRelease [10.4 kB]
Get:3 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
Get:4 http://packages.microsoft.com/repos/code stable/main arm64 Packages [14.2 kB]
Get:5 http://packages.microsoft.com/repos/code stable/main armhf Packages [14.2 kB]
Get:6 http://packages.microsoft.com/repos/code stable/main amd64 Packages [13.7 kB]
Hit:7 https://pkg.duet3d.com unstable InRelease
Get:8 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages [13.0 MB]
Get:9 http://archive.raspberrypi.org/debian buster/main armhf Packages [364 kB]
Fetched 13.5 MB in 8s (1,661 kB/s)
Reading package lists... Done

pi@CXY-MSv1:~ $ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
ffmpeg libjpeg8 rpi-eeprom-images
Use 'sudo apt autoremove' to remove them.
The following packages have been kept back:
libpulse-mainloop-glib0 libpulse0 libpulsedsp pulseaudio
pulseaudio-module-bluetooth pulseaudio-utils python-rpi.gpio
The following packages will be upgraded:
libssl1.1 openssl rpi-eeprom rpi-eeprom-images
4 upgraded, 0 newly installed, 0 to remove and 7 not upgraded.
Need to get 2,520 kB of archives.
After this operation, 488 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://archive.raspberrypi.org/debian buster/main armhf rpi-eeprom armhf 11.7-1 [442 kB]
Get:2 http://mirror.us.leaseweb.net/raspbian/raspbian buster/main armhf libssl1.1 armhf 1.1.1d-0+deb10u5 [1,263 kB]
Get:4 http://archive.raspberrypi.org/debian buster/main armhf rpi-eeprom-images armhf 11.7-1 [7,824 B]
Get:3 http://mirror.us.leaseweb.net/raspbian/raspbian buster/main armhf openssl armhf 1.1.1d-0+deb10u5 [807 kB]
Fetched 2,520 kB in 2s (1,650 kB/s)
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 84232 files and directories currently installed.)
Preparing to unpack .../libssl1.1_1.1.1d-0+deb10u5_armhf.deb ...
Unpacking libssl1.1:armhf (1.1.1d-0+deb10u5) over (1.1.1d-0+deb10u4+rpt1) ...
Preparing to unpack .../openssl_1.1.1d-0+deb10u5_armhf.deb ...
Unpacking openssl (1.1.1d-0+deb10u5) over (1.1.1d-0+deb10u4+rpt1) ...
Preparing to unpack .../rpi-eeprom_11.7-1_armhf.deb ...
Unpacking rpi-eeprom (11.7-1) over (11.6-1) ...
Preparing to unpack .../rpi-eeprom-images_11.7-1_armhf.deb ...
Unpacking rpi-eeprom-images (11.7-1) over (11.6-1) ...
Setting up libssl1.1:armhf (1.1.1d-0+deb10u5) ...
Setting up rpi-eeprom (11.7-1) ...
Setting up rpi-eeprom-images (11.7-1) ...
Setting up openssl (1.1.1d-0+deb10u5) ...
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for libc-bin (2.28-10+rpi1) ...

oliof

@Stephen6309 see just the two posts above yours. This is by design, you need to upgrade to 3.3b1 manually.

oliof

@dc42 during the update of the toolboard, the toolboard did not recover until I power cycled the printer. After that the tool temperature was reported to be at about 90C which seems to indicate the heater got fully powered either while the Duet3 board was already on 3.3b1 and the toolboard still on 3.2.2, or after getting the update before being power cycled ...

dc42

@oliof, this (output 0 turns on while up-loading firmware) is a known issue with the first production batch of tool boards using the original bootloader. It can be fixed by installing an updated bootloader. However, I have a report (yet to be investigated) that uploading the bootloader on a tool board doesn't work when running tool board firmware 3.3beta.

oliof

I have an early tool board (v0.6), but i did update the bootloader late last year:

M122 B10
Diagnostics for board 10:
Duet TOOL1LC firmware version 3.3beta1 (2021-02-14 16:34:04)
Bootloader ID: SAMC21 bootloader version 2.1 (2020-11-03b2)

User3D

@dc42 is it any different from 3.3beta release available on dropbox? (released 10-15 days ago)

dc42

@User3D said in RepRapFirmware 3.3beta1 now available:

@dc42 is it any different from 3.3beta release available on dropbox? (released 10-15 days ago)

Yes, it's more recent. There is an even more recent one at https://www.dropbox.com/sh/q5uqqkjbmhgvlhq/AACYqG0ynLME9ogoLd1zLB2Xa?dl=0 but it should only be used if you need the new features in it, described at https://github.com/Duet3D/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3_Beta.md.

oliof

The deprecation of G10 for setting tool temperature is a bit awkward as PrusaSlicer only recently implemented support for using G10 for RepRapFirmware temperature control ...

chrishamm

@oliof We'll undo the deprecation notice in the next beta, please ignore it for now.

stewwy

Having a slight problem when I change from 3.2 to 3.3 beta 1 my z-probe does not work

from my config.g file

M574 Z1 S2 ; configure Z-probe endstop for low end on Z

; Z-Probe
M558 P8 C"^!zprobe.in" H3 F500 T9000 ; set Z probe type to unfiltered(8) and the dive height + speeds (inductive probe via optocoupler)
G31 P500 X-32 Y-26 Z3.020 ; set Z probe trigger value, offset and trigger height
M557 X5:235 Y25:235 S15 ; define mesh grid

Is my config a problem I checked the notes and could not see any indication of change

The probe is a highly accurate industrial probe,

dc42

@stewwy said in RepRapFirmware 3.3beta1 now available:

Having a slight problem when I change from 3.2 to 3.3 beta 1 my z-probe does not work

from my config.g file

M574 Z1 S2 ; configure Z-probe endstop for low end on Z

; Z-Probe
M558 P8 C"^!zprobe.in" H3 F500 T9000 ; set Z probe type to unfiltered(8) and the dive height + speeds (inductive probe via optocoupler)
G31 P500 X-32 Y-26 Z3.020 ; set Z probe trigger value, offset and trigger height
M557 X5:235 Y25:235 S15 ; define mesh grid

Is my config a problem I checked the notes and could not see any indication of change

The probe is a highly accurate industrial probe,

Which Duet?

stewwy

Duet wifi 1.03

Should also note that it was constantly triggered (.i.e. the triggered light was on constantly)

dc42

@stewwy said in RepRapFirmware 3.3beta1 now available:

Duet wifi 1.03

Should also note that it was constantly triggered (.i.e. the triggered light was on constantly)

If it's connected via an optocoupler as you said, then there is no way that the Duet can cause the LED on the probe to light up.

stewwy

My Bad I should have been clearer, Just finished a print on 3.2 now flashed 3.3 to check

The web page shows it as being on constantly ( Z-probe showing 1000 constantly) regardless of whether the z probe is triggered or not.

The probe indicator works normally, it turns on 8mm from the bed surface but is not being read properly by the duet. it works on 3.2 but not on 3.3.

stewwy

OK that's interesting,
on 3.3 on first turning on the probe shows 0 on the web page
if I activate the probe ( with a piece of metal) the webpage z-probe display latches to 1000 to get it to zero again I have to restart the duet.

The optocoupler display led acts normally, on when probe activated, off when probe is not activated.

dc42

Post a schematic showing how the optocoupler is connected.

If the optocoupler is leaky then you might need to add an external pullup resistor between IN and +3.3V on the Z Probe connector.