| ECS-L Home Automation and Security Archives |
| Subject: From: Date: | Re: PLC-TX Overflow Problem Mark Gilmore Fri, 22 Oct 1999 03:29:13 -0700 |
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