Print Speed UI by jphannifan · Pull Request #343 · X1Plus/X1Plus

jphannifan · 2024-07-08T23:57:41Z

Wiki page: https://github.com/X1Plus/X1Plus/wiki/Speed-Adjust-UI

Screenshot as of 09/16:

Please see the wiki page for an extensive overview of this feature.

Settings keys:
printerui.speedadjust true/false - decides whether to display OEM speed UI (false) or X1Plus UI (true)
printerui.speedadjust.stepSize integer - step size of the dial (UI can toggle between 2 and 10%)

This branch was a month behind main, and there are only two files so it's easier ot cherry pick. Commit notes for the most recent commits: - Improved touch input handling (fixed dead zones on dial) - Localized print speed strings, step size button caption - Fixed boundary conditions for dial - Print time estimate is now displayed next to the dial (a print job must be active)

Added an interpolation function to printSpeed() in GcodeGenerator.js that ensures that the gcode parameters for 50, 100, 124, and 166% are the same as they are for the OEM speed profiles.

jwise · 2024-09-08T06:56:03Z

+            from: 30
+            stepSize:2
+            to:180


This is 50 to 166 now, since we don't extrapolate outside of the Bambu domain, right?

jwise · 2024-09-08T06:57:59Z

+            const scalingFactor = interpolate(x, speeds, values) / func(x);
+            return func(x) * scalingFactor;


haha wait dividing by func(x) and then multiplying through by func(x) is just the same as multiplying by 1, right? so the func(x) is not used here at all, and this only does the linear interpolation, right?

The ratio is between linear interpolation of the "theoretical" value vs the linear interpolation of the "actual" value.

This happened by accident, and I am now realizing I should have just used cubic spline interpolation because interpolating interpolated data is not exactly logical to me.

This results in a smoothed linear interpolation very similar to cubic spline interpolation

jwise · 2024-09-08T07:10:47Z

+            text:qsTr("Acceleration:\n%1\nFeed rate:\n%2\nTime:\n%3")
+                .arg(speedParams.accelerationMagnitude.toFixed(2))
+                .arg(speedParams.feedRate.toFixed(2))
+                .arg(speedParams.speedFraction.toFixed(1)) 


Maybe the following might be more understandable?

Suggested change

text:qsTr("Acceleration:\n%1\nFeed rate:\n%2\nTime:\n%3")

.arg(speedParams.accelerationMagnitude.toFixed(2))

.arg(speedParams.feedRate.toFixed(2))

.arg(speedParams.speedFraction.toFixed(1))

text:qsTr("Acceleration:\n%1%%\nFeed rate:\n%2%%\nTime:\n%3%%")

.arg((speedParams.accelerationMagnitude*100.0).toFixed(0))

.arg((speedParams.feedRate*100.0).toFixed(0))

.arg((speedParams.speedFraction*100.0).toFixed(0))

I think I'm also going to add a tooltip button in the upper right corner so that users don't have to hunt for documentation to figure out what these numbers mean

jwise · 2024-09-08T07:14:27Z

+    property var speedValues: [50,100,124,166] // corresponding to PrintManager.currentTask.printSpeedModeStrings
+    property var speedStr: [3,2,1,0].map(n => PrintManager.currentTask.printSpeedModeStrings[n])


I think this is unused now?

jwise · 2024-09-08T07:18:07Z

+    property alias speed: dial.value
+    property var targetSpeed:100
+    property var currentSpeed: PrintManager.currentTask.printSpeed
+    property var speedLabel:  (Math.abs(currentSpeed-targetSpeed) > 0) ? `${targetSpeed} / ${currentSpeed}%` : `${currentSpeed}%`


I believe that conditional is usually spelled currentSpeed != targetSpeed.

I'm sort of thinking that maybe we do not need that anyway? Like maybe this should always be ${currentSpeed}%, since it reflects what state the printer is in right now, and the change only takes place when you click "apply"?

Suggested change

property var speedLabel: (Math.abs(currentSpeed-targetSpeed) > 0) ? `${targetSpeed} / ${currentSpeed}%` : `${currentSpeed}%`

property var speedLabel: `${currentSpeed}%`

The main reason this exists is because I had initially made a "ramp" feature that would adjust speed at layer changes. Since there is no case now where targetSpeed should differ from currentSpeed, it's definitely not necessary.

For now I'm saving the ramp feature for later. I think we nearly have a framework that makes onLayerChange gcode macros fairly easy to do

jwise

Looks pretty good! I think I would be good with this, though I would appreciate if you would fix the few nits that I highlighted. The other bug I noticed is that if you click on the speed adjust and then click away from it, then it dehighlights:

But if you click on it, and then click apply, then it stays highlighted:

I think the tempList.currentIndex isn't getting reset to -1 in that case?

Also I seriously do not understand how PrintManager.currentTask.printSpeed ends up getting set to the correct percent. Like when I set it to 136%, the Gcode published is M73.2 R0.73, which is OK, because 1/0.73 is 1.369, and the floor of that I guess is 136%. But when I set it to 132%, the Gcode published is M73.2 R0.75, and 1/0.75 rounds to 133.3%! Does it, like, floor() to the nearest 2% or something? How does it... know?

Thanks for pushing this all the way through. It's cool to see people really wanting this in the field. Let's get it to them!

jphannifan · 2024-09-08T21:55:30Z

Looks pretty good! I think I would be good with this, though I would appreciate if you would fix the few nits that I highlighted. The other bug I noticed is that if you click on the speed adjust and then click away from it, then it dehighlights:

Thanks for taking a look and I appreciate the feedback. I have a couple improvements I want to make and I have revisions for each of your comments, and I'll wrap that up today.

I think the tempList.currentIndex isn't getting reset to -1 in that case?

I see the issue here. The 'Apply' button dismisses speedPad by setting speedPad.target to null, which prevents it from resetting the property you mentioned.

Also I seriously do not understand how PrintManager.currentTask.printSpeed ends up getting set to the correct percent. Like when I set it to 136%, the Gcode published is M73.2 R0.73, which is OK, because 1/0.73 is 1.369, and the floor of that I guess is 136%. But when I set it to 132%, the Gcode published is M73.2 R0.75, and 1/0.75 rounds to 133.3%! Does it, like, floor() to the nearest 2% or something? How does it... know?

This one makes no sense to me either.. First off it does the calculation on the MC board apparently, and this value is shared with the slicer via MQTT. I guess since it's calculating the time remaining, that is most accurately done on the MC board. I haven't found a single value that will result in an odd-numbered print speed. It's always rounded down to the closest even. Second this suggests that the printer is very confused about what time it is. You can adjust M73.2 R to make it report anywhere from 0% to 500% regardless of the other parameters. I'm glad you convinced me to correct the calculations especially after realizing this.

Thanks for pushing this all the way through. It's cool to see people really wanting this in the field. Let's get it to them!

Took me longer than it should have but I think we could have a release candidate ready within the next month or two maybe? Depending on what the timeline is for the expansion board

Instead of doing `parent.parent.parent.parent.parent.parent.target = null` we pass a signal from SpeedAdjust to AdjustPage to close the window properly

- Removed some unused code - Adjusted dial range to the range of interpolated values

Replaced the old interpolation method with one that actually makes sense: Interpolation and extrapolation now done on acceleration magnitude vs. feed rate data. Linear extrapolation used for 30 to 50% region and cubic spline interpolation used for 50 to 166% region.

Enforce the upper limit of the dial based on step size, otherwise touch input is handled inconsistently

- fixed the bug where the dial did not update properly if you apply a speed and then quickly reopen the speed UI - "Print time" text is no longer clipping the edge of the window - current speed and target speed are each drawn as arcs on the dial

Glod76 · 2024-11-21T04:26:06Z

is this going to be added to main soon?

ghost · 2025-12-11T18:04:14Z

Has this been completed or abandoned? More than a year without an update on this.

jb1228 · 2026-01-02T16:42:36Z

@jwise Is there anything else that needs to be done with this PR?

For whatever reason (hopefully nothing too bad 😟), there has been no activity from @jphannifan since 2024.

jphannifan requested review from bani6809, jwise and riptidewave93 July 8, 2024 23:57

riptidewave93 approved these changes Jul 9, 2024

View reviewed changes

jneilliii mentioned this pull request Jul 21, 2024

Ability to change flow ratio by X% mid-print. #349

Open

jphannifan added 2 commits September 7, 2024 12:34

Make 100=100

70304b5

Added an interpolation function to printSpeed() in GcodeGenerator.js that ensures that the gcode parameters for 50, 100, 124, and 166% are the same as they are for the OEM speed profiles.

jphannifan force-pushed the jon/qml-speed-adjust branch from c978200 to 70304b5 Compare September 7, 2024 19:36

silly error

86e6fbf

jwise reviewed Sep 8, 2024

View reviewed changes

jwise approved these changes Sep 8, 2024

View reviewed changes

jphannifan added 3 commits September 10, 2024 12:55

fix property issue - SpeedAdjust.qml 'Apply' button

2f54d26

Instead of doing `parent.parent.parent.parent.parent.parent.target = null` we pass a signal from SpeedAdjust to AdjustPage to close the window properly

Cleaning up

74d701b

- Removed some unused code - Adjusted dial range to the range of interpolated values

jphannifan requested a review from jwise September 16, 2024 17:41

jphannifan added 2 commits September 18, 2024 22:49

Fix issue with upper limit of dial

445a0dd

Enforce the upper limit of the dial based on step size, otherwise touch input is handled inconsistently

currentSpeed signal + other improvements

9407b88

- fixed the bug where the dial did not update properly if you apply a speed and then quickly reopen the speed UI - "Print time" text is no longer clipping the edge of the window - current speed and target speed are each drawn as arcs on the dial

		const scalingFactor = interpolate(x, speeds, values) / func(x);
		return func(x) * scalingFactor;

		+ property var speedValues: [50,100,124,166] // corresponding to PrintManager.currentTask.printSpeedModeStrings
		+ property var speedStr: [3,2,1,0].map(n => PrintManager.currentTask.printSpeedModeStrings[n])

	property var speedLabel: (Math.abs(currentSpeed-targetSpeed) > 0) ? `${targetSpeed} / ${currentSpeed}%` : `${currentSpeed}%`
	property var speedLabel: `${currentSpeed}%`

Conversation

jphannifan commented Jul 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jwise Sep 8, 2024

Choose a reason for hiding this comment

Uh oh!

jwise Sep 8, 2024

Choose a reason for hiding this comment

Uh oh!

jphannifan Sep 8, 2024

Choose a reason for hiding this comment

Uh oh!

jwise Sep 8, 2024

Choose a reason for hiding this comment

Uh oh!

jphannifan Sep 8, 2024

Choose a reason for hiding this comment

Uh oh!

jwise Sep 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jwise Sep 8, 2024

Choose a reason for hiding this comment

Uh oh!

jphannifan Sep 8, 2024

Choose a reason for hiding this comment

Uh oh!

jwise left a comment

Choose a reason for hiding this comment

Uh oh!

jphannifan commented Sep 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Glod76 commented Nov 21, 2024

Uh oh!

ghost commented Dec 11, 2025

Uh oh!

jb1228 commented Jan 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jphannifan commented Jul 8, 2024 •

edited

Loading

jwise Sep 8, 2024 •

edited

Loading

jphannifan commented Sep 8, 2024 •

edited

Loading