Posts made by patrickwjoyce

@Phaedrux sure thing here are all the home.g and my starting machine gcode.

Also, its worth noting that I just had a similar issue with just starting a job (it didn't happen the second time I ran the job). so it might not be a race condition, and instead an issue somewhere else. I also disabled skew compensation entirely (M556) for now

; homeall.g
; called to home all axes
;
; generated by RepRapFirmware Configuration Tool v3.3.16 on Fri Oct 27 2023 16:48:23 GMT-0700 (Pacific Daylight Time)
G91                      ; relative positioning
G1 H2 Z5 F6000           ; lift Z relative to current position
G1 H1 X-205 Y205.5 F1800 ; move quickly to X and Y axis endstops and stop there (first pass)
G1 H2 X5 Y-5 F6000       ; go back a few mm
G1 H1 X-205 Y205.5 F360  ; move slowly to X and Y axis endstops once more (second pass)
G90                      ; absolute positioning
G1 X40 Y9.5 F6000        ; go to first bed probe point and home Z
G30                      ; home Z by probing the bed

; Uncomment the following lines to lift Z after probing
;G91                     ; relative positioning
;G1 Z5 F100              ; lift Z relative to current position
;G90                     ; absolute positioning

; homex.g
; called to home the X axis
;
; generated by RepRapFirmware Configuration Tool v3.3.16 on Fri Oct 27 2023 16:48:23 GMT-0700 (Pacific Daylight Time)
G91               ; relative positioning
G1 H2 Z5 F6000    ; lift Z relative to current position
G1 H1 X-205 F1800 ; move quickly to X axis endstop and stop there (first pass)
G1 H2 X5 F6000    ; go back a few mm
G1 H1 X-205 F360  ; move slowly to X axis endstop once more (second pass)
G1 H2 Z-5 F6000   ; lower Z again
G90               ; absolute positioning

; homey.g
; called to home the Y axis
;
; generated by RepRapFirmware Configuration Tool v3.3.16 on Fri Oct 27 2023 16:48:23 GMT-0700 (Pacific Daylight Time)
G91                ; relative positioning
G1 H2 Z5 F6000     ; lift Z relative to current position
G1 H1 Y205.5 F1800 ; move quickly to Y axis endstop and stop there (first pass)
G1 H2 Y-5 F6000    ; go back a few mm
G1 H1 Y205.5 F360  ; move slowly to Y axis endstop once more (second pass)
G1 H2 Z-5 F6000    ; lower Z again
G90                ; absolute positioning

; homez.g
; called to home the Z axis
;
; generated by RepRapFirmware Configuration Tool v3.3.16 on Fri Oct 27 2023 16:48:23 GMT-0700 (Pacific Daylight Time)
G91               ; relative positioning
G1 H2 Z5 F6000    ; lift Z relative to current position
G90               ; absolute positioning
G1 X40 Y9.5 F6000 ; go to first probe point
G30               ; home Z by probing the bed

; Uncomment the following lines to lift Z after probing
;G91              ; relative positioning
;G1 Z5 F100       ; lift Z relative to current position
;G90              ; absolute positioning

And here is my custom start g-code:

M140 S[first_layer_bed_temperature] ; Set Bed Temp
M190 S[first_layer_bed_temperature] ; Wait for Bed temp to reach target
M104 S[first_layer_temperature] T0; Set extruder Temperature
M109 S[first_layer_temperature] T0; Wait for extruder to reach set temp

G28 ;Home
M572 D0 S0.5; Enable Pressure Advance
G29 S1 ;Load Heightmap and enable bed mesh leveling
M376 H1; Taper mesh compensation after 2mm
;Prime the extruder
G92 E0 ; Zero Extruder
G1 X-1 Y-1 Z3; Move just outside origin and up 3mm,
G1 E40 F500; Extrude 35mm filament
G1 Z0.25 X50; Squash blob
G92 E0; Reset Extruder position

Not sure if this is the right place to post this.

Just today, I managed to accidentally create a z-homing race condition by telling my printer to Home all axes and then sending another command that caused the X and Y axes to not move to the z-homing location before attempting to home Z. the two sequences are listed below:

Scenario 1: Use DWC to initiate "Home All", and then clicked "run mesh compensation" before homing had finished. This resulted in the printer failing to home z because my probe is off the build plate when the hot end is at the Y-home position.

Scenario 2: I started a print (which included homing as part of the starting g-code), and then went to use Z-Babystepping. the same thing happened as before where the X and Y homed, but then failed to move before initiating Z-home routine.

Is there a setting or configuration change I can do to prevent this from happening. I don't recall ever having this issue before (despite doing similar sequences), and its been at least a month or more since I last changed the firmware. The only config changes I made were to reorder M556, and adjust it's values.

I'm running this FW config

@tas I just assumed that Z was 1 because of gravity. I think that the frequency domain analysis of each axis is done independently since Z shows a very small amplitude in all of my original graphs.

@gloomyandy thank you, I did eventually figure that out. I did check the wiki and firmware, and the accelerometer is already collecting data at the max frequency (1600 hz). And the biggest issue that was occuring with the long tail of data is the hot end cooling fan frequency was creating a false signal.

Regarding my specific case, I was able to solve a lot of my issues by securing the cable to the gantry because the rubbing on the frame was causing lots of noise. And the low amplitude seems to just be from my printer being particularly rigid at the speeds I can go (score 1 for past me!). I'm currently limited by hot end flow rate, so maybe if I switch back to my volcano, this will become more important.

I reconfigured my setup so that the accelerometer cable is secured to the hot end gantry, and I'm now getting more consistent results. (yay!)

And I think I figured out why the results change with data samples qty. That option doesn't actually change the rate of data points, just the total number of samples. So increasing that number just increases the signficance of ambient vibrations of the system. In my case the fans become the biggest influence.
With Fan

Fan off:

All that being said, I'm now curious if my data is really showing that Input shaping will help me. it seems like my printer is rigid enough that the fans are the primary source of hot end vibration. I'm guess I can try for even more agressive jerk and accelerations until those become relevant.

@Notepad Interesting. I've got speed, accel, and jerk all basically uncapped at this point with the goal of finding the true limits of my printer, but maybe that's contributing to the variable results.

So I've done more testing with lowered limits, and even still, this is feeling more like a random number generator than a measurement tool. It seems like the cable position is just as significant a factor as the actual motion settings.

I just got the Duet3D Accelerometer installed, and in the process of playing with it, I've noticed very inconsistent results in the data collected without any shaping applied. In the interest of taking a slightly scientific approach to this problem, I ran the following move several times with different number of samples:

G1 X45 Y45 G4 S3 M956 P0 S4000 A1 F"9-XY45-135-0-none.csv" G4 P10 G1 X135 Y135 F20000

Here are the outputs for the different runs:
S500:

S1000:

S2000:

S2500:

S3000:

S4000:

Here is the summary of peak frequency for each axis at each resolution:

As you can see the amplitude changes a lot with each increase in resolution, and the overall results seem to change a lot with results until I'm above S3000.

I'm not sure what to do with the results at this point. The difference in peak between X and Y does make sense for my printer layout (Dual Wire Gantry, Bowden), but the highly variable results are concerning. Is this going to strongly affect the output of applying input shaping during real prints?

@phaedrux Thank you! (that did not come up when I did a search before posting)

I'm in the early stages of designing a tool changing platform, and am curious if it is appropriate to hot swap extruder stepper motors for the modular hot ends. In order to simplify the wiring harness, and reduce the cost of electronics, I am hoping to use a pogo pin connection between the tool heads, and the tool holder. I would ideally include channels for the heater core, thermistor, cooling fans, and direct drive extruder motor. The first 3 seem fairly easy to manage from gcode macros, and I'm not aware of any electrical reason that hot swapping those could be a problem. The motor on the other hand has me a bit concerned.

Based on the documentation here: https://duet3d.dozuki.com/Wiki/How_to_destroy_your_Duet_2 it seems like I should be able to avoid problems as long as the motor is powered down during the swap, but I just wanted to confirm that before I go too far down this design path. (I guess this technically wouldn't be hot swapping, but I'd still like to be able to switch out tool heads (with motors) as frequently as once per layer.)

@pixelpieper said in DWC is requiring multiple restarts to connect:

I had a simmilar behavior which seemed to be fixed by making sure to include the SSID within the M552 command.

I do have the SSID entered via the M552 command, but oddly enough, only one of my SSIDs would actually connect properly. Over the course of my trouble shooting I tried my 3 different SSIDs but the only one that would connect was my super isolated IOT subnet. I'm wondering if the new wifi server version might fix that issue as well.

@phaedrux The non-beta version of the wifi server appears to have solved the problem of requiring multiple reboots to connect to wifi. Thank you very much.

I will note that I spent a good amount of time, last month, searching for a non-beta wifi server firmware, but had no success finding it. I am fairly familar with Github, so I don't know why it was such a challenge to find that particular item. What is the best way to find specific wifi server updates?

@phaedrux That is correct, those were done while the board would not connect to wifi. Down near the bottom you can see the the wifi IP address is 255.255.255.255.

Here is the output once it does connect:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.2.2 running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: 676VY-Y196U-D65J0-40KMJ-NF03Z-ZZSK0
Used output buffers: 3 of 40 (40 max)
=== RTOS ===
Static ram: 98732
Dynamic ram: 107964 of which 76 recycled
Never used RAM 38444, free system stack 124 words
Tasks: NETWORK(ready,192) HEAT(blocked,315) CanReceiv(blocked,947) CanSender(blocked,358) CanClock(blocked,362) TMC(blocked,106) MAIN(running,438) IDLE(ready,20) AIN(blocked,264)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 02:00:18 ago, cause: power up
Last software reset at 2021-04-22 12:58, reason: User, GCodes spinning, available RAM 38444, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x04
Aux0 errors 0,0,0
Aux1 errors 0,0,0
Supply voltage: min 11.5, current 11.8, max 12.5, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: position 19800, standstill, SG min/max 0/18, read errors 0, write errors 0, ifcnt 12, reads 42939, writes 3, timeouts 0, DMA errors 0
Driver 1: position 12100, standstill, SG min/max 0/20, read errors 0, write errors 0, ifcnt 12, reads 42939, writes 3, timeouts 0, DMA errors 0
Driver 2: position 4020, standstill, SG min/max 0/56, read errors 0, write errors 0, ifcnt 18, reads 42933, writes 9, timeouts 0, DMA errors 0
Driver 3: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 9, reads 42942, writes 0, timeouts 0, DMA errors 0
Driver 4: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 9, reads 42942, writes 0, timeouts 0, DMA errors 0
Driver 5: position 0, assumed not present
Driver 6: position 0, assumed not present
Date/time: 2021-04-23 17:05:47
Cache data hit count 4294967295
Slowest loop: 16.03ms; fastest: 0.12ms
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 3.9ms, write time 4.6ms, max retries 0
=== Move ===
DMs created 83, maxWait 5548851ms, 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, 8], 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 = 0 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.7
=== 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 doing "M190 S65" 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.
=== Network ===
Slowest loop: 200.93ms; fastest: 0.08ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 1
WiFi firmware version 1.25beta0
WiFi MAC address f4:cf:a2:6f:bd:8f
WiFi Vcc 3.39, reset reason Power up
WiFi flash size 2097152, free heap 21504
WiFi IP address 192.168.30.27
WiFi signal strength -41dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages queued 64640, send timeouts 64639, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 16

It doesn't make any sense, all I do is reboot another two times, and it just connects no problem.

Sorry for the delay, here is the output of M122:

M122<CR><LF>
=== Diagnostics ===<LF>
RepRapFirmware for Duet 3 Mini 5+ version 3.2.2 running on Duet 3 Mini5plus WiFi (standalone mode)<LF>
Board ID: 676VY-Y196U-D65J0-40KMJ-NF03Z-ZZSK0<LF>
Used output buffers: 1 of 40 (13 max)<LF>
=== RTOS ===<LF>
Static ram: 98732<LF>
Dynamic ram: 107756 of which 40 recycled<LF>
Never used RAM 38688, free system stack 148 words<LF>
Tasks: NETWORK(ready,166) HEAT(blocked,315) CanReceiv(blocked,947) CanSender(blocked,372) CanClock(blocked,362) TMC(blocked,106) MAIN(running,440) IDLE(ready,20) AIN(blocked,264)<LF>
Owned mutexes: WiFi(NETWORK) USB(MAIN)<LF>
=== Platform ===<LF>
Last reset 19:50:32 ago, cause: power up<LF>
Last software reset at 2021-04-22 12:58, reason: User, GCodes spinning, available RAM 38444, slot 2<LF>
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a<LF>
Error status: 0x00<LF>
Aux0 errors 0,0,0<LF>
Aux1 errors 0,0,0<LF>
Supply voltage: min 0.0, current 12.3, max 12.4, under voltage events: 0, over voltage events: 0, power good: yes<LF>
Driver 0: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 9, reads 46488, writes 9, timeouts 0, DMA errors 0<LF>
Driver 1: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 9, reads 46488, writes 9, timeouts 0, DMA errors 0<LF>
Driver 2: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 9, reads 46488, writes 9, timeouts 0, DMA errors 0<LF>
Driver 3: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 9, reads 46486, writes 9, timeouts 1, DMA errors 0, failedOp 0x6f<LF>
Driver 4: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 9, reads 46488, writes 9, timeouts 0, DMA errors 0<LF>
Driver 5: position 0, assumed not present<LF>
Driver 6: position 0, assumed not present<LF>
Date/time: 2021-04-23 14:48:24<LF>
Cache data hit count 4294967295<LF>
Slowest loop: 7.49ms; fastest: 0.12ms<LF>
=== Storage ===<LF>
Free file entries: 10<LF>
SD card 0 detected, interface speed: 22.5MBytes/sec<LF>
SD card longest read time 3.9ms, write time 0.0ms, max retries 0<LF>
=== Move ===<LF>
DMs created 83, maxWait 0ms, bed compensation in use: none, comp offset 0.000<LF>
=== MainDDARing ===<LF>
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1<LF>
=== AuxDDARing ===<LF>
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1<LF>
=== Heat ===<LF>
Bed heaters = 0 -1, chamberHeaters = -1 -1<LF>
=== GCodes ===<LF>
Segments left: 0<LF>
Movement lock held by null<LF>
HTTP is idle in state(s) 0<LF>
Telnet is idle in state(s) 0<LF>
File is idle in state(s) 0<LF>
USB is ready with "M122" in state(s) 0<LF>
Aux is idle in state(s) 0<LF>
Trigger is idle in state(s) 0<LF>
Queue is idle in state(s) 0<LF>
LCD is idle in state(s) 0<LF>
SBC is idle in state(s) 0<LF>
Daemon is idle in state(s) 0<LF>
Aux2 is idle in state(s) 0<LF>
Autopause is idle in state(s) 0<LF>
Code queue is empty.<LF>
=== Network ===<LF>
Slowest loop: 85.01ms; fastest: 0.00ms<LF>
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions<LF>
HTTP sessions: 0 of 8<LF>
- WiFi -<LF>
Network state is active<LF>
WiFi module is connected to access point <LF>
Failed messages: pending 0, notready 0, noresp 0<LF>
WiFi firmware version 1.25beta0<LF>
WiFi MAC address f4:cf:a2:6f:bd:8f<LF>
WiFi Vcc 3.39, reset reason Power up<LF>
WiFi flash size 2097152, free heap 24568<LF>
WiFi IP address 255.255.255.255<LF>
WiFi signal strength 31dBm, mode 802.11n, reconnections 0, sleep mode modem<LF>
Clock register 00002002<LF>
Socket states: 0 0 0 0 0 0 0 0<LF>
=== CAN ===<LF>
Messages queued 642890, send timeouts 642888, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 16<LF>
ok<LF>

And M21:

M21<LF>
T0:22.3 /0.0 B:22.6 /0.0<LF>
SDHC card mounted in slot 0, capacity 7.95Gb<LF>
ok<LF>

It does not appear that there is any error with the SD card

I'm not sure if this is the appropriate category, or not, I can start a new thread elsewhere if its not.

I have a fairly new Duet 3 Mini 5+ (about a month old), and when I reset or power off the board I have to reboot it 3-4 times before I can get access to DWC. The board shows up as connected to my network, but going to the IP address returns an "unable to connect" message.

I am running RepRapFirmware 3.2.2 (2021-02-11), and Duet Wifi Server 1.25beta0 (if there is an updated wifi server ver I have not been able to find it easily)

Once things do get connected, the web interface works great, as does the printer generally.

Any ideas where to begin troubleshooting this? I don't even know if the issue is software, hardware, or my network.

@Veti Thank you for clarifying the warning. I have the V1.0 BLTouch, and it is currently setup for 5V.

The dozuki documentation calls out 5V, as does the BLTouch manufacturer. However, the RRF config tool gives this warning: "Make sure you change it to use +3.3V instead of +5V before you connect it or you risk damaging your board!" (this is specifically using the Duet 3 Mini 5+ in standalone mode where I get the warning).

On my old maestro the BLTouch was wired to 5V, so I'm not sure which voltage to use now. Thanks

I tried plugging it into my linux box, and it powers up, but the system doesn't acknowledge a device as plugged in.

I decided to just buy a Duet 3 Mini yesterday, which should be here Friday.

(I actually bought an SKR V1.4 first, but it's been 5+ years since I setup a Marlin based controller, and I'd forgotten how awful and complex that process is. I truly appreciate the ease of setting up an RRF board, and the extensive documentation you guys provide!)

((Is there any value in sending the dead board back to you for a postmortem?))

I've tried with a few different cables, and it just shows up as an unknown usb device with code 43 error. I'm guessing that means its pretty damn dead. I guess I could try on a linux machine just to confirm

I did attempt to use the erase jumper, but I can't tell if anything is happening. When I plug in the device with the jumper installed, it looks the same LED wise. I think this board is truly dead.

So the SD card appears to have also been fried. It does not register as being plugged in when using an external card reader on windows. That indicates that is likely other damage to the system.

I do get the green 3.3v led, and red 5v led when connecting to usb power only. the red DIAG and reset leds are both staying lit. When connecting to windows, the device shows up as "Unknown USB Device (Device Descriptor Request Failed". Attempts to install the Duet driver are unsuccessful.

I tried loading a new config + firmware on a new sd card, nothing seems to happen when connecting to USB power. Do I need the 12v power in order for the firmware to update from the SD card?

Long story short, I thought I would be fancy and try to replace my hot end umbilical cables (bltouch, part fan, hot end fan, y-end stop, and hot end thermistor) with a USBC cable connected via breakout boards. I got everything connected, turned on my printer, and there was a pop and a puff of smoke.

Close inspection of the board reveals a small hole in the WIZnet W5500 networking chip

Based on my investigation of the incident, it would appear that I grossly underestimated the complexity of USBC wiring. Through sheer bad luck, I wired the optical end stop (+3.3V) to A4, and the fan source (+12V) to A9 without realizing they are connected inside of the cable.

I have some questions:

• How might I go about troubleshooting the board to determine if this is the only damage done?

• If I managed to only damage the ethernet controller, could the board still be controlled via USB (either a PC or octoprint)?

• If I had access to the right facilities, could the ethernet controller chip be removed and replaced without having to do any SW/FW shenanigans?