DueUI Release 3.0.1-beta2 Available

DaBit

What am I doing wrong when I see this?

alt text

I took the 'DSF' release since it seemed to contain the files in unzipped form, unzipped the contents of that file to the wwwroot of the lighttpd server on a Pi running at 192.168.0.23, pointed the config to http://192.168.0.23/dueui/dueui_config_default.json and the location of the Duet to 192.168.0.42
(I swap to names instead of IP's when things work)

The config JSON appears when the URL is entered in a browser, so the link to the config is OK. The Duet is also reachable since the ATX power button works.

[edit]
http://dueui.org/v3/ does the same, so probably not installation related.
[/edit]

gtj0

@garyd9 said in DueUI Release 3.0.0-beta1 Available:

@gtj0

My first impression seeing this thread was "What is DueUI"? Unfortunately, that first question wasn't answered early in the post... (In fact, I really didn't get an answer until I followed your wiki link.)

So, please accept my suggestion based on that first impression: In the top line of the post, mention what this is. For example: "A lightweight replacement (or addition) to DWC"

Yeah, that's a great point. I'll update the first post.

gtj0

@Danal said in DueUI Release 3.0.0-beta1 Available:

Blank config URL would not pick the default for me, even with DSF mode set. I believe it is trying RR_ commands that don't work on RRF3 with Pi.

Changing config url to 192.168.7.101/dueui/dueui_config_default.json worked.

Rats. I thought I had that fixed. If you want to create your own config, stick in in /sys/ and change the URL to http://<sbc>/machine/file/sys/<your_config.json>

gtj0

@DaBit said in DueUI Release 3.0.0-beta1 Available:

What am I doing wrong when I see this?

I took the 'DSF' release since it seemed to contain the files in unzipped form, unzipped the contents of that file to the wwwroot of the lighttpd server on a Pi running at 192.168.0.23, pointed the config to http://192.168.0.23/dueui/dueui_config_default.json and the location of the Duet to 192.168.0.42
(I swap to names instead of IP's when things work)

The config JSON appears when the URL is entered in a browser, so the link to the config is OK. The Duet is also reachable since the ATX power button works.

The default config is set for a Duet3 with the DSF. I need to get a default config up for the Duets in standalone mode. Sorry about that. I'll get one up shortly.

Which version of RRF are you running?

DaBit

That would be 3.01-beta1+1 (2020-01-15b2)
The board I am running is a Duet2 Wifi

gtj0

@DaBit said in DueUI Release 3.0.0-beta1 Available:

That would be 3.01-beta1+1 (2020-01-15b2)

Perfect.

zapta

Reading the post here and the github page it looks very impressive. Thanks for doing it. A quick question about the installation, if I upload DueUI-1.1.0.zip to the Duet as described, will the zip file stay as is on the SD card or will it be decompressed into multiple directory and files?

(my preference is to have the DueUI as a single file or directory on the SD so I can easily manage and delete if needed).

gtj0

@zapta said in DueUI Release 3.0.0-beta1 Available:

Reading the post here and the github page it looks very impressive. Thanks for doing it. A quick question about the installation, if I upload DueUI-1.1.0.zip to the Duet as described, will the zip file stay as is on the SD card or will it be decompressed into multiple directory and files?

(my preference is to have the DueUI as a single file or directory on the SD so I can easily manage and delete if needed).

Unfortunately, the DWC unzips the file and places the javascript files in /www/js, the css files in /www/css, etc. right beside the DWC files. With the exception of 2 font files, all DueUI files start with "dueui" though so it'd be easy to get rid of.

On an SBC/DSF, you'd manually unzip the zip file and it all goes in 1 directory: /opt/dsf/sd/www/dueui

gtj0

What's New in 3.0.1-beta1

https://github.com/gtjoseph/DueUI/releases/tag/v3.0.1-beta1

Updates for Standalone Duet

Added a dueui_config_default_standalone.json file.
Fixed some issues in the standalone backend.

Settings Update

Moved the "Backend Type" selection to the top of the page and
changed "NonDSF" to "Standalone".
If the backend type changes:
- The Hostname label will change to "SBC" or "Duet" as appropriate.
- The DueUI Config URL will change to an appropriate URL path
  and default file name (if it was one of the defaults to start with).
- If DSF is selected, the Polling Intervals will be hidden.
Changed the default config file name to
"dueui_config_default_standalone.json" to match the default backend
type.

garis

I liked the previous version, but had left you with some crude code ~20 July, and comments related to my simple needs, but I had abandoned use of DueUI as I thought you had abandoned this project as there had been no response and looked like there would be no support.

I notice babystepping is now included - thanks?

Is there anything critical that is new? Although I can implement and customise this I am not conversant with JSON in general & my brain will take some hours to reboot into this project.

gtj0

@garis I am so sorry. It was your post that got me working on the additional stuff and I just lost track of that other thread. I have definitely not abandoned this project. The two big hold-ups for me have been writing the documentation for the wiki and the fact that both RRF3 and the DSF were getting lots of changes in preparation for the Duet3 release, and are still getting lots of changes. Every time I thought about doing another release, something else in the environment changed.

Anyway, the biggest functional change is the ability to interface to the SBC. Others include the Image/WebCam support and the File Select widget. The File Select widget could be a great space saver because it only occupies a small space on the layout and the files only show in the dropdown when you click on it.

As I've been going through the default configs, I've also realized that the config is getting a bit "verbose" :). I'm trying to find ways to balance config complexity and flexibility so I'll probably come up with more "composite" widgets.

DaBit

With the new standalone config it works. Now I have to adjust the config for my printer, but since adding the second extruder and the webcam image took 15 minutes that seems completely doable.

Just wondering / thinking out loud: let's assume dueui can run under Electron. How hard would it be to add a backend that talks over serial (to the PanelDue port) or USB virtual comport instead of Wifi?
That would make the printer usable when the Wifi infrastructure disappears. For example, when I want to put the printer temporarily at the school of my sons to let the kids play with it..

It is probably easier to add an access point to the printer (or use the Pi for that) and just give the printer it's own Wifi network, but I can dream, right?

gtj0

@DaBit That could be really interesting. None of the actual UI stuff would need to change at all. It'd be just adding another backend that implements the same contract that the other two do. I'll look into it!

DaBit

I skimmed through the code, and if you add a third backend for serial which emits M408 and reads the response it should work. Don't ask me how to do that; I never did serious Javascript before.

However, I do have the serial line coming from the PanelDue connector connected to the Pi, so I can test. And setting up the build environment would be possible too.

I just set DueUI up on the Pi + 7" Pi screen on the printer.

alt text

Of course I have to configure it. I do get the basic idea of how to do that. However, a few things:

The camera image is not refreshing. DWC reloads the image every X milliseconds, DueUI does not. Not a big issue; having the camera image taking up real estate on the 7" Pi screen while I only have to look up 30cm to have a real view makes no sense.
Current/last file says 'unknown'. Which makes sense if I look at the config, line 355 of dueui_config_default_standalone.json. Isn't the real current filename available somewhere (I am not seeing it in a M408 response either)?

"value": "Current/Last File:  ${state.status == 'P' ? 'unknown' : 'Not printing'}",

Time and times left stay at 0:00:00. In the config the calculated values are commented out, but the referenced values seem OK. Still a beta thing?

Maybe I'm missing something, but how would this make the paneldue any more functional than it already is on IO0? I.e. you cannot start jobs from SD. (you could probably execute macros or console commands to start prints, but the paneldue cannot list the fake sd card on the pi)?

gtj0

@DaBit :

How is the webcam sending the stream? As Motion JPEG or something else? If it's just a jpeg that the webcam regenerates, I may have to add a refresh parameter. Also check if the webcam can support other types of output.

The M408 responses and the ones you get by http://<duet>/rr_status?type=3 are actually different. Browse to the rr_status page and you should be able to pick out the fields you want, then you can just substitute them on your config file. I'll look at that again though. At one point I was using the M409 command to get the object model but it's not complete. I might have missed changing it back to rr_status.

gtj0

@bearer said in DueUI Release 3.0.1-beta1 Available:

Maybe I'm missing something, but how would this make the paneldue any more functional than it already is on IO0? I.e. you cannot start jobs from SD. (you could probably execute macros or console commands to start prints, but the paneldue cannot list the fake sd card on the pi)?

Well, it's not ever going to make the panel due more functional and we're talking in a standalone mode for serial connection, not SBC/DSF. There's no real point to DueUI connecting in serial mode in the SBC/DSF environment because you can run DueUI in a browser on the SBC. In a standalone environment though, you could run DueUI (with modifications) on a non-networked laptop and just connect to the Duet via a USB connection or direct serial-to-serial.

gtj0

@DaBit I've added a "refresh_seconds" parameter to the image widget. It'll be in the next beta.

gtj0

Oh, I've also noticed that there's a slight delay before the values are populated from the object models resulting in the expressions appearing in widgets instead of the values for a brief time. That just started happening so it must be something I just did.

DaBit

@gtj0 said in DueUI Release 3.0.1-beta1 Available:

How is the webcam sending the stream? As Motion JPEG or something else? If it's just a jpeg that the webcam regenerates, I may have to add a refresh parameter. Also check if the webcam can support other types of output.

I am using RPi-Cam-Web-Interface. It probably does support output other than a static jpeg frame, but one image every 10 seconds or so is fine for me. On a 3D printer not that much is happening in 10 seconds, and a lower update rate saves bandwidth in case I just want to check if everything still runs fine through a mobile connection when abroad.

@gtj0 said in DueUI Release 3.0.1-beta1 Available:

@DaBit I've added a "refresh_seconds" parameter to the image widget. It'll be in the next beta.

Great!

@gtj0 said in DueUI Release 3.0.1-beta1 Available:

Oh, I've also noticed that there's a slight delay before the values are populated from the object models resulting in the expressions appearing in widgets instead of the values for a brief time. That just started happening so it must be something I just did.

The current beta also does that.

I tried using DueUI running on the Pi yesterday evening, but I had some more issues:

After I pressed 'home all' it took several seconds before the printer reacted.
Jogging Z (after homing) did not work.

I did not dive into it but switched to DWC; I had work to do. Will check more thoroughly soon.