Connecting to DWC v3.3.0 via wifi

[michaelr123]

Hello there,

So in my adventures to update to latest firmware, I've got my system back up and running after reconfiguring everything. My last struggle is with sketchy wifi signal from my SBC (Pi 3) to my wifi network. I used to be able to leave my computer connected to both ethernet and wifi and just make sure my desktop was on the wifi to connect DWC, but now I've found that if ethernet is on at all I am unable to stay connected to DWC. If I disable my ethernet connection I can then connect to DWC. I'd really like to be able to stay connected to ethernet for gaming while my printer is running, but I want to be able to upload gcode files from this workstation as well.

Has anyone else run into a similar situation with v3.3.0?

Thanks,
-Michael

[Phaedrux]

That seems more like a router thing than a RRF 3.3 thing. What firmware version were you running before? Have you tried going back to see if the behaviour with the ethernet goes away?

[michaelr123]

@phaedrux

I think I was on 3.1-ish?

In general the board is now just super sketchy, often times on start up the fans never start up, and it says "failed to enable endstops." I'm leaving the pi connected to a screen to help troubleshoot, but I'm often times restarting / power cycling the system a few times before it finally boots properly.

If all of that goes well, and I home the build, this is usually where it disconnects. I've checked my router, and the pi is actually not connected to the router anymore.

Any ideas?

[Phaedrux]

Try a USB wifi dongle with an external antena on the pi?

Can you post the results of M122?

You can try enabling some additional monitoring on the Pi to see if its anything duet related that is happening

https://duet3d.dozuki.com/Wiki/Getting_Started_With_Duet_3#Section_Monitoring_optional

[michaelr123]

@phaedrux

Thanks, I'll try this later today. Its odd because this exact set of hardware worked great before I messed up and reset everything (reflashed raspbian - duet version, and rrf 3.3.0 manually onto the duet 3 board).

Would going to a raspberry Pi 4 help at all?

[michaelr123]

@michaelr123 M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.3 (2021-06-15 21:45:47) running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956BA-NA3TN-6JKF0-3S86T-1VBLS
Used output buffers: 1 of 40 (10 max)
=== RTOS ===
Static ram: 150904
Dynamic ram: 61460 of which 0 recycled
Never used RAM 141828, free system stack 219 words
Tasks: SBC(ready,6.5%,318) HEAT(delaying,0.0%,345) Move(notifyWait,0.0%,352) CanReceiv(notifyWait,0.0%,944) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,333) TMC(notifyWait,7.0%,93) MAIN(running,86.2%,1250) IDLE(ready,0.2%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:00:50 ago, cause: power up
Last software reset at 2021-09-16 20:20, reason: User, none spinning, available RAM 143092, slot 0
Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Step timer max interval 128
MCU temperature: min 16.6, current 26.9, max 27.0
Supply voltage: min 23.9, current 23.9, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.0, max 12.0, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Driver 0: position 0, standstill, reads 20201, writes 14 timeouts 0, SG min/max 0/0
Driver 1: position 0, standstill, reads 20201, writes 14 timeouts 0, SG min/max 0/0
Driver 2: position 0, standstill, reads 20201, writes 14 timeouts 0, SG min/max 0/0
Driver 3: position 0, standstill, reads 20201, writes 14 timeouts 0, SG min/max 0/0
Driver 4: position 0, standstill, reads 20204, writes 11 timeouts 0, SG min/max 0/0
Driver 5: position 0, standstill, reads 20204, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2021-09-17 18:24:18
Slowest loop: 0.45ms; fastest: 0.05ms
=== 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, 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 = 0 -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 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 358, received 0, lost 0, longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 49 (min 49), ts 253/0/0
Tx timeouts 0,0,252,0,0,104 last cancelled message type 4514 dest 127

=== SBC interface ===
State: 4, failed transfers: 1, checksum errors: 0
Last transfer: 1ms ago
RX/TX seq numbers: 678/678
SPI underruns 0, overruns 0
Disconnects: 1, timeouts: 1, IAP RAM available 0x2c83c
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.3.0
Code buffer space: 4096
Configured SPI speed: 8000000Hz
Full transfers per second: 0.01, max wait times: 9.2ms/0.0ms
Codes per second: 0.00
Maximum length of RX/TX data transfers: 2852/84

[ShaunCro]

Sounds like an IP address conflict, try assigning you nic a static IP in the upper part of the IP range.

[michaelr123]

@shauncro It started up just fine this time BTW

• I just made the IP address for the printer static, we'll see if that helps?

[michaelr123]

This post is deleted!

[michaelr123]

@michaelr123 - Update: ran a job and it went great, still connected to ethernet through desktop and everything's running great!

[michaelr123]

@michaelr123

Interesting note, with the static IP I have a good connection, but sometimes I need to emergency stop the system before everything will fire up. Its not to much of a big deal, any thoughts on why I need to do this?

[Phaedrux]

@michaelr123 said in Connecting to DWC v3.3.0 via wifi:

Would going to a raspberry Pi 4 help at all?

Should be ok on a pi3, but the pi4 definitely has a lot more breathing room. It might be a useful way to see if it's a hardware problem with
the Pi itself, which does occasionally happen.