SBC Disconnects from Duet 3 Mini - Network error
-
@shauncro - but why should my wifi access point's functionality impact duet 3 mini and rpi 4 communicating over SPI cabled connection ?
-
Instruction state:
Once done, run
ls /dev/spidev*
and verify that /dev/spidev0.0 has been created.Mine is - /dev/spidev0.1
-
sudo /opt/dsf/bin/DuetWebServer info: Microsoft.Hosting.Lifetime[0] Now listening on: http://[::]:80 info: Microsoft.Hosting.Lifetime[0] Application started. Press Ctrl+C to shut down. info: Microsoft.Hosting.Lifetime[0] Hosting environment: Production info: Microsoft.Hosting.Lifetime[0] Content root path: /home/pi info: DuetWebServer.Services.ModelObserver[0] Connections to DuetControlServer established info: Microsoft.AspNetCore.Hosting.Diagnostics[1] Request starting HTTP/1.1 GET http://das-voron/machine - - info: Microsoft.AspNetCore.Cors.Infrastructure.CorsService[5] CORS policy execution failed. info: Microsoft.AspNetCore.Cors.Infrastructure.CorsService[6] Request origin http://das-voron does not have permission to access the resource. info: Microsoft.AspNetCore.Routing.EndpointMiddleware[0] Executing endpoint 'DuetWebServer.Controllers.WebSocketController.Get (DuetWebServer)' info: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[3] Route matched with {action = "Get", controller = "WebSocket"}. Executing controller action with signature System.Threading.Tasks.Task Get() on controller DuetWebServer.Controllers.WebSocketController (DuetWebServer). info: DuetWebServer.Controllers.WebSocketController[0] WebSocket connected from ::ffff:127.0.0.1:53116 info: Microsoft.AspNetCore.Hosting.Diagnostics[1] Request starting HTTP/1.1 GET http://das-voron/machine/directory/0:%2Fmacros application/json - info: Microsoft.AspNetCore.Routing.EndpointMiddleware[0] Executing endpoint 'DuetWebServer.Controllers.MachineController.GetFileList (DuetWebServer)' info: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[3] Route matched with {action = "GetFileList", controller = "Machine"}. Executing controller action with signature System.Threading.Tasks.Task`1[Microsoft.AspNetCore.Mvc.IActionResult] GetFileList(System.String) on controller DuetWebServer.Controllers.MachineController (DuetWebServer). info: Microsoft.AspNetCore.Hosting.Diagnostics[1] Request starting HTTP/1.1 GET http://das-voron/machine/directory/0:%2Fgcodes application/json - info: Microsoft.AspNetCore.Routing.EndpointMiddleware[0] Executing endpoint 'DuetWebServer.Controllers.MachineController.GetFileList (DuetWebServer)' info: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[3] Route matched with {action = "GetFileList", controller = "Machine"}. Executing controller action with signature System.Threading.Tasks.Task`1[Microsoft.AspNetCore.Mvc.IActionResult] GetFileList(System.String) on controller DuetWebServer.Controllers.MachineController (DuetWebServer). info: Microsoft.AspNetCore.Mvc.Infrastructure.ContentResultExecutor[1] Executing ContentResult with HTTP Response ContentType of application/json info: Microsoft.AspNetCore.Mvc.Infrastructure.ContentResultExecutor[1] Executing ContentResult with HTTP Response ContentType of application/json info: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[2] Executed action DuetWebServer.Controllers.MachineController.GetFileList (DuetWebServer) in 279.0607ms info: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[2] Executed action DuetWebServer.Controllers.MachineController.GetFileList (DuetWebServer) in 149.8088ms info: Microsoft.AspNetCore.Routing.EndpointMiddleware[1] Executed endpoint 'DuetWebServer.Controllers.MachineController.GetFileList (DuetWebServer)' info: Microsoft.AspNetCore.Routing.EndpointMiddleware[1] Executed endpoint 'DuetWebServer.Controllers.MachineController.GetFileList (DuetWebServer)' info: Microsoft.AspNetCore.Hosting.Diagnostics[2] Request finished HTTP/1.1 GET http://das-voron/machine/directory/0:%2Fmacros application/json - - 200 545 application/json 374.4218ms info: Microsoft.AspNetCore.Hosting.Diagnostics[2] Request finished HTTP/1.1 GET http://das-voron/machine/directory/0:%2Fgcodes application/json - - 200 297 application/json 214.1152ms -
@sputnikoc3d It might help if you post a picture of the browser interface you are using showing the errors you are getting. I assume that you are using the interface displayed on the screen you have attached to the rPi and it is on this screen that you are seeing errors?
It would also help if you explain exactly what it is you are doing and when you get the errors. So for instance, do you get an error if you boot the printer and just leave it alone? What happens if before you start a print you enter commands in the DWC (the web display console), do you get errors then? If you start a print and do not enter any commands after that does the print complete? Do you get any errors?
-
pi@das-voron:~ $ sudo /opt/dsf/bin/DuetControlServer -l debug Duet Control Server v3.4-b3 Written by Christian Hammacher for Duet3D Licensed under the terms of the GNU Public License Version 3 [info] Settings loaded [info] Environment initialized [info] Connection to Duet established [info] IPC socket created at /var/run/dsf/dcs.sock [debug] Updated key limits [debug] Assigning filament V2-SnoLabs PC-CF Dragonfly to extruder drive 0 [debug] Requesting update of key boards, seq 0 -> 103 [debug] Updated key boards [debug] Requesting update of key directories, seq 0 -> 0 [debug] Updated key directories [debug] Requesting update of key fans, seq 0 -> 6 [debug] Updated key fans [debug] Requesting update of key global, seq 0 -> 0 [debug] Updated key global [debug] Requesting update of key heat, seq 0 -> 10 [debug] Updated key heat [debug] Requesting update of key inputs, seq 0 -> 153 [debug] Updated key inputs [debug] Requesting update of key job, seq 0 -> 7 [debug] Updated key job [debug] Requesting update of key move, seq 0 -> 1338 [debug] Updated key move [debug] Requesting update of key network, seq 0 -> 3 [debug] Updated key network [debug] Requesting update of key scanner, seq 0 -> 1 [debug] Updated key scanner [debug] Requesting update of key sensors, seq 0 -> 58 [debug] Updated key sensors [debug] Requesting update of key spindles, seq 0 -> 0 [debug] Updated key spindles [debug] Requesting update of key state, seq 0 -> 1 [debug] Updated key state [debug] Requesting update of key tools, seq 0 -> 6 [debug] Updated key tools [debug] Requesting update of key volumes, seq 0 -> 0 [debug] Updated key volumes [debug] Requesting update of key move, seq 1338 -> 1339 [debug] Updated key move [debug] IPC#2: Got new UNIX connection, checking permissions... [debug] IPC#2: Granting full DSF permissions to external plugin [debug] IPC#2: Subscription processor registered in Patch mode [debug] IPC#3: Got new UNIX connection, checking permissions... [debug] IPC#3: Granting full DSF permissions to external plugin [debug] IPC#3: Command processor added [debug] IPC#3: Received command ResolvePath [debug] IPC#4: Got new UNIX connection, checking permissions... [debug] IPC#4: Granting full DSF permissions to external plugin [debug] IPC#4: Subscription processor registered in Patch mode [debug] IPC#5: Got new UNIX connection, checking permissions... [debug] IPC#5: Granting full DSF permissions to external plugin [debug] IPC#5: Command processor added [debug] IPC#5: Received command AddUserSession [debug] IPC#6: Got new UNIX connection, checking permissions... [debug] IPC#6: Granting full DSF permissions to external plugin [debug] IPC#6: Command processor added [debug] IPC#6: Received command ResolvePath [debug] IPC#7: Got new UNIX connection, checking permissions... [debug] IPC#7: Granting full DSF permissions to external plugin [debug] IPC#7: Command processor added [debug] IPC#7: Received command ResolvePath [debug] IPC#7: Connection closed [debug] IPC#6: Connection closed -
@gloomyandy said in SBC Disconnects from Duet 3 Mini - Network error:
@sputnikoc3d It might help if you post a picture of the browser interface you are using showing the errors you are getting. I assume that you are using the interface displayed on the screen you have attached to the rPi and it is on this screen that you are seeing errors?
Yes thats exactly correct. The default screen that the dcs/dsf etc ... gives me after Ive installed the fw on the sd card running in the Pi. it launches automatically - im not launching the DWC app im given - it jsut shows up on boot and reboot of the pi. Everyone is acting as if thats not the norm ???
Its just a chromium interface i imagine without browser "options"
It would also help if you explain exactly what it is you are doing and when you get the errors. So for instance, do you get an error if you boot the printer and just leave it alone? What happens if before you start a print you enter commands in the DWC (the web display console), do you get errors then? If you start a print and do not enter any commands after that does the print complete? Do you get any errors?
Tried to explain above ... just normal actions one would take while a print is underway ... maybe like babystepping on 1st layer / changing temp / changing fan % / Emergency stop / Pause / Resume
Those commands in the DWC window if wifi connection drops - will fail to execute and produce an error in console and in the bottom right corner of dwc screen : M11-whatever... failed : Network Error
-
@gloomyandy - the errors only seem to happen if the pi loses connection to the wifi. Which makes zero sense to me.
-
-
@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
