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

More Relevant Time Scale #343

Closed
cakeller98 opened this issue Jan 9, 2014 · 8 comments
Closed

More Relevant Time Scale #343

cakeller98 opened this issue Jan 9, 2014 · 8 comments
Labels
determine feasibility Not yet clear whether this can be implemented at all request Feature request

Comments

@cakeller98
Copy link

I'd like to request a more relevant time scale. It's really great to have a lot of history, but I use octoprint as a server... and hence leave it on all the time. what that means is - when the printer is idle octoprint gathers thousands of minutes of data... and displays it all at the same scale.

would be great if the time scale was logarithmic, so the latest information always has the highest level of detail while the oldest data gets more and more compressed.

IOW - the right 1/2 the graph should show the last 5 minutes always, then the next 1/4 would show the last 50 minutes, then the next 1/8th 500, then the next 1/16 5000....

or some form of that...

@foosel
Copy link
Member

foosel commented Jan 9, 2014

First of all: I'm interested in the logarithmic idea and will look into that.

Now, that your server appears to gather thousand of minutes of data appears to be a bug. It should actually only keep the 300 most recent data points, both on the server and on the client. Are you sure that nothing is suspending here? Because that might throw this clean-up off...

@cakeller98
Copy link
Author

oh... yes, my server does go to sleep... so it must have only 300 pts of data.... I always clear it because I want to know how much longer it's going to be heating for. So I've never waited to see if it clears. I bet it does.

That said - a simple idea would be having some way to flush the cash manually.

Thanks for listening... and great work on OctoPrint it is just GREAT!!

@cakeller98
Copy link
Author

So since my server does go to sleep, and the log ends up with data outside a reasonable time period, is it possible to either have a flush-cache button, OR have Octoprint automatically detect time ranges that would make it difficult to read the graph? IOW - it takes a long time for 1000-2000 minute old data points to get flushed. In the mean time the relevant data-points of the last 5 minutes are all squished up into the right most 2 pixels.

A very simple solution(I think), is just to clamp the time scale to a maximum of some minutes (ideally configurable by the user in settings)

@brandonheller
Copy link

+1: I also suspend my OctoPrint computer when not in use and after a wake-up and print, the timescale doesn't have more than 1 pixel for the last few minutes, making the graphical temp display useless. I don't think logarithmic is the way to go - it would distort the heat/cool curves. A simple cap on the last N minutes of data would be great. Thanks!

@sprior
Copy link

sprior commented May 27, 2014

I turn off the printer, but keep OctoPrint running on the Pi, so maybe it is keeping the last 300 points, but there was a gap in the timestamps. If that's true then maybe what needs to be done is to throw away data points even within the 300 when there is a time gap.

@cakeller98
Copy link
Author

that is exactly what's happening @sprior. And the same thing that happened to me. I agree OR perhaps throw an event that is "offline" and another "online" and use those to compress that period of time to zero. IOW if there's a time that the printer is offline - then that time should be squished to a single pixel wide...

though a logarithmic scale could also be more useful anyway. Where the time scale gets more and more coarse as we move to the right, and perhaps the points should be only time...

first 25% represents the last 2 minutes, next 25% represents the next 20 minutes, the next 25% represents the next 200 minutes, and the last... 2000 minutes. And seriously, anything beyond 2222 minutes, would anyone care?

@msmollin
Copy link

Just wanted to +1 this as well. If you point me towards the right direction in the code, I can make an attempt to try to fix this.

foosel added a commit that referenced this issue May 5, 2015
…a points

Cut off of the temperature graph is now not based on the number of data points any more but on the actual time of the data points. Anything older than ``n`` minutes will be cut off, with ``n`` defaulting to 30min. This value can be changed under "Temperatures" in the Settings

Closes #343
@foosel
Copy link
Member

foosel commented May 5, 2015

Fixed in devel

@foosel foosel closed this as completed May 5, 2015
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
determine feasibility Not yet clear whether this can be implemented at all request Feature request
Projects
None yet
Development

No branches or pull requests

5 participants