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

[Feature Request] - Print speed indicator #200

Closed
KenLucke opened this issue Sep 5, 2020 · 12 comments
Closed

[Feature Request] - Print speed indicator #200

KenLucke opened this issue Sep 5, 2020 · 12 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@KenLucke
Copy link

KenLucke commented Sep 5, 2020

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

@StefanCohen StefanCohen added the enhancement New feature or request label Sep 7, 2020
@StefanCohen
Copy link
Collaborator

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
Outer Wall: 50
Inner Wall: 60
Top Surface Skin: 50
Top/Bottom: 60
Travel: 250
Initial Layer Speed: 30

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?

@KenLucke
Copy link
Author

KenLucke commented Sep 7, 2020

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

@StefanCohen
Copy link
Collaborator

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?

@KenLucke
Copy link
Author

KenLucke commented Sep 7, 2020

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 :)

@j7126
Copy link
Owner

j7126 commented Sep 27, 2020

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

@j7126 j7126 self-assigned this Sep 27, 2020
@StefanCohen
Copy link
Collaborator

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.

@StefanCohen
Copy link
Collaborator

StefanCohen commented Sep 28, 2020

Example: Add this to send_notifications in order to log the feedrates:

if event == "DisplayLayerProgress_feedrateChanged":
            self._logger.info("Feedrate: " + str(float(payload.get("feedrate")) / 60) + "mm/s")

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:

from collections import deque
feedrate_ts = deque([], maxlen = 10)
...

if event == "DisplayLayerProgress_feedrateChanged":
            self.feedrate_ts.append(float(payload.get("feedrate")) / 60) #store in mm/s
            self._logger.info(sum(self.feedrate_ts) / len(self.feedrate_ts)) #average of the last 10 moves

gauge.js seems like a nifty visualization for this.

@j7126 j7126 added this to the 1.17.0 milestone Dec 14, 2020
j7126 added a commit that referenced this issue Dec 30, 2020
@j7126
Copy link
Owner

j7126 commented Dec 30, 2020

ready for next release

@ChuckRider
Copy link

ChuckRider commented Jan 1, 2021 via email

@j7126 j7126 closed this as completed Jan 11, 2021
@KenLucke
Copy link
Author

Any thoughts on when this version will be released?

@Willmac16
Copy link
Collaborator

The new version was just released. You may need to force refresh in the software update tab if you want it right now.

@KenLucke
Copy link
Author

Kewl. I have a few prints going right now, when they're done, I'll install it. Thanks (in advance) for the new feature!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants