Ideas for a successor of DWC

bot

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.

chrishamm

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

T3P3Tony

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

bot

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

Danal

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

brunofporto

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!

chrishamm

@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

brunofporto

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

TLAS

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.

chrishamm

@brunofporto Or perhaps even a "loading" icon in the right corner of the G-code input, I think Element-UI provides some nice templates for that. I'll check it out.

@TLAS I looked into Angular and Ember before I started development with Vue, see here for a comparison. Separation of view and model and reusability are the main goals of the upcoming DWC rewrite and this already worked quite decently in the config tool rewrite. AFAIK this idea is a core concept of Angular too.

A Duet Reliability Initative could be an option but this would introduce privacy aspects which I didn't want to touch before. However I expect the new UI will be a lot more robust anyway and I'm still considering the introduction of unit tests too.

sonderzug

@chrishamm who remembers all the hate M$ received when releasing Windows 8 in 2012... however much sense it makes to build a desktop OS around this kind of UI is debatable at best, imo it's still a very good design approach and I'm very excited to play around with this once it takes shape.

what's it gonna be called, btw? DWC2? DDWC (dynamic duet web Control)?

chrishamm

@sonderzug Since it will be a NodeJS app it will be possible to turn it into desktop app will without much trouble, I think. I'll call it DWC2, which is why there is no DWC 2.0 release yet.

brunofporto

@chrishamm said in Ideas for a successor of DWC:

By that I mean the responsive grid that will allow you to customise the pages as you like

Idea: Be able to SAVE, and maybe in a way that is shareable, the customization.

chrishamm

@brunofporto Yep, that is going to be possible - OEMs will need this feature, too. I doubt it will be feasible to implement dynamic menus right in the first DWC2 version but I'll keep an eye on it while porting everything over to the new framework.

I've got the first draft of the file structure ready but I decided to stop using Element-UI because it violates so many design rules that would enable theme support (e.g. colour keys in layout/HTML files instead of CSS). Instead I will focus on Vuetify, iziToast and vue-chartjs. Vuetify also provides light+dark themes out of the box and I'm sure many users will want to see that when upgrading to a newer DWC version.

brunofporto

@chrishamm

One thing:

When I send a command from the top "send" area there is no indication that it was sent or executed!!! If at least the text box was cleared was a nice indication. But it does not even do that So sometimes I execute more than once the same command.

So another suggestion is to always have clues that something was executed! Like a color quick change at a Macro's button holding it like that until it finishes execution, for example, the text box been cleaned after pressing enter and the queued indicator mentioned earlier.

SupraGuy

Hmmm. I see in the history box below the GCode box that it shows that it's sent it, even if I can't see that it's executed.

Personally, I'd like a better history on the GCode box. Sometimes, I want to send the same sequence of commands. Kind of like with a linux bash shell. That way, I can send a sequence of commands easily without typing it out again, or stuff like redefining my Z probe between manual and having the piezo probe quickly.

(Yes, I could just define these in macros, but for whatever reason, I don't.)

fma

I second this.

dc42

Me too. Perhaps we could have a drop down list giving the last 8 or so commands sent, after removing duplicates?

dragonn

It would be nice to have a search future in the history.
Like a fish shell on linux. I think the history could be nicely saved in localStorage, it can store much data.

fma

@dc42 said in Ideas for a successor of DWC:

Me too. Perhaps we could have a drop down list giving the last 8 or so commands sent, after removing duplicates?

When using DWC on a desktop computer, with a keyboard, using the up arrow key to select previous commands, like in linux shell, is much better. But it does not work with a tablet, with only touch screen... So, both systems should be implemented (with more than 8 commands in the history for keyboard usage).

And for keyboard usage, history search should take care of the first chars entered (if I start writing G1, using the up arrow key should only show me commands in the history starting with G1).