I feel like the guy who builds a boat in his basement or the classic car guy who spends more time working on his car than driving it. Anyway, I started build Black Beauty a few years ago and although I've done plenty of printing, lately I've been working on the software side of things. A few weeks ago I realized I needed to get back to actual printing but thought Black Beauty was looking a little rough around the edges and could do with some minor work. Then it occurred to me that having all the wiring and electronics on the back of the printer just didn't look right. That turned into a complete re-wiring job.

So, this is what I wound up with...

The whole assembly is elevated to allow good air flow and there's a cover that sits on top of the whole thing.

Mains enters at the back and all mains wiring stays at the center back. Luckily the two power supplied cooperated by having their mains terminal towards the center. Low voltage exits the power domain to the left and right and never crosses mains wiring.

Back left to right

• 5V6A 12V3A PSU. This provides 5V to all electronics and 12V to my touch screen monitor.
• The two SSRs switch the mains powered bed and the 24V21A PSU.
• The 24V PSU has a blower fan on top pointing to the right.

Front right to left

• The SBC I'm using is a Jetson Nano.
• There's a small USB hub that connects the Nano's serial and debug ports to my development machine for testing purposes.
• The ribbon cables on the right side of the Nano connect to the Duet3's 26pin header and provide 5V power to the Duet3 and the serial uart on the Duet3 connects back to the Nano for diagnostic purposes.
• The Nano has a network cable of course but also connected is the USB camera, the Duet3's USB port, and my touch screen monitor (HDMI and USB).
• You can figure out what's connected to the Duet3 by looking at it.
• The RJ45 connectors on the left go to the bed (temp and LEDs), tool carriage(temp, probe, endstop) and my manual emergency button box.

Here's a wider view:

The control box, from left to right:

• The latching stomp button connects to the reset header on the duet.
• The paddle switch turns 5V to the Duet3 on and off.
• The green button is the power button for the Nano.
• The red button is the reseet switch for the Nano.

Here's what the top end looks like now although I have a feeling it'll need some "minor" work as well

And in all its glory:

Look nice and neat huh?

Here's what my workspace looks like:

Around the beginning of the year I was getting a little frustrated trying to find the "right" way to control my printer from the printer itself. I have a PanelDue but the layout just doesn't fit my work process and while I can, and have, modified the firmware to be closer to what I wanted, it just wasn't enough. So then I spent some time trying to figure out if there were a way to allow the PanelDue's layout to be controlled from a config file and quickly realized that while the PanelDue is great at what it does, dynamically laying out the UI isn't one of them. Then I had an epiphany. Just before Christmas I bought an Amazon Fire 7" Tablet for $79 as a backup to my trusty Nexus 7. It's got a Chromium based HTML5 browser. Can you see where I'm headed? No? Look at these screenshots...

So now I have a UI that's close to what I want but that's not the best part. Every one of the tabs, buttons, labels, etc. were configured in 1 config file. This way you can get the layout you want.

Here's a sample config for the 2 heater widgets...

// Minimal config for  the Bed using the built in defaults.
{
	"id": "bed_heater",
	"type": "heater",
	"enabled": true,
	"label": "Bed",
	"position": {
		"my": "left top",
		"at": "right top",
		"of": "#heater_labels"
	},
	"button_defaults": {
		"style": {
			"height": "2.5em"							
		}
	},
	"tolerances": [
		{"limit": 2, "style": {"background": "lightgreen"}},
		{"limit": 5, "style": {"background": "yellow"}},
		{"limit": 999, "style": {"background": "red"}}
	],
	"heater_index": 0
},
// Extended config for Extruder 1
//  These use the new, as yet unreleased,  M308 command.
{
	"id": "extr1_heater",
	"type": "heater",
	"enabled": true,
	"label": "Extr 1",
	"position": {
		"my": "left top",
		"at": "right top",
		"of": "#bed_heater"
	},
	"style": { "width": "100px" },
	"button_defaults": {
		"style": {
			"height": "2.5em"
		}
	},
	"state_styles": [
		{"background": "gray", "color": "white"},
		{"background": "green", "color": "white"},
		{"background": "lightgreen", "color": "black"},
		{"background": "red", "color": "black"},
		{"background": "voilet", "color": "black"}
	],
	"tolerances": [
		{"limit": 2, "style": {"background": "lightgreen"}},
		{"limit": 5, "style": {"background": "yellow"}},
		{"limit": 999, "style": {"background": "red"}}
	],
	"heater_index": 1,
	"status_level": 1,
	"current_temp_field": "${status.temps.current[1]}",
	"active_temp_field": "${status.temps.active[1]}",
	"standby_temp_field": "${status.temps.standby[1]}",
	"state_field": "${status.temps.state[1]}",
	"state_commands": {
		"off": "M308 P1 T0",
		"standby": "M308 P1 T1",
	        "on": "M308 P1 T2"
	},
	"set_temp_commands": {
		"standby": "M308 P1 R${value}",
		 "active": "M308 P1 S${value}"
	}
},
// Need another extruder, just cut and paste another one.

I've got about another weeks worth of work before I push a release up to GitHub. I need to come up with a decent file browser layout for starting prints and I need to remove a lot of embarrassing debug code. In the mean time, comments and questions will be welcomed.

To be clear... DueUI is NOT meant to replace the DWC or the PanelDue. It fits somewhere between the 2 and is completely independent from them. Installing DueUI doesn't affect the DWC in any way. Installation is as easy as using the DWC to upload the DueUI zip file. In fact, you don't even need to install DueUI on the Duet at all. Any device that has a reasonably functional web server, like a Raspberry Pi, will do.

Yeah.
me: "Home Z"
printer: "I'm sorry, you can't home Z because X and Y aren't homed. Would you like to home them first?"
me: "Yes please"
printer: "Done. Would you like to automatically home X and Y before Z in the future?"
me: "Yes"
me: "Print file Benchy"
printer: "I'm sorry but if you hadn't noticed I'M ALREADY PRINTING SOMETHING YOU IDIOT!"
me: "Fine. Cancel current print and print Benchy."
printer: "Okaaayyy but if I cancel the current print you'll have wasted 250 grams if filament"
me: "JUST CANCEL THE CURRENT PRINT AND PRINT THE BENCHY"
printer: "Fine"
me: "FINE"
printer: "Please remove the current print from the bed"
me: "DONE"
printer: "Printing Benchy"
printer: "I'm sorry but you don't have enough filament left to print Benchy"
me: throws up hands and walks away.

DueUI is an alternate web-based user Interface for the Duet family of products. It's not meant to replace the full fledged DuetWebControl (DWC) interface but rather to complement it. I needed something more compact, kind of like the PanelDue user interface and had started looking at ways to make the PanelDue more user-customizable. Unfortunately, while the PanelDue is great at what it does, trying to develop a framework that would let it be more customizable without recompiling the firmware every time just wasn't feasable. It then dawned on me that 7" Android tablets with serviceable browsers were ridiculously cheap so I started down the road of creating a customizable widget based user interface that could run on any modern browser. Not only does it work well on tablets, it works great on a small(ish) touch screen attached to an SBC. I run it on an 11" 1920x1080 touchscreen monitor mounted on the side of my printer.

DueUI Wiki

Download

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

Yeah I know it should really be 2.0.0 but I wanted to be cool and make it match RRF 3.0 and the Duet3.
I also know that it's not exactly Beta "Firmware" but it's still a Beta something. If a mod wants to move it, that's fine.

What's New in 3.0.0-beta1

• The DueUI Wiki!!

  • Complete documentation with examples for every widget.
  • Samples of the printer status objects.
  • Installation and Upgrade guide.
  • Sample configs.

• Functions, templates and constants can now be defined in the config file.

• A new backend for the Duet Software Framework.
  Standalone still works.

• There are some new widgets

  • "Image" allows you to embed an image or a Motion JPEG stream anywhere.
  • "File Dropdown" allows you to display a select box with a list of files.
  • "File Select" is a File Dropdown with accompanying Refresh and Run/Print
    buttons.

• Lots of behind-the-scenes updates.

• Stuff I can't remember.

Here's a screen shot of my "Print" panel...

...and my Movement panel...

Remember, this is my layout. You can make yours look like anything you want.

I've been using it with my Duet3 and the DSF for a few months now and I think I've got all the bugs. As with any Beta release though, I'm sure there are others I haven't caught.

What's New in 3.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.

What's New in 3.0.1-beta2

Fixed issue with fields showing the format instead of value

• When first started or refreshed, the UI could display format
  strings like "${state.heat.heaters[1].current.toFixed(1)}" for a
  short time iunstead of the actual value. This was due to the model
  not being populated before the UI elements. Now we populate the
  model before showing the UI.

Minor backend refactoring

Add refresh_seconds to the Image widget

• Some WebCams only provide an image snapshot instead of
  a live MJPEG stream. If you have one, you can now set
  "refresh_seconds" to control how often teh image should
  be refreshed.

I'm on the road this week but wanted to make some additional PanelDue firmware changes while I was away. The problem was that the printer and PanelDue would be separated by about 1700 miles so how would I test? On a whim, I tossed the PanelDue in my bag and scrounged around in my store room and found a few of these https://www.adafruit.com/product/954 so I tossed one in as well.

So now I'm sitting in my sister's house in Boston with the PanelDue connected to my laptop via the USB serial converter and my laptop connected to the printer in Denver via VPN.

I just ran...

# socat TCP4:duet0:23 /dev/ttyUSB0,b115200,nonblock,rawer

to connect the Duet's telnet to the PanelDue's serial port and now my PanelDue is happily connected to my printer!

I should have set up the webcam before I left but I forgot. That way I could have scared the hell out of my pet sitter by raising Black Beauty's bed 500mm up and down at 6000mm/min whenever she walked by.

Anyway, this will work with any Linux (and possibly Mac) machine and if it has a 3.3v UART, like a Pi you don't even the USB converter (but you will still need 5v power).

I actually have some Wandboards in the store room so I'm going to print a case that has the PanelDue in front with a Wandboard behind it to provide network connectivity.

Scroll down for the latest release

https://forum.duet3d.com/topic/9257/dueui-1-1-0-is-released/29

---

Last week I announced plans to release an alternate user interface for the Duet.
https://forum.duet3d.com/topic/9169/preview-dueui-an-alternate-web-interface

Well, it's ready for testing!
https://github.com/gtjoseph/DueUI

Please read the README completely before installing DueUI. The "Known Issues" section has some info that explains why I'm not thrilled with some of the widgets yet.

Remember, this is test software and meant to be customized by you. WORK IT OUT! I really want feedback (good, bad or ugly) and let's keep the feedback to this thread for now rather than issues filed on GitHub.

Welcome to DueUI 3.0

This is a lightweight user interface for the Duet family of 3D printing electronics.

This user interface is not meant to replace the full fledged DuetWebControl (DWC) interface but rather to complement it. I needed something more compact, kind of like the PanelDue user interface and had started looking at ways to make the PanelDue more user-customizable. Unfortunately, while the PanelDue is great at what it does, trying to develop a framework that would let it be more customizable without recompiling the firmware every time just wasn't feasable. It then dawned on me that 7" Android tablets with serviceable browsers were ridiculously cheap so I started down the road of creating a customizable widget based user interface that could run on any modern browser: The DueUI.

Sample Screens:

Everything on the screens above is user-customizable:

• Widgets
• Labels
• Colors
• Placement
• Number of panels

In fact, with no customization, all you'll get is a settings panel.

Here's a screen that was created by user @thwe :

It doesn't look much like mine does it? He implemented that solely using the config file!

For more information, please visit the DueUI Wiki

Yes, that's peanut butter.
No, it wasn't my idea... https://reprap.org/forum/read.php?1,642473,732969#msg-732969

I haven't tried it before but it'd better work. That was supposed to be my lunch tomorrow.

I figured it out. I stupidly forgot to set the MISO pins to TRISTATE so the data was getting corrupted.
Tested and things now seem fully operational.
Grab the new u-boot and dtb files from:
https://github.com/gtjoseph/jetson-nano-support/tree/l4t_32.2.1

Just a quick update...

There are official 64 bit builds of Duet Software Framework available from Duet3D. All you have to do is create a file named /etc/apt/sources.list.d/duet3d.list with one line in it...

deb https://pkg.duet3d.com/ stable armv7

Even though armv7 is mentioned, you'll get the arm64 packages.

Then copy the attached gpg key to /etc/apt/trusted.gpg.d/duet3d.gpg.
duet3d.gpg.txt
The .txt suffix was added just to satisfy the forum's upload restrictions so you need to remove it.

Finally, do an apt-get update and apt-get install duetsoftwareframework

@stuartofmt said in Custom Java Script in config file:

: The default state is state.sensors.probes[0] = null

Interesting. So there is an entry at index 0 but it's null? Can you share the relevant config bits that produce that situation? If it's too complicated, no worries, I'm just curious.

@stuartofmt You've got a couple of issues...

When you were using Array.isArray, you were testing state.sensors.probes[0] and state.sensors.probes[0] which are the elements of the probes array, not arrays themselves so both tests will always return false.

Your second attempt using the global variable will never return 1 because probes, being an array, can't have an array element at index 1 without there being one at 0.

I'm guessing you're using the K parameter on M574 to set the probe number? That value only appears in the state.sensors.endstops object as the probe value. It doesn't control where in either the endstops or probes arrays the probe appears. If you only have 1 probe, that probe will always be state.sensors.probes[0] no matter what you have the K value set to.

If I guessed wrong and you're doing something else, let me know and I'll see if I can help.

I'm going to test it again later today but I think you're going to have to declare getProbeNum as static...

class DueUIConfig {
	static getProbeNum(state) {
		var myprobe = "No Probe";
		if (Array.isArray(state.sensors.probes[0])) {
		

@stuartofmt said in Possible Issue with v3.5.0-beta1:

As a side note, I have noticed that naming the config file xyz.js (instead of xyz.json) makes no difference. Or at least it seems to make no difference.

Now that I think of it, yeah. Originally, I was fetching the config using the old javascript Ajax calls which forbade retrieving code "for security reasons" and required the awful JSONP workarounds. When I did the big refactor a few years ago, I switched to dynamically updating the DOM with a "script" element which caused the browser to just retrieve the config file like any other javascript file. I forgot all about that until I just looked at the code.

@stuartofmt You can indeed include javascript in the config file. It has a suffix of json to get around browser issues but it's actually parsed as a javascript file. In fact, you'll notice that the config is actually wrapped in a class named DueUIConfig. You can add a function to that class or just add it to the top level as a global function, then call it from a ${...} expression elsewhere in the config. In your example, you could create a a function called getProbeNum() that contains the code you posted modified to return the probe number, then call it like ...

"field": "${state.sensors.probes[getProbeNum()].value}"

I thought I had an example of this on the wiki but I don't see it now. I'll have to add it.

@stuartofmt I didn't see your first message, sorry about that. Not sure why. Glad you got it sorted. The reason you were seeing that message repeating as often as you did is because when you're in SBC mode, DueUI is connected to the SBC via a websocket and receiving streaming events. DueUI only goes into polling mode when it's connected directly to a Duet (Standalone mode).

@dc42 Are you going to do this or should I submit a pull request for it?

@Herve_Smith said in Alternative to DWC with R.R.F. ?:

Fluidd

Take a look at DueUI. I wouldn't classify it as "slick" but "slick" is a bit subjective anyway.

https://forum.duet3d.com/category/33/dueui
https://github.com/gtjoseph/DueUI/wiki

@dc42 said in 3.5: Linux build of CrcAppender isn't marked executable:

@gtj0 good idea! What does OsType resolve to on a Mac?

According to org.eclipse.core.runtime.Platform, OsType is one of...

public static final String OS_WIN32 = "win32";
public static final String OS_LINUX = "linux";
public static final String OS_MACOSX = "macosx";

There are others for aix, solaris, hpux, etc but I don't think we care about them

Actually, while we're talking about it, how about also changing CrcAppender in the post-build step that appends the crc to...

`"${workspace_loc:/${ProjName}/Tools/CrcAppender/${OsType}-x86_64/CrcAppender}"

On Linux, ${OsType} resolves to linux.
On Windows, it resolves to win32 (even on 64 bit).
Not sure about macos but it wold be easy enough to find out. Probably macos or osx.

It would require renaming the directories under Tools/CrcAppender but it would remove the need for users to copy the appropriate binary to a directory outside the project that's already in their PATH.