-
Notifications
You must be signed in to change notification settings - Fork 39
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
[Feature Request] - Print speed indicator #200
Comments
Thanks for the feedback. I get the Idea but I don't see how practical it would be. A typical slicer will set different speeds for various movements. For example (My current print settings): Infill: 100 I imagine that that a current print speed would constantly jump between these values. During a typical layer it would switch like crazy between 250, 100, 60 and 50. What do you think? |
Well, it's more of an OCD thing for me. :) The layer height display indicator jumps constantly, too, as zhops and layer changes happen, so it would not be the only one jumping like crazy. :) I guess it's the ex-pilot thing coming out in me, wanting to know every possible detail of what's going on on my "dashboard." |
I understand. I'm not saying that it would be impossible or even undesired. I just don't see the value for me personally as it would be a blur on most of my prints. Maybe some kind of average speed during the last few seconds would be more interesting? |
Maybe toggleable between the two? Or Current/Average display (both), with the average time frame a preference? I know, I'm just being OCD, as I said :) |
I think instead of a current display (as it would be constantly changing) what would be more practical would be Average(last 5 seconds)/Average(total)/Maximum |
It is possible to get feedrate, feedrateG0 and feedrateG1 from DLP. The event handler in Dashboard already supports them but you will need to add the event listener for "DisplayLayerProgress_feedrateChanged". I would recommend to break it out to a separate event listner as that event would fire very frequently. Then aggregate the readings in an array and calculate an average using a rolling time window. The average can then be sent to the frontend less frequently together with the other stats. |
Example: Add this to send_notifications in order to log the feedrates:
The feedrates could then for example be added to a time-series data structure (list of dicts?) and the average could be calculated with pandas before it is sent to the front-end. An simpler solution would be to store the last n moves in a deque and send the average. Something like this:
gauge.js seems like a nifty visualization for this. |
ready for next release |
Been running it through its paces this evening. Looks great!
Everything seems to be working as it should. If I were going to provide
any suggestions it would be to either remove the word Tool from the
hotend temp gauge or add the words bed and fan to the other two. That
would provide a more consistent look. That is being nit-picky though,
it looks and works great.
Jefferey Neuffer wrote on 12/29/2020 10:55 PM:
…
ready for next release
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#200 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOAPIXK5CVS6FNQPIYYE2JDSXKXF5ANCNFSM4Q3QWNSA>.
|
Any thoughts on when this version will be released? |
The new version was just released. You may need to force refresh in the software update tab if you want it right now. |
Kewl. I have a few prints going right now, when they're done, I'll install it. Thanks (in advance) for the new feature! |
I'd like to see [in among the static, non-addressable information displays, similar to the layer height and others] a simple indicator of the current print speed (in mm/second). Should be able to be read from the G0/G1/G2/G3 Fxxxxxx gcode strings
The text was updated successfully, but these errors were encountered: