ADICON Support Forum Applied Digital, Inc.
Page 1 of 2 12>
Topic Options
#20552 - 11/18/08 09:44 PM Timer Troubles...
Nathan Gregory Offline
active contributor


Registered: 02/17/03
Posts: 157
Loc: San Jose CA
I noticed that some of my programming wasn't working. On troubleshooting, I discovered that timers are not advancing.

The Ocelot is working normally as far as responding to X10 and IR signals, but all the functions that depend on timers are not happening.

I have done a reload of the executive, reload the program and tried the 'set controller clock to PC clock' function all to no avail. The latter sometimes advances timers by one count, but does not restart them.

I tried a power cycle and reload again, checking timer operation with no program loaded. Ditto. No advance.

Help.......

Nathan

Top
#20555 - 11/19/08 06:14 AM Re: Timer Troubles... [Re: Nathan Gregory]
ADI Tech Support Moderator Offline
addict


Registered: 12/22/02
Posts: 608
Loc: Branson West, MO
In C-Max, click Controller Utilities, Set Controller Clock to PC Clock. See if that gets your timers working again.

Kevin Barrett
ADI Tech Support

Top
#20556 - 11/19/08 08:43 AM Re: Timer Troubles... [Re: ADI Tech Support]
Nathan Gregory Offline
active contributor


Registered: 02/17/03
Posts: 157
Loc: San Jose CA
Hi Kevin,

Need some coffee this morning? Or had too much? ;\)

quote "tried the 'set controller clock to PC clock' function all to no avail. The latter sometimes advances timers by one count, but does not restart them." end quote...

So, no it does not restart them...

Any better suggestions?

Nathan

Top
#20557 - 11/19/08 09:07 AM Re: Timer Troubles... [Re: Nathan Gregory]
ADI Tech Support Moderator Offline
addict


Registered: 12/22/02
Posts: 608
Loc: Branson West, MO
Sorry, typed before I had any:-)

Check the clock (controller utlities, get controller clock). Does it report a valid time. Try it a couple of minutes later and make sure the clock is correctly updating. The timers in the Ocelot are based off the real time clock in the Ocelot.

If that is all good, look at your code. See the there is anything that is setting a clock to 1 based on a constant event.

For example:

If time of day is > than 0600
Then timer 0 = 1

In this example, as long as the time of day is later than 6 am, the timer would be continually set to 1 and never count. You would change the "is >" to "becomes >" in the If statement.

Another example;

If Variable 3 is = to 1
Then timer 0 = 1.

In this example, as long as variable 3 is setting at a value of 1, the timer would be constantly being reset to 1 and never count up, You would change "is =" to "becomes =" in the If statement.

Kevin Barrett
ADI Tech Support

Top
#20558 - 11/19/08 09:42 AM Re: Timer Troubles... [Re: ADI Tech Support]
Nathan Gregory Offline
active contributor


Registered: 02/17/03
Posts: 157
Loc: San Jose CA
The code that I run has been in place unmodified for months, and the problem apparently affects all timers, not just one or two.

Using the "get controller clock" function returns the correct time, and it is advancing, i.e. If I check it again in a couple minutes it is updated.

But even with no program loaded, after a fresh exec reload and power cycle, setting a random timer to 1 via CMAX does not result in timers advancing. I think that pretty well eliminates the program as being at fault when it behaves the same with no program whatever.

The unit is fully responsive to IR and X10 commands, but all functions that depend on timers are failing...

Any clue??

Nathan

Top
#20559 - 11/19/08 09:53 AM Re: Timer Troubles... [Re: Nathan Gregory]
ADI Tech Support Moderator Offline
addict


Registered: 12/22/02
Posts: 608
Loc: Branson West, MO
You said "I tried a power cycle and reload again, checking timer operation with no program loaded. Ditto. No advance."

What is the application version being reported by the Ocelot at the bottom of the Controller Access Screen?

Kevin Barrett
ADI Tech Support

Top
#20560 - 11/19/08 10:01 AM Re: Timer Troubles... [Re: ADI Tech Support]
Nathan Gregory Offline
active contributor


Registered: 02/17/03
Posts: 157
Loc: San Jose CA
Firmware V8.31/58 Application V3.18

I believe this has run unchanged for years....... Many months for sure...

Top
#20561 - 11/19/08 10:19 AM Re: Timer Troubles... [Re: Nathan Gregory]
ADI Tech Support Moderator Offline
addict


Registered: 12/22/02
Posts: 608
Loc: Branson West, MO
At this point then I think it needs to come to me to be looked at. Something is not right.

Kevin Barrett
ADI Tech Support

Top
#20562 - 11/19/08 10:44 AM Re: Timer Troubles... [Re: ADI Tech Support]
Nathan Gregory Offline
active contributor


Registered: 02/17/03
Posts: 157
Loc: San Jose CA
Yes, clearly, something is not right.

One significant item is that doing a get controller clock, followed by a set controller clock to PC clock usually advances the timers by one count. It is as if the timers are being started, but stop again immediately. In other hardware I have seen this sort of problems occur when a crystal goes bad, causing the oscillator that drives it to become flaky and intermittent. If timers are advanced by an interrupt from a crystal controlled oscillator, this is kinda the behavior I would expect in case of such a failure.

A failed capacitor could also cause similar problems.... Heaven knows capacitor failures have been a big issue in recent years.

Perhaps I should examine the hardware for a failed oscillator... I am experienced in electronics repair and have tools and test equipment, including oscilloscopes and such at hand. I don't suppose it would be possible to get a schematic of the relevant portion of the Ocelot to facilitate such troubleshooting...

Have you any history of such failures that you can relate to me?

Thanks,
Nathan

Top
#20581 - 11/24/08 09:47 PM Re: Timer Troubles... [Re: Nathan Gregory]
Nathan Gregory Offline
active contributor


Registered: 02/17/03
Posts: 157
Loc: San Jose CA
Ok, I've been banging my head on this a couple of days. At times the system would start working, only to stop again. At other times it might work for a couple of hours, then be dead for a full day or more. But in spite of all the intermittency, I decided there was no obvious hardware problem, after extensive testing.

Since my automation system has been effectively dead, I haven't paid a lot of attention to X10, but after a while I gradually noticed that there seemed to be an awful lot of traffic on the X10 side of things, even with the Ocelot shut down. Investigating, I find I have a wireless motion sensor on address H13 that seems to be streaming continuous H13/H-ON messages.

But here's the catch. When I disconnected the TW523 interface from the wall, suddenly the timers started working again.

It may be a bit premature, but it appears that excessive X10 traffic keeps timers from advancing.

IS THIS POSSIBLE?

Now I have to go climb a tree and fix/replace that darn motion sensor and retest everything. But my first hypothesis is that (a) Timers are driven off a maskable Z80 interrupt and (b) while receiving X10 traffic, that interrupt is masked leading to (c) Excessive X10 traffic can effectively halt all the timers.

Crazy, huh....

I would be inclined to count this as a flaw in the CMAX executive. As it stands, if further testing bears out the theory, excessive X10 traffic can in fact halt functions that otherwise have absolutely nothing to do with X10.

I.E. I have several chunks of code that react to a Secu input, and then after a timer operates a bit, closes or opens Secu outputs. e.g. A vehicle sensor at my front gate closes a relay that is seen as a contact closure by a Secu, which after some logic, evaluates to a secu relay closure that opens the gate.

No X10 involved in the loop at all. Yet, with the TW523 interface seeing this H13 traffic, the gate won't open, because the timers don't run. When I unplugged the wall interface, now the gate operates as I designed it.

If further study confirms this diagnosis, I am now faced with the task of adapting all my logic to reduce or eliminate dependence on timers, as it appears that anything that depends on a timer can fail unexpectedly should something go awry with an X10 device.

Thoughts anyone?

Thanks,
Nathan

Addendum: After writing the above, I climbed the tree and retrieved the motion sensor. I noticed immediately that it had a LED hard on. I removed it's batteries, and reinstalled the TW523 and all my Ocelot programming is back to normal, timers are running, events are being responded to and so on. This seems pretty conclusive to me.

Odd as it seems, excessive X10 traffic from a failed transmitter can indeed stop Ocelot timers from advancing, and thereby cause logic that has nothing whatever to do with X10 to fail.


Edited by Nathan Gregory (11/24/08 10:31 PM)

Top
#20582 - 11/25/08 06:53 AM Re: Timer Troubles... [Re: Nathan Gregory]
Guy Lavoie Administrator Offline
Beyond All Hope
*****

Registered: 12/21/02
Posts: 6401
Loc: Montreal, QC, Canada
It is the first time I hear of excessive X10 traffic messing with timers, *but* there is a known issue with excessive X10 or IR reception causing problems with loading the executive or C-Max programs in the Ocelot. It would appear that in both cases, the PIC chip (which handles both IR and X10) might be interrupting the main cpu (Z80) too much and messing up its regular operations. It can only do so much at any given moment. I'm glad you found the source of the excessive X10 signals.
_________________________
"If you don't know what you're doing, do it neatly..."

Top
#20585 - 11/25/08 07:59 AM Re: Timer Troubles... [Re: Guy Lavoie]
Nathan Gregory Offline
active contributor


Registered: 02/17/03
Posts: 157
Loc: San Jose CA
Yeah, it is counter-intuitive that something happening on the X10 side might halt the timers. But I have a proven instance of exactly that.

This is a great blow to my programming. I have used the Ocelot for all sorts of stuff because the code in the Ocelot is much more reliable than the PC. Timers have been an important part of that, and I use a LOT of timers, for lots of different functions. If an X10 malfunction can so easily halt all timers, then this calls into question the reliability of using timers.

I will be spending some time going thru my code and looking at how I use timers and trying to defensively program around this failure mode.

Note, that the CMAX code still ran. Anything that did not depend on timers still operated. Just timers were halted.

Cheers,
Nathan

Top
#21685 - 03/06/10 09:57 AM Re: Timer Troubles... [Re: Nathan Gregory]
RRA Offline
newbie


Registered: 03/05/10
Posts: 8
I have almost the same trouble except that timers begin to work after setting controller clock to PC clock. As I noticed, timers along with the system real time clock usually stops after reconnecting power to the controller, the system clock stops just at the moment, when I connect the power plug. Any ideas?
Top
#21686 - 03/06/10 11:25 AM Re: Timer Troubles... [Re: RRA]
Guy Lavoie Administrator Offline
Beyond All Hope
*****

Registered: 12/21/02
Posts: 6401
Loc: Montreal, QC, Canada
I've also had that happen a few times. I don't know what the cause is however.
_________________________
"If you don't know what you're doing, do it neatly..."

Top
#21688 - 03/09/10 07:06 AM Re: Timer Troubles... [Re: Guy Lavoie]
Brave Sir Robbin Offline
newbie


Registered: 01/09/03
Posts: 24
Loc: Las Vegas, Nevada
This is an interesting thread. I use timers a lot and noticed that one timer would never work right. It's a timer that gets triggered with my car monitor, which does send an X-10 signal every couple of seconds.

I could never figure out why this one timer would not work correctly. I'll have to take another look at my CMax code.
_________________________
**** Do You Cocoon? ****

Top
#21689 - 03/10/10 10:23 AM Re: Timer Troubles... [Re: Brave Sir Robbin]
RRA Offline
newbie


Registered: 03/05/10
Posts: 8
after a few day experiments 2 different ocelots were tested with the same problem. I tried to use different executives, from v3.06 through v3.18 with their native c-max software. No result. The ocelot RTC stops exactly at the moment of power reconnection. It seems like the RTC chip Epson 72421 not switching out of standby mode. Another thing I noticed, that more than a couple of minutes must pass before reconnecting power. Doing this quikly not causes the RTC to stop. The battery is new, RTC stops exactly at the time of power reconnecting even when the system have been unplugged for more than a day. Is this really not the bug but the feature? Two different ocelots with different date of manufacturing? If so, I will be forced to refuse using Adicon controllers at all!
Top
#21690 - 03/10/10 11:17 AM Re: Timer Troubles... [Re: RRA]
Barry Parr Offline
journeyman


Registered: 02/15/04
Posts: 98
Loc: NZ
Hi. What is the 'No Load' Measured voltage of your power supply?
Top
#21691 - 03/10/10 11:33 AM Re: Timer Troubles... [Re: Barry Parr]
RRA Offline
newbie


Registered: 03/05/10
Posts: 8
12.62 volts 2 A switching power supply. I've try 3 different ones already along with AC and just 12V battery
Top
#21692 - 03/10/10 11:34 AM Re: Timer Troubles... [Re: RRA]
RRA Offline
newbie


Registered: 03/05/10
Posts: 8
12.62 - without load... 12.55 under the load
Top
#21693 - 03/10/10 12:17 PM Re: Timer Troubles... [Re: RRA]
Barry Parr Offline
journeyman


Registered: 02/15/04
Posts: 98
Loc: NZ
OK. That screws My spike thought.Sorry I don't have any other ideas as I have never encountered this problem.
Top
Page 1 of 2 12>


Moderator:  Dan Smith, Monte G, ADI Tech Support, Guy Lavoie 
Hop to:
Who's Online
1 registered (John Vomastic) and 21 anonymous users online.
Recent Posts
SECU16IR Output Connecting To A Xantech Connecting Block
by Jean-Marie
Today at 08:36 AM
SECU16IR Output Connecting To A Xantech Connecting Block
by Jean-Marie
Today at 08:34 AM
how to post an icon
by manu
02/03/12 03:40 AM
Command Pair
by kuro
02/01/12 12:49 AM
Does anyone have a copy of the latest TSE?
by sevenzenith1
01/30/12 05:17 AM
Shout Box

Newest Members
feshh, manu, kuro, chuck214, Funkhauser
2747 Registered Users
Forum Stats
2747 Members
19 Forums
3837 Topics
22713 Posts

Max Online: 67 @ 08/16/11 03:08 PM
February
Su M Tu W Th F Sa
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29