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

Comments

Projects
None yet
5 participants
@cakeller98
Copy link

commented Jan 9, 2014

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

This comment has been minimized.

Copy link
Owner

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

This comment has been minimized.

Copy link
Author

commented Jan 9, 2014

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

This comment has been minimized.

Copy link
Author

commented May 18, 2014

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

This comment has been minimized.

Copy link

commented May 27, 2014

+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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Author

commented Jul 9, 2014

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

This comment has been minimized.

Copy link

commented Dec 21, 2014

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

Base cut off point for temperature graph on timestamps instead of dat…
…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

This comment has been minimized.

Copy link
Owner

commented May 5, 2015

Fixed in devel

@foosel foosel closed this May 5, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.