Oh, this is a lot to think about, thank You:)
I'm kind of balancing between a desire to actually build this (so it
has to be simple) and to build it as bulletproof as possible (native
habit in telecom business). Most probably best way would be to build
it as simple as possible to get it running, and then update when real
needs show up in real use.
Better done then perfect? :)

Basically sounds like my own version was close enough to what others
are doing, so it should be ok.

On Fri, May 27, 2016 at 4:17 PM, Denny Esterline <desterline@gmail.com> wro=
te:
> There's a lot of different ways to approach something like this and each
> has their own merits.
> My first thought would be to structure it like so: [skipping some details
> here]
>
> MainLoop{
>
> if ((CurrentTime >=3D StartTime) && (CurrentTime <=3D StopTime)
>          Output(ON);
> else
>          Output(Off);
> }
>
> With this loop being called quite frequently (somewhere between once/minu=
te
> to 1000/second)
>
> Assuming that internally you're storing times as integers (opposed to som=
e
> type of data structure
> that separates seconds/minutes/hours/days) this has the advantage that a
> system reset mid
> cycle is "self-healing". I used this type of mechanism on a project that
> had a hard requirement
> that a failure must NOT leave the thing running.
>
>
> Later you mention "One of the issues was - when power failed during the
> "ON" cycle - load
> was switched off, and the cycle lost until next event" Well... Maybe I've
> read too much garbage
> coming from my marketing people, but that's a bit ambiguous and subject t=
o
> multiple
> interpretations.
> Suppose you programmed it to run the load from 0:00 to 1:00, Suppose the
> power was out
> from 0:20 to 0:25.
> The code above would
> 0:00 ON
> 0:20 OFF (with some assumptions about how the load is being switched)
> 0:25 ON
> 1:00 OFF
> (for the record, this is what my device did, and is exactly how we wanted
> it)
>
> Stretching that example a bit, if the power was out before 0:00 and did n=
ot
> come on until
> after 1:00, the system would never turn on at all that day.
>
> But perhaps you actually _want_ it to run to 1:05 to make up for the time
> lost???
> Or come on when the power was restored and run for the difference between
> Start and Stop times?
> (this is the behavior of a typical mechanical timer device - more or less=
)
>
> In that case, I would approach it a bit differently. The system would nee=
d
> a nonvolatile variable.
> (could be in EEPROM, some RTCs have a small amount of battery backed RAM,
> there's ways
> to use FLASH...) but it would become a count of time the load was on. In
> that case:
>
> MainLoop{
>
> if ((CurrentTime >=3D StartTime) && (TimeRunToday <=3D PlannedTimeRunToda=
y)
>          Output(ON);
> else
>          Output(Off);
>
>
> //RunTime housekeeping - add a 'tick' to the nonvolitile counter every so
> often
>
> TimeRunToday =3D TimeRunToday + (CurrentTime - LastLoopTime)  //concept o=
nly
> - do not implement it like this.
> LastLoopTime =3D CurrentTime;
> }
>
>
> There's a couple ways that can bite you because FLASH and EEPROM have
> limited life span
> and do not like to be continuously written to like this. There's "standar=
d"
> ways to deal with this,
> but the details are quite messy for an example like this.
>
> The added quirk here is you now need a _good_ method to manage the RunTim=
e
> variable.
> Do you clear it to zero at 0:00? What if the power was off during 0:00?
> What if the operation
> has the system on as the time rolls over from 23:59 to 0:00? (either user
> programmed that way
> or a result of "clock stretch" because of power outage)
> Do you clear it as part of the turn on / turn off event?
> It can be managed with more nonvolitile memory and a series of flags
> through a state machine,
> it's not even terribly difficult - but there are plenty of places to get
> tripped up. You really need
> so spend some time examining all the corner cases.
>
>
> Another point worth mentioning is the concept of "CurrentTime". I tossed =
it
> around in that example,
> but it's actually quite nuanced. This pseudo code treats it like a
> variable, in reality it's probably a
> function to retrieve the current time from [RTC, GPS, HTTP, etc] and
> massage it into your numbering
> system - that will take time... what happens when the minute changes part
> way through the loop?...
> Typical solution here is to retrieve it once at the beginning of the loop
> LoopStartTime =3D CurrentTime()
> Then replace all the later references to CurrentTime with LoopStartTime.
>
>
> -Denny
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist



--=20
KPL
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.