I am not sure what you mean by ‘Corrupt’ a program. The program is not being corrupted at all.
OK, maybe I didn’t choose the best words. What I meant is that the program execution was incorrect. ‘Incorrect’ means:
- stations programmed to water 2x times are not watered 2x times
- multiple iterations of the same program don’t water the same set of stations
Specifically, firmware 2.1.0 will ignore overlapping programs — if a program is still running when a new program is scheduled to start, the new program will be ignored.
I don’t know how this can be the case, my FW2.1.0 screenshot shows otherwise. Notice there is zero gap between any of the station run times in the first screenshot, and I definitely did not take the time to match perfectly the repeat time to program time.
For example, if you request the program to repeat every 1 minute, for 100 times, and the program takes 60 minutes to run, what do you expect to happen?
Well first I think that is nonsensical programming, and hopefully the user would see their mistake using Program Preview and then correct it. 🙂 But for the sake of argument I would expect it to run for 100 times @ 60 minutes each, back-to-back with no pause between them. You could mitigate this sort of nonsensical program by limiting repeat times to something sensible (4 or 8 or whatever), or by limiting total (program run time x num repeats) run time.
I don’t think Pro-C even supports such flexible repeating programs
Fair point. But I can demonstrate exactly the same issue by programming overlapping Additional Start Times, which the Pro-C most certainly does support. I know, because I used to utilize this feature on my Pro-C, and indeed it would queue-up multiple runs when multiple start times of the same program resulted in program overlapping.
If you set your program to repeat every 47 minutes, it WILL run immediately after the previous run finishes.
I understand that. That’s not the issue. The issue is that changing weather conditions mean my station run times are constantly changing. Now I’ll to constantly need to tweak the repeat time in response to that, otherwise I have a bunch of dead (non-watering) time while my programs are running. I’m trying to minimize that since I can only water during certain hours. This is not a big deal, just an disappointment since FW2.1.0 used to do this the way I had expected it to.
And, isn’t this a bigger problem for your users who use the automated “Water Adjustment” feature to vary the % of watering? What happens when a dry-spell and high temperatures result in increased station run times to the point where the program length exceeds interval time? Maybe there was no overlapping at 80%, but there is at 90%. Does the user get notified that there is now an overlapping program caused as a result of automated station run time increase, or does their lawn go brown because the overlapping program means some stations didn’t run when they expected them to? [I don’t use this feature, so I don’t know..]
For the sake of comparison: here are some details from the Pro-C feature list:
Ray, listen, I think you get the wrong impression from my post. 🙂
I’m not trying to compare OpenSprinkler to anybody — indeed it is far more flexible than any off-the-shelf controller. I’m not questioning that. I was merely pointing out this behavior which is different than most of your new users will be accustomed to (migrating from Hunter/RainBird, etc), and also that it is a different (and IMO less desirable) than the way it used to work. Or at least different than the way FW2.1.0 Preview used to tell me it would work.