SBC Disconnects from Duet 3 Mini - Network error
-
@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.
-
@sputnikoc3d it looks like there may be a slight difference between your host name and duet name, Linux is case sensitive, you have Das-voron\das-voron both need to be case exact with Linux. But those permission errors are worrying, either your filesystem is in read-only mode, or that SD is on it's way out. Either way, your quickest repair is as @Phaedrux advised. SD Cards are sometimes bad straight out the packaging, prefer a SSD on USB 3 as a boot device personally but that takes a bit more to setup.
Just to confirm, you are running the following image correct?
-
@shauncro - confirming DuetPi image is being used.
When the machine was all default ...
config.g had "Duet 3"
raspi had duet-3 - iirc since no upper case and no spaces allowed - so stock FW and configurator or whatever - or somehow its been a mismatch from day one. Maybe thats been part of the issue - i dunno.
Whats everybody else doing ?
config.g duet-3
raspi - duet-3 ?Flashing a fresh image now on a new 64GB SanDisk Extreme 170 ms / 90 ms card - hope thats sufficient.
-
@sputnikoc3d Busy with a standalone install on my laser that is frustrating me.
Running Mini 5+ with SBC on Tevo Little Monster
Busy with 2 x 400W servo setup and Duet 3 + SBC on a custom build. -
Flashed new FW Full Duet Pi Image via Belena etcher - as before. 64 GB SanDisk Extreme blah ...
added the wpa_supplicant.conf
Setup guide says to use - http://duet3.local/
failed to connect to duet3.local - network error
failed to connect to duet check your connection ( DCS Not Started )
its showing me dwc - what that looks like when you lose wifi connectivity - it knows its there or was there but - flashes connecting
hdmi screen out from the Pi is dark - dead nada -
updating and upgrading ... guessing dcs not launched and Duet 3 not connecting to pi as its likely mismatched firmware ?
Duet 3 is 3.4 Beta?? whatever was last week
-
pi@duet3:~ $ sudo raspi-config pi@duet3:~ $ ls /dev/spidev* /dev/spidev0.0 /dev/spidev0.1 pi@duet3:~ $ -
The DuetPi when updated will be running 3.3 as it is on the stable branch by default. If you have manually updated the Duet3 to 3.4 beta I suggest you use the firmware update procedure described here to return it to 3.3.
https://duet3d.dozuki.com/Wiki/Installing_and_Updating_Firmware#Section_Duet_3_Mini_5_WiFi_Ethernet
https://github.com/Duet3D/RepRapFirmware/releases/tag/3.3
Afterwards, you should be able to establish connection between the pi and duet again. Then if you wish to try the beta again you'll need to use the unstable branch on the pi to get pre-release versions.
https://github.com/Duet3D/DuetSoftwareFramework/wiki/SBC-Setup-Guide#unstable-package-feed
