Duet Web Control 2.0.0-RC3 is ready

brandonh

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.

sigxcpu

@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.

burtoogle

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.

burtoogle

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.

sigxcpu

True, but the problem here is the initial/cold/first load. Speeding that up will be helpful if it actually loads reliably.

burtoogle

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

True, but the problem here is the initial/cold/first load. Speeding that up will be helpful if it actually loads reliably.

Understood. However, when using basket.js you are in control as to when a resource is loaded so you don't get the multiple concurrent connections that cause problems with low-powered hosts.

dc42

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.

My guess is that with 8 you are running short of memory. Each HTTP responder needs around 2K of memory.

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.

It already does. From https://github.com/dc42/DuetWiFiSocketServer/blob/dev/src/Listener.cpp, around line 150:

	}
	p->listeningPcb = tcp_listen_with_backlog(tempPcb, Backlog);
	if (p->listeningPcb == nullptr)
	{

The constant Backlog is set to 8.

fotomas

Bug report:

Duet Web Control 2.0.0-RC2 / RepRapFirmware 1.23

Sending G-Code using a mouse click on the "send" button sends previous command. It seems to always be one step behind. Two mouse clicks on send button makes the intended command execute. This behavior occurs on both places where a G-Command can be executed.

Sending a command using Enter key works.

gnydick

@sigxcpu yeah, the polling via Ajax is expected. But I was assuming there are a lot more elements than that that are async.

Like I said, it's just too complicated. It's not a control panel, it's a beauty show piece, and until they realize it, it's not going to be really efficient.

whosrdaddy

Small warning for those who are running the duet on a non standard port (ie port <> 80), DWC2.0 (RC2) will not function.
I opened an issue on the Github page so @chrishamm can fix this small bug

BLV

Could you share please some screenshots of the new interface?

sigxcpu

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

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.

My guess is that with 8 you are running short of memory. Each HTTP responder needs around 2K of memory.

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.

It already does. From https://github.com/dc42/DuetWiFiSocketServer/blob/dev/src/Listener.cpp, around line 150:
	}
	p->listeningPcb = tcp_listen_with_backlog(tempPcb, Backlog);
	if (p->listeningPcb == nullptr)
	{
The constant Backlog is set to 8.

Then something is broken in backlog implementation because the Nth+1 connection gets TCP RST instead of waiting. Here is how to find out N:

bash-3.2$ ab -r -v 0 -dSq -n 10 -c 3 http://192.168.27.8:80/index.html
...
Concurrency Level:      3
Time taken for tests:   0.185 seconds
Complete requests:      10
Failed requests:        0
...

bash-3.2$ ab -r -v 0 -dSq -n 10 -c 4 http://192.168.27.8:80/index.html
...
Concurrency Level:      4
Time taken for tests:   0.123 seconds
Complete requests:      10
Failed requests:        0

bash-3.2$ ab -r -v 0 -dSq -n 10 -c 5 http://192.168.27.8:80/index.html
...
Concurrency Level:      5
Time taken for tests:   0.162 seconds
Complete requests:      10
Failed requests:        9
   (Connect: 0, Receive: 1, Length: 8, Exceptions: 0)

Synapsis

Is there a way to change the size of the iframe for the webcam? In older versions the webcam would fill up the entire space while in the last update and the
this new one it onlys fills part of the space.
I'm using a Sance like the one dc42 suggested.

AS-3D Druck

It works just fine 4 me.
The Theme could be more (if dar mode turned on) like the realy Dark on V1 but it is way cooler and organized than the "old" one.

Danal

New web interface just shows blank screen on an iPhone 8+ running IOS 12.something. Both Safari and Chrome. Works fine on desktop Chrome on Win 10. Worked fine on phone before the upgrade.

Two different duets. I use IP addresses only.

When it fails on the phone, there are no error messages, and the progress bar seems to indicate something loaded... just no display, blank white screen.

kazolar

@Danal I am seeing the same blank page on the Pixel 3 XL. Just a blank screen. Tried Chrome and AdBlocker browser.

Works in firefox thouhg

Jacotheron

Works fine on my iPhone 6S in Safari (on both the printer and CNC). Loads very quickly, even while also connected on my computer (Firefox Developer Edition - latest aurora) mid print.

A few other things I found that bothered me:

In Dark mode, the "Idle" status is not very visible - it melts into the background.
Both the Speed Factor and Extrusion Factor sliders appears to be dynamic. When changed, they will adjust their position (for example 100% is at the center, then you drag it to 90%, and it centers it again, though displaying the 90%; dragging it back to 100%, and it adjust itself again to be in the center). I would prefer it to remain static.

3dmntbighker

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

New web interface just shows blank screen on an iPhone 8+ running IOS 12.something. Both Safari and Chrome. Works fine on desktop Chrome on Win 10. Worked fine on phone before the upgrade.

Two different duets. I use IP addresses only.

When it fails on the phone, there are no error messages, and the progress bar seems to indicate something loaded... just no display, blank white screen.

I had to use the reprap.htm page to get it to display on my iPhone 8+. I tried Chrome, Safari and Firefox.

Edgars Batna

The Yes/No dialog buttons changed order. Please use the most common order: https://www.google.com/search?q=yes+no+dialog&num=100&safe=off&client=firefox-b-ab&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiq_behwcLfAhXH66QKHbIADbYQ_AUIDigB&biw=1600&bih=787

YES NO

Reverting to v1 does not work. Tried waiting, tried hitting F5.
Macros and GCode pages are now blocking the whole UI when clicked for around 10s.
I can't extrude from the UI - buttons are always disabled. Tried enabling cold extrusion. Sending commands directly and printing works tho.

config.g:
M305 P1 B4725 C7.060000e-8 ; Semitec 104-GT2 (used by E3D)
M305 P0 R4700 T100000 B3950
M570 H0 P30 T20

M563 P1 S"Extruder0" D0 H1 ; define tool (P), extruder drives (D, D0:1)
M207 S3 R0.0125 F20000 Z0.4 ; set retraction length (S), un-retract length (R), Z hop
M592 D0 A0.04 B0.0005 L0.2 ; nonlinear extrusion
M572 D0 S0.80 ; pressure advance (S) in seconds
M200 D1.75 ; set filament diameter
G10 P1 X0 Y0 Z0 ; Set tool axis offsets
G10 P1 R0 S0 ; Set initial tool active and standby temperatures to 0C

Send GCode button only sends it if clicked twice. Hitting Return works always tho.
No prompt for restart after updating config.g.
It's harder to click into text when editing files. No longer can click into the beginning of a line by clicking the blank space prior to the first character.
I get CORS request failed seemingly sporadically. The error does not go away until I reload the page. My last upload seemed to always fail at around 500KiB. I'm not sure if this is the frontend or backend. The next upload seemed to pause at 500KiB but eventually finished.
config .bak instead of config .g .bak is created when updating config . g. (Added spaces because my posts were flagged as spam).

resam

@Edgars-Batna one would argue that Yes/No buttons are bad UX in general. It is more intuitive to re-use the verbs of the action you want to carry out:

"Are you sure you want to delete this file?" -> Delete / Cancel
"Start print now?" Print / Cancel

I'm not sure about the current state, but I think Mac and Windows used to have opposite positions for the affirmative and the cancel button placement (left or right)...