[Bug]: Graphical inconsistency in #dashboardFeedrateAvg element of FeedRate widget (with fix)

[drgeoffb]

The problem

The 'Tool Temperature' and 'Bed Temperature' widgets shows target temperatures in
the form of a narrow arc centred within the present temperature arc.

The 'Feedrate' widget displays the #dashboardFeedrateAvg arc aligned with the
outer edge of the #dashboardFeedrate5Avg arc.

This doesn't affect functionality, it's just visually inconsistent.

Tweaking the setup coordinates for the #dashboardFeedrateAvg ark in file
/octoprint_dashboard/templates/dashboard_settings.jinja2 makes the
Feedrate widget visually consistent with the others.

Fix:

Sorry, I'm not sufficiently git-literate yet to prepare a patch / pull request, but this
little patch achieves my proposed fix:

--- dashboard_tab.jinja2	2024-03-18 15:00:56.057136900 +1100
+++ dashboard_tab-patched.jinja2	2024-03-18 15:14:54.701838700 +1100
@@ -608,7 +608,7 @@
               stroke-dashoffset="120" style="transition: stroke-dashoffset 1s;"
               data-bind="attr: { 'stroke-dashoffset': Math.abs((feedrateAvLastFiveSeconds() / dashboardSettings.feedrateMax()) * 120 - 120)}">
             </path>
-            <path id="dashboardFeedrateAvg" d="M16 50a44 44 0 1 1 88 0" stroke="#85c6c6" stroke-dasharray="138.2"
+            <path id="dashboardFeedrateAvg" d="M22 50a38 38 0 1 1 76 0" stroke="#85c6c6" stroke-dasharray="138.2"
               stroke-dashoffset="138.2" style="transition: stroke-dashoffset 1s; stroke-width:4;"
               data-bind="attr: { 'stroke-dashoffset': Math.abs((feedrateAv() / dashboardSettings.feedrateMax()) * 138.2 - 138.2)}">
             </path>

Version of OctoPrint

1.9.3

Platform

Orange Pi Zero +, armv7l

Operating system running OctoPrint

Linux newpearl 6.1.63-current-sunxi #1 SMP Mon Nov 20 10:52:19 UTC 2023 armv7l armv7l armv7l GNU/Linux

Dashboard version

1.19.10

Python version

3.10.12

Printer model & used firmware incl. version

E3V3SE

Browser and version of browser, operating system running browser

Chromium 116.0.5845.141, Firefox 116.0.3, OrcaSlicer internal 2.0.0-beta (on Win10x64 desktop)

Logs and other files needed for analysis

• Systeminfo Bundle (always include!) See here if you don't know where to find that.
• Screenshots and/or videos showing the problem (always include in case of issues with the user interface)
• GCODE file with which to reproduce (always include in case of issues with GCODE analysis or printing behaviour)

File uploads & additional information

fix_gauge.patch
octoprint-systeminfo-20240318154301.zip

[drgeoffb]

My screenshots were taken maybe 1 minute apart on a running system (job approx 1hr length), so
I don't expect identical values, however, the feedrate average (black arc, the focus of this bug) seems
to have moved more than might be expected.

My patch doesn't change any 'live' parts of the graphic, but perhaps there's a follow-on effect (or
fix?) in the way the arc represents the value?

[j7126]

I think this would change the overall length of the stroke, meaning that the stroke-dasharray and calculation of stroke-dashoffset would also need to be changed in order to ensure the data displayed appears correct.

[drgeoffb]

I think this would change the overall length of the stroke, meaning that the stroke-dasharray and calculation of stroke-dashoffset would also need to be changed in order to ensure the data displayed appears correct.

I do tend to agree with you; that's pretty much why I mentioned it before... however... an unscientific observation just now... printing a job in 'vase mode' in which flow/feed rate should be pretty much constant throughout the job, all three indicators - dashboardFeedrate5Avg, dashboardFeedrateAvg and dashboardFeedrateLive - are consistently aligned...