Posts made by wifibeagle

@wifibeagle

On second thought don't bother with Gcode Modifyer. It only allows one change before saving and reloading the file. I think it is just as easy to modify the code in Notepad+. Oh well...

@wifibeagle

FYI: I found a program called "Gcode Modifyer" that makes it relatively easy to add user gcode at any desired layer. It would be better if CURA had such a post processing feature but this beats manually editing the gcode file. I'm still trying to figure out all the possibilities.

https://www.youtube.com/watch?v=ikwa3nVHrO8 shows a demonstration plus links to the program.

In my case it inserted the following at each selected layer

;G-Code Modifier DATA Start
M98 P"0:/macros/wipe" ;1st Command LAYER
;G-Code Modifier DATA End

@Phaedrux

As is often the case I make things more difficult than necessary. I made a copy of my wipe macro with G60 S3 at the beginning and G1 X0 Y0 Z0 F3000 at the end and it worked!

Thank you for your help and patience. Now I'll see how it works for the 600 layer print.

John

@Phaedrux

The next command in the process gcode is M104 S230

The custom code sounds like an interesting approach. I will read more in the documentation to see how I might use that technique.

Unfortunately, cura does not have a simple way to insert gcode at height. It has insert gcode at layer change but I can't wipe every layer in a 600 layer print! Filament change is an option (M600) but with my limited understanding that seems basically like M226. There is also a time lapse script that uses a user specified Mcode to trigger the camera with a configurable pause.

I think my basic problem is I don't understand how the system knows to return to the last print location and continue the print if I were to manually insert the wipe macro call into the gcode. That's why I'm stuck on the pause/resume approach. Can you point me to some detailed documentation to help me understand?

John

@Phaedrux
Well, I was hoping it would be that simple unfortunately it is not. I tried replacing the M24 with M98 P"0:/macros/wipe". After the wipe macro nothing happened, no resume. So I selected the DWC resume and the print head moved to the last position and extruded some filament then returned to the wipe position so I cancelled the print. Then I tried adding M24 to a copy of the wipe macro. That functioned just like having the M24 in the print gcode. It is a coreXY printer so the wipe mechanism is mounted to the frame of the printer vs. attached to the bed.I have attached a screen print of the CURA pause at height dialog for reference. I really do not understand the pause/resume process in enough detail.

Most of the PETG I have printed had tolerable blobs. This 3Kg roll has many more and larger blobs even after reducing the extrusion flow. The nozzle picks up little imperfections in the previous layer(s) which eventually turns into a blob sticking to the print. I mostly print functional parts where appearance is not the primary focus but these blobs are just too big and plentiful.

Any more suggestions/questions?

John

my wipe macro

if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
  exit

if move.axes[2].machinePosition < 35
 G1 Z35 F500

G1 X-15 Y20 F6000

while iterations < 4
	M280 P4 S130
	G4 S0.3
	M280 P4 S65
	G4 S0.3
   continue

M280 P4 S0

I am trying to insert a pause to wipe the nozzle periodically using the Cura 5.6 post processing "pause at height" function. Manually pressing the DWC pause and resume buttons works as expected. Executing the following gcode the pause works as expected but the resume does not. The pause.g file gets executed then nothing happens. After waiting a bit I pressed the DWC resume button. The extruder resumes the previous print X & Y positions but instead of printing it returns to the pause position after extruding the 10mm called for in resume.g. While at the pause position it then tries to retract and extrude 10mm. This cycle repeats without human intervention until I hit the DWC emergency stop. Something is different with the M226, M24 sequence vs the DWC pause and resume.

Any ideas?

Board: Duet 3 MB6HC (MB6HC)
DSF Version: 3.4.5
Firmware: RepRapFirmware for Duet 3 MB6HC 3.4.5 (2022-11-30)

;added code by post processing
;script: PauseAtHeight.py
;current layer: 5
M83 ; switch to relative E values for any needed retraction
M104 S0 ; standby temperature
M84 S3600 ; Keep steppers engaged for 1h
M226 ; Do the actual pause
M24
M104 S230 ; resume temperature
G1 F2700 ; restore extrusion feedrate
M83 ; switch back to relative E values
G92 E0.23155
;LAYER:5

; pause.g
; called when a print from SD card is paused
;
; generated by RepRapFirmware Configuration Tool v3.1.4 on Thu Sep 03 2020 12:19:15 GMT-0400 (Eastern Daylight Time)
M83            ; relative extruder moves
G1 E-10 F3600  ; retract 10mm of filament
G91            ; relative positioning
G1 Z5 F360     ; lift Z by 5mm
G90            ; absolute positioning
;G1 X0 Y0 F6000 ; go to X=0 Y=0
G1 X0 F6000 ; go to X=0 
M98 P"0:/macros/wipe"

; resume.g
; called before a print from SD card is resumed
;
; generated by RepRapFirmware Configuration Tool v3.1.4 on Thu Sep 03 2020 12:19:15 GMT-0400 (Eastern Daylight Time)
G1 R1 X0 Y0 Z5 F6000 ; go to 5mm above position of the last print move
G1 R1 X0 Y0          ; go back to the last print move
M83                  ; relative extruder moves
G1 E10 F3600         ; extrude 10mm of filament

@dc42 I selected r1. 3 because I may change to the hemera xs knowing the mount spacing is different. I have already added the new mounting holes to my bracket. The grounding through the mounting is also a bonus. I'll have to modify the wiring connections either way.

@dc42 R25 measures about 3.6K ohms which seems close enough in circuit to suggest it is functional. So the T1 issue is still unknown. I will look for possible external problems as you suggested.

I have ordered a R1.3 toolboard due today. I see the mounting holes are grounded through a 100K resistor. I have found a good way to add a ground wire to the Revo heater block by sliding a male Dupont connector between the wires and the metal strain relief. I will connect it to one of the mounting screws. I also plan to replace the plastic mounting standoffs with metal ones to ground the board to the aluminum mount for the extruder. I verified there is a good connection through the heater core to the nozzle. I'm including a couple pictures of the grounding in case someone stumbles upon this post with a similar issue.

Thank you for your help and prompt response.

This image was captured from cnckitchen's excellent review of the Revo (https://www.cnckitchen.com/blog/e3d-rapidchange-revo-review)

@dc42 R21 measures about 200K, R22 1890 Ohms. The resistor appears to be the issue with T0. R22 is close enough to 2.2K that T1 looks like a different problem. I will order some resistors and try replacing R21.

Meanwhile I have ordered a replacement toolboard and will ground the hotend before powering any tooboard.

Thanks for your help.

John

@dc42 Here's the M122

m122 B121
Diagnostics for board 121:
Duet TOOL1LC rev 1.0 or earlier firmware version 3.4.1 (2022-06-01 21:16:39)
Bootloader ID: not available
All averaging filters OK
Never used RAM 3512, free system stack 80 words
Tasks: Move(notifyWait,0.0%,153) HEAT(notifyWait,0.4%,95) CanAsync(notifyWait,0.0%,61) CanRecv(notifyWait,0.0%,76) CanClock(notifyWait,0.0%,65) TMC(notifyWait,3.0%,57) MAIN(running,91.7%,351) IDLE(ready,0.0%,40) AIN(delaying,4.9%,142), total 100.0%
Last reset 01:10:53 ago, cause: software
Last software reset at 2021-03-11 09:54, reason: HardFault, available RAM 3936, slot 0
Software reset code 0x0060 ICSR 0x00000003 SP 0x20002f60 Task MAIN Freestk 746 ok
Stack: 00000001 00000002 2000332c 00000000 41000000 a5a5a5a5 00017aba 61000000 a5a5a5a5 2000332c 20006db8 a5a5a5a5 a5a5a5a5 4b07e7d4 a5a5a5a5 20003398 00000001 200033d8 a5a5a5a5 00017bbb a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 20000ddc 00000001 200020b4
Driver 0: pos 0, 420.0 steps/mm,standstill, SG min 0, read errors 0, write errors 1, ifcnt 25, reads 29552, writes 12, timeouts 0, DMA errors 0, CC errors 0, steps req 0 done 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0, step errors 0, maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0
Peak sync jitter 5/10, peak Rx sync delay 213, resyncs 0/0, no step interrupt scheduled
VIN voltage: min 24.1, current 24.2, max 24.2
MCU temperature: min 32.6C, current 33.8C, max 33.9C
Last sensors broadcast 0x00000002 found 1 221 ticks ago, 0 ordering errs, loop time 1
CAN messages queued 85068, send timeouts 0, received 38296, lost 0, free buffers 37, min 37, error reg 0
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0
Accelerometer: none

@dc42 After changing to temp1 the room temperature reading is now about 244.4C. So it appears the second input also has a problem. Testing with a different thermistor is not as easy as I only have the one tiny plug to fit temp1. It looks like the resistors on the toolboard are the tiny 402 size. I do have a microscope but it would be challenging to replace something so small. Which resistors would need to be changed?

My hot end is installed in a Precision Piezo Orion which does insulate it from the rest of the machine. I'm still trying to decide how to ground the Revo hot end.

I recently changed my hotend to a revo six. I changed the thermistor configuration based on this forum as follows.

M308 S0 P"temp0" Y"thermistor" T100000 B4725 C7.06e-08F

The first couple prints were not very satisfactory so I started some basic tuning. While testing the max extrusion rate at different temperatures twice the temperature went to 2000C. I reset the system and it returned to a reasonable temperature. Later the temperature just started climbing from the 210 setting. I set the temperature to zero and it did start falling but started to level out around 170C. I disconnected the thermistor and the temperature dropped to ~39C. I connected a known good thermistor and the indicated temperature returned to ~160 with the thermistor at room temperature. With no thermistor connected the toolboard reports 39.2C.

My conclusion is the toolboard has failed but on the chance there is something else wrong I am posting here.

Here are the results of Diagnostics
M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.1 (2022-06-01 21:09:01) running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956L2-G43S8-6J1D6-3S86R-KA3YF
Used output buffers: 1 of 40 (12 max)
=== RTOS ===
Static ram: 151000
Dynamic ram: 66164 of which 28 recycled
Never used RAM 133408, free system stack 137 words
Tasks: SBC(ready,0.6%,466) HEAT(notifyWait,0.0%,321) Move(notifyWait,0.0%,267) CanReceiv(notifyWait,0.0%,772) CanSender(notifyWait,0.0%,356) CanClock(delaying,0.0%,339) TMC(notifyWait,7.9%,58) MAIN(running,91.5%,923) IDLE(ready,0.1%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:24:38 ago, cause: software
Last software reset at 2023-03-17 10:02, reason: User, GCodes spinning, available RAM 133264, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Step timer max interval 135
MCU temperature: min 33.8, current 34.1, max 34.4
Supply voltage: min 23.8, current 23.9, max 23.9, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 11.8, current 11.9, max 11.9, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, mspos 40, reads 51000, writes 19 timeouts 0
Driver 1: standstill, SG min 0, mspos 680, reads 51001, writes 19 timeouts 0
Driver 2: standstill, SG min 0, mspos 312, reads 51001, writes 19 timeouts 0
Driver 3: standstill, SG min 0, mspos 312, reads 51001, writes 19 timeouts 0
Driver 4: standstill, SG min 0, mspos 312, reads 51001, writes 19 timeouts 0
Driver 5: standstill, SG min 0, mspos 8, reads 51009, writes 11 timeouts 0
Date/time: 2023-03-17 10:27:33
Slowest loop: 32.67ms; 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, segments created 3, maxWait 16511ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 11, completed 11, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 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, chamber heaters -1 -1 -1 -1, ordering errs 0
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 13329, received 29600, lost 0, boc 0
Longest wait 5ms for reply type 6024, peak Tx sync delay 244, free buffers 50 (min 49), ts 7394/7393/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 58635/58635
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x2b880
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server v3.4.1
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 39.71, max time between full transfers: 128.2ms, max pin wait times: 59.8ms/27.1ms
Codes per second: 0.08
Maximum length of RX/TX data transfers: 3044/904

@wifibeagle
Reprinted a part that required the G4 delay after deleting that command. No problems with the print. It appears 3.4.1 may have cured the problem even if it has not completely solved the mystery.

I can live with that!

@phaedrux Thank you for your suggestions.

There is no problem homing, zeroing the Z axis, G32 bed leveling or probing to verify the bed leveling.

The reset seems to occur with the first slight XY move at the start of a print. Then a short delay, less than a second, Z zero reset and the start of the air print. It all happens so fast it is hard to tell the exact behavior. I would not expect the Z probe to be active at this time.

There is a slight sensitivity difference for the piezo after the hotend change. It seems slightly less sensitive than before. Translating between probe locations at 6000mm/min there are frequent probe triggers. I have a 0.8 second delay between motion and the start of a probe. That has eliminated false trigering. Reducing the acceleration during probing also helped but not as much as the delay.

I upgraded to 3.4.1 yesterday for other reasons. I will try a print today without adding the G4 delay and see if the problem persists.

John

I have a curious problem that appeared after changing back to a standard V6 clone from a dragon hotend. When I start a print the Z axis zero gets reset before the first movement. Then it air prints about 35mm above the bed. If I add a short pause (G4 S1) to the gcode file before the initial movement command it prints normally. I am currently using Cura 5.0 slicer with no additional starting gcode commands. Initially my start.g file was unchanged. I have tried several additions and deletions to that file without success. Including or excluding the wipe macro had no effect.

Any suggestions? Editing the gcode file every time is a pain.

The printer is a custon coreXY with a Duet3 and a single rev1 toolboard. It has 3 Z axis steppers for bed leveling. I have been running release 3.3 before and after the hotend switch. My Z probe has been a Precision Piezo Orion throughout.

echo "start.g executing"
M220 S100 ; reset speed factor
M557 X35:285 Y35:285 S50 ; define default mesh grid
G1 Z35.0 F1000 ; Move the platform down to 35mm
;G92 E0 ; reset extruder
;G1 X150 Y0 F6000
;G29 S0
;M376 H3
;G1 E5 F100 ; Extrude a short distance before wipe
M98 P"0:/macros/wipe"
;G4 S1 ; wait then beep
M300 S500 P500
G4 S1

wipe macro
if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
exit

if move.axes[2].machinePosition < 35
G1 Z35 F500

G1 X-15 Y20 F6000

while iterations < 4
M280 P4 S115
G4 S0.2
M280 P4 S80
G4 S0.2
continue

M280 P4 S20

Typical starting section of the gcode file
;FLAVOR:RepRap
;TIME:1838
;Filament used: 7.81383m
;Layer height: 0.35
;MINX:103.875
;MINY:90.082
;MINZ:0.35
;MAXX:144.943
;MAXY:219.915
;MAXZ:17.85
;Generated with Cura_SteamEngine 5.0.0
T0
M190 S70
M104 S245
M109 S245
M82 ;absolute extrusion mode

M83 ;relative extrusion mode
G1 F1800 E-1
;LAYER_COUNT:51
;LAYER:0
M107
M204 T1500
M566 X1200 Y1200
G4 S1
G0 F7200 X105.327 Y92.253 Z0.35
G0 X103.876 Y96.79
M204 P1000
M566 X2100 Y2100
;TYPE:SKIRT
G1 F1500 E1
G1 F1800 X103.886 Y96.111 E0.07411

Reference files
config-g-6-14-22.txt
M122.txt
M122-B121.txt

@gloomyandy

I should have noticed the difference in the C parameters. I guess I focused too much on the R parameter. The part cooling fan is always off during initial heating which is where the fault occurs. I have made some modifications to the part fan nozzle so I should have redone the auto tune. I will watch carefully to insure the part fan comes on during the tune.

Thanks for the suggestions.

John

My printer is controlled by a Duet3 with a toolboard (v1.0). I have used M303 to tune the hot end heater a couple times. Its a Dragon hot end with a 50 watt heater. If I use the following tuning with 100% PWM I get a heater fault at about 50-60DegC but no error shows in the console.
M307 H1 B0 R2.436 C284.6:199.0 D7.35 S1.00 V23.9

If I use the following tuning with 80% PWM I don't get the fault.
M307 H1 B0 R2.314 C340.3:340.3 D9.18 S0.80 V23.9

So I can certainly live with the 80% tuning but it seems very odd to get a fault and no error. If I reset the fault and continue heating to 120C (my probing temp) the heating continues with no fault. I never get a fault heating from 120C to printing temperatures. I suspect there is some heating rate limit for safety and at 100% my printer exceeds that limit. A 50 watt heater may be overkill for this hot end. I do get the possible over temperature warning when starting up or executing the M307 commands.

Any Idea what causes the fault?

Board: Duet 3 MB6HC (MB6HC)
DSF Version: 3.3.0
Firmware: RepRapFirmware for Duet 3 MB6HC 3.3 (2021-06-15)

John

Thanks for the link and the heads up on the new release.

I have had a LinuxCNC router much longer than I've been 3D printing. I was surprised to learn Duet does not include the CNC limit switch philosophy. Not a real issue for a 3D printer but a major concern for the energy involved with a typical CNC machine.

Progress! Thanks for the help. I was able to create a new SD card and update to the latest stable release.

RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v1.01 or later (SBC mode)

If the status is idle all of the button and switch triggers work as expected. Each causes a momentary idle to busy status transition when activated. However, if the status is busy none of the triggers work. After my config.g file executes the status is (sometimes?) busy and the triggers don't work. M502 resets the status to idle and the triggers then work as expected. One of my goals with these triggers is to have a button that stops all XYZ movement during a print without resetting the machine. It appears the triggers will not work for that purpose. Is this the expected behavior or do I have something configured incorrectly?

M98 P"config.g" does not return any errors.

I have attached my config file for reference.

; Configuration file for Duet 3 (firmware version 3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.1.4 on Thu Sep 03 2020 12:19:13 GMT-0400 (Eastern Daylight Time)

; General preferences
G90 ; send absolute coordinates...
M83 ; ...but relative extruder moves
M550 P"duet3" ; set printer name
M667 S1 ; select CoreXY mode
M669 K1 ; switch to CoreXY mode
M80 ; enable the powersupply before relay time expires

; 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 S1 ; enable Telnet

; Drives
M584 X0.1 Y0.0 Z0.4:0.3:0.2 E121.0 ; set drive mapping
M569 P0.0 S1 ; left XY drive 0.0 goes forwards
M569 P0.1 S1 ; right XY drive 0.1 goes forwards
M569 P0.2 S0 ; Z1 drive 0.2 goes backwards
M569 P0.3 S0 ; Z2 drive 0.2 goes backwards
M569 P0.4 S0 ; Z3 drive 0.2 goes backwards
M569 P121.0 S1 ; extruder drive 1.0 goes forwards
;M584 X0.0 Y0.1 Z0.2 E1.0 ; set drive mapping
;M584 X0.0 Y0.1 Z0.2:0.3:0.4 E1.0 ; set drive mapping
;M584 X0.1 Y0.0 Z0.2:0.3:0.4 E121.0 ; set drive mapping
M350 X16 Y16 Z16 E16 I1 ; configure microstepping with interpolation
M92 X100.00 Y100.00 Z800.00 E420.00 ; set steps per mm Z*1.22
M203 X18000.00 Y18000.00 Z1500.00 E1200.00 ; set maximum speeds (mm/min)
M201 X1000.00 Y1000.00 Z20.00 E250.00 ; set accelerations (mm/s^2)
M566 X900.00 Y900.00 Z120.00 E80.00 ; set maximum instantaneous speed changes (jerk) (mm/min)
M906 X1000 Y1000 Z800 E600 I30 ; set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout

; Axis Limits
M208 X-22 Y-10 Z-0.2 S1 ; set axis minima
M208 X326 Y317 Z300 S0 ; set axis maxima
M671 X-64:373:373 Y155:6:308 S3.0 ; leadscrews at left middle, right front and right rear

; Endstops
M574 Y1 S1 P"!io0.in" ; configure active-low endstop for low end on Y via pin io0.in
M574 Z1 S1 P"!io1.in" ; configure active-low endstop for low end on Z via pin io1.in
M574 X1 S1 P"!121.io2.in" ; configure active-low endstop for low end on X via toolboard pin io2.in

; Z-Probe
M558 P8 C"^!121.io0.in" H5 F100 T6000 ; set Z probe type to switch and the dive height + speeds
G31 X0 Y0 Z0 ; set Z probe trigger value, offset and trigger height
M557 X10:300 Y10:300 S58 ; define mesh grid

; Heaters
;Heater 0 model: gain 157.2, time constant 209.1, dead time 1.7, max PWM 1.00, calibration voltage 23.9, mode PID
M308 S0 P"temp0" Y"thermistor" T100000 B3950 ; configure sensor 0 as thermistor on pin temp0
M950 H0 C"out0" T0 Q1 ; create bed heater output on out0 and map it to sensor 0
M307 H0 B0 A157.2 C400 D4 S1.0 ; 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 B3950 ; configure sensor 1 as thermistor on toolboard temp0
M950 H1 C"121.out0" T1 ; nozzle heater output on toolboard out0 and map it to sensor 1
M307 H1 A796 C220 D5 V23.9 B0 S0.50 ; disable bang-bang mode for heater and set PWM limit

; Fans
M950 F0 C"!121.out1" Q25000 ; create fan 0 (hot end) on toolboard out1 and set its frequency0
M106 P0 S0 H1 L0.5 T45:120 C"HotEnd" ; set fan 0 value. Thermostatic control is turned on
M950 F1 C"121.out2" Q100 ; create fan 1 (part cooling) on toolboard out2 and set its frequency
M106 P1 S0 H-1 C"PartFan" B0.5 L0.4 ; set fan 1 value. Thermostatic control is turned off
M950 F3 C"!out4" Q25000 ; Power supply Aux Fan
M106 P3 S0.55 H-1 C"PSfan" L0.2 ; set fan 3 value. Thermostatic control is turned off

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

; Lighting
M950 F2 C"out1" Q500
M106 P2 S0.2 C"LEDs"

; Toolboard Buttons
M950 J0 C"^!121.button0"
M950 J1 C"^!121.button1"
M581 T2 P0 S0 R0
M581 T3 P1 S0 R0

; Front panel button & switch
M950 J2 C"^io2.in" ; Input 2 pullup enabled - front panel switch
M950 J3 C"^!io3.in" ; Input 3 inverted, pullup enabled - red button
M581 T4 P2 S0 R0
M581 T5 P2 S1 R0
M581 T6 P3 S0 R0

; Custom settings are not defined

; Miscellaneous
M501 ; load saved parameters from non-volatile memory
M911 S10 R11 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000" ; set voltage thresholds and actions to run on power loss

T0

I have run apt update/upgrade but it does not update the Duet files. I am using a copy of the SD card that came with the Duet3 so I still have the untouched original Duetpi card.

my /etc/apt/sources.list.d/duet3d.list file contains
deb https://pkg.duet3d.com/ stable armv7

When I run sudo apt update it shows

Hit:3 https://pkg.duet3d.com stable InRelease

so it is looking for Duet updates but none are found when I run apt update. I realize there are other update methods but I really want this method to work going forward.

A potentially related question: Where are the sys and macro folders that I see in DWC physically located?