Changing the Time scale #5
Comments
|
Ah, nice thanks, I had to finish some other stuff first, but I'll look into it tonight. And BTW, not to be a smart-ass, but it's all javascript, not java. There is a big difference, even though the names imply similarity :) |
|
Ach! That was me trying to type quickly on my phone ;) |
|
Could you pull and try how that feels (in terms of the graph display)? You still have to add/edit the points in the curve editor in seconds but at least the graph will show a somewhat more sensible timescale, automagically scaling after 1800 sec (30 min) for now. I've been thinking about this a bit and would really like to give picoReflow a complete UI refactoring but the time is too tight right now. I think the next sensible solution will be to add some ui element in the curve editor, where the user can simply switch between seconds and hours(including minutes), whatever is preferred for the particular use case. And I would like to have the tickFormater lock on 0 and maybe 15/30 minute ticks, not every odd or even minute inbetween, it seems too confusing to me (as it is now with #d782185). Unfortunately I ran out of time for my budget today, so depending on where you are, you might be just getting up and can test it and tomorrow when I wake up there will already be feedback :) |
|
Having the graph automagically scale is something that I never considered, and it seems to work pretty well! I agree that having the tick labels read in even 10 or 15 minutes increments would make the graph easier to read, but the last point on the graph could get tricky. Would you make the last column short so it lands on the point? Or allow the graph to overflow, and have a dead spot at the end? The first option is the more friendly (although probably not friendly to code). Really it would be best to do the same for the temperature axis as well. I've been resetting the max temp to 1300C. Having it auto scale to the highest temp value would make the whole thing more versatile (even for my application I can peak at 250, 600, 1000 or 1300C). You of course have the same odd tick label values. Here overshooting would be fine, I think. I was also thinking about the time entry, and was thinking of just having 3 entry boxes per data point (hours/minutes/seconds). That way the user could enter into any field they wanted, and let the script convert it all into seconds in the background. The user could choose what they wanted to enter, even if it was all in seconds. Right now there's no way for the profile to remember that I entered 120 seconds and not 2 minutes. It would probably need to convert what ever was entered into hh:mm:ss. Would this be an issue? I don't think so . For me, once its entered, the converted format is easier to read. Even now the total time and ETA are converted. Also, my "professional" reflow oven at work uses mm:ss... :-) This is an awesome start! And I should be able springboard off this new code to make some further modifications. Thanks so much for your help!! I'll share back with an update. By the way, I was wondering if you had any thoughts on visualizing the fan control? Having the fan icon turn on when the fan is on is good, but what about setting times for the fan to turn on, ramp speed with the mosfet, or show on the graph? Would you show it as another line on the graph with fan speed (in % power) on the right axis? I'd appreciate your thoughts/plans. |
|
Hey scott, sorry for the delay but I'm really in a bad spot right now and except for the critical factor of my forcefully wasted lifetime, my mind is not in the best of spirits to just let go and dig into it. I very much appreciate your feedback though and I'd love to come up with a quick fix but the more I look at the code the more I want to get rid of all this messy original proof-of-concept code and refactor the client to make all these valuable thoughts and considerations much easier to implement than in its current state. It makes no sense to minimize the area of impact of this software by constraining it to reflow soldering purposes. It should be just called picoPID and highly configurable to any kind of hardware and use-case (seconds/mm:ss/hh:mm) that needs comfortable web based PID temperature control. I see this often, that there are plenty of different cases where the user should actually be able to decide how the app presents itself, to give maximum freedom and range of use cases, we maybe didn't even consider. Hell, I could even see an internal scheduler, where you could just connect, create/select a curve and schedule a time to run (cron/at functionality), done. If you were willing to offer some time we could come up with some from of structure what we basically want (feature/infrastructure wise) and use this as a guide for a more efficient/structured development process... what do you think? |
|
Sorry, I was away from my computer the last 2 days due to the holiday. I would of course be willing to help however I can. Having a programmable PID controller with added event control would be AWESOME!! |
|
Alrighty then, that's the spirit :) I've opened a new pad to make collaboration a bit more friendly and structured than messing around back and forth in ticket comments. When ever you've got time or are thinking/reflecting about it go to: https://apollo.open-resource.org/pad/picoPID I've begun to abstract the the actions, elements and possible flows in a crude draft. But this only covers the inevitable boundaries of my own universe and needs/views. I would very much like to see your view/experience and use cases/interaction scenarios in there as well to figure out what probably everyone will need (basic set) and which features should come optional/configurable so that everyone can adjust the system's behavior, actor availability/control and user interface appeal to either global defaults, per-curve overrides or client setting overrides to achieve the least amount of pre-determination towards specific use cases and make it usable in as many contexts one can imagine. Just add the things you would like to see as well, even if conflicting with already existing stuff. When we're done with summing up what we both want we can start to compromise and divide it down again to simple packages which should be easy enough to tackle. It would also be great to collect more feedback of people who would also like to have something like this and also can contribute their scenarios as well. So, if anyone else reads this and has something to contribute then go to the pad and add it. If you know people hacking around with ovens/reflow/kiln or closed-loop temperature control systems in general, send them a link to get their feedback. The more data we collect now, the better we can analyse what people really need from a broad perspective, to work out a really useful, open-source PID control system, which is comfortable and intuitive to use, preferably from a mobile device like a tablet. |
|
Sorry for taking so long to reply. I got thrown a ridiculous deadline that took all my time. Its done now, so I'm back in action! Honestly what you've got looks great. I made a few suggestions/comments. |
|
I just wanted to let you know that I ran a complete firing using the system, and other then the MAX31855 ground fault problem others are getting (which I just had the code ignore), and having to swap the SSR output, the run went GREAT! The PID loop was right on with out any tweaking! I did have a small issue of the websocket being slow/non-responsive after 5-6 hours of run time. Other then not being able to monitor the system well, it ran smoothly. Any ideas how to fix this? Could it be that I jut have too many data points after 5 hours and its lagging the whole system? Thanks for sharing this code, and I'm definitely looking forward to the picoPID! |
|
Nice, I'm happy that it kinda works for you :) Now we just have to iron out the bugs. Using PID for temperature control is actually completely overblown, as a german idiom would say, firing cannons at sparrows but it's a proven and reliable technology, so we figured it wouldn't hurt. Thanks for using, testing and coming back and reporting to help improve it. |
|
Is there an easy way in the code, like add a time multiplier, to only store data points every 5 seconds or so? Even 30 seconds would probably be fine in my situation. That might alleviate the resource drain of having millions of data points after a long run. |
|
Nope, not yet anyways and I don't think that is really the issue. Of course we could think about building some input throttling but today storage is cheap and available and leveldb is is pretty robust and scales very well up and down. The issue is the aggregation when querying, which has to kick in automatically if the query would return a dataset that is too big for the browser to handle so that we can have both, a macroscopic view, showing the whole timeframe aggregated to viewer points and the ability to "zoom" in, with full data resolution in a microscopic view which might help with other things. |
Here is the question I posted on your other site (as requested). I assumed that since this wasn't an error in the code, it wasn't a true "issue". I posted my original post as well as your reply and my response:
scott
2014/11/23 19:46
This is great! I've been pouring over the code trying to convert it to a ceramic kiln controller. To do so, I need to change the time scale from seconds to minutes. I would assume that I would be able to add a *60 scale to where the code reads the profiles, but cant seem to see where to input it. Any tips? I'm fine with the code running in seconds (even if its a bit overkill for the thermal inertia my kiln has), but I would like the display and profile input to be in minutes. A 12 hour run on the kiln becomes a bit silly in seconds :)
Thanks for your help and awesome code!
chrono
2014/11/23 20:00
Do you mean in the python or in the UI part of the code? We've opted for the most efficient integer SI unit for storage and calculation, which are seconds. The UI part was originally designed for Reflow Curves, which are short enough to be displayed in seconds for curve/datasheet comparison. However, in your case, I can see that keeping the legends and UI stuff in seconds would be more than a bit silly, when you're going over several hours.
If you have a github account, I'd love if you would open a new issue, so we and possibly others can keep track of this issue (history and solutions). If not, don't worry about it, I would leave the data in seconds as it is, I think the solution rather lies in the datapoint/legend aggregation of the plotting framework we used and maybe a couple of *60 in the javascript for the curve detail panel. I'll have to have a look into the code and will come back to you, either here via comment (don't forget to subscribe) or via github, if we have a new issue :)
scott
2014/11/24 8:27
Yes, my thought was to leave the Python in seconds (unless its easier not to), and modify the Java so that the interface (display and profile entry) are in hours and minutes. I am fairly mediocre in Java at the moment, so any help would be great! I can see how to change some of the display points (like total duration), but I have a problem translating the input from the profile file.Thanks for your help!
The text was updated successfully, but these errors were encountered: