I additionally reran T0 PID tuning after this with CPAP to ensure things are stable on the heaters -> same results even with stable temps. Main difference noticed is the error appears twice now since I left it to run for a couple minutes instead of stopping it.

@jay_s_uk
I pulled this via laptop connected to the 2nd 6HC over USB in Repetier. I had it connected during initial moves but it was causing the machine to move hyper stuttery so I disconnected and reconnected after the error occurred then pulled the M122.

17:11:26.785 : === Diagnostics ===
17:11:26.785 : RepRapFirmware for Duet 3 MB6HC version 3.6.0-beta.3 (2025-01-16 19:09:36) running on Duet 3 MB6HC v1.01 (expansion mode)
17:11:26.785 : Board ID: 08DJM-9P63L-DJMSS-6J1F6-3SN6T-KUHHB
17:11:26.785 : Used output buffers: 1 of 40 (2 max)
17:11:26.785 : === RTOS ===
17:11:26.785 : Static ram: 136892
17:11:26.785 : Dynamic ram: 124960 of which 0 recycled
17:11:26.785 : Never used RAM 76660, free system stack 184 words
17:11:26.785 : Tasks: NETWORK(1,ready,10.6%,545) HEAT(3,nWait 6,0.0%,355) Move(4,nWait 6,0.0%,333) TMC(4,nWait 6,2.9%,377) CanReceiv(6,nWait 1,0.1%,682) CanSender(5,nWait 7,0.0%,334) CanClock(7,invalid,0.0%,351) MAIN(1,running,85.9%,440) IDLE(0,ready,0.5%,29) USBD(3,blocked,0.0%,137), total 100.0%
17:11:26.785 : Owned mutexes: USB(MAIN)
17:11:26.785 : === Platform ===
17:11:26.785 : Last reset 00:00:19 ago, cause: software
17:11:26.785 : Last software reset at 2025-01-31 22:10, reason: HeatTaskStuck, Gcodes spinning, available RAM 84820, slot 2
17:11:26.785 : Software reset code 0x0143 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0040080f BFAR 0x00000000 SP 0x2041d500 Task Move Freestk 1044 ok
17:11:26.785 : Stack: 00000000 2041ce5c 10000000 e000e000 2041d610 0049c135 0049c92c 61030000 20421268 0000002c 2041d5f0 204329b8 a5a5a5a5 204329b0 004551d1 0045825f a5a5a5a5 20432a38 a5a5a5a5 a5a5a5a5 a5a5a5a5 3e9ffad4 41c17ae3 41c27bff 3dd366e1 41419774 41422094
17:11:26.785 : Error status: 0x00
17:11:26.785 : MCU temperature: min 40.3, current 42.8, max 42.9
17:11:26.785 : Supply voltage: min 24.2, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
17:11:26.785 : 12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0
17:11:26.785 : Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
17:11:26.785 : Events: 0 queued, 0 completed
17:11:26.785 : Date/time: 2025-01-31 22:11:18
17:11:26.785 : Slowest loop: 1.04ms; fastest: 0.07ms
17:11:26.785 : USB interrupts 234
17:11:26.785 : === Storage ===
17:11:26.785 : Free file entries: 20
17:11:26.785 : SD card 0 detected, interface speed: 25.0MBytes/sec
17:11:26.785 : SD card longest read time 1.6ms, write time 0.0ms, max retries 0
17:11:26.785 : === Move ===
17:11:26.785 : Segments created 350, maxWait 0ms, bed comp in use: none, height map offset 0.000, hiccups added 0/0 (0.00/0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
17:11:26.785 : Pos req/act/dcf: 16732.80/0/0.00 0.00/0/0.00 0.00/0/0.00 0.00/0/0.00 0.00/0/0.00 0.00/0/0.00
17:11:26.785 : Peak sync jitter -1/1, peak Rx sync delay 175, resyncs 0/0, next step interrupt due in 262 ticks, disabled
17:11:26.785 : Driver 0: standstill, SG min n/a, mspos 840, reads 39232, writes 14 timeouts 0
17:11:26.785 : Driver 1: standstill, SG min n/a, mspos 8, reads 39235, writes 11 timeouts 0
17:11:26.785 : Driver 2: standstill, SG min n/a, mspos 296, reads 39235, writes 11 timeouts 0
17:11:26.785 : Driver 3: standstill, SG min n/a, mspos 296, reads 39235, writes 11 timeouts 0
17:11:26.785 : Driver 4: standstill, SG min n/a, mspos 296, reads 39235, writes 11 timeouts 0
17:11:26.785 : Driver 5: standstill, SG min n/a, mspos 8, reads 39235, writes 11 timeouts 0
17:11:26.785 : Phase step loop runtime (us): min=0, max=5, frequency (Hz): min=0, max=2212
17:11:26.785 : === DDARing 0 ===
17:11:26.785 : Scheduled moves 190, completed 190, LaErrors 0, Underruns [0, 0, 0]
17:11:26.785 : Segments left 0, axes/extruders owned 0x00000000, drives owned 0x00000000
17:11:26.785 : Code queue is empty
17:11:26.785 : === DDARing 1 ===
17:11:26.785 : Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
17:11:26.785 : Segments left 0, axes/extruders owned 0x00000000, drives owned 0x00000000
17:11:26.785 : Code queue is empty
17:11:26.785 : === Heat ===
17:11:26.785 : Bed heaters -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1 -1 -1 -1 -1, ordering e=== GCodes ===
17:11:26.785 : Movement locks held by null, null
17:11:26.785 : HTTP is idle in state(s) 0
17:11:26.785 : Telnet is idle in state(s) 0
17:11:26.785 : File is idle in state(s) 0
17:11:26.785 : USB is ready with "M122" in state(s) 0
17:11:26.785 : Aux is idle in state(s) 0
17:11:26.785 : Trigger is idle in state(s) 0
17:11:26.785 : Queue is idle in state(s) 0
17:11:26.785 : LCD is idle in state(s) 0
17:11:26.785 : SBC is idle in state(s) 0
17:11:26.785 : Daemon is idle in state(s) 0
17:11:26.785 : Aux2 is idle in state(s) 0
17:11:26.785 : Autopause is idle in state(s) 0
17:11:26.785 : File2 is idle in state(s) 0
17:11:26.785 : Queue2 is idle in state(s) 0
17:11:26.785 : === CAN ===
17:11:26.785 : Messages queued 158, received 462, lost 0, ignored 19, errs 0, boc 0
17:11:26.785 : Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 1/0/0
17:11:26.785 : Tx timeouts 0,0,0,0,0,0
17:11:26.785 : === Network ===
17:11:26.785 : Slowest loop: 0.22ms; fastest: 0.00ms
17:11:26.785 : Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
17:11:26.785 : HTTP sessions: 0 of 8
17:11:26.785 : = Ethernet =
17:11:26.785 : Interface state: disabled
17:11:26.785 : Error counts: 0 0 0 0 0 0
17:11:26.785 : Socket states: 0 0 0 0 0 0 0 0 0
17:11:26.785 : === Multicast handler ===
17:11:26.785 : Responder is inactive, messages received 0, responses 0

@jay_s_uk
Is that a different command than the M122 B1 (it is CAN address #1 for the expansion board)
The M122 in comment#0 is an M122 B1 pulled right after the error presents itself.

Summary:

When using 3.6.b3 on a configuration using a 6HC mainboard and a 2nd 6HC connected as an expansion board -> whenever the printer goes to actually start printing the system returns an error for "Expansion Board 1 Reconnected". This causes all motor drivers on the 2nd 6HC to stop responding. M122 B1 looks something like this:

M122 B1
Diagnostics for board 1:
RepRapFirmware for Duet 3 MB6HC version 3.6.0-beta.3 (2025-01-16 19:09:36) running on Duet 3 MB6HC v1.01
Last reset 00:00:21 ago, cause: software
Hiccups 0 (0.00/0.00ms), segs 427
Driver 0: 80.0 steps/mm, standstill, SG min n/a, mspos 648, reads 42032, writes 14 timeouts 0
Driver 1: 80.0 steps/mm, standstill, SG min n/a, mspos 8, reads 42038, writes 11 timeouts 0
Driver 2: 800.0 steps/mm, standstill, SG min n/a, mspos 296, reads 42040, writes 11 timeouts 0
Driver 3: 80.0 steps/mm, standstill, SG min n/a, mspos 296, reads 42043, writes 11 timeouts 0
Driver 4: 80.0 steps/mm, standstill, SG min n/a, mspos 296, reads 42045, writes 11 timeouts 0
Driver 5: 80.0 steps/mm, standstill, SG min n/a, mspos 8, reads 42048, writes 11 timeouts 0
VIN: 24.2V, V12: 12.1V, MCU temperature: min 39.0C, current 39.7C, max 39.9C
Peak sync jitter -1/1, peak Rx sync delay 175, resyncs 0/0, next step interrupt due in 52 ticks, disabled

NOTE: the settings listed here don't even match the configuration for the 2nd 6HC as its steps per/mm are supposed to be 727:727:1600:1600:1600. It also doesn't match the mainboard 6HC as its supposed to all be 80steps/mm.

If you run the M122 B1 after a reboot -> it returns expected values

Expected Results:

When initiating a print file or manually written gcode that follows proper formatting -> the firmware/machine should execute it as directed without issues.

Actual Results:

When initiating a print file or manually written gcode that follows proper formatting -> the machine will initiate the file and shortly after return an error for

Expansion Board 1 Reconnected

This causes all motor drivers to no longer respond on the expansion mainboard 6HC

Notes

At first I thought this could be other issues so I attempted the following:

• Swapped multiple CAN cables in -> CAN connection is fine for hours on end as long as its not printing
• Tried several Class 10 SD cards on the 2nd 6HC ranging from 4gb to 64gb with fresh formats
• Moved the GCODE file from a print file to a macro file to see if observed results changed
• Dropped Z microstepping to x8 and 800 steps/mm to see if it was a load issue.

No observed changes.

When not under a Print or Macro run status -> all drivers respond as expected and this error never occurs.

My setup is 4Y motors and 1X and 1U motors on the main 6HC with 2E and 3Z motors on the expansion 6HC.
EZ are unresponsive whenever you initiate a gcode stream via a macro(an attempted hack workaround) or whenever you are under a printing status.

This is similar behavior to 3.5.4 except in 3.5.4 ANY extruder motor on the expansion mainboard will not respond AT ALL regardless of machine status.

Same SD card; -> I did leave the other firmware binaries on the /firmware directory this time since that seemed harmless.
Its possible my adapter/reader corrupted something on previous attempts -> this time I did it through a laptop with reader built in.

Followup -> something wonky must've happened I reckon.
Backed up the newly working setup and went through and reset it back to the way Docs specify and now it works.
Same files I've used all along (copy/paste)

I won't question the gremlins in the hardware, its working now.

@jay_s_uk
Yes, config.g with just M954 A1 was in /sys and the firmware file for CAN was in /firmware on previous attempts.
On this latest attempt same thing, except, I left all other files and folders in place.

@droftarts

I reflashed the 2nd board to 3.6 beta3 to align with the auto update done on the rest of the system -> no results.
Like before -> status lights blink in unison but lacked connection when querying with a M115 B1

So on a whim I put the FULL folder directories, as if this were the mainboard, with all files onto the SD card for the 2nd board and merely added the Duet3_CANiap32_MB6HC.bin file to the list of files in /firmware and then wiped out the config.g to only have the M954 A1 command. These 2 folders and 2 files were in place prior but with no other directories or files.
CAN is now connected as expected.

@dc42
I think the documentation for connecting mainboard as a CAN board expansion could clarify this a bit as it currently implies you only need those two directories with the 1 file in each of them -> which apparently is not the case. Dumb mistake on my end again.

@jay_s_uk said in Dual 6HC not connecting via CAN and DWC won't update:

@aetherialdesign sounds like a browser cache issue. Clear the cache then see if it's now reporting the correct dwc version

Bingo! Didn't even think to check caching. Incognito returned expected results while normal browser still reported 3.5.3. Cleared cache and versioning is right now. One headache down!

@dc42 said in Dual 6HC not connecting via CAN and DWC won't update:

@aetherialdesign regarding the CAN connection, most likely it's a problem with the cable. Check that the wires are not crossed between the two ends. Also check that both boards are actually running the same firmware version. Putting the firmware on the SD card is not sufficient, it needs to be installed.

Cable is the kernable that comes with the Duets. Was pulled off a working toolchanger, however, I've got some replacements coming in later this afternoon to test. Regarding firmware -> both boards were flashed with the same 3.5.4 files via BOSSA back to back. Although now that everything else is on 3.6 beta 3 I expect I need to go back and manually flash the 2nd board to this.

Hi,
We’re currently commissioning the firmware and configuration for a large IDEX machine that utilizes two Duet 6HC v1.01 boards in SBC mode (required due to connectivity constraints). Here’s a breakdown of the setup:

• Primary 6HC: Controls 4 Y motors and 2 X motors and most peripherals.
• Secondary 6HC: Connected via CAN-FD, handles 2 extruders and 3 Z motors.

During the commissioning process, we’ve encountered a couple of issues:

1. CAN Connection Failure for Secondary 6HC

The secondary 6HC is not completing the CAN connection despite the following:

• Voltage lights are on, and the status lights are blinking on both boards.
• The SD card in the secondary board contains:
  /firmware folder with Duet3_CANiap32_MB6HC.bin.
  /sys folder with a single M954 A1 command in a config.g file (based on the documentation).

Are there additional steps or settings required to ensure the secondary 6HC connects via CAN successfully?

For reference, I’ve attached a basic bare-bones config file:
config.g

2. Firmware and DWC Version Mismatch

We are receiving critical errors for software mismatch versions.
When reviewing DWC we had the board and DSF firmware on 3.5.4 except DWC which was stuck on 3.5.3.
Attempting to update via sudo apt update and sudo apt upgrade did not fix this.
We then attempted several versions of the M997 command to get an update -> none stuck.
We then attempted to adopt the 3.6 beta 3 firmware via M997 -> this did not stick but DWC in the browser now showed it was on 3.5.4

Later, after a power cycle -> all firmwares were suddenly displaying as 3.6 beta 3; error stopped presenting itself.
However, after another power cycle -> DWC was back down to 3.5.3 again while the main 6HC and DSF were on 3.6 beta 3.

Looking for some assistance as to what may be going on here.
Previously these boards had been flashed to Kalico for other single tool builds but due to the inane way Klipper handles IDEX -> it was decided to re-adopt RRF. We followed the typical ERASE jumper and reset to get the boards back into programming mode and wipe out what was on them -> then reflashed via usb connection to RRF 3.5.4

Side Quest note: Docs specify the SZP keep out zone is 30mm...how strict is that? When this machine was on Kalico it was running a Beacon which is about 18mm below the all metal toolhead -> technically in Beacon's keep out zone but functionality was 'fine'

Awesome, thanks!
The short answer I glean here is that options exist for the setup I wanted to do and it isn't exactly reinventing the wheel. But there are some minor potential issues with setup that may/may not be addressed in coming releases.

Guess that's enough to start working towards laying out the CAD. And choose which board gets dedicated to the application down the road.

Hi all,
I have an old Duet2 WiFi(v1.01) as well as a 6HC(v1.0) lying around that I had decided to re-use for 2 laser builds. However, after evaluating frame footprints and such what not, I have decided I'd rather shoehorn both builds into a single frame with manually swappable toolheads.
Please note I already have the laser hardware pre-existing in my shop

• Diode Laser: This is a PLH3D-6W-XF. It also has the OptLasers Magnetic Docking station as well as the OptLasers PLH3D-CNC Adapter. This setup was previously on my gantry mill (run by a Blackbox X32 unfortunately), however, its become a nuisance on that machine and would be better suited in a machine designed around Laserwork. This tool, thanks to the dock, has a magnetic kinematic mount + pogo pins

• K40: Standard usual cheap china K40. Mine is from OMTech similar to this one. I've been wanting to move this K40 to a bigger build volume since its just slightly too small for products I commonly work on in the woodshop part of the workshop.

Issue I am having is trying to figure out "how" to configure and wire both lasers to a single board (either Duet2 or the 6HC)

For the Diode laser: Per the OptLasers CNC adapter manual under downloads tab here they only showcase wiring the adapter to a Duet2 using the heater/3.3v/ground from expansion header (page 16). Per their pinout on the CNC adapter:
Expansion Header Duet2 Wifi -> PLH3D CNC Adapter:

• heater3 is going to Pin7 Inverted PWM/TTL Input
• Ground(2) is going to Pin4 Ground
• 3.3v is going to Pin2 PWM/TTL Input

Are there alternative pinouts that can safely be used for control in this scenario on the 6HC? Or are some of the pinouts showcased for other boards compatible with updated hardware on Duet3? Example: the Blackbox seems to only utilize Ground (Pin4 ground on Adapter) and 0/3.3v signal pin (Pin2 PWM/TTL input on adapter).

For the K40 laser: I have no idea what is needed here but I assume the dedicated servo/laser output should suffice? And just assign those pins to the Tool. Do we have any good guide posts on wiring this? I did a cursory search through the forums and read a few posts but it started jumping around a lot and was mostly related to older Duet2 hardware with custom PCB adapters.

I assume the 6HC overall will be the better board choice for flexibility here; although I admittedly would rather utilize the Duet2 if its viable without crazy add-ons. I'd like to keep the electronics as simple and off the shelf as possible since its not my forte.

Just wanting to check in and cover base before I start putting effort into laying out the components and frame in CAD.
Thanks for taking the time to review.

Hi all,
Back on the forum but new account since I can't seem to find my credentials.
One of my Duet 6HCs purchased from Filastruder on September 29th, 2022 has decided to start spitting out an consistent yet intermittent error.

The error is Driver 0.1 Phase A short to VIN.

What Happened:
Running a print yesterday and I notice that the gantry is no longer moving. Login to Duet web Control and I am met with a Driver 0.1 Phase A short to VIN that is persistent and won't close when you hit "close". So can't pull an M122 while error is active. However, cycling the power and the error goes away until you begin another print (will happen about an hour into a print... 30 minute heatsoak + 30 minutes into printing).

Printer is a Voron 2.4 in the farm with about 1k hours on it.

• Driver 0.1 is tied to one of the stationary Z motors so no wire movement happens during operation.
• Swapping the cables around does not change the error.
  ** Example swapping connector 0.0 to 0.1 and 0.1 to 0.0 still kicks an error for Driver 0.1 Phase A short to VIN. So the error doesn't follow the motor/wiring.
• Electronics chamber under the Voron 2.4 is actively cooled by 2 60mm fans directly across from the Duet board.
• Printer is married to its own personal APC UPS 1500VA so electrical acts of "god" unlikely.
• Today is the first time I've had to access the electronics compartment on this machine since it finished being commissioned.
• Electrical tape in pictures is just for rub-points or strain points. Everything crimped with proper auto crimpers and/or heat shrink connectors (also crimped with proper crimpers).

I suspect the driver for 0.1 is just giving up prematurely; first time ever having to request this on a Duet product despite using since the launch of Duet WiFi across 20+ builds. Still an amazingly robust product. Shame since I'm in the middle of a huge order and losing a Voron is going to cost weeks.

Config:

; Configuration file for Duet 3 MB 6HC (firmware version 3.3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.3.13 on Sat Oct 15 2022 12:00:07 GMT-0400 (Eastern Daylight Time)

; General preferences
G90                                                       ; send absolute coordinates...
M83                                                       ; ...but relative extruder moves
M550 P"Voron"                                             ; set printer name
M669 K1                                                   ; select CoreXY mode

; Wait a moment for the CAN expansion boards to start
G4 S1

; Network

;M552 P0.0.0.0 S1                                         ; enable network and acquire dynamic address via DHCP
M586 P0 S1                                                ; enable HTTP
M586 P1 S0                                                ; disable FTP
M586 P2 S0                                                ; disable Telnet

; --- Z Drive map ---
;     _______
;    | 3 | 2 |
;    | ----- |
;    | 0 | 1 |
;     -------
;      front
;
; (looking at the printer from the top)

; Drives
M569 P0.4 S0                                              ; physical drive 0.4 goes forwards
M569 P0.5 S0                                              ; physical drive 0.5 goes forwards
M569 P0.0 S1                                              ; physical drive 0.0 goes forwards
M569 P0.1 S0                                              ; physical drive 0.0 goes backwards
M569 P0.2 S0                                              ; physical drive 0.0 goes forwards
M569 P0.3 S1                                              ; physical drive 0.0 goes backwards
M569 P121.0 S0                                            ; physical drive 121.0 goes forwards
M584 X0.4 Y0.5 Z0.0:0.1:0.2:0.3 E121.0                                ; set drive mapping
M350 X16 Y16 Z16 E16 I1                                   ; configure microstepping with interpolation
M92 X80.00 Y80.00 Z400.00 E690.00                         ; set steps per mm 705 for CW2
M906 X1300 Y1300 Z1300 E600                               ; set motor currents (mA)
M84 S0                                                    ; Disable motor idle current reduction

; Accelerations and speed
M98 P"/macros/print_scripts/setup_printing.g"

; Axis Limits
M208 X-150 Y-150 Z0 S1                                    ; set axis minima
M208 X150 Y160 Z260 S0                                    ; set axis maxima

; Endstops
M574 X2 S1 P"^io0.in"                                     ; configure switch-type (e.g. microswitch) endstop for high end on X via pin !io0.in
M574 Y2 S1 P"^io3.in"                                     ; configure switch-type (e.g. microswitch) endstop for high end on Y via pin !io3.in
M574 Z0 P"nil"											  ; No Z endstop

; Z-Probe
M558 K1 P8 C"121.io1.in" T18000 F240:60 H2 A10 S0.005 R0.2  ; Set Z probe type to switch, the axes for which it is used and the dive height + speeds
G31 K1 P500 X0.0 Y23.0 Z6.7 ; 0.4mm nozzle this was 6.66
;G31 K1 P500 X0.0 Y23.0 Z6.60 ; 0.6mm nozzle

; Bed leveling
M671 X200:-200:200:-200 Y-175:-175:195:195 S20            ; Define Z belts locations (Front_Left, Front_Right, Back_Right, Back_Left)
M557 X-125:125 Y-125:125 S25                    		  ; Define bed mesh grid (inductive probe, positions include the Y offset!)

; Heaters
M308 S0 P"temp0" Y"thermistor" T100000 B4138              ; configure sensor 0 as thermistor on pin temp0
M950 H0 C"out1" T0                                        ; create bed heater output on out3 and map it to sensor 0
M307 H0 R0.976 K0.649:0.000 D2.86 E1.35 S1.00 B0          ; disable bang-bang mode for the bed heater and set PWM limit
M140 H0                                                   ; map heated bed to heater 0
M143 H0 S120                                              ; set temperature limit for heater 0 to 120C
M308 S1 P"121.temp0" Y"thermistor" T100000 B4725 C7.06e-8 ; configure sensor 1 as thermistor on pin 121.temp0
M950 H1 C"121.out0" T1                                    ; create nozzle heater output on 121.out0 and map it to sensor 1
M307 H1 R3.828 K0.450:0.622 D1.54 E1.35 S1.00 B0 V24.2    ; disable bang-bang mode for the hot-end heater and set PWM limit
M143 H1 S280                                              ; set temperature limit for heater 1 to 280C
M308 S10 Y"mcu-temp" A"MCU" 							  ; defines sensor 10 as MCU temperature sensor
M308 S11 Y"drivers" A"Duet stepper drivers" 			  ; defines sensor 11 as stepper driver temperature sensor

; Fans
M950 F0 C"121.out2" Q500                                  ; create fan 0 on pin 121.out2 and set its frequency
M106 P0 S0 H1 T45 C"Hot-End Fan"                          ; set fan 0 value. Thermostatic control is turned on
M950 F1 C"121.out1" Q500                                  ; create fan 1 on pin 121.out1 and set its frequency
M106 P1 S0 H-1 C"Part Cooling Fan"                        ; set fan 1 value. Thermostatic control is turned off
M950 F2 C"out7" Q100                                      ; create fan 2 on pin out7 and set its frequency
M106 C"Electronics Bay" P2 T40:70 H10:11     			  ; Electronics bay fan, turn on gradually if MCU is over 45C or any TMC driver is over temp
M950 F3 C"out8" Q100                                      ; create fan 3 on pin out8 and set its frequency
M106 C"Electronics Bay" P3 T40:70 H10:11     			  ; Electronics bay fan, turn on gradually if MCU is over 45C or any TMC driver is over temp

; Tools
M563 P0 S"E3D Revo Voron" D0 H1 F0:1                      ; define tool 0
G10 P0 X0 Y0 Z0                                           ; set tool 0 axis offsets
G10 P0 R0 S0                                              ; set initial tool 0 active and standby temperatures to 0C

; Firmware Retraction and Pressure Advance
M572 D0 S0.045											  ; pressure advance T1
M207 S0.4 F1800 T1800 Z0.2 								  ; ABS/ASA retract T0 0.4mm at 30mm/s unretract at 30mm/s with a 0.2mm Z hop
;M207 S0.8 F1800 T1800 Z0.2 								  ; PLA retract T0 0.8mm at 30mm/s unretract at 30mm/s with a 0.2mm Z hop
M376 H10                           						  ; Fade mesh out compensation over 10mm Z

;Lights
M150 X3
M150 R0 U0 B0 W255 P255 S2 X3 F0 						  ; turn on Stealthburner LEDs for startup and set to white

;Input Shaping
;M593 P"zvdd" F29

; Miscellaneous
M912 P0 S-10.0                       					  ; MCU temp calibration
T0      												  ; Select Tool 1 on startup