-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Comments
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... |
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!! |
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) |
+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! |
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. |
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? |
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. |
…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
Fixed in |
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...
The text was updated successfully, but these errors were encountered: