Timers

G

Thread Starter

Gerry Hagberg

Hi All,

I don't wish to offend anybody, but I think the discussions about how to implement timers have gone off the deep end! I don't believe they
require anything like an 'engine'. To my mind they could and should be implemented as a simple subroutine in the logic solver.

The essential data for a timer is stored in a 3-word structure in the data table: preset, accumulator (elapsed time), and control. When the
program (ladder, IL, ST, etc.) encounters a timer instruction it (the solver) calls the subroutine and passes the data structure as a parameter (by reference). The control word contains status bits
(enabled, timing, done), time base info., and a reference count. The subroutine has access to a free-running timer/counter in the nether regions of the solver or OS that counts "heartbeats" of the system which are frequent enough and consistent enough to give the desired timing
resolution and accuracy. When called, the subroutine compares the count in the passed structure's control word with the heartbeat counter, then updates the accumulator and the control word count and status and returns.

Three subroutines or one with 3 entry points to handle TON, TOF, RTO.

Gerry

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
The reason for a separate timer execution engine, is that its a part of the more general purpose solution for all non logic, non data
manipulation (eg copy fal) instructions. For example their will be a counter execution engine, a PID execution engine, a motion control execution engine, and maybe some more.

The basic logic engine will only process such things as true/false, branches, set/reset.

Surely you don't propose building all of these into every flavor of the logic engine (of which they may be many)> A generic timer (execution task (for instance) can thus be used by all the different flavors of logic engine, since to use it they simple need to manipulate the appropriate timer structures in shared memory.



--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--

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

Scott Cornwall

> From: Gerry Hagberg [mailto:[email protected]]

> The essential data for a timer is stored in a 3-word structure in the
> data table: preset, accumulator (elapsed time), and control. When the
> program (ladder, IL, ST, etc.) encounters a timer instruction it (the
> solver) calls the subroutine and passes the data structure as a
> parameter (by reference). The control word contains status bits
> (enabled, timing, done), time base info., and a reference count. The
> subroutine has access to a free-running timer/counter in the nether
> regions of the solver or OS that counts "heartbeats" of the
> system which
> are frequent enough and consistent enough to give the desired timing
> resolution and accuracy. When called, the subroutine compares
> the count
> in the passed structure's control word with the heartbeat counter, then
> updates the accumulator and the control word count and status and returns.
>
> Three subroutines or one with 3 entry points to handle TON, TOF, RTO.

What about the situation where an online debugging environment or a HMI/SCADA system needs to see the timer values, but the timer is not
currently being scanned by the program. There needs to be an alternate method of calling the update subroutine. I am definitely not saying you are wrong, just that this situation needs
consideration.

Scott Cornwall
www.psc.fp.co.nz


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

Scott Cornwall

> If the external system (HMI or whatever) has access to the data table it
> can see the current timer values. Elapsed time and status are only
> updated when the rung or statement containing the timer's instruction is
> scanned. If the program stops scanning the part containing the timer, it
> (the timer) essentially 'freezes'. This can occur intentionally by
> design or unintentionally through error. If by design, then the timer
> values are no longer relevant to the program. If through error, then
> some debugging is required.
>
> A further point of interest - the elapsed time will increment at the
> greater of the time base and the program scan rate, i.e. a timer with a
> 10 msec time base that is scanned every 20 msec will increment by 2's
> (and will overrun an odd-value preset).
>
> This is how all A-B PLC's have functioned down through the ages...

OK, I am trying to step beyond the method of operation of the legacy PLC, where the norm is for every rung to be evaluated on every scan.
Take for example a program structured with SFC or a state methodology. If you want to start timing a multistep operation in one particular step, do
you then need to include a "timer instruction" in _all_ other steps of the sequence simply so that the timer will be updating for the external systems. That would be asking for trouble, let alone being a major annoyance to the programmer and impact scan time. I do not think this project should limit its capability based on how ladder
logic PLCs have operated in the past. The timer subsystem that has been discussed so far is very close to something that will be generic enough for many language implementations.

Scott Cornwall
www.psc.fp.co.nz

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
Are my messages getting on to the list?

Here goes anyway.

The timers are updated by an update event caused by an independant thread or process. However, the timer can only be evaluated when the timer is scanned in the program (ladder or IL).

For more info see http://www.warrier.demon.co.uk/JPLC.htm


> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Scott Cornwall
>
> > If the external system (HMI or whatever) has access to the data table it
> > can see the current timer values. Elapsed time and status are only
> > updated when the rung or statement containing the timer's instruction is
> > scanned. If the program stops scanning the part containing the timer, it
> > (the timer) essentially 'freezes'. This can occur intentionally by
> > design or unintentionally through error. If by design, then the timer
> > values are no longer relevant to the program. If through error, then some debugging is required.
> >
> > A further point of interest - the elapsed time will increment at the
> > greater of the time base and the program scan rate, i.e. a timer with a
> > 10 msec time base that is scanned every 20 msec will increment by 2's
> > (and will overrun an odd-value preset).
> >
> > This is how all A-B PLC's have functioned down through the ages...
>
> OK, I am trying to step beyond the method of operation of the legacy PLC,
> where the norm is for every rung to be evaluated on every scan.
> Take for example a program structured with SFC or a state methodology....<clip>

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

Scott Cornwall

> For the SFC situation you describe, a 'latched' action in the first step
> to contain the timer would accomplish what you want. 'Unlatch' the action in a step subsequent to the relavent sequence.

How does that work in respect of the timer system that was being discussed ?
In place of a scanned instruction is there an internal flag that the timer thread (or equivalent) checks to determine whether to update each active timer ? I assume there would be one update per timer per scan , effectively a timer scan (synced to the main scan optional ?).

> For a State machine, I would attempt something similar but lack
> appropriate experience to say definitely - care to enlighten us on how the PSC might handle this?<

Simply start a timer when you want, and read its values/fields when you want. There is no special handling such as requiring an instruction to be
called each scan to update the timer.
Our timer subsystem is quite similar to what was being discussed, allows an unlimited number of timers of 1 msec resolution, and has virtually no impact on scan time.

I think the most important point for the LinuxPLC is that the timer system should flexible enough to cover many language implementations. Flowcharting and others are likely to have similar requirements. I don't want to distract the discussion too much with the details from one
commercial implementation of a PLC, especially as I do not envisage putting any development effort into the project at present. However I am happy to
discuss some specific details "offlist".

Sorry if this is a little disjointed, I got distracted by the America's Cup racing.

Scott Cornwall
www.psc.fp.co.nz

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
I have given this some thought and this is my take on things. If we have a free running logic engine that loops around scanning and
processing as fast as it can then where do you check the timers? Do we do it at he beggining, end or after processing each logic item? We cannot use an alarm() and signal() handler as the granularity is poor to say the least and there is no accuracy either.

> -----Original Message-----
> From: Gerry Hagberg <[email protected]>
> >
> >I don't wish to offend anybody, but I think the discussions about how to
> >implement timers have gone off the deep end! I don't believe they
> >require anything like an 'engine'. To my mind they could and should be
> >implemented as a simple subroutine in the logic solver.
> >
> >The essential data for a timer is stored in a 3-word structure in the
> >data table: preset, accumulator (elapsed time), and control. When the
> >program (ladder, IL, ST, etc.) encounters a timer instruction it (the
> >solver) calls the subroutine and passes the data structure as a
> >parameter (by reference). The control word contains status bits
> >(enabled, timing, done), time base info., and a reference count. The
> >subroutine has access to a free-running timer/counter in the nether
> >regions of the solver or OS that counts "heartbeats" of the system which
> >are frequent enough and consistent enough to give the desired timing
> >resolution and accuracy. When called, the subroutine compares the count
> >in the passed structure's control word with the heartbeat counter, then
> >updates the accumulator and the control word count and status and
> >returns.
> >
> >Three subroutines or one with 3 entry points to handle TON, TOF, RTO.


Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Wed, 26 Jan 2000, Gerry Hagberg wrote:

> >What about the situation where an online debugging environment or a
> >HMI/SCADA system needs to see the timer values, but the timer is not
> >currently being scanned by the program.
> >There needs to be an alternate method of calling the update subroutine.
>
> >I am definitely not saying you are wrong, just that this situation needs consideration.
> >
> I'm not sure I fully understand the question, but here's an attempted answer.
>
> If the external system (HMI or whatever) has access to the data table it
> can see the current timer values. Elapsed time and status are only
> updated when the rung or statement containing the timer's instruction is
> scanned. If the program stops scanning the part containing the timer, it
> (the timer) essentially 'freezes'. This can occur intentionally by
> design or unintentionally through error. If by design, then the timer
> values are no longer relevant to the program. If through error, then
> some debugging is required.
>
> A further point of interest - the elapsed time will increment at the
> greater of the time base and the program scan rate, i.e. a timer with a
> 10 msec time base that is scanned every 20 msec will increment by 2's
> (and will overrun an odd-value preset).
>
> This is how all A-B PLC's have functioned down through the ages...

Is it really? Are you sure?
I'm not disagreeing. I just find it incredible.

Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


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

Curt Wuollet

Dave West wrote:

> I have given this some thought and this is my take on things.
> If we have a free running logic engine that loops around scanning and
> processing as fast as it can then where do you check the timers? Do we do
> it at he beggining, end or after processing each logic item? We cannot use
> an alarm() and signal() handler as the granularity is poor to say the
> least and there is no accuracy either.
>

FWIW, I am still planning on synchronization flags or semaphores in the map. With a range of IO speeds, I don't see how we can avoid it and
maintain data consistancy.

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
The free running logic engine must be scheduled to run at a specific rate so that there is sufficient cpu time for the OS may service other
processes in the computer (i.e. mouse, keyboard, network, etc...). You have to realize that unlike many traditional PLCs the LINUX PLC will
exist in a general purpose computer.


Dave West wrote:
>
> I have given this some thought and this is my take on things.
> If we have a free running logic engine that loops around scanning and
> processing as fast as it can then where do you check the timers? Do we do
> it at he beggining, end or after processing each logic item? We cannot use
> an alarm() and signal() handler as the granularity is poor to say the
> least and there is no accuracy either.

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

Gerry Hagberg

I'm not sure I fully understand the question, but here's an attempted answer.

If the external system (HMI or whatever) has access to the data table it can see the current timer values. Elapsed time and status are only
updated when the rung or statement containing the timer's instruction is scanned. If the program stops scanning the part containing the timer, it
(the timer) essentially 'freezes'. This can occur intentionally by design or unintentionally through error. If by design, then the timer
values are no longer relevant to the program. If through error, then some debugging is required.

A further point of interest - the elapsed time will increment at the greater of the time base and the program scan rate, i.e. a timer with a
10 msec time base that is scanned every 20 msec will increment by 2's (and will overrun an odd-value preset).

This is how all A-B PLC's have functioned down through the ages...

Gerry

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

Gerry Hagberg

For the SFC situation you describe, a 'latched' action in the first step to contain the timer would accomplish what you want. 'Unlatch' the
action in a step subsequent to the relavent sequence.

For a State machine, I would attempt something similar but lack appropriate experience to say definitely - care to enlighten us on how the PSC might handle this?

Gerry

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

Locke, Alan S

Dave West wrote:
>> If the external system (HMI or whatever) has access to the data table it
>> can see the current timer values. Elapsed time and status are only
>> updated when the rung or statement containing the timer's instruction is
>> scanned. If the program stops scanning the part containing the timer, it
>> (the timer) essentially 'freezes'. This can occur intentionally by
>> design or unintentionally through error. If by design, then the timer
>> values are no longer relevant to the program. If through error, then
>> some debugging is required.
>>
>> A further point of interest - the elapsed time will increment at the
>> greater of the time base and the program scan rate, i.e. a timer with a
>> 10 msec time base that is scanned every 20 msec will increment by 2's
>> (and will overrun an odd-value preset).
>>
>> This is how all A-B PLC's have functioned down through the ages...
>
>Is it really? Are you sure?I'm not disagreeing.
>I just find it incredible.
>
Gerry is correct here, even for the newer ControlLogix. This can be an anoyance in
ControlLogix in particularily where multiple tasks can have different periodic rates set.
If you enable a global timer in one task that executes really slowly at every 100 msecs
and then examine the acc attribute in another task that executes faster than 100 msecs,
you'll still only get the acc attribute updated every 100 msecs. But then who needs
global timers in ControlLogix anyway ;)

Alan Locke
Controls Engineer, Boeing

"My opinions are my own and not necessarily those of my employer"




_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Wed, 26 Jan 2000, Curt Wuollet wrote:

> Dave West wrote:
>
> > I have given this some thought and this is my take on things.
> > If we have a free running logic engine that loops around scanning and
> > processing as fast as it can then where do you check the timers? Do we do
> > it at he beggining, end or after processing each logic item? We cannot use
> > an alarm() and signal() handler as the granularity is poor to say the
> > least and there is no accuracy either.
>
> FWIW, I am still planning on synchronization flags or semaphores in the
> map. With a range of IO speeds, I don't see how we can avoid it and
> maintain data consistancy.
>
> cww

We can't avoid it. I would use a semaphore as this allows one process to block while waiting for the table and not eat up processor time that is better used on the other processes.


Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Wed, 26 Jan 2000, Rick wrote:

> The free running logic engine must be scheduled to run at a specific
> rate so that there is sufficient cpu time for the OS may service other
> processes in the computer (i.e. mouse, keyboard, network, etc...). You
> have to realize that unlike many traditional PLCs the LINUX PLC will
> exist in a general purpose computer.

Yes the linux PLC will be running on general purpose hardware but will it be doing general purpose things? Eg. will some secretary be typing a letter to a supplier on the same computer that is controlling the plant? I know it is capable but will it be allowed? I think not.

The free running logic engine will block from time to time when it wants to copy the data tables and that will allow other processes there shot. Ok this will increase the scan time for a period. I don't see why we need to give it a specific scheduling rate at this point in the development.

> Dave West wrote:
> >
> > I have given this some thought and this is my take on things.
> > If we have a free running logic engine that loops around scanning and
> > processing as fast as it can then where do you check the timers? Do we do
> > it at he beggining, end or after processing each logic item? We cannot use
> > an alarm() and signal() handler as the granularity is poor to say the
> > least and there is no accuracy either.

Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R
Dave West wrote:
>
> On Wed, 26 Jan 2000, Rick wrote:
>
> > The free running logic engine must be scheduled to run at a specific
> > rate so that there is sufficient cpu time for the OS may service other
> > processes in the computer (i.e. mouse, keyboard, network, etc...). You
> > have to realize that unlike many traditional PLCs the LINUX PLC will
> > exist in a general purpose computer.
>
> Yes the linux PLC will be running on general purpose hardware but will it
> be doing general purpose things? Eg. will some secretary be typing a
> letter to a supplier on the same computer that is controlling the plant? I
> know it is capable but will it be allowed? I think not.
>
> The free running logic engine will block from time to time when it wants
> to copy the data tables and that will allow other processes there shot. Ok
> this will increase the scan time for a period. I don't see why we need to
> give it a specific scheduling rate at this point in the development.

In this scenario the operating system will only work from time to time. I wasn't thinking about a secretary typing letters, I was thinking about
a technician trying to figure out why there is a pile of twisted metal at the end of the production line and what he/she is going to tell the boss.

---- snip ---

Rick J

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

Gerry Hagberg

Just off the top of my head, I think this results in more work for the CPU, since it is probable in a system programmed with SFC's that not all
timers will be scanned all the time. Also, the bulk update would need to be synchronised to the program scan or you will introduce inconsistency similar to what occurs with asynchronous I/O scans.

Gerry

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