Forum Replies Created
-
Posts
-
This brings up the question of what the scheduler should do if a new program is supposed to start during the period the controller is pausing. Should it push it back to the queue or should it just ignore the new program? If it’s pushed back, obviously this can end up accumulating a lot of stations and the controller will run out of space to queue these stations.
Excellent question. I would say implement two different pauses:
1) Pause program – this will pause the program but the system will continue to run and if ANOTHER program is scheduled to run then it will. If the paused program comes up to run as scheduled again it remains paused where it was and the scheduled program just gets ignored
2) Pause system – the system (all programs0 pause exactly where it is. All programs scheduled to run do not run until taken out of pause.
This begs the question what happens when the system (or a program) is taken out of pause and conflicts with a scheduled run? I would say it would give the user the choice to continue the current program or start the program that is “supposed” to be currently running.
A way to avoid some of these conflicts is to require the pause be time bound – e.g. Pause for X minutes (maximum being that of the next scheduled run).
It’s funny – this is an excellent example of “hey – lets have a pause” and when you dig deeper into the logic you realize that it requires thinking through the various scenarios.
-Andrew (just another Gozerian)
We need to differentiate between a pause WITHIN a program and the ability to manually (and on an as needed basis) pause any running program. My need is for the latter of the two.
Here’s the info for the MFG testing info:
http://www.irrigation.org/SWAT/Manufacturer/Manufacturer_FAQ.aspx
Hmmmm….. “achieve my result”….that would solve the delay but I’m not sure if that addresses the recursion. The concept that you have to hit a zone a second time in sequence.
Notice below that zone 1 gets hit twice. In my case I have a few zones that have 4 or 5 heads that will take a few (2-3) shots before fully blown out with the capacity of my compressor.zone 1 30s
pause 2 minutes
zone 1 30s
pause 2 minutes
zone 2 30s
pause 3 minutes (larger flow zone)
zone 3 5mins (drip zone)
pause 2 minutes
and so on.Interesting. That’s great to know. I was in the process of blowing out the sprinklers so pressure was variable – that definitely could have something to do with it.
I think it’s actually fine. It just took a long time to close the valve (upwards of 30 seconds) and that threw me off. I did some more testing and it seems like it all working fine.
So it’s the station that reads the rain delay not the program? A station within a program that is supposed to run when the rain delay expires (goes to 0) will then run?
Looking at other irrigation systems the rain delay is typically to delay the program not the station. Weather and boundaries are typically considered on a calendar day period.
Example below:
Program “All” begins to run (3pm) which includes 12 stations. It’s currently cycling through station #4 at 4pm.
I tell the system to rain delay 1 day (absolute 4pm).
The next day it’s scheduled to run the same program at the same time.
Come 3pm when program “All” is set to run, it detects a rain delay and doesn’t run – none of the stations.
The following day, program “All” runs.If you want to supply functionality both ways, a check box that says “[]Delay Program” would work.
adding LCD auto-dimming support.
I noticed in setup options there is now the “lcd dimming” option. The default value is 5. Can you point me to where it explains what this setting does and what effect changing it to 0-4 will have?
During the rain delay period, only stations which are set to ‘ignore rain’ will run. Other stations will not run.
Right but assuming all of your stations are not set to “ignore rain” and you you decide to put in a rain delay period of 24 hours AND you did this midway into your program which is scheduled to start 22 hours from when you put in this rain delay but stations in THAT program are scheduled to in 25 hours…will the program pick up where it would have been running as soon as the rain delay period ends?
I’m not familiar with the code so this is just a guess – but I would think this would be just a refactoring of the valve status. In fact, when talking this over with another engineer he suggested that the each of the 8 current display places represent the station status of each group of 8.
In other words – the first display digit would have a flashing 0 for MC station one, or a flashing 1 for the first station of the next group of 8 and so on. This would not take up ANY additional real estate. This would replace the code for the current station status.
Ah, ok. That’s why you previously HAD to split it because you had to program and END time. Now that’s not the case and you can run it as one contiguous program.
I was reading in the forum that you posted. This thread
“Because the program’s end time has to be prior to start time, what you need to do is to split the program to two the first program will start somewhere before midnight (say 9pm), and end at 11:59pm. The second program will start at 00:00am (or perhaps later if you don’t want it to start right at 00:00), and end at, say 6am. Both programs will be set to water the selected station(s) for 15 minutes, and repeat every hour. This should achieve what you need.”
Is the above no longer accurate? Since it conflicts with what was written in this current post.Ray – that’s why I said based on the current design there actually is space for current station status to be showing. Here’s my suggestion in detail.
- Keep the segment display as is for the “overview” station status. Scroll through this based on active stations. In other words if any of stations 1-8 are currently running it shows the MC station status. If stations 9-16 are running the it shows the station status of E1 and if stations 17-24 are running it shows the stations status line E2. These are static displays and show you what is actually running. In the situation that stations running span multiple groups, then automatic scrolling would happen say every 2 seconds or so.
- Then, I propose we add data to the stations status line.
- If more than one station is currently running just display a “M” for multiple in one of the last three spaces (which is currently open) of the station status line.
- If only one station is running, then display the station NUMBER in the last three digits of the station status line.
Reasoning: With a quick view of the the display you can see what the actual status of the system is. What station is running and how far along it is in the process? Has it just started and it’s running station 1 or is it midway through say at station 9.
More info: I had an older irritrol and it has a VERY minimal display. It simply cycles the display to show the current station running and the time that stations has been running. So if it’s on station 12 that is programmed to run for 25 minutes and it’s run for 10 minutes, it cycles displaying (12 15:00) then (12 14:59)…and so on.
And while we’re on this topic, having the functionality to program the buttons on the side would be helpful as well. I know your goal is to have as much functionality within the gui as possible, but simple control from the unit is a very useful aspect as well. I would program one of the buttons to be “interrupt current program and pick up at the next program”.
Thanks,
Andrew
