My suggestion would be the same as all the others.
Make sure the aluminium plate has been cast, not rolled. Cast plates have less internal stresses and will warp less when heated, you should also make sure that plate has been face milled so it is level and flat.
This type of plates is a commodity if you can tolerate to use a default size, they are of the shelf parts you can can get on eBay.
You can drill the mouting holes with a drillpress or even a cordless if need be, just start with a small size drill and low rpm.

Since we are talking 400x400 and up, your only practical option is mains powered silicone heater in the 1kW range. Keenovo is a commonly used brand, they publish the specs for the integrated thermistors, there are even a few config samples here in the forum you can copy paste.
You can get those of Ali but there are also a bunch of retailers in europe. ... please do not forget, to run a ground wire to the bed as the silicone heaters only have a 2 wire connection

Insulation, my prefered choice is mealamin foam, often sold under brand the name Basotect. It can be used up to 240C and is flame retartend. It is commonly used as sound and heat insulation in cars, offices, public buildings. You can get 20mm sheets on Amazon or eBay. Use some 3M-468MP, high temperature resistant double sided sticky tape, and put the foam under your bed.

Print surface, get a magnetic sheet with a spring steel sheet, you can get those as kits on eBay and Amazon. It is just so much more convinient ... seperating a large PETG print from a ridgit plate without damaging the build surface or the print can quickly become a challenge.
Build surface it selfe, personal choice, my favourite is FR-2.

It was always my fault with my macros not beeing resiliant enough.

Thanks for the script but my point was a different one,
With the BLTouch we have a sensor that is able to detect and report a malfunction, which i think is a good feature.

IMHO it would be good if RRF could make use of this and be enabled to recognize when a malfunction is reported and to respond..

There is already specialised code for the BLTouch so this would "complete" the current implementation and close the feedback loop.

@razrudy I normally use 8mm at the size we are talking it is already quite a chunck of metal. You might be able to get away with 6mm anything below that makes no sense in my mind.
10mm will work as well, its just heavier and has more thermal mass aka. needs longer to heat and cool. Depends on what you can get you hands on.

As others mentioned mounting that thing is the challange, at 400x400 you will need to somehow compensate for thermal expansion or it will warp no matter how thick the plate is.

Take a look at the HeVORT printer, the guy is on the forum here as well, I think he has a nice way of mounting the bed ... it is just bit overkill . Also take a look at the Jubilee nice bed mounting as well.

On eBay and some stores you can also find silicone blocks and spacers intended for moutng printer beds. They are flexible enough to allow the bed to expand and act as a heat break between the bed and the frame at the same time ... not my first choice but apparently people use them succesfully.

Couple of related notes; You can get silicone heaters with holes in them so you can do the mounting directly under the bed and maximize the print area.

Forget about the Cartisan, 8mm 400x400 should weight something in the 3-4kg range(?) accelerating and decelerating that quickly without loosing steps is a whole different discussion. If you want to go Cartisian your only option is a PCB heater ... Chinese clone of the Prusa Mk42 most likely?

FYI I am just dialing in my new build, bit smaller then yours (300x300 build plate on a 8mm cast aluminium tool plate ~380x350) and with propper mounting there is next to no warping.
I disabled mesh bed compensation, active leveling with three Z screws is enough and I can print right up to the edge with a nice and even first layer.

@razrudy I normally use 8mm at the size we are talking it is already quite a chunck of metal. You might be able to get away with 6mm anything below that makes no sense in my mind.
10mm will work as well, its just heavier and has more thermal mass aka. needs longer to heat and cool. Depends on what you can get you hands on.

As others mentioned mounting that thing is the challange, at 400x400 you will need to somehow compensate for thermal expansion or it will warp no matter how thick the plate is.

Take a look at the HeVORT printer, the guy is on the forum here as well, I think he has a nice way of mounting the bed ... it is just bit overkill . Also take a look at the Jubilee nice bed mounting as well.

On eBay and some stores you can also find silicone blocks and spacers intended for moutng printer beds. They are flexible enough to allow the bed to expand and act as a heat break between the bed and the frame at the same time ... not my first choice but apparently people use them succesfully.

Couple of related notes; You can get silicone heaters with holes in them so you can do the mounting directly under the bed and maximize the print area.

Forget about the Cartisan, 8mm 400x400 should weight something in the 3-4kg range(?) accelerating and decelerating that quickly without loosing steps is a whole different discussion. If you want to go Cartisian your only option is a PCB heater ... Chinese clone of the Prusa Mk42 most likely?

FYI I am just dialing in my new build, bit smaller then yours (300x300 build plate on a 8mm cast aluminium tool plate ~380x350) and with propper mounting there is next to no warping.
I disabled mesh bed compensation, active leveling with three Z screws is enough and I can print right up to the edge with a nice and even first layer.

My suggestion would be the same as all the others.
Make sure the aluminium plate has been cast, not rolled. Cast plates have less internal stresses and will warp less when heated, you should also make sure that plate has been face milled so it is level and flat.
This type of plates is a commodity if you can tolerate to use a default size, they are of the shelf parts you can can get on eBay.
You can drill the mouting holes with a drillpress or even a cordless if need be, just start with a small size drill and low rpm.

Since we are talking 400x400 and up, your only practical option is mains powered silicone heater in the 1kW range. Keenovo is a commonly used brand, they publish the specs for the integrated thermistors, there are even a few config samples here in the forum you can copy paste.
You can get those of Ali but there are also a bunch of retailers in europe. ... please do not forget, to run a ground wire to the bed as the silicone heaters only have a 2 wire connection

Insulation, my prefered choice is mealamin foam, often sold under brand the name Basotect. It can be used up to 240C and is flame retartend. It is commonly used as sound and heat insulation in cars, offices, public buildings. You can get 20mm sheets on Amazon or eBay. Use some 3M-468MP, high temperature resistant double sided sticky tape, and put the foam under your bed.

Print surface, get a magnetic sheet with a spring steel sheet, you can get those as kits on eBay and Amazon. It is just so much more convinient ... seperating a large PETG print from a ridgit plate without damaging the build surface or the print can quickly become a challenge.
Build surface it selfe, personal choice, my favourite is FR-2.

It was always my fault with my macros not beeing resiliant enough.

Thanks for the script but my point was a different one,
With the BLTouch we have a sensor that is able to detect and report a malfunction, which i think is a good feature.

IMHO it would be good if RRF could make use of this and be enabled to recognize when a malfunction is reported and to respond..

There is already specialised code for the BLTouch so this would "complete" the current implementation and close the feedback loop.

Okay, that worked, thanks!

To be honest it is kinda counter intuitive, communication failures with a filament monitors, unrealistic readings from thermal sensors or a wiring fault on a NC switch are all handled in a way that tries to prevent damage, ZProbe errors seem to be the exception.
I understand, that it is complicated as most probes are constantly triggered during a print but it is not impossible.

RRF is aware that the ZProbe is a BLTouch (M558 P9) and a BLTouch reports errors by being constantly triggered. It would be nice I RRF could recognise when a BLTouch is in error mode and handle it appropriately.

The tips of those probe pins snap of rather easily and replacement pins cost a fortune, so much that I have given up on using a BLTouch in combination with a Duet board.

... well, just my 2 cents.

The same happens for other errors with the ZProbe. aka. ‘“Z Probe did not trigger during probe move” RRF logs the error and just continues as normal,
Happens on RRFv2 and v3 also happened to me with the BLTouch and a Pinda, a regular inductive probe and the differential IR Probe

Another scenario is when you do active bed levelling with multiple Z screws if one probe point fails, it continues with the other points and eventually starts to print.

Hi,

during the update I had the same issue I had on Beta 4.1

This time I did the following:

• Downloaded a new image of DuetPI put it on a new SD card, enabled SSH and configured WiFi, booted and confirmed normal operation of the Duet stack.
• Updated the kernel and user land to the latest version (apt update/upgrade) and confirmed normal operation once more.
• Switched to the unstable Duet repo and executed the update (apt update & upgrade).. Like with Beta 4.1, the control server was unable to connect to the Duet3.

I am using a RPI4, 4GB

root@duet3:/opt/dsf/bin# ./DuetControlServer -l debug
Duet Control Server v3.2.0-rc2
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(Boolean inTransfer) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 1086
   at DuetControlServer.SPI.DataTransfer.ExchangeHeader() in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 1148
   at DuetControlServer.SPI.DataTransfer.PerformFullTransfer(Boolean connecting) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 162
   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@duet3:/opt/dsf/bin#

This time i was able to run the g-codes requested when I reported the error for Beta 4.2.

M115
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.2-RC2 ELECTRONICS: Duet 3 MB6HC v0.6 or 1.0 FIRMWARE_DATE: 2020-12-24

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2-RC2 running on Duet 3 MB6HC v0.6 or 1.0 (standalone mode)
Board ID: 08DGM-9T66A-G63SJ-6J9F2-3S86Q-TA0BA
Used output buffers: 1 of 40 (1 max)
=== RTOS ===
Static ram: 149788
Dynamic ram: 91516 of which 396 recycled
Never used RAM 117132, free system stack 160 words
Tasks: NETWORK(ready,547) HEAT(blocked,353) CanReceiv(blocked,927) CanSender(blocked,371) CanClock(blocked,352) TMC(blocked,53) MAIN(running,1345) IDLE(ready,19)
Owned mutexes: USB(MAIN)
=== Platform ===
Last reset 00:05:23 ago, cause: reset button
Last software reset details not available
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
MCU temperature: min 21.7, current 24.3, max 24.5
Supply voltage: min 23.9, current 23.9, max 23.9, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.2, under voltage events: 0
Driver 0: position 0, standstill, reads 53913, writes 11 timeouts 0, SG min/max 0/0
Driver 1: position 0, standstill, reads 53913, writes 11 timeouts 0, SG min/max 0/0
Driver 2: position 0, standstill, reads 53913, writes 11 timeouts 0, SG min/max 0/0
Driver 3: position 0, standstill, reads 53913, writes 11 timeouts 0, SG min/max 0/0
Driver 4: position 0, standstill, reads 53913, writes 11 timeouts 0, SG min/max 0/0
Driver 5: position 0, standstill, reads 53914, writes 11 timeouts 0, SG min/max 0/0
Date/time: 1970-01-01 00:00:00
Slowest loop: 2.59ms; fastest: 0.05ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 2.1ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], 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 = -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is ready with „M122“ in state(s) 0 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.
=== Network ===
Slowest loop: 0.16ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 0 of 8
- Ethernet -
State: disabled
Error counts: 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages queued 0, send timeouts 1614, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 47
ok

I had to downgrade to 3.1.1 in order to restore normal operation.

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