Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
2 of 3 tasks
drgeoffb opened this issue Mar 18, 2024 · 3 comments
Open
2 of 3 tasks
Labels
bug Something isn't working

Comments

@drgeoffb
Copy link

drgeoffb commented Mar 18, 2024

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

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

@drgeoffb drgeoffb added the bug Something isn't working label Mar 18, 2024
@drgeoffb
Copy link
Author

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
Copy link
Owner

j7126 commented Mar 19, 2024

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants