SBC Disconnects from Duet 3 Mini - Network error
-
-
@sputnikoc3d The majority of people probably do not have a displayed connected to the rPi like you do, so may not be familiar with how you are running things.
As I asked above, if you just boot the system and leave it do you ever get errors on the display? If you start a print and leave it (so no interaction via the web interface), do you get errors?
One of the reasons that folks are confused is that if you are running a DWC on the rPi it should not be connected via WiFi to the rPi it would normally be connected directly internally on the device. Is you rPi connected to your network by WiFi? If so can you connect to the rPi over WiFi from another device? If you do that do you get the same errors?
Note that you may have multiple problems here, your m122 is showing errors in the link between the rPi and the Duet board, but it sounds like you may also be having problems with the connection between the rPi and the browser displaying the DWC UI. Unfortunately the error messages displayed by DWC in both situations can be similar and this may be causing some of the confusion, again a good reason to post a picture of the actual errors you are getting.
From the picture you have posted it looks like you may have multiple tabs open in the browser on the rPi. For now it may help if you avoid doing that as switching between the tabs may be causing a refresh of DWC (which may cause it to reconnect).
You might also want to check your rPi syslog file to see if the rPi is reporting any network errors. The screenshot you posted includes the message "wlan0: Expired IPv4LL", which may indicate a possible problem in that area. It may be that if/when your rPi loses the network connection it is resetting the network stack which is also causing local (internal to the rPi) connections to drop/reconnect.
-
I dont know how to screen cap on a pi - sorry man. I had the multiple browsers open to read the things that Phadrux asked me to try ... I need the duet documentation open somewhere to execute - Im far from nix savvy. When Im printing the only job function Im asking of the Pi4 8 MB system is to do whatever Duet is asking it to do ... nothing more - no web browsing email youtube vids or any such nonsense. Its just acting as the DCS/DWC print controller only. People are running full windows 10 installs on these things and 4k youtube videos. I cannot be over taxing this system with just the Duet hooked to it and serving DWC. The WHOLE reason I went Duet3 and SBC was to have an HDMI out and BT kb and Mouse on the printer to control it from THE PRINTER itself.
If I just boot the sytem and connect to it via wifi with my intel NUC and launch a DWC screen in chrome browser on my NUC to remotely control the printer like 99.9% of people do with duet wifis - yes I will still get network errrs that shows up.
If I just boot it and let it sit, and do nothing it will get network connections errors in the rpi DCS/DWC - just the typical ... lost connection / reconnecting network error - because Im NOT doing anything.
If I just boot it up and run a print job and get lucky to not have to alter ANYTHING about my slice [ rarely ever ] it will always complete the print - but console will have random wifi connection related errors Connection Lost / Reconnected / Network Error. I wont get the dwc button related gcode error messages because - well Im not executing any.
If I just boot and run a job and lose wifi connectivity and I need to hit Estop on a print and wifi connect is LOST - it wont execute the estop commands and will keep printing until I power off ... The only error is ...
whatever the GCODE command the dwc button represents ... GCODE Failed : Network Error - there no more or less info provided.It may be that if/when your rPi loses the network connection it is resetting the network stack which is also causing local (internal to the rPi) connections to drop/reconnect.sounds like a very logical assessment if that is indeed how things work on the pi.
-
What a freakin mess ... now this - this is new. I tried starting and stopping the DCS and DWS as per the instructions in the article @Phaedrux linked me. Now its completely hosed.
This is what I see logged into DWC remotely from a wifi connected - intel nuc in a chrome browser - can screen cap here.
Just tried to run a print and it failed ... start.g executed improperly and I had no control had to power it off ...
-
Failed to get file info for SMA-300.gcode Operation failed (Reason: UnauthorizedAccessException in GetFileInfo: Access to the path '/opt/dsf/sd/gcodes/SMA-300.gcode' is denied.) -
@sputnikoc3d not sure to be honest, haven't been able to replicate the issue he's having. But it sounds similar to yours, like any connection drop forces a reboot.
-
@sputnikoc3d tried replacing the SD card on the pi?
Lets just get one thing straight....
You don't own a Delta! It's true, you don't!
It owns you!
-
@sputnikoc3d As I said above it looks like you may have multiple problems here. The errors about headers and the spi connection being reset are almost certainly being caused by problems with the connection between the rPi and the Duet 3 Mini. As to your network errors, I've not been able to reproduce them (I also have a hdmi display connected to my rPi), I've even tried turning off my WiFi network, but did not get any sort of network error reported by dwc.
I'm pretty much out of ideas. But just want to check a few things....
What is the rPi image that you are using? Did you install the standard DuetPi image that Duet3D supply?
If you connect to your rPi via ssh from another system what do you get if you enter the following:
echo $(hostname)
ping $(hostname)It looks like you have changed the name of your system (the default is normally duet3 I think, yours displays Das-Voron), what did you do to change the name?
Have you made any other changes to the standard DuetPi install. Your desktop display seems different to mine (I don't have the rPi top bar with the time and network status icons in it), but that may be because I started with a different base image.
-
@gloomyandy He's not running the headless install, he's running the full install just with the desktop visible, so the screen isn't maximized. That's raspian in background, the task bar with the icons. But you raise something interesting there as well, host name and duet name have to match, so that could be a reason for the network errors.
-
@sputnikoc3d check that you have enabled the read only file system
Ctrl+alt+t
Sudo raspi-configOption 4 > performance options
P3 overlay filesystem - Enable\Disable read only file system
Could possibly be the permission errors you getting
Lets just get one thing straight....
You don't own a Delta! It's true, you don't!
It owns you!
-
@shauncro Are you suggesting that the read only file system should be enabled?
-
@shauncro said in SBC Disconnects from Duet 3 Mini - Network error:
@sputnikoc3d tried replacing the SD card on the pi?
No I have not ... hoping not to but have extras here if need be.
-
Thank you for your continued assistance ...
I did change the machine name - to match in config.g and via the rpi -config interface. I was having the initial dwc error issues before I did that for days though. It may have worsened the problems but was not the causation. Prior to that it was stock install.
I used the full raspian version suggested by duet off their website. DuetPi with GUI.... cuz Im not a ssh/nix/putty/command line kinda guy.
config.g [ M550 P"Das-Voron" ; set printer name ]
from the pi's desktop - in terminal I did the following. Im not doing vnc or ssh as of yet, thought the gui install would allow me to not set all that putty and ssh/vnc etc up and learn yet another set of tools and interfaces.
pi@das-voron:~ $ echo $(hostname) das-voron pi@das-voron:~ $ ping $(hostname) PING das-voron (127.0.1.1) 56(84) bytes of data. 64 bytes from das-voron (127.0.1.1): icmp_seq=1 ttl=64 time=0.113 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=2 ttl=64 time=0.052 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=3 ttl=64 time=0.056 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=4 ttl=64 time=0.068 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=5 ttl=64 time=0.086 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=6 ttl=64 time=0.055 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=7 ttl=64 time=0.070 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=8 ttl=64 time=0.056 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=9 ttl=64 time=0.101 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=10 ttl=64 time=0.084 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=11 ttl=64 time=0.088 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=12 ttl=64 time=0.047 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=13 ttl=64 time=0.059 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=14 ttl=64 time=0.054 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=15 ttl=64 time=0.055 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=16 ttl=64 time=0.061 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=17 ttl=64 time=0.076 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=18 ttl=64 time=0.058 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=19 ttl=64 time=0.078 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=20 ttl=64 time=0.096 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=21 ttl=64 time=0.054 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=22 ttl=64 time=0.054 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=23 ttl=64 time=0.055 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=24 ttl=64 time=0.065 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=25 ttl=64 time=0.058 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=26 ttl=64 time=0.052 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=27 ttl=64 time=0.096 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=28 ttl=64 time=0.092 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=29 ttl=64 time=0.097 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=30 ttl=64 time=0.100 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=31 ttl=64 time=0.105 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=32 ttl=64 time=0.089 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=33 ttl=64 time=0.102 ms 64 bytes from das-voron (127.0.1.1): icmp_seq=34 ttl=64 time=0.091 ms ^C --- das-voron ping statistics --- 34 packets transmitted, 34 received, 0% packet loss, time 352ms rtt min/avg/max/mdev = 0.047/0.074/0.113/0.020 ms -
@shauncro said in SBC Disconnects from Duet 3 Mini - Network error:
@sputnikoc3d check that you have enabled the read only file system
Ctrl+alt+t
Sudo raspi-configOption 4 > performance options
P3 overlay filesystem - Enable\Disable read only file system
Could possibly be the permission errors you getting
I just followed these steps ... Im desperate - so did so blindly lol and at this point feel - like not much to lose.
From the Console of my intel NUC connected to Das Voron/das-voron via wifi and using DWC
9/11/2021, 9:08:00 AM Failed to get file info for SMA-300.gcode Operation failed (Reason: UnauthorizedAccessException in GetFileInfo: Access to the path '/opt/dsf/sd/gcodes/SMA-300.gcode' is denied.) 9/11/2021, 9:06:24 AM Warning: Discarded std reply src=121 RID=20 exp 21 "" 9/11/2021, 9:05:48 AM Warning: SPI connection has been reset 9/11/2021, 9:05:48 AM Connection to Duet established 9/11/2021, 9:05:47 AM Warning: Lost connection to Duet (Board is not available (no header)) -
Definitely try a fresh SD card that is as fast and high quality as possible.
Backup your current config set from
/opt/dsf/sdDownload a fresh copy of Duet Pi with GUI and burn it to the new SD card.
Boot up and do a sudo apt update && sudo apt full-upgrade
Restore your config.g, etc from your backup.
See if we still get the errors.
-
Ok will do but ... damn. Thats a good bit of nix tomfoolery ...
I may need some specific guidance - step by step ... not sudo guru.
-
Well you've got the GUI, so backing up the files you can do with the file manager.
And the updates are usually prompted on first boot of duet pi anyway, so probably won't even have to send a terminal command.
That's really all the tomfoolery involved.
-
@phaedrux - need to understand why ... I now need a new SD card. I will buy one and am as I should have spares ... but ...
I want to be able to control this printer via the Pi - as if I lived on a deserted island and all I had was electricity ... and config updates arrived via a sd card in a bottle. No wifi - no internet - no ancillary BS ... just the SBC and the Duet ... talking to eachother over the 40 pin cable / spi.
I dont want to have to rely on the pi having wifi access in order to control my printer - period. If i get wifi sometimes for misc stuff fine .. but I want to be able to hit the estop button in the dwc and the damn printer STOP - not be dependent if this thing is effectively routing tcpip packet thru some bug ridden interface / stack ...
Is my understanding of how the sbc is to control the duet3 via spi / dicrect connection - not reliant on wifi or ethernet routing and connectivity - errant? Or is the design and fw reliant on networking to the internet in order to function as intend ?
-
Yes that's fine. I use my duet+pi with a direct connect touch display as well. Should be no problem with no network connectivity in that situation.
The reason I suggest trying a new SD card is that perhaps yours is failing and a fresh install is a good way to troubleshoot anyway.
-
@sputnikoc3d I totally agree. If you're connected via localhost, it should not look for the network at all. The whole point of a loopback address is to be able to test and run software without sending data over the network. That's literally what loopback means. Loop to the physical interface, and right back again.
