Duet Web Control 2.0.0-RC3 is ready

Danal · 27 Dec 2018, 23:28

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 · 28 Dec 2018, 00:51

@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 · 28 Dec 2018, 09:03

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 · 28 Dec 2018, 09:17

@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 · 28 Dec 2018, 12:21

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 · 28 Dec 2018, 12:28

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

Edgars Batna · 28 Dec 2018, 12:50

@resam I suppose I agree. You could expand that to left-to-right reading order and having the first button as the default. Also, it's better to have the actions stacked vertically and have much larger buttons once the text is longer.

But otherwise it's more about the change compared to previous version. It should stay consistent per application. Changes like this between versions of same application are way worse in terms of UX. At some point people don't even read the messages anymore as they predict what comes next.

kazolar · 28 Dec 2018, 16:30

@3dmntbighker thanks for reprap.htm idea, that worked on my pixel

JRDM · 28 Dec 2018, 18:41

So far, I like how it's laid out. Time will tell if it's a more efficient layout.

I think the "light" scheme is way too flat, not enough contrast between background white and the almost-white sub-boxes. Even on a good monitor it's kind of a big field of almost white on white, on a marginal monitor it all washes out to white and there's no good edges for my eyes to catch onto. It would be helpful if the dividing lines would be a bit thicker too.

kraegar · 28 Dec 2018, 18:49

Not exactly related to the new version, but I'd love to see the ability to move gcode files into sub directories from within the GUI.

wilriker · 28 Dec 2018, 18:59

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

Not exactly related to the new version, but I'd love to see the ability to move gcode files into sub directories from within the GUI.

That was possible in DWC1 already. I have not yet tried in DWC2, though.

kraegar · 28 Dec 2018, 19:00

@wilriker How? I can make a folder, but can't figure a way to move a gcode file between folders. Unless I just upload a new copy of them.

wilriker · 28 Dec 2018, 19:02

@kraegar Select them via the checkbox and then drag-n-drop. To get them a folder up use the bread-crumbs above the file list.

P.S.: Just tested: you don't even have to select them via the checkboxes. Single files can just be drag-n-dropped directly. Use the "link" (that usually opens the wanna-print-this-dialog) as a click-location.

kraegar · 28 Dec 2018, 19:10

@wilriker Hmm. What browser? Isn't working for me in either. I'm on chrome. Could be user error I guess

wilriker · 28 Dec 2018, 19:14

@kraegar I use Vivaldi but that is basically a Chrome with a modified UI.

Are we both talking about DWC1? Because that's where it works. I just tried and it seems to not be implemented in DWC2 so far.

kraegar · 28 Dec 2018, 19:19

Yep. Maybe it's being interefered with by a plugin or something on my side. Going to stop spamming this thread with it.

kraegar · 28 Dec 2018, 19:26

Ok, yep, it works in DWC1, not 2

dc42 · 28 Dec 2018, 19:53

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

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:

I've found a couple of reasons for these issues:

DuetWiFiServer is coded to reject TCP connections if there are no listeners available for them. There are 4 HTTP responders, so an attempt to open a 5th concurrent HTTP connection is refused. I think this is the right thing to do. With luck, the browser will respect it.
The main problem I have identified is that DuetWiFiServer is running out of buffer space when returning multiple files concurrently. This results in the connection being aborted. I plan to change the code to buffer outgoing messages in our own code instead of in lwip, so that I can be sure that sufficient memory is available before accepting a message from the Duet.

sigxcpu · 28 Dec 2018, 20:16

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

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

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:

I've found a couple of reasons for these issues:

DuetWiFiServer is coded to reject TCP connections if there are no listeners available for them. There are 4 HTTP responders, so an attempt to open a 5th concurrent HTTP connection is refused. I think this is the right thing to do. With luck, the browser will respect it.

The main problem I have identified is that DuetWiFiServer is running out of buffer space when returning multiple files concurrently. This results in the connection being aborted. I plan to change the code to buffer outgoing messages in our own code instead of in lwip, so that I can be sure that sufficient memory is available before accepting a message from the Duet.

Maybe I don't get this right, but 4 HTTP responders and backlog = 8 means that we can have up to 12 simultaneous connections, 4 accepted, 8 pending. The reset/connection refused should happen on the 13th concurrent attempt.
Based on your description (thanks, btw) and my network knowledge, I am pretty sure that the actual backlog is 0 if the 5th connection is refused.

percar · 28 Dec 2018, 20:56

I have now been using the DWC 2.0.0 R2 for a few days now. I love the format. I also understand that this is a new undertaking and bugs are expected. Please continue in this direction because I feel that the new DWC format will be awesome once the bugs are gone. I ran into very few issues with one being the download time for the Gcodes to be printed. Also there have been a few disconnects which I have not really investigated the reason behind the disconnects. I am sure as time progresses this will all be sorted out. Again Thanks