timer library

J

Thread Starter

Jiri Baum

Hello,

I've added lib/logic/timer.h to CVS, containing a proposed "timer" type. This is intended as a module-private timer, to be used, among other places, in the basic demo.

Any comments before implementation?

It can be thought of as a real-valued variable which magically increments its value at a rate of 1.0 per second. On-, off- etc timers can be built
out of this using standard C comparisons and if/while statements.

The functions provided are:

zero - zeroes and stops the timer. This is an init function.

start - zero and start the timer. This is an init function.

get - get the current value of the timer (in seconds).

elapsed - returns true or false depending on whether the given time
has already elapsed. This is a one-line wrapper around get.

stop - stop the timer. No effect if already stopped.

restart - start the timer at its current value. No effect if
already running.

add - advance or retard the timer. Can be used on both stopped and
running timers.

Note: for count-down semantics, start the timer at a negative value.

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Timers should have the resolution of milliseconds. Even if the default prescalar multiplies the value by 1000 (to get seconds), the core structure should be based on a millisecond tick. With PLCs running sub
millisecond scans, this is not unreasonable.

Suggestion: Steeplechase assigns timers to their IO table which allows you to treat them just like normal IO and the kernel handles all of the details, like copying the values to the IO table (I would think at the end of logic scan, but I don't really know how they do it)

To interface to the Timer they define a structure like so:

TimerName.Done
TimerName.Enable
TimerName.Preset
TimerName.Clear
TimerName.Accum
Timer.Prescale

(These might not be exact, but you get the idea ...)

In the end I think this would make a nice way to interface to them.
Are these functions you mention just primitives for higher level code to use???

Thanks,

~Ken


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Ken Emmons, Jr.:
> Timers should have the resolution of milliseconds. Even if the default
> prescalar multiplies the value by 1000 (to get seconds), the core
> structure should be based on a millisecond tick.

I said real-valued, and intend to keep the time as Linux gives it to me (which turns out to be microseconds).

We are not limited to integer constants here.

(Yes, I know floats have resolution problems; I'll be careful. Just never add or subtract two reals unless you know what you are doing.)

> Suggestion: Steeplechase assigns timers to their IO table

Yes, they should be in the IO table. But that will take some designing, and that demo has been bothering me ever since I wrote it. These will probably come in handy anyway.

> To interface to the Timer they define a structure like so:

> TimerName.Done
> TimerName.Enable
> TimerName.Preset
> TimerName.Clear
> TimerName.Accum
> Timer.Prescale

> (These might not be exact, but you get the idea ...)

> In the end I think this would make a nice way to interface to them.

Do you have a description of the above functions? I can guess some of them, but not all, and not the details...

> Are these functions you mention just primitives for higher level code to
> use???

That's probably how they will wind up, mostly. But they are intended to be sensible enough to be directly used by C code.

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D

D. Daniel McGlothin

Generally something like this.

.Prescale = the unit of measure of the timer 'click', often 0.01 or 1.0 seconds.
.Preset = the number of timer 'clicks' that pass to expire the timer
.Accum = the number of 'clicks' that are currently accumulated since
.Enable(d)
.Clear = resets the .Accum to zero
.Reset = resets the timer by clears .Accum, .Enable, .Timing, .Done

For a Turn-On-Delay timer (TON)
[signals that the timer has been on for a specified amount of time]
{
.Enable transitions to TRUE:
when the pre-conditions for running the timer are met
.Enable transitions to FALSE:
when the pre-conditions for running the timer are no longer met
or when a .Reset is received
When .Enable transitions to TRUE:
resets .Accum
starts the accumulation of timer 'clicks'
When .Enable transitions to FALSE:
sets .Done to FALSE
or when a .Reset is received

.Timing transitions to TRUE:
on leading edge of .Enable going TRUE
.Timing transitions to FALSE:
when .Enable goes FALSE
or when .Accum >= .Preset

.Done transitions to TRUE:
when .Accum >= .Preset
.Done transitions to FALSE:
when .Enable goes FALSE

Other rules:
.Prescale not generally changeable while timer is running
.Preset not generally changeable while timer is running

}

For a Turn-Off-Delay timer (TOF)
[signals that the timer has been off for a specified amount of time]
{
.Enable transitions to TRUE:
when the pre-conditions for starting the timer are met
.Enable transitions to FALSE:
when the pre-conditions for starting the timer are no longer met
or when a .Reset is received
When .Enable transitions to TRUE:
resets .Accum
sets .Done to TRUE
When .Enable transitions to FALSE:
starts the accumulation of timer 'clicks'
or when a .Reset is received

.Timing transitions to TRUE:
when leading edge of .Enable going FALSE
and .Accum < .Preset
.Timing transitions to FALSE:
when .Enable goes TRUE
or when .Accum >= .Preset
or a .Reset is received

.Done transitions to TRUE:
when .Enable goes TRUE
.Done transitions to FALSE:
when .Accum >= .Preset

Other rules:
.Prescale not generally changeable while timer is running
.Preset not generally changeable while timer is running

Usually there is a CAUTION about using the .Reset on a TOF. Probably having the .Reset be aware of the timer-type (AND modifying its behavior
appropriately) could eliminate this CAUTION.

}

The above describe non-retentive timers. Retentive timers differ in that only a .Reset or a .Clear zeros the .Accum.

Regards,
D. Daniel McGlothin
(A-B and ISaGRAF experience)


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> Hello,

I wrote a couple of days back:
> I've added lib/logic/timer.h to CVS, containing a proposed "timer" type.

There is now a first-draft implementation in the CVS.

In line with the comments, some of the function names have changed:
zero -> clear
elapsed -> done
stop, restart -> enable, disable

I'm not sure on the semantics of done and preset, so these might still change (let me know which way they'd be better).


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top