Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Network Setup not working in SBC mode

    Scheduled Pinned Locked Moved
    Beta Firmware
    4
    8
    312
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • RevoAlexundefined
      RevoAlex
      last edited by

      Hi everyone,

      First of all, I apologize if I am in the wrong category - I am pretty new to this forum.

      I was wondering if I am just misunderstanding the M589 Code or doing something wrong.

      My setup consists of one MB6HCv1.01A Board with a Raspberry Pi 4 Model B. It's a fresh and minimal installation (v3.5.0-rc.3).

      Now I am trying to setup the Duet in AP-mode (and optionally wired via Ethernet) with the M589 command, as the documentation https://docs.duet3d.com/User_manual/Reference/Gcodes#m589-configure-access-point-parameters says it is possible - even with a SBC setup, right?

      I can connect via direct Ethernet connection and everything is working but as soon as I send the M589 or M552 or any other network related command the DWC always says:

      Error: M589: On-board firmware cannot process network-related commands when using an attached Single Board Computer
      

      allthough the documentation says "In SBC mode, sending this command makes a persistent change. It does not need to be added to dsf-config.g. It should NOT be included in config.g.".

      So... what am I doing wrong?

      Any help would be very much appreciated. Thanks a lot! šŸ™‚

      1 Reply Last reply Reply Quote 0
      • Phaedruxundefined
        Phaedrux Moderator
        last edited by

        Can you share the results of M122?

        Z-Bot CoreXY Build | Thingiverse Profile

        1 Reply Last reply Reply Quote 0
        • droftartsundefined
          droftarts administrators
          last edited by

          @chrishamm can M589 AP mode be used when in SBC mode, together with a normal Ethernet connection?

          @RevoAlex generally the RPi controls all networking, and AP mode would work on the RPi WiFi, not the Duets. It sounds like the SBC is not intercepting the command, which then generates that message. As @Phaedrux says, please post M122 so we can test this.

          Ian

          Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth

          chrishammundefined 1 Reply Last reply Reply Quote 0
          • RevoAlexundefined
            RevoAlex
            last edited by

            Yeah for sure! Here is the output:

            M122
            === Diagnostics ===
            RepRapFirmware for Duet 3 MB6HC version 3.5.0-rc.3 (2024-01-24 17:58:49) running on Duet 3 MB6HC v1.01 (SBC mode)
            Board ID: 0JD2M-999AL-D2PS0-6J9F8-3S46N-9NKB1
            Used output buffers: 1 of 40 (17 max)
            === RTOS ===
            Static ram: 155184
            Dynamic ram: 85188 of which 0 recycled
            Never used RAM 105620, free system stack 214 words
            Tasks: SBC(2,ready,0.7%,440) HEAT(3,nWait 6,0.0%,353) Move(4,nWait 6,0.0%,336) CanReceiv(6,nWait 1,0.0%,940) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,336) TMC(4,nWait 6,8.3%,56) MAIN(2,running,91.0%,444) IDLE(0,ready,0.0%,30), total 100.0%
            Owned mutexes: HTTP(MAIN)
            === Platform ===
            Last reset 00:03:54 ago, cause: software
            Last software reset at 2024-03-11 08:55, reason: StuckInSpinLoop, Gcodes spinning, available RAM 105620, slot 0
            Software reset code 0x4083 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0040080f BFAR 0x00000000 SP 0x2041b8b4 Task MAIN Freestk 1983 ok
            Stack: 0041a123 0041a13a 210f0000 00000000 00000000 00000000 00000000 00000000 20439a4c 00000003 00000002 00000002 0004dfe0 20439a94 000001c2 2042fdd0 00000000 43425320 722c3228 74696157 0000003a 00000000 00000000 00000000 00014cc4 00000000 00000000
            Error status: 0x00
            MCU temperature: min 29.5, current 30.7, max 30.8
            Supply voltage: min 23.3, current 23.4, max 23.4, under voltage events: 0, over voltage events: 0, power good: yes
            12V rail voltage: min 12.0, current 12.0, max 12.1, under voltage events: 0
            Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
            Events: 0 queued, 0 completed
            Driver 0: standstill, SG min n/a, mspos 8, reads 31176, writes 0 timeouts 0
            Driver 1: standstill, SG min n/a, mspos 8, reads 31176, writes 0 timeouts 0
            Driver 2: standstill, SG min n/a, mspos 8, reads 31176, writes 0 timeouts 0
            Driver 3: standstill, SG min n/a, mspos 8, reads 31176, writes 0 timeouts 0
            Driver 4: standstill, SG min n/a, mspos 8, reads 31176, writes 0 timeouts 0
            Driver 5: standstill, SG min n/a, mspos 8, reads 31175, writes 0 timeouts 0
            Date/time: 2024-03-11 09:00:12
            Slowest loop: 1.45ms; fastest: 0.08ms
            === Storage ===
            Free file entries: 20
            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, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, ebfmin 0.00, ebfmax 0.00
            no step interrupt scheduled
            Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
            === DDARing 0 ===
            Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
            === DDARing 1 ===
            Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
            === Heat ===
            Bed heaters -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
            === GCodes ===
            Movement locks held by null, 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
            File2 is idle in state(s) 0
            Queue2 is idle in state(s) 0
            Q0 segments left 0, axes/extruders owned 0x0000000
            Code queue 0 is empty
            Q1 segments left 0, axes/extruders owned 0x0000000
            Code queue 1 is empty
            === CAN ===
            Messages queued 614, received 0, lost 0, errs 576440, boc 0
            Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 614/0/0
            Tx timeouts 0,0,614,0,0,0 last cancelled message type 30 dest 127
            === SBC interface ===
            Transfer state: 5, failed transfers: 0, checksum errors: 0
            RX/TX seq numbers: 6092/6092
            SPI underruns 0, overruns 0
            State: 5, disconnects: 1, timeouts: 1 total, 1 by SBC, IAP RAM available 0x255cc
            Buffer RX/TX: 0/0-0, open files: 0
            === Duet Control Server ===
            Duet Control Server version 3.5.0-rc.3 (2024-01-26 12:37:35)
            Code buffer space: 4096
            Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
            Full transfers per second: 39.10, max time between full transfers: 40.7ms, max pin wait times: 28.3ms/0.9ms
            Codes per second: 0.01
            Maximum length of RX/TX data transfers: 4360/48
            
            1 Reply Last reply Reply Quote 0
            • chrishammundefined
              chrishamm administrators @droftarts
              last edited by

              @droftarts Yes but only with an existing wired connection.

              @RevoAlex Sounds like the DuetPiManagementPlugin is not started. Start it in Settings -> Plugins -> External and networking M-codes should work as expected.

              Duet software engineer

              RevoAlexundefined 1 Reply Last reply Reply Quote 0
              • RevoAlexundefined
                RevoAlex @chrishamm
                last edited by

                @chrishamm The services duetpluginservice as well as duetpluginservice-root are running and I can (de-)activate Plugins under Settings -> Plugins (e.g. the G-Code Viewer):

                $ sudo systemctl status duetpluginservice.service
                ā— duetpluginservice.service - Duet Plugin Service
                     Loaded: loaded (/lib/systemd/system/duetpluginservice.service; enabled; preset: enabled)
                     Active: active (running) since Mon 2024-03-11 15:12:35 CET; 7min ago
                   Main PID: 848 (DuetPluginServi)
                      Tasks: 9 (limit: 1585)
                        CPU: 1.312s
                     CGroup: /system.slice/duetpluginservice.service
                             └─848 /opt/dsf/bin/DuetPluginService
                
                Mar 11 15:12:34 revopitest systemd[1]: Starting duetpluginservice.service - Duet Plugin Service...
                Mar 11 15:12:34 revopitest DuetPluginService[848]: Duet Plugin Service v3.5.0-rc.3
                Mar 11 15:12:34 revopitest DuetPluginService[848]: Written by Christian Hammacher for Duet3D
                Mar 11 15:12:34 revopitest DuetPluginService[848]: Licensed under the terms of the GNU Public License Version 3
                Mar 11 15:12:35 revopitest DuetPluginService[848]: [info] DuetPluginService.Program: Settings loaded
                Mar 11 15:12:35 revopitest DuetPluginService[848]: [info] DuetPluginService.Program: Connection established
                Mar 11 15:12:35 revopitest systemd[1]: Started duetpluginservice.service - Duet Plugin Service.
                
                $ sudo systemctl status duetpluginservice-root.service 
                ā— duetpluginservice-root.service - Duet Plugin Service (root)
                     Loaded: loaded (/lib/systemd/system/duetpluginservice-root.service; enabled; preset: enabled)
                     Active: active (running) since Mon 2024-03-11 15:12:35 CET; 9min ago
                   Main PID: 847 (DuetPluginServi)
                      Tasks: 9 (limit: 1585)
                        CPU: 1.297s
                     CGroup: /system.slice/duetpluginservice-root.service
                             └─847 /opt/dsf/bin/DuetPluginService
                
                Mar 11 15:12:34 revopitest systemd[1]: Starting duetpluginservice-root.service - Duet Plugin Service (root)...
                Mar 11 15:12:34 revopitest DuetPluginService[847]: Duet Plugin Service v3.5.0-rc.3
                Mar 11 15:12:34 revopitest DuetPluginService[847]: Written by Christian Hammacher for Duet3D
                Mar 11 15:12:34 revopitest DuetPluginService[847]: Licensed under the terms of the GNU Public License Version 3
                Mar 11 15:12:35 revopitest DuetPluginService[847]: [info] DuetPluginService.Program: Settings loaded
                Mar 11 15:12:35 revopitest DuetPluginService[847]: [info] DuetPluginService.Program: Connection established
                Mar 11 15:12:35 revopitest systemd[1]: Started duetpluginservice-root.service - Duet Plugin Service (root).
                

                Some codes mentioned here DuetPiManagementPlugin are working: M21, M22, M550, M586, M999

                The other are not and are all throwing the same error message "On-board firmware cannot process network-related commands when using an attached Single Board Computer".

                1 Reply Last reply Reply Quote 0
                • RevoAlexundefined
                  RevoAlex
                  last edited by

                  For anyone having similar issues: I solved it with with a custom bash script and systemd service for now.

                  It checks for an existing connection on eth0 and if it cannot detect one a hotspot on wlan0 is created.

                  #!/bin/bash
                  
                  # ethernet_check.sh
                  # This script checks if the Ethernet cable is plugged into eth0 and manages the WiFi hotspot accordingly.
                  
                  while true; do
                      # Check if the Ethernet cable is connected to eth0
                      if ethtool eth0 | grep "Link detected: yes" > /dev/null; then
                          echo "Ethernet cable is plugged in. Disconnecting WiFi hotspot..."
                          nmcli device disconnect wlan0
                      else
                          # Check if the hotspot is already running to avoid trying to start it again
                          hotspot_status=$(nmcli con show --active | grep Hotspot)
                          if [ -z "$hotspot_status" ]; then
                              echo "No Ethernet cable detected and no active hotspot. Starting WiFi hotspot..."
                              nmcli device wifi hotspot ifname wlan0 ssid YourSSID password YourPassword
                          else
                              echo "Hotspot is already active."
                          fi
                      fi
                      
                      # Wait for 10 seconds before checking again
                      sleep 10
                  done
                  

                  Make it executable with

                  chmod +x /usr/local/bin/ethernet_check.sh
                  

                  Create a service to start it with the Raspberry Pi.

                  [Unit]
                  Description=Ethernet Hotspot Check Service
                  After=multi-user.target
                  
                  [Service]
                  Type=simple
                  ExecStart=/usr/local/bin/ethernet_check.sh
                  Restart=on-abort
                  
                  [Install]
                  WantedBy=multi-user.target
                  

                  Reload systemd:

                  sudo systemctl daemon-reload
                  

                  and enable the service to start on boot:

                  sudo systemctl enable ethernet_check.service
                  

                  Then start the service or reboot.

                  chrishammundefined 1 Reply Last reply Reply Quote 1
                  • chrishammundefined
                    chrishamm administrators @RevoAlex
                    last edited by

                    @RevoAlex I can't reproduce the problem with 3.4.6 or 3.5.0-rc.3+. M589 seems to work in both versions.

                    You also need to check duetpluginservice-root if you want to check the execution state of DuetPiManagementPlugin since it requires root privileges to modify system configs.

                    Duet software engineer

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Unless otherwise noted, all forum content is licensed under CC-BY-SA