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

    Duet Web Control 2.0.0-RC3 is ready

    Scheduled Pinned Locked Moved
    Duet Web Control
    50
    147
    27.4k
    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.
    • sigxcpuundefined
      sigxcpu
      last edited by

      Well, I spoke too soon. The issue came back, randomly. Updated to RC2, no change in behavior.
      DWC1 works, 2 fails to load assets. "ab" testing on a failing asset is successful so I think it is something related to sockets/memory/wifi firmware. There are lots of dups and retransmissions when it fails.

      dc42undefined 1 Reply Last reply Reply Quote 0
      • Jacotheronundefined
        Jacotheron
        last edited by

        Thank you very much for this newer version. It is responsive and amazing.

        A few things I have picked up while running this:

        • The Webcam URL was forgotten and had to be added again. Also the Webcam is now on its own page, I would have liked at least an option of showing a smaller webcam on the Print Status page.
        • Fans do not use their assigned names. My Fans are named with the C-parameter of M106, and this does not show up on the new DWC - not a big issue.

        It is amazing to have the statuses visible on all pages - temperatures, speeds etc.

        1 Reply Last reply Reply Quote 1
        • gnydickundefined
          gnydick
          last edited by gnydick

          Honestly, I feel the new version is worse in almost every way.

          • There are even less buttons that can be clicked by using the space bar
          • The buttons are much slower to respond, for example, clicking baby-step repeatedly is torture, you have to wait for the flash animation to finish before you can click it again
          • It's clunkier, even though it looks prettier; more clicks to do the same thing
          • The pop-up messages take you to the g-code console when you dismiss them

          I'm being brutally honest here, this is the perfect example of form over function. I tried explaining what was needed in the RFC and warned about this kind of stuff.

          The web interface should be fast, instant in response as possible given the web host, predictable, and impossible to click the wrong thing at the wrong time. It should have every single button clickable via the space bar as well as every clickable item tab-indexed.

          I predicted this would be a passion project about learning a new front end library, and I was right.

          Honestly, I suggest going back to square one.

          Start by creating a control interfaces like this was a manufacturing machine. Oh, wait, it is!

          Forget fancy menus. What do we do a lot of?

          Well, when tuning and tweaking

          • I want to have a g-code console and the config editor side-by-side
          • give me a small mechanical control there as well
          • a drop down with macros is enough, they don't need to be listed out
            • if you want to repeatedly run macros, then make a screen for that

          What we don't need

          • Graphs are pretty, but really, there's no reason for them to take up so much space
          • The status pane is also way too big. It would work just as well as a single line along the bottom or top

          I could go on and on, but I'm honestly so mad that I warned this would happen. Since updating to the latest firmware, I can't even revert to Web Control 1. Can I just re-upload it or will I have to clean up files on the SD Card?

          In reality, my suggestion a long time ago was to make each of these panes a widget you can drag 'n drop and resize to make your own screens. THAT would please everyone.

          wilrikerundefined 1 Reply Last reply Reply Quote 2
          • wilrikerundefined
            wilriker @gnydick
            last edited by wilriker

            @gnydick said in Duet Web Control 2.0.0-RC2 is ready:

            Since updating to the latest firmware, I can't even revert to Web Control 1. Can I just re-upload it or will I have to clean up files on the SD Card?

            M30 "/www/index.html"
            

            should get you back to DWC1. Of course with a reload after that.

            Manuel
            Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
            with probably always latest firmware/DWC (incl. betas or self-compiled)
            My Tool Collection

            gnydickundefined 1 Reply Last reply Reply Quote 0
            • dc42undefined
              dc42 administrators @sigxcpu
              last edited by dc42

              @sigxcpu said in Duet Web Control 2.0.0-RC2 is ready:

              Well, I spoke too soon. The issue came back, randomly. Updated to RC2, no change in behavior.
              DWC1 works, 2 fails to load assets. "ab" testing on a failing asset is successful so I think it is something related to sockets/memory/wifi firmware. There are lots of dups and retransmissions when it fails.

              Do you have a M551 password set? If so, try removing it. I've found that RC2 still doesn't work on my Kossel unless I remove the password.

              Btw you can temporarily revert to DWC 1 by entering <ip_address>/reprap.htm in your browser instead of just the IP address.

              Duet WiFi hardware designer and firmware engineer
              Please do not ask me for Duet support via PM or email, use the forum
              http://www.escher3d.com, https://miscsolutions.wordpress.com

              sigxcpuundefined 1 Reply Last reply Reply Quote 0
              • Dougal1957undefined
                Dougal1957
                last edited by

                Love the new layout however are you going to support drag and drop files again or am I doing something stupid?

                1 Reply Last reply Reply Quote 1
                • Jacotheronundefined
                  Jacotheron
                  last edited by

                  A possible bug I found while printing: The Layer Chart does not scale down.

                  I am still having issues where my first layers are not correctly picked up, so my 2nd layer typically shows as taking 10x longer than what it should have taken, will report in separate thread. Now after that first extremely long layer time, the chart is scaled up to fit that time, but long after it is no longer being displayed (for example after the 35th layer [this DWC shows 30 layer's time]), the Y still shows the scale for the longer time - this means my other layers basically produce a flat line at the bottom of the graph.

                  1 Reply Last reply Reply Quote 0
                  • sigxcpuundefined
                    sigxcpu @dc42
                    last edited by sigxcpu

                    @dc42 said in Duet Web Control 2.0.0-RC2 is ready:

                    @sigxcpu said in Duet Web Control 2.0.0-RC2 is ready:

                    Well, I spoke too soon. The issue came back, randomly. Updated to RC2, no change in behavior.
                    DWC1 works, 2 fails to load assets. "ab" testing on a failing asset is successful so I think it is something related to sockets/memory/wifi firmware. There are lots of dups and retransmissions when it fails.

                    Do you have a M551 password set? If so, try removing it. I've found that RC2 still doesn't work on my Kossel unless I remove the password.

                    Btw you can temporarily revert to DWC 1 by entering <ip_address>/reprap.htm in your browser instead of just the IP address.

                    I do have M551 Preprap but that is ignored. Before you asking me I've never noticed it is set. Always logged in as "ftp" with no password.
                    I know about /reprap.htm and that's what I'm using. I still don't understand why downloading assets in DWC2 fails randomly but DWC1 loads.
                    And, again, downloading them with ab returns successfully each and every request. Tried with 2 threads, let's try with 6 just like the browser does.
                    ...
                    ab testing works up to 3 connections. Everything higher than that breaks with connection refused. I think that is the problem with the UI download.
                    Testing it further, I see that it works reliably with 2 connections. 3 is hit and miss, >=4 always fails.

                    dc42undefined 1 Reply Last reply Reply Quote 0
                    • dc42undefined
                      dc42 administrators @sigxcpu
                      last edited by

                      @sigxcpu, I have come to the same conclusion that there are problems triggered by the increased number of concurrent connections that DWC2 uses. The problems are worse when there is a password set, but I get them occasionally even with no password. I've asked chrishamm if he can reduce the number of concurrent connections used. When I next work on DuetWiFiServer, I'll review the way that multiple concurrent connections are handled.

                      Duet WiFi hardware designer and firmware engineer
                      Please do not ask me for Duet support via PM or email, use the forum
                      http://www.escher3d.com, https://miscsolutions.wordpress.com

                      gnydickundefined 1 Reply Last reply Reply Quote 0
                      • wilrikerundefined
                        wilriker
                        last edited by wilriker

                        After using DWC2 a lot today, I have found some issues (some personal others breaking changes)

                        • I looks nice but wastes a lot of space especially on smaller resultion screens, e.g. there now are only 3 axis jog buttons per direction whereas there were 4 before. Changing CSS in dev tools to unhide one extra column of buttons use the space much more efficient without being too dense
                        • It misses some information, e.g. end times based on remaining time estimates, detailed versions currently installed, more details on sliced file being printed (not that important)
                        • Sometimes when switching away form job status and returning, the layer time graph stays empty until page is reloaded in browser

                        And my personal deal breaker: I cannot access DWC from remote anymore. I always get CORS request failed.
                        My setup for remote access:

                        • I have a small server in my network that can be accessed from anywhere via SSH.
                        • This server runs a nginx that has a host duet.localhost as a proxy pass setup and only listens on loopback interface.
                        • I then connect from my smartphone to my server via SSH and do a port forwarding -L8080:localhost:80.
                        • I access http://duet.localhost:8080 on my smartphone's browser and get DWC - and actually the page loads but then quits with the above error and does not load any status

                        EDIT: I just checked and duet.localhost:8080/reprap.htm works as always.

                        EDIT2: what I really do like is that the Macros widget has directories listed first now. 👍

                        Manuel
                        Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
                        with probably always latest firmware/DWC (incl. betas or self-compiled)
                        My Tool Collection

                        1 Reply Last reply Reply Quote 0
                        • Scachiundefined
                          Scachi
                          last edited by

                          For a file Filament usage is shown as:
                          2731.8999999999996
                          when I hover the mouse over this value this information shows up (slides down):
                          $display(props.item[header.value],1,'mm');

                          1 Reply Last reply Reply Quote 0
                          • gnydickundefined
                            gnydick @dc42
                            last edited by

                            @dc42 browsers have a limit of the number of concurrent connections to the same domain (IP address in this case).

                            All the more reason to simplify.

                            sigxcpuundefined 1 Reply Last reply Reply Quote 0
                            • gnydickundefined
                              gnydick @wilriker
                              last edited by

                              @wilriker didn't work 😞

                              1 Reply Last reply Reply Quote 0
                              • sigxcpuundefined
                                sigxcpu @gnydick
                                last edited by sigxcpu

                                @dc42 said in Duet Web Control 2.0.0-RC2 is ready:

                                @sigxcpu, I have come to the same conclusion that there are problems triggered by the increased number of concurrent connections that DWC2 uses. The problems are worse when there is a password set, but I get them occasionally even with no password. I've asked chrishamm if he can reduce the number of concurrent connections used. When I next work on DuetWiFiServer, I'll review the way that multiple concurrent connections are handled.

                                @gnydick said in [Duet Web Control 2.0.0-RC2 is ready]

                                @dc42 browsers have a limit of the number of concurrent connections to the same domain (IP address in this case).

                                All the more reason to simplify.

                                It is the other way around. Browsers have a too high limit of concurrent connections per domain.
                                Most of modern browsers have 6, which is too much compared to Duet's 4.

                                For example, I've recompiled the firmware with 6 HTTP acceptors instead of 4. It reloads DWC2 most of the times, with very few exceptions (i've had DWC1 open in another brower so that ate a connection).
                                Unfortunately, I am pretty sure that will kill the firmware during printing because increasing to 8 kills it in a boot loop.

                                The proper fix here should be to implement TCP connection backlogging, instead of refusing them. OK, we serve 4 simultaneout, but we can keep more intents in the backlog before accepting them. I don't know how much memory a backlogged connection eats.

                                I don't think users care too much about the UI load time, but we do care about it to load reliably.
                                Another fix is in DWC2 to compact all JS files in a single one and all CSS files in a single one.

                                Maybe there is a web tool to compact all these in a single "archive" whatever that is. I am a backend developer, therefore I'm not versed in all of these.

                                gnydickundefined dc42undefined 2 Replies Last reply Reply Quote 0
                                • gnydickundefined
                                  gnydick @sigxcpu
                                  last edited by

                                  @sigxcpu That's exactly my point. The web page code should be simplified. It shouldn't be all ajax-y for an embedded web host (with limited resources -- 4 concurrent connections) .

                                  There definitely are minifying tools fro JS and CSS.

                                  Ultimately, the interface is way too complex for the task. Read my rant up the thread.

                                  Danalundefined sigxcpuundefined 2 Replies Last reply Reply Quote 0
                                  • Danalundefined
                                    Danal @gnydick
                                    last edited by

                                    This post is deleted!
                                    1 Reply Last reply Reply Quote 0
                                    • brandonhundefined
                                      brandonh
                                      last edited by

                                      The new DWC looks good to me. Installed super-quick and looks more modern. I'm very happy to see X axis time labels for the heater diagram - it sounds mundane but this is really useful. Good work!

                                      Minor issues I saw:

                                      • The developer console shows an error upon page load:
                                        GET http://bigkossel.local/rr_download?name=0%3A%2Fsys%2Fdwc2defaults.json 404 (file not found)
                                      • G-code Jobs shows "No jobs" until loaded; would be good to show "loading"
                                      • Clicking the back button for Gcode Jobs after going to a folder takes me to the Settings tab and system folder, oddly.

                                      Suggestions:

                                      • When I'm in a printing Status view, the thing I care about are the estimated print times. These could have the font vastly larger. In this view, speed graphing would be AWESOME for debugging.
                                      1 Reply Last reply Reply Quote 0
                                      • sigxcpuundefined
                                        sigxcpu @gnydick
                                        last edited by

                                        @gnydick said in Duet Web Control 2.0.0-RC2 is ready:

                                        @sigxcpu That's exactly my point. The web page code should be simplified. It shouldn't be all ajax-y for an embedded web host (with limited resources -- 4 concurrent connections) .

                                        There definitely are minifying tools fro JS and CSS.

                                        Ultimately, the interface is way too complex for the task. Read my rant up the thread.

                                        I think "ajax-y" is the right way to do it here because after loading the assets, it just polls for status, which is thin.
                                        Initial loading is the issue here because it tries to load the assets like from a "normal" web server, with parallel connections up to 6.
                                        I see that there are 2 JS, 2 CSS and one "font" besides the index page.
                                        The 2+2 are loaded right after the index page but sometimes one of them fails so I would assume that the browser optimizes loading and initiates an asset download before the index loading is finished and connection reused.
                                        I am pretty sure that's the difference between:

                                        • it loads => index page connection is finished and reused, therefore there are 4 conns available
                                        • it fails to load => index page is lingering a bit more, so one of the 4 assets is failing to load

                                        Maybe another thing that will help is to enable caching because I always see all the things loading, never a 304.
                                        I don't know how complicated would be but HTTP/1.1 does have connection keep alive. Browser asks for it but the server reponds with Connection: close explicitly. Though this means up to 6 connections anyway.

                                        Overall, my grip is not with the complexity of the JS app, but it is obvious that the way it loads is completely incompatible with the embedded webserver.

                                        gnydickundefined 1 Reply Last reply Reply Quote 0
                                        • burtoogleundefined
                                          burtoogle
                                          last edited by

                                          Here's a suggestion that may possibly help. I developed an HTML/Javascript GUI for my PB-4 balancer (https://smartavionics.co.uk/pb4/pb4.html). It's based on jquery + bootstrap and the web server is a WiFi module with minimal resources. What I have done to speed up the initial load is make use of a javascript library called basket.js (https://addyosmani.com/basket.js/) that caches files in the browser local storage. So I just load the initial HTML and basket.js from the WiFi module and then everything else jquery, bootstrap, application code all gets loaded from the basket. Works extremely well.

                                          1 Reply Last reply Reply Quote 0
                                          • burtoogleundefined
                                            burtoogle
                                            last edited by

                                            Another thing, to actually do the data transfer (vibration data, spectra, commands, status, etc.) between the browser and the balancer HW, I use a websocket and that works very well also.

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