persistent data

J

Johan Bengtsson

>> >Unless you synch the data on every write you will lose data if someone
>> >switches the PC off. Syncing the data on every write will kill your
>> >performance. A reasonable technique is to configure the shared memory
>> >as a memory mapped file, this will give you persistence. Periodically
>> >you can flush it to disk.
>
>Stan Brown:
>> Well, I was thinking of a process whose job it is to scan the data
>> tables, and write any changes it finds to the disk files.
>

If it is possible to configure some special (small) area to save and save that as often as possible I think that is enough for most
application, if not - buy an UPS or a battery backed RAM card...

If the data is saved in different places for each save in some kind of round robin scheme together with a version number with enough bits to identify the newest version even when a wrap occurs and some CRC scheme to identify the versions really fully written. This way the data may not be saved really each scan, but if the data
is consistent for a paricular scan not too far from the power failure it should be enough in most cases.

Writing one sector (512 bytes) - say 12 bytes for recover information like CRC, version stamp and so on will still give you about 250 16bit
values or 4000 digital values - (I don't intend this as a limit, just an example for the calculations). This should be quite fast and
probably cover most applications needing to store anything!

Can someone fill in the expected maximum time to write this amount to a harddrive under linux?

<clip>


----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 Hässleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------


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

Johan Bengtsson

>> >The only data tables that need to be written to disk are the "internal
>> >coils", aren't they?
>> No, in a real PLC _all data_ is in battery backed RAM.
>
>I'm not sure whether this is a disagreement or a misunderstanding...
>

I think this depends on type of PLC.
In Some PLC:s I have seen (mostly Mitsubishi) there where special memory areas backed upp and other not backed up. I think the same is true for timers and counters. I do however not know exacly where I saw it right now



----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 Hässleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
In Siemens S5, only the first 64 (?) flag bytes are retentive (retain there
value on power down).

-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of [email protected]

>> >The only data tables that need to be written to disk are the "internal
>> >coils", aren't they?
>> No, in a real PLC _all data_ is in battery backed RAM.
>
>I'm not sure whether this is a disagreement or a misunderstanding...
>

I think this depends on type of PLC.
In Some PLC:s I have seen (mostly Mitsubishi) there where special memory areas backed upp and other not backed up. I think the same is true for timers and counters. I do however not know exacly where I saw it right now

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Mon, 17 Jan 2000, Stan Brown wrote:

> On Mon Jan 17 07:39:40 2000 Dave West wrote...
> >
> >Surely any programmer that relies on the saved state of the I/O after a
> >non orderly shutdown is asking for trouble.
> >What happens to the machine if the power is cut and the operators have to
> >manually do something to the machine to extract the product. If the
> >machine is not put back in the exact same state before power is restored
> >then the machine could at least be damaged or worse injure somebody.
> >Surely the correct programming technique is to re-initialise the machine
> >from real inputs ignoring any saved I/O (because you don't know if it is
> >valid) and drive the machine to a safe startup state. For example I would
> >never code for battery backed inputs, outputs, timers or counters. The
> >only items that should be battery backed are set points, control limits
> >and alarm limits (you may or may not battery back alarm states depending
> >on the kind of automation required).
> >A good example is a printing machine. It should not assume that the piece
> >of paper it was printing is still there to print on or even in the same
> >position after a power interruption. If it can not determine this from
> >real live inputs then it should eject that piece of paper and re-start on
> >a new sheet.
>
> The issue, once again, is _npt_ teh I/O states. It is teh non I/O data table.
>
> Recipes, amounts of material loaded inot vesels, all sorts of required things are stored there. <

Surely a well controlled machine can measure from a live input material loaded into a vessel etc, as such things can change over a power cut.
Recipes I agree with, they need to be saved, but do they really change so often that they need to be saved every scan? and if so surely they are no
longer recipes. It may be that I do not understand your interpretation ofa recipe. I see it as something similar to a cook book with pages of recipes for hotpot, stew, soup, Chicken Kiev etc. Once set it does not change. Anything that a recipe controls that changes depending on how far
you are through the recipe is not part of the recipe but is a variable that is measure against the recipe and therefore should be discernable
from live I/O. Hmm, I just thought about entries in a recipe that are measured by time.This makes it difficult in that the elapsed time would need to be saved and this could be very frequent.

> >As for any of the methods suggested so far none are of any use. You do not
> >know when the power is going to fail. If the data is copied to a disk or
> >flash or whatever then your power cut may occur during the write and your
> >data is then corrupt. The only way to implement this is to add a UPS that
> >will signal a power failure and ensure sufficient time to save the state
> >to permanent storage and then perform an orderly storage.
>
> Journaling filesystems go a long way twoard addressing this.

Yes but they do not reliably solve the problem 100% of the time.

> >We all know why systems check the disks on boot up after an un ordered
> >shutdown. You do not know if your saved state survived the un ordered
> >shutdown and the file system may be corrupt or fixed by fsck or whatever
> >and is therefore invalid anyway.

This is the main point of my argument.
On boot the system state can not be reliably determined from any saved data unless the system shut down in an ordered fashion. To achieve this
you need a UPS that signals power loss and allows you to shut down properly.
Some people have said a UPS in unacceptable because of the situation where the UPS fails. I think this situation is the same as the one where a PLC backup battery fails and therefore all bets are off.


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 Mon, 17 Jan 2000, Alan Locke wrote:

> Dave West wrote:
> >Surely any programmer that relies on the saved state of the I/O after a
> >non orderly shutdown is asking for trouble.
> >What happens to the machine if the power is cut and the operators have to
> >manually do something to the machine to extract the product. If the
> >machine is not put back in the exact same state before power is restored
> >then the machine could at least be damaged or worse injure somebody.
> >Surely the correct programming technique is to re-initialise the machine
> >from real inputs ignoring any saved I/O (because you don't know if it is
> >valid) and drive the machine to a safe startup state. For example I would
> >never code for battery backed inputs, outputs, timers or counters. The
> >only items that should be battery backed are set points, control limits
> >and alarm limits (you may or may not battery back alarm states depending
> >on the kind of automation required).
> >A good example is a printing machine. It should not assume that the piece
> >of paper it was printing is still there to print on or even in the same
> >position after a power interruption. If it can not determine this from
> >real live inputs then it should eject that piece of paper and re-start on
> >a new sheet.
>
> There are many applications that require the machine state to be saved to be
> able to reasonably recover after a power bump. For instance machines that
> don't have enough sensors to determine the state based on inputs alone
> (a common issue with material handling systems), or machines that
> have a degree of autonomy and need to be able to recover without operator
> intervention. Even if the operator is available to assist in the power
> loss recovery, it's nice to have the machine HMI prompt the operator
> through a recovery process based at least partly on prior state. A common
> solution to machines that may be changed (by maintenance personnel possibly)
> without the PLCs knowledge is a machine reset process.
>
> This is definitely one of the difficult areas in control engineering, being so
> highly tied to the machine process and complex fault trees.

I'm not disagreeing with the requirement to save some state on power loss. What I have been trying to say is that any attempt to save state of all
data on every scan will make our project so slow that it will be useless. The correct way to save state is detect the event that requires a state
save (power loss) and deal with it (UPS and ordered shutdown saving machine state prior to power off).

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, 19 Jan 2000, Mark Hutton wrote:

> In Siemens S5, only the first 64 (?) flag bytes are retentive (retain there
> value on power down).
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of [email protected]

> >> >The only data tables that need to be written to disk are the "internal
> >> >coils", aren't they?
> >> No, in a real PLC _all data_ is in battery backed RAM.
> >
> >I'm not sure whether this is a disagreement or a misunderstanding...
> >
>
> I think this depends on type of PLC.
> In Some PLC:s I have seen (mostly Mitsubishi) there where
> special memory areas backed upp and other not backed up.
> I think the same is true for timers and counters.
> I do however not know exacly where I saw it right now

Using MEDOC you set which data values are retentive in blocks via the parameters option.
You can set data registers, timers, counters, relays etc. There is only one block per type and it must be contiguous. Note by default none are retentive.


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
 
All the points you make are very true...
> A good example is a printing machine. It should not assume that the piece
> of paper it was printing is still there to print on or even in the same
> position after a power interruption. If it can not determine this from
> real live inputs then it should eject that piece of paper and re-start on
> a new sheet.

However,
the value of the article being produced has an influence on the machine program. When a fridge, or car body (or several car bodies within a single
machine) is partly completed, a lot of value adding has been invested in them already. Some machine do enforce a clean/empty start, but they are not as well thought of as other machines which try to avoid scrap. It is often not permissible to redo the whole cycle again, starting from scratch, upon the half finished parts/car-bodies. For an example, the tooling
people utter a warning that for some of the punch-tooling/dies it would cause great damage to the tooling if it punches into an pre-existing hole.
Imagine that it is impossible to sense/monitor/measure let alone see some
of the holes until shifted clear of the tooling. So with no direct sensing, a possible second-best/fall-back methodology is to memorise what
has and what has not yet been punched/done. The judicious use of persistence seems sometimes not to be too big a risk to take, especially since there will be a careful operator available to check the machine stages before enabling the machine, stage by stage. But in a better world,
what you say has merit.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
<clip>
However,
the value of the article being produced has an influence on the machine
program. When a fridge, or car body (or several car bodies within a single
machine) is partly completed, a lot of value adding has been invested in
them already. Some machine do enforce a clean/empty start, but they are
not as well thought of as other machines which try to avoid scrap. It is
often not permissible to redo the whole cycle again, starting from scratch,
upon the half finished parts/car-bodies. For an example, the tooling
people utter a warning that for some of the punch-tooling/dies it would
cause great damage to the tooling if it punches into an pre-existing hole.
Imagine that it is impossible to sense/monitor/measure let alone see some
of the holes until shifted clear of the tooling. So with no direct
sensing, a possible second-best/fall-back methodology is to memorise what
has and what has not yet been punched/done. The judicious use of
persistence seems sometimes not to be too big a risk to take, especially
since there will be a careful operator available to check the machine
stages before enabling the machine, stage by stage. But in a better world,
what you say has merit.
</clip>

I go back to my earlier point. NO ASSUMPTIONS should be made on power up. What point is persistance, in this context, if the real world is not persistant.

While the line is powered down there is no way to garauntee that the remembered process state remains accurate. While the machine is powered down product may have been moved, in any direction, by any amount.

Process start up states that cannot be determined by machine initial startup sequences should not automatically restart. If you are worried about reject cost install manual sequencing to bring the process back to the known state, otherwise reject it.


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

Johan Bengtsson

>> >Unless you synch the data on every write you will lose data if someone
>> >switches the PC off. Syncing the data on every write will kill your
>> >performance. A reasonable technique is to configure the shared memory
>> >as a memory mapped file, this will give you persistence. Periodically
>> >you can flush it to disk.
>
>Stan Brown:
>> Well, I was thinking of a process whose job it is to scan the data
>> tables, and write any changes it finds to the disk files.
>

If it is possible to configure some special (small) area to save and save that as often as possible I think that is enough for most
application, if not - buy an UPS or a battery backed RAM card...

If the data is saved in different places for each save in some kind of round robin scheme together with a version number with enough bits to identify the newest version even when a wrap occurs and some CRC scheme to identify the versions really fully written. This way the data may not be saved really each scan, but if the data
is consistent for a paricular scan not too far from the power failure it should be enough in most cases.

Writing one sector (512 bytes) - say 12 bytes for recover information like CRC, version stamp and so on will still give you about 250 16bit
values or 4000 digital values - (I don't intend this as a limit, just an example for the calculations). This should be quite fast and
probably cover most applications needing to store anything!

Can someone fill in the expected maximum time to write this amount to a harddrive under linux?

>The only data tables that need to be written to disk are the "internal
>coils", aren't they?
>
>The place in the architecture where this fits is among the I/O drivers:
>just another set of points, except instead of interfacing to a PLC it'll
>interface to a disk file.
>
>You'll probably lose a few seconds worth of data in a crash, but I don't
>think that can really be helped.
>
>The advantage of doing it like this is that if a few seconds' loss is
>unacceptable, you load the battery-backed-RAM driver instead.
>
>> I realize this is a performance issue, _but_ it is critical to the
>> operation of the process, and it is a problem that has been solved
>> by the database code writers, they can't lose data either.
>
>Yes, but they don't have the real-time problem. (Well, they do, but it's
>not as hard as ours. Their real-time problems are measured in seconds or
>days.)


----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 Hässleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Dave West:
> Hmm, I just thought about entries in a recipe that are measured by time.
> This makes it difficult in that the elapsed time would need to be saved
> and this could be very frequent.

No, you just save the wall-time (either for timer-start or timer-end, probably for whichever is represented as zero).

This must be in GMT/UTC (one of them, anyway), but that's default in Linux.


(Actually, it isn't - for recipe timers you'd want the UTC without the leap seconds - but it's close enough as will make no difference.)


> Some people have said a UPS in unacceptable because of the situation > where the UPS fails. I think this situation is the same as the one where
> a PLC backup battery fails and therefore all bets are off.

Good point.


Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri, 21 Jan 2000, Jiri Baum wrote:

> Dave West:
> > Hmm, I just thought about entries in a recipe that are measured by time.
> > This makes it difficult in that the elapsed time would need to be saved
> > and this could be very frequent.
>
> No, you just save the wall-time (either for timer-start or timer-end,
> probably for whichever is represented as zero).
>
> This must be in GMT/UTC (one of them, anyway), but that's default in Linux.
>
> (Actually, it isn't - for recipe timers you'd want the UTC without the leap
> seconds - but it's close enough as will make no difference.)

Ermm, I think you missed my point slightly. First can you explain wall-time. Second how does a timer that counts a number of seconds know
about GMT/UTC if it is stored in 16 bits. More apropriately what does it care.

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 Fri Jan 21 09:22:53 2000 Dave West wrote...
>
>On Fri, 21 Jan 2000, Jiri Baum wrote:
>
>> Dave West:
>> > Hmm, I just thought about entries in a recipe that are measured by time.
>> > This makes it difficult in that the elapsed time would need to be saved
>> > and this could be very frequent.
>>
>> No, you just save the wall-time (either for timer-start or timer-end,
>> probably for whichever is represented as zero).
>>
>> This must be in GMT/UTC (one of them, anyway), but that's default in Linux.
>>
>>
>> (Actually, it isn't - for recipe timers you'd want the UTC without the leap
>> seconds - but it's close enough as will make no difference.)
>
>Ermm, I think you missed my point slightly. First can you explain
>wall-time. Second how does a timer that counts a number of seconds know
>about GMT/UTC if it is stored in 16 bits. More apropriately what does it
>care.
>

Excelent point. BTW timers need to have a finer resolution that 1 sec.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri, Jan 21, 2000 at 02:22:53PM +0000, Dave West wrote:
> On Fri, 21 Jan 2000, Jiri Baum wrote:
>
> > Dave West:
> > > Hmm, I just thought about entries in a recipe that are measured by time.
> > > This makes it difficult in that the elapsed time would need to be saved
> > > and this could be very frequent.
> >
> > No, you just save the wall-time (either for timer-start or timer-end,
> > probably for whichever is represented as zero).
> >
> > This must be in GMT/UTC (one of them, anyway), but that's default in Linux.
> >
> >
> > (Actually, it isn't - for recipe timers you'd want the UTC without the leap
> > seconds - but it's close enough as will make no difference.)
>
> Ermm, I think you missed my point slightly.

Well, rather than saving elapsed time continually, you save the wall-time whenever the timer is reset.

> First can you explain wall-time.

It's the time on the clock on the wall, eg "Sat Jan 22 14:31:27 UTC 2000".

> Second how does a timer that counts a number of seconds know about
> GMT/UTC if it is stored in 16 bits. More apropriately what does it care.

To turn the question around, how *else* are you going to implement a timer?

Yes, the user only cares about elapsed time. But the only practical way of implementing it is to store the start time (or the end time) and compare
the current time with that whenever the user asks (or on every scan).


Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sun, 23 Jan 2000, Jiri Baum wrote:

> On Fri, Jan 21, 2000 at 02:22:53PM +0000, Dave West wrote:
> > On Fri, 21 Jan 2000, Jiri Baum wrote:
> >
> > > Dave West:
> > > > Hmm, I just thought about entries in a recipe that are measured by time.
> > > > This makes it difficult in that the elapsed time would need to be saved
> > > > and this could be very frequent.
> > >
> > > No, you just save the wall-time (either for timer-start or timer-end,
> > > probably for whichever is represented as zero).
> > >
> > > This must be in GMT/UTC (one of them, anyway), but that's default in Linux.
> > >
> > >
> > > (Actually, it isn't - for recipe timers you'd want the UTC without the leap
> > > seconds - but it's close enough as will make no difference.)
> >
> > Ermm, I think you missed my point slightly.
>
> Well, rather than saving elapsed time continually, you save the wall-time
> whenever the timer is reset.
>
> > First can you explain wall-time.
>
> It's the time on the clock on the wall, eg "Sat Jan 22 14:31:27 UTC 2000".
>
> > Second how does a timer that counts a number of seconds know about
> > GMT/UTC if it is stored in 16 bits. More apropriately what does it care.
>
> To turn the question around, how *else* are you going to implement a timer?

Dead simple count interrupts like Linux does. Remember that Linux has no concept of time just an elapsed time ticker that it initialises from your BIOS RTC at boot time or even from a time server on the internet. Almost all PLC's I have worked with have absolutely no concept of wall-time at all yet they still run lots of timers.

> Yes, the user only cares about elapsed time. But the only practical way of
> implementing it is to store the start time (or the end time) and compare
> the current time with that whenever the user asks (or on every scan).

Many of the devices that were tested for Y2K compliance passed without problem because they have absolutely no concept of wall time yet they all have timers. Thus storing the start time and comparing it with real time is certainly not the *only* practical way of doing this!


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 Sat Jan 22 09:36:53 2000 Jiri Baum wrote...
>
>To turn the question around, how *else* are you going to implement a timer?

It simply a counter, incremented at the timebase, if enabled, and not done. The timebase is a multiple of the dreaded 10ms ticks of the kernel.

>Yes, the user only cares about elapsed time. But the only practical way of
>implementing it is to store the start time (or the end time) and compare
>the current time with that whenever the user asks (or on every scan).
>

I don;t think so, since the timer execution engine will potentially have may timers to deal with, I think keeping up with the start time of all of them would be a royal pain. Also they can be stopped, and restarted (in the case of retentive times) by the logic engines.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat, Jan 22, 2000 at 03:46:10PM +0000, Dave West wrote:
> On Sun, 23 Jan 2000, Jiri Baum wrote:
> > To turn the question around, how *else* are you going to implement a
> > timer?

> Dead simple count interrupts like Linux does.

Not as simple as it sounds. For one thing, you're going to miss clock ticks and get errors unless you really know what you are doing. For another
thing, you don't want to be updating a thousand timers from your interrupt handler.

> Remember that Linux has no concept of time just an elapsed time ticker
> that it initialises from your BIOS RTC at boot time or even from a time
> server on the internet. Almost all PLC's I have worked with have
> absolutely no concept of wall-time at all yet they still run lots of timers.

Hmm, I suspect they do work off the concept of wall-time, it's just that since they are only interested in differences, they don't bother asking for it and just assume they were turned on at midnight 1st January AD 1.

A very private concept of wall-time, I admit, but it suffices for the purposes.

The other way of looking at it is that there is one interrupt-driven "master timer", and all the other timers work off that. In linux, the master timer happens to run on GMT.

Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat, Jan 22, 2000 at 11:35:38AM -0500, Stan Brown wrote:
> On Sat Jan 22 09:36:53 2000 Jiri Baum wrote...

> >Yes, the user only cares about elapsed time. But the only practical way
> >of implementing it is to store the start time (or the end time) and
> >compare the current time with that whenever the user asks (or on every
> >scan).

> I don;t think so, since the timer execution engine will potentially
> have may timers to deal with, I think keeping up with the start
> time of all of them would be a royal pain.

No, having to increment all of them at each tick would be a royal pain.

(Unless you really know what you are doing, you'll end up missing ticks. The kernel already solved that problem - let's hang our timers of the
kernel timer, rather than re-implementing it.)

> Also they can be stopped, and restarted (in the case of retentive
> times) by the logic engines,.

Stopped timers store elapsed time, of course.


Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Mon Jan 24 04:15:08 2000 Jiri Baum wrote...
>
>On Sat, Jan 22, 2000 at 03:46:10PM +0000, Dave West wrote:
>> On Sun, 23 Jan 2000, Jiri Baum wrote:
>> > To turn the question around, how *else* are you going to implement a
>> > timer?
>
>> Dead simple count interrupts like Linux does.
>
>Not as simple as it sounds. For one thing, you're going to miss clock ticks
>and get errors unless you really know what you are doing. For another
>thing, you don't want to be updating a thousand timers from your interrupt
>handler.

Thats why the timer execution engine is a task onto itself. And BTW .01 sec resolution is all we neeed here.

>> Remember that Linux has no concept of time just an elapsed time ticker
>> that it initialises from your BIOS RTC at boot time or even from a time
>> server on the internet. Almost all PLC's I have worked with have
>> absolutely no concept of wall-time at all yet they still run lots of timers.
>
>Hmm, I suspect they do work off the concept of wall-time, it's just that
>since they are only interested in differences, they don't bother asking for
>it and just assume they were turned on at midnight 1st January AD 1.

Many of these devices have no concept of wall time. Just a continuing stream of ticks.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Mon Jan 24 04:06:08 2000 Jiri Baum wrote...
>
>On Sat, Jan 22, 2000 at 11:35:38AM -0500, Stan Brown wrote:
>> On Sat Jan 22 09:36:53 2000 Jiri Baum wrote...
>
>> >Yes, the user only cares about elapsed time. But the only practical way
>> >of implementing it is to store the start time (or the end time) and
>> >compare the current time with that whenever the user asks (or on every scan).
>
>> I don;t think so, since the timer execution engine will potentially
>> have may timers to deal with, I think keeping up with the start
>> time of all of them would be a royal pain.
>
>No, having to increment all of them at each tick would be a royal pain.
>
>(Unless you really know what you are doing, you'll end up missing ticks.
>The kernel already solved that problem - let's hang our timers of the
>kernel timer, rather than re-implementing it.)

This can be impeented very simpy for the resolutin we need. If we can get a consenus on the data table structures, and the library calls to interface to them. I will whip up a sample timer execution engine to put this discussion to bed.


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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Mon, 24 Jan 2000, Jiri Baum wrote:

> On Sat, Jan 22, 2000 at 11:35:38AM -0500, Stan Brown wrote:
> > On Sat Jan 22 09:36:53 2000 Jiri Baum wrote...
>
> > >Yes, the user only cares about elapsed time. But the only practical way
> > >of implementing it is to store the start time (or the end time) and
> > >compare the current time with that whenever the user asks (or on every scan).
>
> > I don;t think so, since the timer execution engine will potentially
> > have may timers to deal with, I think keeping up with the start
> > time of all of them would be a royal pain.
>
> No, having to increment all of them at each tick would be a royal pain.

Yes it would be a royal pain incrementing or decrementing all the timers every tick.

> (Unless you really know what you are doing, you'll end up missing ticks.
> The kernel already solved that problem - let's hang our timers of the
> kernel timer, rather than re-implementing it.)

Well, I'm not sure about hanging our timers off the kernel timer but we should look at the kernel for the best way to handle a quantity of timers.
Basically you know which timer will expire first so you only test for it expiring. If that timer is disabled or a shorter timer is created/started
then you re-evaluate which timer will expire first and test only that one. To do this you need a free running clock such as the jiffies counter and always compare against that. Note I have not mentioned wall-time as I think this free running timer should start when the PLC logic is started
and have absolutely no relation to wall-time.

> > Also they can be stopped, and restarted (in the case of retentive
> > times) by the logic engines,.
>
> Stopped timers store elapsed time, of course.


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
 
Top