persistent data

On Mon, 24 Jan 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.
>
> > 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.

This implies an understanding of minutes, hours, days, weeks, months, years and leap days etc. None of the PLC's I was refering to has any
knowledge, concept or idea of these things. Indeed, I have worked on projects where we designed and built embedded controllers they had timers but no concept of wall-time. I know this to be the case because I wrote all the code in 8085 asm myself.

> 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.

No it does not. It runs on seconds since 00:00 1/1/1970 (or similar). The library routines sort that count into GMT/UTC or whatever on request and
it is not accurate to the millisecond. It may be accurate to within +/- 9 msec depending on when the timer interrupt was initialised and assuming
the clock it initialised the counter from was correct.


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, Jan 24, 2000 at 02:36:14PM +0000, Dave West wrote:
> On Mon, 24 Jan 2000, Jiri Baum wrote:
> > 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.

> This implies an understanding of minutes, hours, days, weeks, months, years and leap days etc. <

Not really, more a willful ignorance of them. In AD 1, years were reckoned Urbis Conditae, started in March, didn't have leap days and days themselves, didn't start at midnight but at sundown. Or something.

...
> > 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.

> No it does not. It runs on seconds since 00:00 1/1/1970 (or similar).

Well, yes and no. It's seconds since 00:00 1/1/1970 GMT.

> The library routines sort that count into GMT/UTC or whatever on request

Yes, they sort it into hours and minutes and whatnot, but we don't need to call that library function - we can just get seconds count and use that.

(It's better to use that count rather than jiffies-since-boot, because the system time will be of the same order of magnitude throughout execution. We don't want to have the problem of losing timing accuracy when running longer, like the Patriot missiles reportedly did around Kuwait and Iraq.)

> and it is not accurate to the millisecond. It may be accurate to within
> +/- 9 msec depending on when the timer interrupt was initialised and
> assuming the clock it initialised the counter from was correct.

Hmm, what does the UTIME patch do to that? Does it make it more accurate?

We probably don't care about leap seconds, do we.

Damn, I just read the manpage and supposedly at 2100.02.28 23:59:59 the system clock will jump by a whole day.

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 Tue, 25 Jan 2000, Jiri Baum wrote:

> On Mon, Jan 24, 2000 at 02:36:14PM +0000, Dave West wrote:
> > On Mon, 24 Jan 2000, Jiri Baum wrote:
> > > 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.
>
> > This implies an understanding of minutes, hours, days, weeks, months, years and leap days etc.< <
>
> Not really, more a willful ignorance of them. In AD 1, years were reckoned
> Urbis Conditae, started in March, didn't have leap days and days themselves
> didn't start at midnight but at sundown. Or something.
>
> ...
> > > 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.
>
> > No it does not. It runs on seconds since 00:00 1/1/1970 (or similar).
>
> Well, yes and no. It's seconds since 00:00 1/1/1970 GMT.
>
> > The library routines sort that count into GMT/UTC or whatever on request
>
> Yes, they sort it into hours and minutes and whatnot, but we don't need to
> call that library function - we can just get seconds count and use that.

Exactly it is not wall-time it is seconds count!!

> (It's better to use that count rather than jiffies-since-boot, because the
> system time will be of the same order of magnitude throughout execution. We
> don't want to have the problem of losing timing accuracy when running
> longer, like the Patriot missiles reportedly did around Kuwait and Iraq.)

And the seconds count is incremented when the jiffies count passes 100's

> > and it is not accurate to the millisecond. It may be accurate to within
> > +/- 9 msec depending on when the timer interrupt was initialised and
> > assuming the clock it initialised the counter from was correct.
>
> Hmm, what does the UTIME patch do to that? Does it make it more accurate?

I don't really know, I think it has the potential to but then who really cares. Most likely the clock you initialised from is only accurate to the
nearest second anyway.

> We probably don't care about leap seconds, do we.
>
> Damn, I just read the manpage and supposedly at 2100.02.28 23:59:59 the
> system clock will jump by a whole day.

What are you trying to say here. That the system clock will jump to March 1? March 1 is the correct next day 2100 is not a leap year.

BTW it's worse than that. As I'm sure you are aware the current system clock will roll over to 00:00 1/1/1970 somewhere around April 2038 so who
cares what happens in 2100?

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 Tue Jan 25 04:13:21 2000 Dave West wrote...
>
>Oh, I don't know about this. Supposing the logic engine keeps track of
>when a coil changes state (including the coils of timers). Then when a
>timer coil gets turned on it can send some message to the timer engine
>telling it to start timer x. When the coil gets turned off a message of
>stop timer x is sent. When the timer engine receives these messages it
>would wake up and re-evaluate the timer expiry order and then sleep untill
>the next timer expires.
>For clarity: I might code this using a FIFO for the message passing
>medium. The timer engine can then use a blocking read on the FIFO with a
>timeout slightly less than the next timer expirey. When the read times
>out, wait for the timer to finish and then re-evaluate and repeat the
>read. When the read returns with a message handle the message, test any
>timers for expirey and re-evaluate before repeating the read.

I have not bought into the inter task communication chanel outside the data tables, yet.

>The way I see things this intercommunication between task has always been
>required and there is no possible way to make this work otherwise.

No, that is _the purpose_ of the data table structures, for things like counters, timers, PID's etc. Not the only purpose, but the single most important one.

>I've had another thought. If the logic engine accesses timers via a shared
>memory segment (the timer data table) then a semaphore or something will
>be required. I believe the timer engine can watch this semaphore and if it
>has been changed by the logic engine or other process (not the timer
>engine) then it can receive a signal and do the processing outlined above.
>This is still inter process communication.

Hmm. prhaps, although my conecept of this has only the shared memory libraries having access to this semaphore.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
-----Original Message-----
From: Dave West <[email protected]>
>
>The way I see things this intercommunication between task has always been
>required and there is no possible way to make this work otherwise.
>
>I've had another thought. If the logic engine accesses timers via a shared
>memory segment (the timer data table) then a semaphore or something will
>be required. I believe the timer engine can watch this semaphore and if it
>has been changed by the logic engine or other process (not the timer
>engine) then it can receive a signal and do the processing outlined above.
>This is still inter process communication.

I think this communications should be through the shared memory like everything else.

Ron Davis

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

Johan Bengtsson

Actually I don't think it will make that much of a
difference, you have to check them anyway and that can be done at the same time. I would go for increasing / decreasing each time but it would not matter THAT much.


/Johan Bengtsson

----------------------------------------
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/
----------------------------------------


-----Original Message-----
From: MIME :[email protected] [SMTP:MIME :[email protected]]

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. ...<clip>

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

Johan Bengtsson

>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.

Hmm, a sorted list of timers sorted by when they would expire... didn't think of that one. Could be quite fast.

>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.

Sounds like a good solution to me


/Johan Bengtsson

----------------------------------------
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
 
On Tue, 25 Jan 2000, Stan Brown wrote:

> On Tue Jan 25 04:13:21 2000 Dave West wrote...
> >
> >Oh, I don't know about this. Supposing the logic engine keeps track of
> >when a coil changes state (including the coils of timers). Then when a
> >timer coil gets turned on it can send some message to the timer engine
> >telling it to start timer x. When the coil gets turned off a message of
> >stop timer x is sent. When the timer engine receives these messages it
> >would wake up and re-evaluate the timer expiry order and then sleep untill
> >the next timer expires.
> >For clarity: I might code this using a FIFO for the message passing
> >medium. The timer engine can then use a blocking read on the FIFO with a
> >timeout slightly less than the next timer expirey. When the read times
> >out, wait for the timer to finish and then re-evaluate and repeat the
> >read. When the read returns with a message handle the message, test any
> >timers for expirey and re-evaluate before repeating the read.
> >
> I have not bought inot the inter task communication chanel outside the data tables, yet.

How about the situation where a logic engine is running on one computer and an HMI on another. There has to be a coomunication channel. You cannot use the data table alone. A better example may be a logic engine on one computer coomunicating with a logic engine on another remote computer.

> >The way I see things this intercommunication between task has always been
> >required and there is no possible way to make this work otherwise.
>
> No, that is _the purpose_ of the data table structures, for things like
> counters, timers, PID's etc. Not the only purpose, but the single most
> important one.

If the data table is not a communication medium what is it? Furthermore each task accessing the data table will need to communicate the state of the data table to others. It has been said that this will be done via semaphores. Semaphores are a means of IPC (Inter Process Communication). Thus the system cannot work without a communication channel of some sort.

> >I've had another thought. If the logic engine accesses timers via a shared
> >memory segment (the timer data table) then a semaphore or something will
> >be required. I believe the timer engine can watch this semaphore and if it
> >has been changed by the logic engine or other process (not the timer
> >engine) then it can receive a signal and do the processing outlined above.
> >This is still inter process communication.
>
> Hmm. prhaps, although my conecept of this has only the shared memory
> libraries having access to this semaphore.

So?
The library has to provide a function to allow the timer engine to read the initial value from the data table. It is simple enough to write a
library function such as wait_for_change(int timeout); that blocks waiting for the semaphore to show the table has updated. The timer engine has to block at some point otherwise we have a real nasty busy wait loop, one cannot call sleep() as the man page says the actual time spent in sleep() is somewhat variable.

The only free running proccess should be the logic engine all others should spend most of there time blocked for I/O or data table access.


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 Tue, 25 Jan 2000, Ron Davis wrote:

> -----Original Message-----
> From: Dave West <[email protected]>
> >
> >The way I see things this intercommunication between task has always been
> >required and there is no possible way to make this work otherwise.
> >
> >I've had another thought. If the logic engine accesses timers via a shared
> >memory segment (the timer data table) then a semaphore or something will
> >be required. I believe the timer engine can watch this semaphore and if it
> >has been changed by the logic engine or other process (not the timer
> >engine) then it can receive a signal and do the processing outlined above.
> >This is still inter process communication.
>
> I think this communications should be through the shared memory like
> everything else.

That was the point of my second thought. That is throught the shared memory.


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
 
Think about this real carefully, then throw away all your thoughts and look at how the kernel handles its timers. The kernel is realy elegant
about this. Before anyone says it's different it is not, the kernel timers (scheduling, alarms etc) all have the functionality we require.


On Tue, 25 Jan 2000 [email protected] wrote:

> Actually I don't think it will make that much of a difference, you have to check them anyway and that can be done at the same time. I would go for increasing / decreasing each time but it would not matter THAT much. <

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
 
Hmm, I should have read more of the list before replying to that last one. I thought you had missed this one.

On Tue, 25 Jan 2000 [email protected] wrote:

> >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.
>
> Hmm, a sorted list of timers sorted by when they would
> expire... didn't think of that one. Could be quite fast.

Oh, it is!!!!

>
> >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.
>
> Sounds like a good solution to me

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
Dave West wrote:

> Think about this real carefully, then throw away all your thoughts and
> look at how the kernel handles its timers. The kernel is realy elegant
> about this. Before anyone says it's different it is not, the kernel timers
> (scheduling, alarms etc) all have the functionality we require.
>

I agree completely, I doubt that we'd be handling thousands of timers anyway.

cww


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

> >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.

> Hmm, a sorted list of timers sorted by when they would expire... didn't
> think of that one. Could be quite fast.

You don't even need a real sort. A priority queue (also known as a "heap", as in "heap-sort") is enough and has O(log n) insertion / deletion time
with constant time to access first element.

> >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.

OK, but be careful with that - make sure you know how long the jiffies counter will last and what happens when it rolls over.


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 Tue, Jan 25, 2000 at 09:26:27AM +0000, Dave West wrote:
> On Tue, 25 Jan 2000, Jiri Baum wrote:
...
> > Damn, I just read the manpage and supposedly at 2100.02.28 23:59:59 the
> > system clock will jump by a whole day.
>
> What are you trying to say here. That the system clock will jump to March
> 1? March 1 is the correct next day 2100 is not a leap year.

Yes, but usually between 23:59:59 one day and 0:00:00 the next the system clock changes by one, not by 86400.

> BTW it's worse than that. As I'm sure you are aware the current system > clock will roll over to 00:00 1/1/1970 somewhere around April 2038 so who > cares what happens in 2100?

With any luck we'll be on 64 bit systems well before then.

Personally, I hope someone will change the specification to say that it takes account of *real* leap days. It should still ignore leap seconds tho.


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 Tue, Jan 25, 2000 at 09:54:16AM -0500, Ron Davis wrote:
> -----Original Message-----
> From: Dave West <[email protected]>

> >The way I see things this intercommunication between task has always
> >been required and there is no possible way to make this work otherwise.

> >I've had another thought. If the logic engine accesses timers via a
> >shared memory segment (the timer data table) then a semaphore or
> >something will be required. I believe the timer engine can watch this
> >semaphore and if it has been changed by the logic engine or other
> >process (not the timer engine) then it can receive a signal and do the
> >processing outlined above. This is still inter process communication.

> I think this communications should be through the shared memory like
> everything else.

Yes, everything should be through the shared memory.

But note that semaphores have to be separate. I was putting them in the We'll Do That Later category, though (besides, the kernel provides them).


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 Wed, Jan 26, 2000 at 09:40:14AM +0000, Dave West wrote:
> How about the situation where a logic engine is running on one computer
> and an HMI on another. There has to be a coomunication channel. You cannot
> use the data table alone. A better example may be a logic engine on one
> computer coomunicating with a logic engine on another remote computer.

As far as I'm concerned, this would be done by a pseudo-IO driver.

Basically, accessing inputs, outputs or internal coils on another linuxPLC box would be exactly the same as accessing the same points on any other
kind of PLC.

(In fact easier, because the linuxPLC box could be set up to emulate any number of legacy PLCs, so your legacy HMI box could run on.)


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 Thu, 27 Jan 2000, Jiri Baum wrote:

> [email protected]:
>
> > >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.
>
> > Hmm, a sorted list of timers sorted by when they would expire... didn't
> > think of that one. Could be quite fast.
>
> You don't even need a real sort. A priority queue (also known as a "heap",
> as in "heap-sort") is enough and has O(log n) insertion / deletion time
> with constant time to access first element.
>
> > >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.
>
> OK, but be careful with that - make sure you know how long the jiffies
> counter will last and what happens when it rolls over.

1 year, 132 days, 2 hours, 27 minutes and 52.95 seconds. Assuming a tick every 0.01 seconds and an unsigned int (32 bit) counter.

As for roll over, the comparison code needs to handle it. It's not too difficult as anybody that has implimented any start time + period duration
code on a 24 hour clock will tell you. Come to think of it even a barrel buffer is similar in principal to this roll over.

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 Thu, 27 Jan 2000, Jiri Baum wrote:

> On Tue, Jan 25, 2000 at 09:26:27AM +0000, Dave West wrote:
> > On Tue, 25 Jan 2000, Jiri Baum wrote:
> ...
> > > Damn, I just read the manpage and supposedly at 2100.02.28 23:59:59 the
> > > system clock will jump by a whole day.
> >
> > What are you trying to say here. That the system clock will jump to March
> > 1? March 1 is the correct next day 2100 is not a leap year.
>
> Yes, but usually between 23:59:59 one day and 0:00:00 the next the system
> clock changes by one, not by 86400.

If I understand this correctly you are saying that the internal clock will add 86400 seconds to itself at 23:59:59 on 28/2/2100 because the library functions are broken!

BTW which man page did you get this from?

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 Thu, 27 Jan 2000, Jiri Baum wrote:

> On Wed, Jan 26, 2000 at 09:40:14AM +0000, Dave West wrote:
> > How about the situation where a logic engine is running on one computer
> > and an HMI on another. There has to be a coomunication channel. You cannot
> > use the data table alone. A better example may be a logic engine on one
> > computer coomunicating with a logic engine on another remote computer.
>
> As far as I'm concerned, this would be done by a pseudo-IO driver.
>
> Basically, accessing inputs, outputs or internal coils on another linuxPLC
> box would be exactly the same as accessing the same points on any other
> kind of PLC.
>
> (In fact easier, because the linuxPLC box could be set up to emulate any
> number of legacy PLCs, so your legacy HMI box could run on.)

Exactly the point. You need the psuedo I/O driver for logic engines on different boxes so why write a new method to provide the same functionality when the two logic engines are on the same box and why complicate a simple enviroment.

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
 
J

Johan Bengtsson

>> Hmm, a sorted list of timers sorted by when they would expire... didn't
>> think of that one. Could be quite fast.
>
>You don't even need a real sort. A priority queue (also known as a "heap",
>as in "heap-sort") is enough and has O(log n) insertion / deletion time
>with constant time to access first element.

Was probably like what I was thinking about :)

>> >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.
>
>OK, but be careful with that - make sure you know how long the jiffies counter will last and what happens when it rolls over.
>

That's easy enough if you make all calculations using the same register size as the original variables and always uses time differences, and expect it to roll over.

instead of: (NOTE! this code is WRONG)
if (now>start+time)
...

you write:
if (now-start>time)
...

Think about what will happen when start+time is a number higher than can be represented by the selected variable. btw. some kind of unsigned integers (any size) is probably the best to use for these ku_nd of caclulations.

My suggestion is (if this kind of code is to be implemented) a fairly low amount of bits is used. Like that it will wrap within hours at least. This will make bugs appear and be fixed instead of hiding them by the fact that no one wants to debug that long.

Like using 32 bits and use usec resolution (sligtly more than 1 hour) actual resolution may be lower depending on the system.

or if msec resolution is to be used, not use more than 16 bits (will wrap after a little bit more than 1 minute)



/Johan Bengtsson

----------------------------------------
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
 
Top