@johnmaundrell I reported this year's ago and even provided a video. Deny deny deny...

@Phaedrux I imagine someone has 2 toolboards somewhere at Duet. This can't possibly be a reasonable "stable" release. It's starting to go beyond the pale with how basic the bugs are getting.

Please see this post, I'd like to get some love (and configure my tools)

https://forum.duet3d.com/post/308709

I know this is going to be a hard pill to swallow, but I'm going to do my best to explain myself.

The current web interface has many, many problems, and I think they're mostly to do with the approach taken, which is why I'm suggesting a re-write.

For brevity I'm going to refer to the versions as D3 and D2.

My test systems are below.
Workstation: AMD TRX-Pro 3975wx w/128GB RAM
Mobile Phone: Google Pixel 6 Pro w/12GB RAM
Tablet: HP Chromebook X2 - Snapdragon 7c w/8GB RAM

User Experience

Full Page Load

Here is a comparison of 2 full page loads while a job is running from my desktop PC

DWC 2

D2 loads in less than 1.75sec, the scale of 2000ms is just to provide scale, the subsequent requests after 1750ms are just status refreshes.

DWC 3

D3 takes 9 seconds to load.

All of those blue and green lines are files or requests the page has to load before you can interact with it

Computational Burden

Here are some comparisons of what's happening underneath the covers.

Main Process/Thread Tree
D2 on the left, D3 on the right

Page Drawing Rasterizing

Other Resources

Mobile Usability

• When interacting with D3, it's easy to accidentally click something you don't want to.
• The user interface has behaviors of it's own, like sliders adaptively scaling themselves. This is not a positive.
• Text editors are not usable on mobile because you can't select text to copy and paste it.
• It's hard to click or slide and be confident that it's doing what you expect. It feels like it has a mind of it's own, interpreting where you're tapping and then figuring out what you meant to tap; as opposed to just tapping a page control and triggering it.

General Usability

• D3 frequently disconnects from the printer.
• The navigation outline organization is less intuitive and more opinionated, just go back to the D2 layout.
• The interface has a feel much more like a DataDog dashboard than a control plane for a piece of hardware.

Conclusion

It's hard to quantify the rest, but it just feels bad to interact with. I know the technology used to create it, and I've expressed this before, but it was the wrong choice. It should really be much lighter and not worry about being a Progressive Web App and be much more like D2.

@alankilian I'm not complaining about anything. I'm asking a question based on my understandings and hoping someone can either corroborate or correct me.

Try actually reading the post instead of being offended by the title.

@T3P3Tony that's true, but that's the exception that should be coded for. One observation, it doesn't seem like the tool boards like being hot swapped, they pop when you plug power in while it's on.

I don't know how aware everyone is, but a few years ago when 3D printers proliferated and cheap clones started popping up with no thermal runaway safeguards, all of the influencers started shredding them, just ripping their reputations apart, telling followers to not buy any of brand X, Y, Z and maybe not even after they fix it, wait a couple generations.

I don't think it would be very good PR for Duet if that started happening again.

I see it this way...

Implementation

1. The Input Shaping plugin measures straight line movements, one at a time.

2. There is also an option to not record from the very beginning of the move, I assume because that would show a large impulse at the beginning.

Someone please correct me if I'm wrong, but isn't Input Shaping for smoothing out changes in velocity?

Problems with Implementation

1. There is nearly no change in velocity for a single, straight line segment that is both fast and high acceleration, shouldn't it be recording explicit velocity changes only? The current way just measures vibration and not the effect of corner changes or speed changes.

2. Why would you not record the beginning of the movement? There are many different circumstances where the tool head will be moving from a dead stop.

After using duet hardware for the last 5 years, I've finally realized that one of the most commonly used instructions is wrong.

When using multiple Z motors, you use M671 to describe where your lead screws are so the board knows how much to adjust each screw to tram the bed.

That is wrong. You describe where the pivot point for each screw is. It makes a huge difference.

So much, that not until now had I EVER had a close to perfect repeat tram.

To put all potential arguments to bed...

Imagine your lead screws are 1 km away from your bed in X. You have a 300mm square bed with mounting points 30mm away in X, meaning your brackets are 1km-30mm long.

Would you tell it that your lead screw offset is 999970mm away in the X direction? No, that would result in literally zero adjustment.

I would be happy if the behavior was a config toggle between 2 modes

1. baby steps never persist across resets of the system, it's up to the end user to manage them, they don't get reset by any command other than the baby step gcode - I believe this is the current behavior

2. baby steps are treated as a fixture of the calibration of the system, so they persist across resets of the system and all other activity and their display is only via modal windows and the console.

Basically a baby steps vs. live-z switch.

@bearer that's exactly what I'm talking about... That's not always how it works. What about a printer that is in development and not everything is perfect? And, if the controller is being used in a CNC machine, that's REALLY not how it works.

@dc42 no, i don't think it is, but I don't think they shouldn't be able to override it if they want that ability. I think the reason why people have said they don't want it this way is because they're used to thinking about bs-ing in a certain way. That's why it deserves serious analysis, not whimsical forum threads.

IMHO, no mater which way you implement baby-stepping, if it's not fool-proof and consistent it's not right.

If I think of every g-code I know and how black-and-white it's behavior is, then think about how bs-ing is treated, bs-ing is the odd one out. It shouldn't take a flow chart to figure out how to configuring a z-offset.

Rather than thinking about bs-ing being a probe offset or end stop adjustment or a +/- on a widget, just treat it as what it is -- a Z correction.

I guarantee you, GUARANTEE, the way I'm suggesting will simplify things greatly. But you don't have to take my word for it. Do the analysis by use case and personas. Every single interaction will be much easier to understand, not require flow chart logic to configure, and will have predictable behavior. That is exactly what is missing from all of the other implementation ideas.

Like I said before. I'm happy to do that analysis and present it to the thread.

And, if I'm wrong, we at least potentially have a common framework for how to analyze features.

@dc42 that's no better. It doesn't solve any of the problems I mentioned about having to remember things, having to add code to the stop script is no different than having to remember to add it to the home script. All this change is doing is moving the pain from one place to another with no reduction in complexity.

Please, think about my proposal and give it some time. Go look at Prusa and play with the Live-Z.

additive mode - persist baby-steps, do not change the Z position on screen

subtractive mode - never persist baby-steps, do change the Z position on the screen

That, I believe will work for everyone. Yes, it's a paradigm change, so it takes some effort and will to really give it a fair chance, but I think it's worth exploring. This way, there is no guesswork. No custom script entries. It just works.