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

    Ideas for a successor of DWC

    Scheduled Pinned Locked Moved
    Duet Web Control wishlist
    16
    40
    4.6k
    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.
    • chrishammundefined
      chrishamm administrators
      last edited by chrishamm

      Hello everyone,

      I've started thinking about a potential successor of DWC and I'd like to hear your thoughts on a few things. Please do not use this thread for single feature requests though, there is already a wishlist for this purpose on this forum.

      As some of you may have noticed I rewrote the config tool using VueJS and Bootstrap-Vue (BS4) and I'd like to use VueJS for the next generation of DWC, too. It allows the usage of reusable components and I expect it will give us a big performance, reliability, and flexibility boost compared to the current version.

      As part of this change, I'd like to restructure the web interface and make use of HTML5 history so that navigating back and forth will be supported just like in the new config tool but even to a broader extend. By that I mean I'd like to introduce a more hierarchical structure which will allow better abstraction and increased usability for people who are still new to 3D printing. Yet I am not sure about a few things in particular:

      • What navigation structure would you propose? My only rough idea now is to split up the UI into four main categories like Control, Job, Files and Settings which would have more subcategories
      • Would it make sense to develop entirely different layouts for different screen sizes? If yes, what should they (roughly) look like?
      • Do we always need to show the info row as is the case at the moment? What could an alternative look like?
      • If you are familiar with CNC/Laser machines, which features are you missing on the web interface that are not alreay part of the wishlist?
      • Where do you see other shortcomings of the current web interface?
      • What other questions am I missing here that you would ask?

      At the moment DWC provides only one big layout that is more or less responsive, yet the entire content is rather fixed and it can only be adjusted for different screen sizes to a limited amount. Yet this is nothing I can easily change at the moment because unfortunately a lot of the JS code in the backend relies on this. That is why I'd really like to rewrite it with VueJS and make extended use of reusable components.

      The next question is the UI framework. Even though I mentioned Bootstrap 4 before, I don't think I will use it for a fullscreen web app like Duet Web Control again. Instead I have been considering to use Element UI which provides a broad catalog of different standard components and good integration with VueJS. Besides it does not need many extra libraries, which will allow me to keep the size of DWC relatively small. I'd like to keep an eye on the size in the future, too, because I do not want to import 1000 different libraries for every little thing. Yet this framework has a couple of downsides like rather bad theming support, the usage of pixels instead of em sizes and a rather bad documentation. So if you know any better alternative, feel free to let me know. In other interest I will be aiming to use vue-grid-layout to achieve dynamic content mapping. Unfortunately Muuri does not seem to allow controls to be resized.

      Please let's do some brainstorming here - this is your chance to share your toughts on the next-generation web interface so I am really looking forward to hearing your opinions and ideas ๐Ÿ™‚

      Duet software engineer

      gnydickundefined 1 Reply Last reply Reply Quote 1
      • crynoolundefined
        crynool
        last edited by

        Hi Chris,

        I'd like to see i.e. the GCODE Console output always visible on screen, so I do not need to switch between the several sections back and forth again and again when experimenting.

        Other than that, I'd like to have instead if a single line input for gcode some sort of 'copy and paste' multiple line edit window (again ... when experimenting...)

        On top, some sort of customizing aspect when using pre-defined interactions, like 'Run Mesh ...'

        I know, last points belong more into the 'feature request' section, but ... ๐Ÿ™‚

        1 Reply Last reply Reply Quote 4
        • gnydickundefined
          gnydick @chrishamm
          last edited by

          @chrishamm Here are my extremely thoroughly thought out ideas.

          In terms of UX, the best thing would be a blank slate. Let me explain...

          Each button is just a g-code call. There's really no state that is tracked in the page, it's polling all of the time. It would be rather doable to create a palette of controls and readouts that are arrangeable and resizable. Obviously, some things are more than just a button, like the tool manager, but that too should be composable.

          One of the things I hate is the constant refreshing causing me to accidentally click the wrong macro, machine control, system editor file, etc.

          I would also include refresh-on-poll and no-refresh-on-poll divs. The refreshing ones should manage scroll better and not keep resetting position with each reload.

          I think if you do those two things, you'll have something that will never need fixing.

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

            Thanks for your comments!

            @crynool said in Ideas for a successor of DWC:

            I'd like to see i.e. the GCODE Console output always visible on screen, so I do not need to switch between the several sections back and forth again and again when experimenting.

            Other than that, I'd like to have instead if a single line input for gcode some sort of 'copy and paste' multiple line edit window (again ... when experimenting...)

            Interesting ideas about the G-code input. I'll keep them in mind.

            @crynool said in Ideas for a successor of DWC:
            On top, some sort of customizing aspect when using pre-defined interactions, like 'Run Mesh ...'

            You will be able to customise the UI to this extend anyway, so I don't think this is an extra requirement.

            @gnydick said in Ideas for a successor of DWC:

            In terms of UX, the best thing would be a blank slate.

            I agree we need a flexible slate so users will be able to rearrange things, which is why I am aiming to use vue-grid-layout (see above). But I disagree that it needs to be empty because it's always good to provide some reasonable defaults.

            @gnydick said in Ideas for a successor of DWC:

            Each button is just a g-code call.

            This may be true at the moment but it will change once we have the new object model 100% ready. There is no way we could use two-way bindings though, so we'll need some kind of new async actions/mutators anyway where Vuex comes into play.

            @gnydick said in Ideas for a successor of DWC:

            There's really no state that is tracked in the page, it's polling all of the time. It would be rather doable to create a palette of controls and readouts that are arrangeable and resizable. Obviously, some things are more than just a button, like the tool manager, but that too should be composable.

            Well, at the moment there is no global state and not having it there creates a whole lot of different problems that I would like to overcome. Once it is available to every component, flexibility will be no longer an issue. In addition the polling mechanism is likely to be replaced by another approach for the Duet 3 so I want to be able to track mutations in the future.

            @gnydick said in Ideas for a successor of DWC:

            One of the things I hate is the constant refreshing causing me to accidentally click the wrong macro, machine control, system editor file, etc.
            I would also include refresh-on-poll and no-refresh-on-poll divs. The refreshing ones should manage scroll better and not keep resetting position with each reload.

            What exactly do you mean by this, things like the web interface jumping to the top? As I said in other threads I have never observed this problem on my own setups but I did hear multiple reports about it. I am quite sure it is related to the "Always show info and main area" option on the Settings which I did not really want to introduce but which was a mandatory requirement I had to fulfill. I think I will omit this feture in the next version.

            @gnydick said in Ideas for a successor of DWC:

            I think if you do those two things, you'll have something that will never need fixing.

            There is no such thing as perfect code, though ๐Ÿ˜„

            Duet software engineer

            gnydickundefined 1 Reply Last reply Reply Quote 0
            • Vetiundefined
              Veti
              last edited by

              you will never have a layout that everyone will be happy with.
              what about making the elements movable/re-sizable and storing their positioning using HTML5 Web Storage?

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

                @veti said in Ideas for a successor of DWC:

                you will never have a layout that everyone will be happy with.
                what about making the elements movable/re-sizable and storing their positioning using HTML5 Web Storage?

                Sure, that's why it will be a key feature of the next version to allow users to customize things as they need it. But of course we need to clarify which things people will need in the first place.

                I'd like to store the layout on the Duet itself but I am still unsure if it made sense to maintain different layouts for different screen sizes (xs, sm, md, lg, xl).

                Duet software engineer

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

                  @chrishamm

                  Yes, I didn't mean a true "blank" slate, default views would obviously be a good idea.

                  By never needing to fix, I meant, the layout, not the actual code ;).

                  But honestly, it sounds like you're overcomplicating things. Unless you're planning on reinventing how g-code works and the completely serial nature of it's communications, I don't see the point in what you're proposing.

                  Frameworks and other technology libraries, methodologies, approaches, tools, etc. are all very shiney, but none of them are silver bullets.

                  I understand passion projects, but I feel you're risking passion over product.

                  I think we'd all rather see a UI that works as we want before it gets completely redesigned from the ground up.

                  Just the mention of Duet 3 as a motivation for any of this kinda pisses me off because 2 isn't finished and while the current UI is leaps and bounds beyond the traditional printer, the UX is actually not that different in terms of how many clicks and menus you have to go through to do things until you eventually macro-ize everything, which is a long iterative process in and of itself.

                  You've come a long way in incorporating the administration of the printer in a central place, no Arduino studio needed, no compiling, no some stuff on the scroll wheel, other stuff in octoprint, etc., that's awesome, but KISS and get us happy before chasing the shiney.

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

                    @gnydick I don't think this has too much to do with passion over functionality, I just don't want to repeat mistakes I made when I designed my initial verison of DWC. Eventually I will need to start the development of another web interface that will work well with the Duet 2 and of course at the same time I need to start considering different techniques for the Duet 3 because it will be using a different subsystem. Even after the launch the Duet 2 will remain a solid product of the Duet3D project range so this is really nothing you should be worried about.

                    Migrating the current web interface to newer frameworks and JS techniques would be no big deal but the current layout/design of the web interface is not perfect, so I'd like to get a discussion going before I implement everything again from scratch or start porting over stuff. This is just the way I hope I can keep things simple enough and the community happy.

                    To be fair I did not maintain DWC regularly over the past year and I only spent a relatively small fraction of my time improving it, however due to better collaboration with the Duet3D project I am going to invest more time in it. That is why I am trying to come up with a good concept that will surely require some work and yet provide the best compromise I can achieve.

                    Duet software engineer

                    1 Reply Last reply Reply Quote 1
                    • sonderzugundefined
                      sonderzug
                      last edited by

                      Hi,

                      first of all, I think DWC is a remarkable puzzle piece in the 3d printing world, which made having a dedicated Control unit on the Printer completely obsolete for me. My printer only has its power button and nothing else (it's sitting directly next to my PC though). Before I worked with Duet, I was constantly searching for "the perfect" UI, considering everything from 12864-style displays with encoder to full fledged touchscreens. So this shows how much of a game changer this well done web interface was for me personally.

                      That being said, this use case is not for everyone. To answer your question and offer my 2 cents:
                      I think DWC might have potential to be the truly universal UI for remote and non-remote operation of the printer. Therefore beyond the screen size adapting to smaller (smartphone) and bigger (desktop) screens, there should be different "modes" that you can set up. I'm thinking "printer display" mode which offers at least the functionality that classical 12864-style controllers (or Paneldue ๐Ÿ‘… ) offer, and "admin" mode like the current DWC UI, offering full access to the printers configuration, files etc. "Printer Display" mode should adapt to smartphones or tablets, maybe offering more tactile UI elements (e.g. knobs for temperature adjustment, if possible), which leaves the user to choose if they want to use their smartphone, or fix a tablet or RPI display to the printer itself (offering the possibility to even add mouse and keyboard there).

                      I can't really offer any feedback on features I find missing in DWC, because for me personally there are none. Maybe one thing (which would apply to "printer display" and "admin" mode both):
                      My Anycubic Photon (DLP printer) uses a Chitu board and touchscreen, which shows a little representation of the model in the slicer. It's a screenshot of the slicer window, which makes it difficult to implement in our FDM world as I know of no slicer that offers this atm, but maybe there is a way to have a little graphical representation of the model in the Gcode file list?

                      HTH, Niklas

                      1 Reply Last reply Reply Quote 1
                      • SupraGuyundefined
                        SupraGuy
                        last edited by

                        Re-sizable controls. I might want a fairly control dense screen on my RPi 480X320 screen with a trackball, or I might want only a few key buttons if I'm using the same in a 5" touchscreen. Kind of different if I'm displaying on a 4k monitor.

                        I commonly use an RPi with a 1280X720 7" screen, my phone (5" 1080X1920 or 1920X1080 screen) or my media PC (40" 4k screen) with DWC now.

                        The phone is the most maddening, but the one that I am most likely to use for babystepping adjustments.

                        For me thought the biggest thing that I'd like to see is user levels. One level where you can print pre-stored files, one level where you can upload macros and files, and one where you can update firmware, and main configuration. (Let the kids print another object, daily use, and admin privs.) Yeah, I'm aware that with "Gcode everywhere" uploading a Gcode file can do whatever mucking with the configuration files can do, but at least it can be reset with a power down. (I'm a network admin for my day job. Proper user sandboxing is something that I like.)

                        Lead screw driven printer, powered by Duet 2 Wifi
                        MPCNC powered by Duet 2 Wifi
                        CoreXY printer driven by Duet 3 6HC
                        LowRider CNC powered by Duet 2 Wifi

                        pabomanundefined 1 Reply Last reply Reply Quote 2
                        • pabomanundefined
                          paboman @SupraGuy
                          last edited by

                          @supraguy
                          agree, user levels authentication is something we really need

                          1 Reply Last reply Reply Quote 0
                          • botundefined
                            bot
                            last edited by

                            It would be interesting if the new version of DWC could intrinsically manage a farm of printers. I guess the web servers would have to somehow communicate with one another. I guess you would go to the appropriate URL for any DWC instance, and in some part of the UI you could see the status of the other printers on the network, and quickly jump to their DWC instance.

                            I guess that's actually not very important, because one could just have the multiple instances open in tabs, but it could streamline the process and cause less confusion for users who are not as intimate with the setup as the admin.

                            *not actually a robot

                            chrishammundefined Danalundefined 2 Replies Last reply Reply Quote 0
                            • chrishammundefined
                              chrishamm administrators @bot
                              last edited by

                              @bot Nice idea, I think somebody requested this before, too. Would anyone mind if this was only an option when running on the local PC, though? At the moment DWC already allows an IP to be specified if it detects it is running on localhost so I figure it would be a good extension to allow the same for multiple boards. Besides, that way DWC could avoid getting confused by stored DWC settings on the machine(s) that it connects to.

                              Duet software engineer

                              T3P3Tonyundefined botundefined 2 Replies Last reply Reply Quote 0
                              • T3P3Tonyundefined
                                T3P3Tony administrators @chrishamm
                                last edited by

                                @chrishamm another option could be a print farm mode when you connect to one Duet and have a setup option mode to scallops for other duets on the local network. Then the user can select the live instances of DWC they want to control.

                                www.duet3d.com

                                1 Reply Last reply Reply Quote 0
                                • botundefined
                                  bot @chrishamm
                                  last edited by

                                  @chrishamm However you and others find best to implement, I'd be fine with. You've done well so far, I have no reason to doubt the solution you come up with.

                                  I guess it could actually be a separate application/web server that could be run on the same network, from a PC or micro computer, and configured to access whichever printers is needed. Perhaps it could interface with the DWC instances to handle user privileges in an elegant way (ie, the credentials are passed through from the farm interface to the DWC instance, though perhaps this is a major security worst-practice) .

                                  *not actually a robot

                                  1 Reply Last reply Reply Quote 0
                                  • Danalundefined
                                    Danal @bot
                                    last edited by

                                    @bot said in Ideas for a successor of DWC:

                                    It would be interesting if the new version of DWC could intrinsically manage a farm of printers.

                                    I'd love to see this built in. Meanwhile:

                                    https://github.com/DanalEstes/MultiDuetWebMonitor

                                    I guess the web servers would have to somehow communicate with one another.

                                    Not really. Chris already has a discovery protocol. Once any printer provided the UI and script to a browser, that browser could find all the other printers.

                                    I guess you would go to the appropriate URL for any DWC instance, and in some part of the UI you could see the status of the other printers on the network, and quickly jump to their DWC instance.

                                    Exactly. If Chris wants to do that.

                                    I guess that's actually not very important, because one could just have the multiple instances open in tabs, but it could streamline the process and cause less confusion for users who are not as intimate with the setup as the admin.

                                    Tabs hide each other. Having "arms length" color codes on "one pane of glass" was a design goal for multiduetwebmonitor.

                                    Delta / Kossel printer fanatic

                                    1 Reply Last reply Reply Quote 2
                                    • brunofportoundefined
                                      brunofporto
                                      last edited by

                                      Idea:

                                      Show commands that are registered but not executed yet due to the printer been busy!

                                      For example, my end gcode commands the bed to go to 50C and wait, then play the buzzer so I know when the bed is cool enough to get parts out of it.

                                      While I was waiting I sent some commands (heat the bed to 100C and start a simulation). As expected it will execute those commands but there is no indication that they are at the "queue" for execution...

                                      Another suggestion is to show the Macro's list (like the one that exists in Machine Control) besides the gcode console.

                                      Thanks!

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

                                        @brunofporto Thanks for the proposal, I'll consider it! Perhaps it would make sense to disable the G-code inputs temporarily until the firmware indicates a response?

                                        Meanwhile I've made some more progress and got a big part of the backend working. By that I mean the responsive grid that will allow you to customise the pages as you like. If anyone wants to play with it, check out the demo sandbox here. The source code of the component can be found here even though it is still a first version.

                                        Nevertheless I guess it will give you an idea about what the upcoming UI designer will look like. Because the original vue-grid-layout component isn't nearly as flexible as I hoped I had to add a whole bunch of features but I'm quite happy with it so far. And don't be surprised about the poor looks of the demo page, that is just a sandbox with plain HTML and JavaScript ๐Ÿ™‚

                                        Duet software engineer

                                        sonderzugundefined brunofportoundefined 2 Replies Last reply Reply Quote 1
                                        • brunofportoundefined
                                          brunofporto
                                          last edited by

                                          @chrishamm said in Ideas for a successor of DWC:

                                          Perhaps it would make sense to disable the G-code inputs temporarily until the firmware indicates a response?

                                          Show them at the terminal with a different color, marking it as halted, until executed than the color changes to indicate it was executed.

                                          chrishammundefined 1 Reply Last reply Reply Quote 0
                                          • TLASundefined
                                            TLAS
                                            last edited by

                                            Not sure if youโ€™re familiar with AngularJS, but itโ€™s an awesome architecture. Whatever you come up with, Iโ€™d like to see the core functions as disconnected from the UI as possible (Angular does great with this). This allows UI changes very easily. Especially with the move to SBCs on the Duet 3, a main-stream web architecture would be great.

                                            The SBC shift also opens up a large potential for server based operations. I dare to even suggest it, but a โ€˜Duet Reliability Initativeโ€ sounds feasible. Essentially have the web interface / SBC send information to a central server about errors, failed / cancelled prints, config setup / firmware feature use, bed compensation deviations, heater Calibrations, laser filament results, etc. You could do a lot of cool stuff with that data. Map out the most successful filaments / printer configurations, Recommend heater calibration changes, auto-notify errors for error message improvements, Of course have the opt-in / out options for privacy.

                                            Just some thoughts.

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