04-24-2022, 12:43 AM
To be honest I'm a little surprised about the fear of running on a live tank as it feels like you've been making more changes in the code lately than I have based on our emails and posts. You're also updating manually due to this and if anything is missed it's not good.
The scheduling system is actually well written and quite fail proof as long as the program runs, after running over a year I've never seen the program lock up or a missed schedule but I guess anything is possible that's why it's still beta. The scheduling is using milliseconds but based on actual time, as you mentioned there is no real clock, everything is just a counter, surely you can't use actual time format in code. RTC starts counting at January 1, 1970 12:00:00 AM which is used as a starting point. When the program starts up or a schedule runs or a schedule is added/edited a simple function runs to calculate all schedules next upcoming time in unix timestamp. Then a simple loop is used to trigger the schedule when the current timestamp is greater than the next schedule time stamp, once that passes the schedule has to trigger, it's just logic. Once it triggers it updates the next upcoming schedules and waits again. Very simple system that uses hardly any code. If the program is running it's impossible for it not to run.
The dosing is a separate system from scheduling, the schedule simply starts the dosing process at which point the dosing system is responsible for stopping the pump. If a pump doesn't stop it's not due to scheduling, there are no off schedules for dosing. I think you've mentioned a few times you changed things with dosing so that could be the issue. The run time for dosing is calculated using the dose pump rate * dose amount. When the pump actually starts the system is flagged as it having done so and then a loop is always monitoring this and the counter is compared to stop the pump, this is also a pretty simple system, as long as the program runs the logic has to flow.
I'm confident with the scheduling but I still want to improve the RTC code but it's nothing related to what you're experiencing. If you feel it's RTC related disable that and it'll use NTP instead.
Signs that the program has stopped running would be a red plug next to time, the health meter should drop to 0 and for sure the clock in the browser will stop updating as this is showing what the controller is working on. One thing I've noticed with the Pi and c++ program is it never locks up, instead if something occurs that would cause that it crashes and the program is closed. For my personal use I don't use the Pi service file to start the program, instead I leave my SSH terminal open 24/7 with the program started manually (not really recommended as program stops if SSH terminal is closed). I do this so I can see output from program to verify things do what they should and also to know if the program ever crashes. Honestly I've never seen it crash without reason but it's still possible if something isn't configured correctly, as I find these I'm adding extra validation in front end so it can't happen but that's a process. Things happen in real world that one can never predict. The time it would crash is when a function runs that has bad code or invalid data in a variable. For example if a dosing pump started up and a variable wasn't correct it's very possible the program crashes after it starts the pump and at that point it wouldn't stop it as it's down and out. Maybe something like this is happening. I do have dosing pumps configured and this has never happened but again just wondering if a change you made might be causing it. Editing someone else's code is very hard when you don't know how it all flows, this is a large program and everything connects one way or another so you really need to be in my head to see how it's all laid out.
I certainly don't hold it against you for not using it, I understand and thanks for your feedback.
The scheduling system is actually well written and quite fail proof as long as the program runs, after running over a year I've never seen the program lock up or a missed schedule but I guess anything is possible that's why it's still beta. The scheduling is using milliseconds but based on actual time, as you mentioned there is no real clock, everything is just a counter, surely you can't use actual time format in code. RTC starts counting at January 1, 1970 12:00:00 AM which is used as a starting point. When the program starts up or a schedule runs or a schedule is added/edited a simple function runs to calculate all schedules next upcoming time in unix timestamp. Then a simple loop is used to trigger the schedule when the current timestamp is greater than the next schedule time stamp, once that passes the schedule has to trigger, it's just logic. Once it triggers it updates the next upcoming schedules and waits again. Very simple system that uses hardly any code. If the program is running it's impossible for it not to run.
The dosing is a separate system from scheduling, the schedule simply starts the dosing process at which point the dosing system is responsible for stopping the pump. If a pump doesn't stop it's not due to scheduling, there are no off schedules for dosing. I think you've mentioned a few times you changed things with dosing so that could be the issue. The run time for dosing is calculated using the dose pump rate * dose amount. When the pump actually starts the system is flagged as it having done so and then a loop is always monitoring this and the counter is compared to stop the pump, this is also a pretty simple system, as long as the program runs the logic has to flow.
I'm confident with the scheduling but I still want to improve the RTC code but it's nothing related to what you're experiencing. If you feel it's RTC related disable that and it'll use NTP instead.
Signs that the program has stopped running would be a red plug next to time, the health meter should drop to 0 and for sure the clock in the browser will stop updating as this is showing what the controller is working on. One thing I've noticed with the Pi and c++ program is it never locks up, instead if something occurs that would cause that it crashes and the program is closed. For my personal use I don't use the Pi service file to start the program, instead I leave my SSH terminal open 24/7 with the program started manually (not really recommended as program stops if SSH terminal is closed). I do this so I can see output from program to verify things do what they should and also to know if the program ever crashes. Honestly I've never seen it crash without reason but it's still possible if something isn't configured correctly, as I find these I'm adding extra validation in front end so it can't happen but that's a process. Things happen in real world that one can never predict. The time it would crash is when a function runs that has bad code or invalid data in a variable. For example if a dosing pump started up and a variable wasn't correct it's very possible the program crashes after it starts the pump and at that point it wouldn't stop it as it's down and out. Maybe something like this is happening. I do have dosing pumps configured and this has never happened but again just wondering if a change you made might be causing it. Editing someone else's code is very hard when you don't know how it all flows, this is a large program and everything connects one way or another so you really need to be in my head to see how it's all laid out.
I certainly don't hold it against you for not using it, I understand and thanks for your feedback.
