Print Speed UI #343
Print Speed UI #343
Conversation
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.
c978200 to
70304b5
Compare
| from: 30 | ||
| stepSize:2 | ||
| to:180 |
There was a problem hiding this comment.
This is 50 to 166 now, since we don't extrapolate outside of the Bambu domain, right?
| const scalingFactor = interpolate(x, speeds, values) / func(x); | ||
| return func(x) * scalingFactor; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
| 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)) |
There was a problem hiding this comment.
Maybe the following might be more understandable?
| 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)) |
There was a problem hiding this comment.
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
| + 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 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}%` |
There was a problem hiding this comment.
- 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"?
| property var speedLabel: (Math.abs(currentSpeed-targetSpeed) > 0) ? `${targetSpeed} / ${currentSpeed}%` : `${currentSpeed}%` | |
| property var speedLabel: `${currentSpeed}%` |
There was a problem hiding this comment.
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
left a comment
There was a problem hiding this comment.
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!
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 see the issue here. The 'Apply' button dismisses speedPad by setting speedPad.target to null, which prevents it from resetting the property you mentioned.
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
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
|
is this going to be added to main soon? |
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.speedadjusttrue/false - decides whether to display OEM speed UI (false) or X1Plus UI (true)printerui.speedadjust.stepSizeinteger - step size of the dial (UI can toggle between 2 and 10%)