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

    Wifi 2.1beta6 from 3.5.0-rc.2/3 still disconnecting

    Scheduled Pinned Locked Moved Solved
    Beta Firmware
    10
    82
    4.3k
    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.
    • gloomyandyundefined
      gloomyandy @moth4017
      last edited by

      @moth4017 I'm not sure which WiFi module you are using, but on the skrpro there will be a separate set of wires that connects the module UART interface (used for flashing new versions of the WiFi firmware and for debug output) to the main board. That is the connection you need in place to see debug output from the board. If it is working and you run M552 s-1 followed by M522 S1 you should see a lot of debug output from the board.

      If a refresh of the web page allows it to work again, I'd say that probably means it it not a problem with the WiFi module, check the Web browser developer console for errors, it may be that DWC has crashed for some reason.

      moth4017undefined 1 Reply Last reply Reply Quote 0
      • moth4017undefined
        moth4017 @gloomyandy
        last edited by

        @gloomyandy
        M111

        The oldest data was removed. Continue...
         conn on socket 0 for local port 80
        Found responder
        Received 350 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 349 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 350 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 349 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 350 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 349 bytes
        Damon running
        Debugging On
        Fan & Heater Off
        12896
        5
        New conn on socket 0 for local port 80
        Found responder
        Received 350 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 360 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 361 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 337 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 349 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 359 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 360 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 336 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 350 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 349 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 350 bytes
        Serial port COM3 closed
        Serial port COM3 opened
        Serial port COM3 closed
        Serial port COM3 opened
        Serial port COM3 closed
        Serial port COM3 opened
        Serial port COM3 closed
        Serial port COM3 opened
        Serial port COM3 closed
        Serial port COM3 opened
        M552 s1 ok
        New conn on socket 0 for local port 80
        Found responder
        Received 349 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 350 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 349 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 350 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 349 bytes
        M552 s1 ok
        New conn on socket 0 for local port 80
        Found responder
        Received 350 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 349 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 350 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 349 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 350 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 349 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 350 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 349 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 350 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 349 bytes
        Damon running
        Debugging On
        Fan & Heater Off
        12917
        5
        New conn on socket 0 for local port 80
        Found responder
        Received 350 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 360 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 361 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 337 bytes
        New conn on socket 0 for local port 80
        Found responder
        Received 349 bytes
        M552 s-1 WiFi module stopped
        ok
        M552 s1 WiFi: 
        WiFi:  ets Jan  8 2013,rst cause:2, boot mode:(3,6)
        WiFi: 
        WiFi: load 0x4010f000, len 1392, room 16 
        WiFi: tail 0
        WiFi: chksum 0xd0
        WiFi: csum 0xd0
        WiFi: v00000000
        WiFi: ~ld
        ok
        WiFi: phy buf[107] is ff adc mode is ff
        WiFi: boot not set
        WiFi: ota1 not set
        WiFi: ota2 not set
        WiFi: V2
        WiFi: Mo
        WiFi: irf cal sector: 1019
        WiFi: freq trace enable 0
        WiFi: rf[112] 
        WiFi: SDK:3.0.2(824dc80)/Core:unspecified=0/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-17-g354887a/BearSSL:89454af
        WiFi: SocketServer.cpp(1576): Init completed
        WiFi: SocketServer.cpp(1577): 
        WiFi: 
        WiFi: DuetWiFiSocketServer version 1.27-04S-D ready
        WiFi: 
        WiFi module started
        ESP reported status change
        ESP reported status change
        WiFi: SocketServer.cpp(1222): Set hostname to octo
        WiFi: mode : sta(e8:68:e7:d9:f9:a3)
        WiFi: add if0
        Damon running
        Debugging On
        Fan & Heater Off
        12927
        5
        Serial port COM3 closed
        
        

        <

        gloomyandyundefined 1 Reply Last reply Reply Quote 0
        • gloomyandyundefined
          gloomyandy @moth4017
          last edited by

          @moth4017 I would have expected to see details of the WiFi server connecting to your access point in that output, did you remove that from what you posted?

          But anyway I don't see any signs of a problem with the WiFi module in that output.

          1 Reply Last reply Reply Quote 0
          • T3P3Tonyundefined T3P3Tony moved this topic from Beta Firmware
          • Chrissundefined
            Chriss @Chriss
            last edited by

            my loop in the config files was not the root unfortunately. The board is again not reachable. It lost the connection approximately 15 minutes after I started a print at a fresh booted printer. I will get an USB extension cable and connect via USB as soon as I have the cable.

            I understood that you guys want M122, something else? M11? M552 s-1 followed by M522 S1?

            Cheers, Chriss

            gloomyandyundefined 1 Reply Last reply Reply Quote 0
            • gloomyandyundefined
              gloomyandy @Chriss
              last edited by

              @Chriss I think ideally what we need is...

              1. Reboot the board
              2. Connect over USB
              3. Run M111 P14 S1
              4. Run m122
              5. Leave the USB connection open and wait for the WiFi disconnect
              6. Run M122
              7. run M552
              8. run M552 s-1
              9. run M552 s1
              10. capture all of the output from the above and post it here.

              @droftarts may have other suggestions.

              Chrissundefined 1 Reply Last reply Reply Quote 1
              • Chrissundefined
                Chriss @gloomyandy
                last edited by

                @gloomyandy

                Got it, so the current status does not help at all than. But I think that I can reproduce that now.
                My local hardware dealer was unable to provide a long enough USB cable. Amazon will bring me one tomorrow noon. Is there anything I need to know for the serial interface? (115200 8n1?)
                The only M575 I found is commented out:

                M575 P1 B115200 S1
                

                Cheers, Chriss

                gloomyandyundefined 1 Reply Last reply Reply Quote 0
                • gloomyandyundefined
                  gloomyandy @Chriss
                  last edited by

                  @Chriss If you haven't restarted the board since you lost the connection and it is still disconnected then running M122 might provide some information.

                  gloomyandyundefined 1 Reply Last reply Reply Quote 0
                  • gloomyandyundefined
                    gloomyandy @gloomyandy
                    last edited by

                    @gloomyandy If you are connecting over USB it is not really a "serial" connection in the normal way of things (so things like the baud rate, stop bits etc. don't really apply).

                    Chrissundefined 1 Reply Last reply Reply Quote 0
                    • Chrissundefined
                      Chriss @gloomyandy
                      last edited by

                      @gloomyandy

                      Well, at least the baud rate is needed. I will give it a try with 115200 or the half of it, let's see what I will get out of it.
                      The docu "https://docs.duet3d.com/en/How_to_guides/Getting_connected/Getting_connected_to_your_Duet" mentions "screen /dev/ttyACM0 115200", so it should be 115200 than.

                      The printer is still printing and I do not want to disturb it now. I will give the M122 a try as soon as the print is finished and I found a laptop to provide the output from that till my long cable arrives out of the Amazon. 😉

                      Cheers, Chriss

                      gloomyandyundefined 1 Reply Last reply Reply Quote 0
                      • gloomyandyundefined
                        gloomyandy @Chriss
                        last edited by

                        @Chriss The baud rate means nothing when connecting via USB to RRF.

                        Chrissundefined 1 Reply Last reply Reply Quote 0
                        • rechrtbundefined
                          rechrtb
                          last edited by

                          @Chriss Hello, I'm also looking into this issue. I have a few questions:

                          1. You mentioned that before 3.5.0rc2 + 2.1beta6, you also observed disconnects but reconnection always succeeded. Do you remember the RRF version and WiFi firmware version you were running then?

                          2. You mentioned that all Duet boards you have on RRF 3.5rc + WiFi firmware 2.1beta6 have this issue, but the 'others' are fine. Can you tell me what versions these other boards are on?

                          3. Can you downgrade maybe one of the problematic boards to RRF 3.5.0rc2 + WiFi firmware v1.27?
                            @moth4017 reports that this issue still occurs for the v1.27 firmware, just want to confirm if that also occurs for you.

                          4. I assume the RRF firmware you flashed on the boards are exactly the release binaries in the GitHub repo. Is this correct?

                          Chrissundefined 1 Reply Last reply Reply Quote 1
                          • Chrissundefined
                            Chriss @gloomyandy
                            last edited by

                            @gloomyandy That would be an surprise. I do not think that you can have a serial connection without that both sides use the same speed of the signals. But anyway, a topic for a talk later. 🙂

                            gloomyandyundefined 1 Reply Last reply Reply Quote 0
                            • gloomyandyundefined
                              gloomyandy @Chriss
                              last edited by

                              @Chriss It isn't a serial connection. It is a direct USB connection that presents itself to Windows as a com port, that's why most of the "normal" serial settings do not apply. Do a search for USB CDC, RRF implements a USB CDC device that basically ignores all of the baud rate and other settings.

                              Chrissundefined 1 Reply Last reply Reply Quote 0
                              • Chrissundefined
                                Chriss @rechrtb
                                last edited by

                                @rechrtb s

                                1. You mentioned that before 3.5.0rc2 + 2.1beta6, you also observed disconnects but reconnection always succeeded. Do you remember the RRF version and WiFi firmware version you were running then?

                                I'm not 100% sure, so please do not nail me down to it. But I think that it is 3.5.0RC2 I had before on it. But I saw that behaviour with the reconnects in 3.4 something already. It never bother me because the printer did always reconnect.
                                And it was only visible via the PanelDue, most of my printers do not have one.

                                1. You mentioned that all Duet boards you have on RRF 3.5rc + WiFi firmware 2.1beta6 have this issue, but the 'others' are fine. Can you tell me what versions these other boards are on?

                                My two other printers and my "on my desk test board" are on 3.4.6. And I have found a other printer which I did not upgraded to RC2, it is still 3.5.0rc2 and this one does not have the problem. And this is very much in use at the moment.

                                1. Can you downgrade maybe one of the problematic boards to RRF 3.5.0rc2 + WiFi firmware v1.27?

                                Sure, I can do that, but please let Amazon deliver the USB cable first. I want to get the logs from the board in the problematic state. Bring it back into it etc. I will do the downgrade right after that.

                                1. I assume the RRF firmware you flashed on the boards are exactly the release binaries in the GitHub repo. Is this correct?

                                Yes, all of them are downloaded from the duet githup repo, they are not self compiled.

                                Just to be clear here about the status and for unblocking my confusion:
                                1: RC3 with that problem, with PanelDue and printing (My Voron 2.4)
                                2: RC3 without problem, without PenalDue and not printing (VCast)
                                3: RC2 without problem, without PenalDue and printing (V0)
                                4: 3.4.7 without problem, without PenalDue and not printing (Workbench, VCore, Creality)

                                I had to make that clear for me too.. I thought that my V0, which is printing and does not have the problem, is on RC3 already. But it is RC2. The VCast is not fully working at the moment so it is not in use but powered on and does not have the problem.

                                Cheers, Chriss

                                rechrtbundefined 1 Reply Last reply Reply Quote 0
                                • Chrissundefined
                                  Chriss @gloomyandy
                                  last edited by

                                  @gloomyandy I wounder how that works than. What I see on linux is that the board behaves like any other serial device. Like a Arduino, a USB2Serial adapter etc. And what I do is connection with a terminal program like minicom to that port. So the "getty" (to stay here in the linux term) on the other side (on the board) must use the same speed as the terminal does. Both sides can not decode the signals via the serial interface otherwise.
                                  That is at least how I understand serial connections, that is the first time in more than 30 years that I have heard that the baud rated does not matter. Do not get me wrong, I believe you, I'm a bit surprised only and I would like to understand it because that is against 80% of my understanding how serial connections work. (Or the duet board has some magic to detect the baud rate from the terminal and use that speed.)

                                  Cheers, Chriss

                                  Chrissundefined gloomyandyundefined 2 Replies Last reply Reply Quote 0
                                  • Chrissundefined
                                    Chriss @Chriss
                                    last edited by Chriss

                                    I had a look at my WiFi access point. The AP told me that the "problematic board" is connected, the mac and the IP are correct. My workstation is connected to the AP via wire.
                                    Don't know whether that helps or not, but I think that I should share every observation.

                                    Cheers, Chriss

                                    gloomyandyundefined 1 Reply Last reply Reply Quote 0
                                    • gloomyandyundefined
                                      gloomyandy @Chriss
                                      last edited by

                                      @Chriss As I said there is no actual serial port hardware involved in the connection between your linux box and the RRF board. There is a software driver on the linux side that sits on top of the USB endpoint that basically makes the USB connection look like a serial port, the USB system transfers the bytes to the RRF board and on the RRF side there is again software that allow RRF to simply view the data in and out as a simple byte stream. That entire process is defined by the USB CDC standard I mentioned above. This standard does allow for the communication via USB of the baudrate and other settings but in the case of a software only stack as used by RRF this information is not needed and is ignored.

                                      That same standard is used to provide USB to UART devices. These present the same USB interface to your linux system, but they have an actual hardware UART interface that can then talk to other hardware UART devices. Some devices (like the original Arduinos) do not have built in USB hardware so instead they use a USB to UART converter (like the various FTDI chips or the CH340 and CP2102) and this in turn connects via an actual UART serial protocol to the UART built into the Arduino. In this case you do need to ensure that the baud rate and other settings match.

                                      But more advanced micro-controllers like the those used by the Duet boards or many of the the other 32bit chips like the rPi Pico and STM32 chips provide hardware that supports USB directly and in this case the extra complexity (and cost) of the the USB to UART converter is not needed.

                                      1 Reply Last reply Reply Quote 0
                                      • gloomyandyundefined
                                        gloomyandy @Chriss
                                        last edited by

                                        @Chriss When it is in this state (showing up on the access point as being connected), but DWC not working. What happens if you force a refresh of the DWC window? Does it then connect?

                                        What URL are you using to connect to your board? Are you using the IP address or are you using the .local name of your printer?

                                        Chrissundefined 1 Reply Last reply Reply Quote 0
                                        • Chrissundefined
                                          Chriss @gloomyandy
                                          last edited by

                                          @gloomyandy Hahaha.... we can start some levels deeper, my host does not get back the mac address. I see the arp requests (one collision domain) but I do never get an answer from the printer to inform my host which MAC access should be reached.

                                          b7ac76ea-95c5-4002-9498-e7d254e69d15-image.png

                                          So you can forget DNS and all of the other stuff.

                                          Cheers, Chriss

                                          Chrissundefined oliofundefined 2 Replies Last reply Reply Quote 0
                                          • Chrissundefined
                                            Chriss @Chriss
                                            last edited by

                                            @Chriss

                                            Here the screenshot from wireshark while I try to ping the printer:
                                            37307e69-50b0-4240-83b8-c507c6e46ca5-image.png

                                            Cheers, Chriss

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