ECS-L Home Automation and Security Archives
  learn more | view messages for this month | NetBloc® | terms of use | search

Google
 


  subject (prev) or (next) | time (prev) or (next) | author (prev) or (next) | view more subjects

Subject:
From:
Date:
Re: [ECS] Re: PLC-TX Overflow Problem
Don Stephens
Fri, 22 Oct 1999 17:47:07 -0700

Mark:
 Great! I haven't had an error msg since the latest beta.
Thanks;
Don
----- Original Message -----
From: Mark Gilmore <omnip@usit.net>
To: <ecs-list@netbloc.com>
Sent: Friday, October 22, 1999 3:29 AM
Subject: [ECS] Re: PLC-TX Overflow Problem


> Regarding the "PLC OVERFLOW" problem:
> I think the latest beta upload will help with this problem
> (but it will still exist to a degree).
> I still don't have an acceptable solution (if one exists).
>
> But in the mean time, please try to avoid logic such as this:
> If Dark Is True
> And Light Is OFF
> Then Set Light ON
> This will cause the X10 unit/function commands to be sent
> EVERY event-pass until the original unit/function commands
> are actually transmitted (some 2 seconds later). The result
> is that some 16 commands will be queued for output (assuming
> 4 event-passes/sec).
>
> Use something like this instead:
> If Dark Is NOW True
> And Light Is OFF
> Then Light Set ON
> --
> Mark Gilmore
> Omnipotence (ECS home automation software)
> http://www.usit.com/omnip
> 423-745-0026
>
>
> Michael David wrote:
> >
> > Hi Mark!
> >
> > >How are we sending out these commands ?
> > >Via normal SETs to LIGHT Items ?
> >
> > Yup.  Here's an example:
> > If      Dark    Is      True
> > And     Front Yard Flood        Is Not          On
> > Then    Front Yard Flood        Set             On
> >
> > >If so, why the need to send them again ?
> >
> > I absolutely don't want them sent again.  That is the problem.
> >
> > Let's look line two of example above:
> > And     Front Yard Flood        Is Not          On
> >
> > At startup, when ECS processes this event line, it will test true, and
ECS
> > will send the PLC command to turn the Front Yard Flood on.   However,
since
> > the state of PLC items aren't  updating for several minutes, the state
of
> > the Front Yard Flood will still show as Off, and this line will continue
to
> > test true.  So, ECS will send the PLC command to turn on the Front Yard
> > Flood again on the next event pass - and every pass thereafter for a
while.
> >
> > Make sense?
> > Cheers!
> >
> > Michael David
> > michael@michaeldavid.com
> >
> > --
> > Mark Gilmore
> > Omnipotence (ECS home automation software)
> > http://www.usit.com/omnip
> > 423-745-0026
> >
> > Michael David wrote:
> > >
> > > Hi Mark!
> > >
> > > Oh yeah - I should have thought of that.  :)
> > >
> > > OK, since you can't try the .cfg I sent you, let me take another crack
at
> > > explaining the problem.  Here's the real issue with this version:
> > >
> > > When ECS starts, my config has it sending out about 50 PLC commands.
> > > Unfortunately, it takes a REALLY LONG time (several minutes) for the
> > states
> > > of all those items to be updated to reflect the new state.  This
creates a
> > > BIG problem, because I often use logic that turns things on if they
are
> > not
> > > on, or turns things off if they are not off.
> > >
> > > Here's the point-> Since most of the states on those 50 PLC items have
NOT
> > > been updated by the next event pass, many of those PLC commands get
sent
> > > again.  And again, and again, and again, and again, and again every
event
> > > pass thereafter, until everything catches up.  At some point, I just
end
> > up
> > > with a few thousand PLC-TX overflow error messages. (yup - a few
THOUSAND
> > > errors)
> > >
> > > So, the real difference between this new version, and previous
versions,
> > is
> > > this: It never used to take more than a pass or two for the state of
all
> > > these PLC items to get updated.  Now it takes several minutes.  In
fact,
> > in
> > > previous versions, while ECS was spitting out these 50 or so PLC
commands,
> > I
> > > could go to the group page, and change the state on a PLC item, and
it's
> > > state would immediately change.  In this version, that is not the
case.
> > > Now, if I manually change the state of a PLC item while ECS is
spitting
> > out
> > > those same 50 or so PLC commands, it's state doesn't change - for
several
> > > minutes.
> > >
> > > Mark, I know I can be a bit wordy at times.  I apologize for that.
> > Clearly,
> > > I am having trouble explaining this problem!
> > >
> > > How about this:
> > >
> > > It's now taking ECS several minutes to update the state of a PLC item
to
> > > reflect a state-change that actually happened several minutes earlier.
I
> > > think that's bad. :)
> > >
> > > Cheers!
> > >
> > > Michael David
> > > michael@michaeldavid.com
> > >
> > > -----Original Message-----
> > > From: Mark Gilmore [mailto:omnip@usit.net]
> > > Sent: Tuesday, October 19, 1999 11:17 AM
> > > To: Michael David
> > > Subject: Re: PLC-TX Overflow Problem
> > >
> > > Sorry guy, but I was really looking for a SMALL cfg
> > > that would re-create the problem (I don't have one
> > > REDAC, let alone 3).
> > > As I stated before, the State of Light/Appliance Items
> > > are not updated until the queued commands are transmitted.
> > > This has always been the case, but it may be "more so"
> > > in this update.
> > > Forgetting cfgs, what is it we are trying to do ??
> > > --
> > > Mark Gilmore
> > > Omnipotence (ECS home automation software)
> > > http://www.usit.com/omnip
> > > 423-745-0026
> >
> > Michael David wrote:
> > >
> > > Hi Mark!
> > >
> > > Oh yeah - I should have thought of that.  :)
> > >
> > > OK, since you can't try the .cfg I sent you, let me take another crack
at
> > > explaining the problem.  Here's the real issue with this version:
> > >
> > > When ECS starts, my config has it sending out about 50 PLC commands.
> > > Unfortunately, it takes a REALLY LONG time (several minutes) for the
> > states
> > > of all those items to be updated to reflect the new state.  This
creates a
> > > BIG problem, because I often use logic that turns things on if they
are
> > not
> > > on, or turns things off if they are not off.
> > >
> > > Here's the point-> Since most of the states on those 50 PLC items have
NOT
> > > been updated by the next event pass, many of those PLC commands get
sent
> > > again.  And again, and again, and again, and again, and again every
event
> > > pass thereafter, until everything catches up.  At some point, I just
end
> > up
> > > with a few thousand PLC-TX overflow error messages. (yup - a few
THOUSAND
> > > errors)
> > >
> > > So, the real difference between this new version, and previous
versions,
> > is
> > > this: It never used to take more than a pass or two for the state of
all
> > > these PLC items to get updated.  Now it takes several minutes.  In
fact,
> > in
> > > previous versions, while ECS was spitting out these 50 or so PLC
commands,
> > I
> > > could go to the group page, and change the state on a PLC item, and
it's
> > > state would immediately change.  In this version, that is not the
case.
> > > Now, if I manually change the state of a PLC item while ECS is
spitting
> > out
> > > those same 50 or so PLC commands, it's state doesn't change - for
several
> > > minutes.
> > >
> > > Mark, I know I can be a bit wordy at times.  I apologize for that.
> > Clearly,
> > > I am having trouble explaining this problem!
> > >
> > > How about this:
> > >
> > > It's now taking ECS several minutes to update the state of a PLC item
to
> > > reflect a state-change that actually happened several minutes earlier.
I
> > > think that's bad. :)
> > >
> > > Cheers!
> > >
> > > Michael David
> > > michael@michaeldavid.com
> > >
> > > -----Original Message-----
> > > From: Mark Gilmore [mailto:omnip@usit.net]
> > > Sent: Tuesday, October 19, 1999 11:17 AM
> > > To: Michael David
> > > Subject: Re: PLC-TX Overflow Problem
> > >
> > > Sorry guy, but I was really looking for a SMALL cfg
> > > that would re-create the problem (I don't have one
> > > REDAC, let alone 3).
> > > As I stated before, the State of Light/Appliance Items
> > > are not updated until the queued commands are transmitted.
> > > This has always been the case, but it may be "more so"
> > > in this update.
> > > Forgetting cfgs, what is it we are trying to do ??
> > > --
> > > Mark Gilmore
> > > Omnipotence (ECS home automation software)
> > > http://www.usit.com/omnip
> > > 423-745-0026
>


  subject (prev) or (next) | time (prev) or (next) | author (prev) or (next) | view more subjects




Services provided by [NetBloc]®! NetBloc Solutions Inc.
Terms of use. Indexing software (c) 1999 Lin-De, Inc
.