I understand what you want to achieve: run programs back to back, and also allow for varying program run times (due to weather adjustment). There is not a simple way to achieve this currently, due to the way the firmware handles station runs.
Fundamentally, this is due to the fact that the firmware is centered around ‘stations’ and not ‘programs’. Conceptually the OpenSprinkler does not treat a program as an entity, so the concept of ‘queuing’ a program does not apply here. Rather, it treats each station as an entity. The reason it’s done this way is to accommodate both sequential and parallel stations. The firmware gives each station one run-time slot. If the slot is non-empty, it does not allow additional schedule to overwrite that slot. That’s why if a station is already scheduled while it’s being requested to run again, it can’t achieve that.
The main point to compare with Pro-C’s features is to explain that the limitations come from prioritizing the limited resources towards different goals. Pro-C allows only up to 16 stations, 3 programs, and 4 start times; while OpenSprinkler allows up to 48 stations, 14 programs, unlimited start times. On top of that, OpenSprinkler allows both sequential and parallel stations, allows individually setting each station to ignore rain, to activate a master station. As a result, the concept of ‘queuing programs’ does not apply here. I chose to implement the scheduling algorithm and data structures in a different way to accommodate the capabilities.
Firmwware 2.1.0’s preview has a bug itself — I am pretty sure that overlapping programs will be ignored by the firmware. Firmware 2.1.2 is the first that can actually handle overlapping programs to some extent, albeit with the limitation that it can’t handle overlapping stations.
Regarding the extreme case I brought up “repeat every 1 minute, for 100 times, and the program takes 60 minutes to run” — I don’t expect the sprinkler controller to be able to handle unlimited cases like this — it has to cut off somewhere. There may be other programs that are scheduled while the 100 runs are going on, so if you think about having a stack, that is going to overflow at some point if you don’t have any limit of such repeating schedules. On the microcontroller the resources are very limited — it’s not like a Raspberry Pi that has fairly large amount of RAM and virtual memory system. It will have to set a cutoff point somewhere, and decide that it can’t accommodate additional runs until some existing ones complete.
My main point here is that different high-level goals impose different limitations. I will think about how to solve the issue — for example, by having a station queue that allows the same station to appear multiple times in the queue, as opposed to reserving one and only one slot for each station. I think this can absolutely solve the issue that you have encountered. Still, the queue will have a limited size, so if there are too many station runs being requested, it will have to still abandon additional station runs until some slots are freed up in the queue. It will always have to cut off somewhere.