Time for a complete re-write or start over with v2 of DWC
-
DWC is open source, so anyone is free to add, modify or replace it as they see fit.
Perhaps start with some interface changes and submit a pull request. -
I don't agree with the OP, but there could be some improvement in the interface for CNC users. Some of the acreage is used to provided irrelevant printer-related information for us, but this is editable with the work @MintyTrebor has done. I just haven't had the time to try ity out, yet!
As I understand it, there are moves afoot to develop the interface, though.
-
This post is deleted! -
@arnold_r_clark what alternatives would you recommend for web based control of Duet boards?
-
This post is deleted! -
@arnold_r_clark your comment is absolutely correct, and not helpful at all, and besides the point. I think that especially for people that choose to use RRF and DWC, discussions about performance regressions are super interesting.
-
This post is deleted! -
To be contentious, I tend to agree with the OP but not for the same reasons. IMO, the performance is OK but the layout and functionality leave a lot to be desired. I have submitted numerous requests on the forums, but nobody who can fix it takes much notice
e.g. https://forum.duet3d.com/topic/24841/anoying-behaviour-with-the-status-page-of-dwc,
and https://forum.duet3d.com/topic/27067/request-to-reduce-the-amount-of-padding?_=1656321685718
The latter was upvoted by two moderators and when I bumped it 3 months later, it was further upvoted by one user and seconded by another. But nothing has changed.
I guess the reason why these things never get fixed is that the majority of users only have a single tool and 3 axes, so they don't have any issue with the interface. Most of the replies to the OP are in the form "it works fine for me so it isn't a problem". But to those people I would say, try it with 6 or more tools and 7 axes then tell me it is just fine. It isn't - even on a large monitor - but with smart phone or similar? - well forget it. And while I'm in rant mode, I've said before that the estimates to completion are as much use as an ashtray on a motor bike and seem to have gotten worse over the years.
I use something called Home Assistant for my smart home devices which is another open source project. It has the ability for users to create their own "tabbed" views based on whatever information they want to see and where on the screen they want to see it, both on large screens and small mobile devices, all without writing any code. Just drag, drop, copy, paste, select from drop down list etc etc. I also use video editing software which enables me to hide/unhide, move, dock, and resize windows depending on what information is relevant to the task in hand. DWC on the other hand gives users almost no control over what information they want to see and uses fixed windows with acres of padding meaning that a scroll wheel mouse is an absolute essential (IMO).
-
This post is deleted! -
@deckingman I don't know if a complete rewrite is required, but I think it's worth discussing the issue at hand.
I see almost entirely identical performance numbers on my laptop which is by all means compared to the machine the original posts values were sampled a potato, so I don't think this can be blamed on a client machine.
Drilling further into the numbers, I see that the main causes for the slow load are three files: app.js (565k,3.84sec), materdialdesignicons-webfont (354k, 3.32sec, and HeightMap.js (486k, 4.3sec (I've skipped the unique identifiers for them). webfont and heightmap.js mostly overlap due to the magic of multiple HTTP connections at the same time, so deferring the load of HeightMap.js until someone clicks on the HeightMap menu item would only shave off a second (still about 10% performance increase).
Considering DOMContentLoaded is at roughly 40% of total load time, I think it should be possible to get load time down to maybe 5 seconds by carefully inspecting why those files are so big.
PS: Here is an article how to reduce the material designs icons font and javascript to only those selectors actually in use:
https://www.shedloadofcode.com/blog/reduce-material-design-icons-font-to-7kb-and-automate-with-pyautogui -- getting that under 10k certainly would be interesting.
-
@oliof I don't really understand much of that and as I said, speed for me isn't really much of an issue. But I was replying to the OP's title, rather than the OPs specific issues.
But just out of interest, I have shortcuts on my desktop to urls for both my printer and home assistant. My printer is hardwired with (Gigabit) Ethernet (running stand alone - no SBC), as is my PC and my Odroid running home assistant. With my browser open, if I click the shortcut for home assistant, the page appears fully loaded in less than a second. That's displaying data from over 40 devices, each with multiple "entities" as well as long term statistics graphs. If I click the shortcut for my printer (which is powered up) it takes around 6 seconds for DWC to connect and load. I don't know enough to say it's a DWC issue or a Duet board issue.
I'm just putting that out there - it's neither here nor there to me personally if DWC takes 6 seconds to load or 1 second but I kind of "get" what the OP is saying. The only speed issue I have is with the ancient laptop that is connected to my network via WiFi and which takes a long time to upload large gcode files. The fix is easy - I just use my (wired) desktop PC instead.
-
@deckingman surely one contributing factor is that home assistant runs on a computer (Odroid), and the DWC UI comes from an ESP chip which has it's own IO and resource limits. I don't have an SBC setup because I don't see the point, but it may be worth looking if that loads faster or not, because that would prove a hypothesis that the ESP chip is the bottleneck. Other similarily sized files of DWC load much faster by the way, so it's something specific to the JavaScript/font files and not just an issue with their size.
<>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>
-
@oliof with a H7 board running an ESP32 at the faster transfer speed (effectively 2.4mb/s), DWC for me loads in about 3 seconds
-
@oliof It sounds like @deckingman may have an ethernet board rather than one using WiFi. My experience (with a Duet2 Ethernet based board), is that wired connections to Duet boards are significantly slower than WiFi based ones....
But for most people I'd guess that speed is not really a big deal. I'd say some of the UI issues are more important.
-
@gloomyandy his ethernet board is still about 60% faster than my STM RRF board on wifi. I agree the UI aspects are worth discussing, but this thread was about speed originally, so I am trying to stick to that topic.
-
I've no idea if any of this is relevant, especially as I'm not too concerned about the speed of DWC but I'll throw it out there anyway as people were commenting about board types and wired vs wifi etc.
Uploading a circa 40 MB gcode file from my aged wifi connected laptop to the printer via DWC takes around 58 seconds at a reported transfer speed of around 750kbits/sec. Uploading the same file via my desktop Ethernet connected PC takes about half that time at a reported speed of roughly 1.6Mbits/sec. Transferring that same file from my Desktop (Ethernet) PC to my aged (WiFi) laptop takes around 3 seconds (no idea what speed that was because it happened too quickly for me to catch it).
All that means is that transferring a file to my printer SD card is about 10 times slower than transferring the same file, from the same machine, to a (aged and slow) Laptop, but it probably proves nothing. It's not my field of expertise by any means but I guess there area number of things at play here, not least of which would be the write speed of the SD card and/or the size of any cache files? It probably has nothing to do with DWC.
-
@fcwilt that's a big part of it. Panel Due leaves a lot to be desired, doesn't it makes sense it SHOULD work on a tablet or mobile just fine?
-
@owend true, but it was written with a framework that is very hard to cone up to speed on for the sake of a hobby.
-
Thanks for the discussion. To clear up some, the point of my post wasn't entirely about speed and certainly not about speed on the desktop.
I ran out of steam and couldn't really get to the mobile device timings. I was hoping to make my point about performance through comparison using the desktop and then implying just how much more burdensome it is on mobile.
There are other points in the post besides performance, if you have the time to read the whole post, please do.
I'm happy to try do more requirements gatherings if interested.
-
@gnydick both the klipper interfaces (fluidd and mainsail) are also written in Vue and Javascript and both actually have their origins in DWC and they seem to do pretty well in terms of features etc.
Hopefully in the future we see DWC getting some more love
