Duet Web Control 2.0.0-RC3 is ready

sigxcpu

Is there any special thing to do except uploading the .ZIP?
I have updated to Duet WiFi Firmware 2.0.2 yesterday and today to DWC2 RC1.

Both my printers behave the same: the page does not load.

The browser console shows two errors:
0_1545726285232_f5152fd8-7359-43ec-8bd6-ff626a6509e9-image.png

If I click reload maaaany times, I get a page without style applied sometimes. DWC 1.22.6 loads and works perfectly every time.

Strange thing, Firefox fails to load it the first time (missing files errors) then a refresh fixes it. Another refresh breaks it the same way then a another refresh fixes it and so on.
Other browsers (Safari, Chrome, Webkit based) all fail.

Later edit:
I think this is more for @dc42.
Interestingly, a failed request for /js/app*js shows this:

HTTP/1.1 200 OK
Content-Type: application/javascript
Content-Encoding: gzip
Content-Length: 70034
Connection: close

But the connection is forcibly reset by Duet with RST, ACK after ~26KB. ~~These 26KB are interesting because they match around the value of the uploaded file over FTP, which is another bug I encounter.~~ (not related, because there are 26KB uncompressed vs 26KB compressed sent by FTP). The FTP bug described below is still valid, but it may have nothing to do with the HTTP download bug.
If I try to upload file on /www over FTP they always reach the SD card truncated. This specific file has it's size between always the same 3 values: 26.XX KB, 27.XX KB and 28.XX KB. Never 70.XX KB.

Again, I don't think this is a Wifi network error because everything else works beautifully. Even more, doing an ab benchmark on these specific JS files, it never fails in 100 requests with concurrency 2.

Even later edit. Sorry for the long post.

It looks like downloading the "big" files like chunk-vendorsjs and appjs always fails. One of them is always failing randomly.

Enabled serial debugging and got this:

HTTP connection accepted
HTTP req, command words { GET / HTTP/1.1 }, parameters { }
Read 0 1 12022
Read 0 1 23286
Read 0 1 23287
Sending reply, file = yes
Read 0 1 119158
HTTP connection accepted
HTTP connection accepted
HTTP connection accepted
HTTP req, command words { GET /css/app.41ddf9b3.css HTTP/1.1 }, parameters { }
HTTP req, command words { GET /css/chunk-vendors.30c0b939.css HTTP/1.1 }, parameters { }
HTTP req, command words { GET /js/chunk-vendors.92cfeab5.js HTTP/1.1 }, parameters { }
HTTP connection accepted
HTTP req, command words { GET /js/app.9bf271d0.js HTTP/1.1 }, parameters { }
Read 0 1 12022
Read 0 1 23286
Read 0 1 115190
Read 0 1 115191
Sending reply, file = yes
Read 0 1 12022
Read 0 1 23286
Read 0 1 115190
Read 0 1 115191
Sending reply, file = yes
Read 0 1 12022
Read 0 1 23286
Read 0 1 116982
Sending reply, file = yes
Read 0 1 12022
Read 0 1 23286
Read 0 1 116982
Sending reply, file = yes
Read 0 2 118390
Read 0 1 118392
Read 0 4 119414
Read 0 4 119418
Read 0 4 120822
Read 0 4 120826
Read 0 4 120054
Read 0 4 120058
Read 0 4 119422
Read 0 4 120830
Can't send anymore
WiFi reported error: incomplete write

Looks somewhat solved. Errors appear from time to time, but it works. What I did on both printers is that I've forced a firmware rewrite for the WiFi server using serial console.
Both were 1.21 before, both are 1.21 now. Maybe there are multiple 1.21 versions out there?

dragonn

I got this:
0_1545734870732_bea578d9-6053-4e99-9e89-61a4e8b81f79-image.png
When I tried to print a file.

dragonn

And the "warning Revert to Duet Web Control 1" doesn't work for me

dragonn

I changed the name of the file to "GhostingTes MakerMuse.gcode", uploaded it and now it prints fine.

chrishamm

Thanks for your feedback so far! DWC2 may take a few seconds to load initially but once cached it's way faster. Again, RRF 2.02 is required for this web interface version.

If you cannot access your machine after upgrading to DWC2 but DWC1 worked, you can still access DWC1 via http://<your printer>/reprap.htm. This will effectively load the old UI.

I could reproduce the password input problem when DWC2 is running in remote mode (i.e. when it's downloaded from the board), so I will have a look at it and fix it in RC2.

@SupraGuy Are you on DuetWiFiServer 1.21 and does the problem persist on different devices? Can you press F12 while loading and check if you get any error messages in the Console? Maybe reflashing DuetWiFiServer resolves your problem.

@sigxcpu Thanks for investigating this. Did you power-cycle your board once after the initial DuetWiFiServer 1.21 update? Glad you could solve it though.

hurzhurz

I just noticed that the axis move buttons don't seem to switch to relative movement first?
Had a little nozzle crash while testing something...

chrishamm

@hurzhurz Oops, you're right - will provide RC2 later today which will fix this, the password problem and what else is reported in the meantime.

PlasticMetal

Is there a way to change the Z movement increments? With a 460mm delta, I'd really like a 100mm increment.

Otherwise, I like it. I have the same password & "revert" problems as noted above, but for the moment I pulled the card & commented out the M551. Running an Ethernet v1.03 with 2.02.

Phaedrux

@plasticmetal try right clicking on the button. At least that worked previously.

PlasticMetal

@phaedrux Sweet! I've tried right clicking on other items before, but for some reason never there. Thanks!

chrishamm

Alright, here you go: https://github.com/chrishamm/DuetWebControl/releases/tag/2.0.0-RC2

The password issue is now fixed as well as the movement buttons not sending relative/absolute position codes. Enjoy!

Mike

Amazing, don't know if that was intended, but I'm getting twice higher G-code upload speeds now.

wilriker

Very nice new DWC! I really like it. The one thing I like three most so far is finally listing print and simulation times for GCode files.

Also I like the timeline on the X axis of the temperature graph.

One question though: what is the -mini version on the release page? Is it just minified JS and CSS or is there something else mini?

sigxcpu

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.

Jacotheron

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.

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.

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.

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.

Dougal1957

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

Jacotheron

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.