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

drgeoffb commented 3 months ago

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

[X] Systeminfo Bundle (always include!) See here if you don't know where to find that.
[X] 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

dashboard-feedrate-before dashboard-feedrate-after fix_gauge.patch octoprint-systeminfo-20240318154301.zip

drgeoffb commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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...

j7126 / OctoPrint-Dashboard