Shared memory / persistence / io polarity

S

Thread Starter

Simon Martin

Hi all,

There was the suggestion of using a memory mapped file for sharing the data between processes, and the persistence being created by periodically
updating the associated disk file, as opposed to writing a memory block to disk. How about something different for persistence, and let the IO process itself store the statii of the different IO. This means that a given interface would keep a status file holding all the data for the IO it handles, just writing CHANGES to disk when they occur (at the end of a scan). This will reduce disk activity and improve throughput. One side effect of this approach is that there must be a VirtualIO interface that stores all internal registers.

Someone was talking about changing IO polarity, if we define this as an attribute for an IO point then the IO interface can handle this concept.
This is a patch. Design the PLC program(s) for the IO involved, but it allows a cop out clause...

Debian GNU User
Simon Martin
Project Manager
Isys
mailto: [email protected]

There is a chasm of carbon and silicon the software cannot bridge


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
One power cycle is (at 50Hz) 20mS.

Contactors regularly take upto 50mS to operate.

PLC Scan times can usually be kept below 20mS, typically 10-20, (though I
did have a PLC3 app. that averaged 200mS).

Program scan times are not the end of the story though, I/O and network
update must also be taken into acount.

-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of Hurd, David L (GEA, 053698)

Guys,
In regards to scan times; As a long time PLC user, I always try to keep PLC
scan time below 20 msec. On large processes this is not always possible and
I've had a few scan time as large as 50 msec. But remember that a PLC is
emulating relays which can operate in 1 power cycle, so let's try to
maintain that speed as a point of reference.
Dave Hurd
GE Appliances

> -----Original Message-----
> From: [email protected]
>
> In a message dated 1/17/00 9:06:14 AM Pacific Standard Time, [email protected] writes:
>
> > >My guess is that this approach would be acceptable for the vast majority of
> > >applications. For the few that it is not, we need some way to write the data
> > >table into a faster storage medium (like battery backed RAM) on the
> fly.
> > >This should not be too difficult to implement.
> >
> > I don't think we can do this, and achieve the speed of scan required for
> > this project to be viable in many applications.
> >
> A couple observations/questions.
>
> 1. How fast does the scan need to be to be viable in most applications?
> 100 msec? I'd guess the overwhelming majority of PLC applications do not require
> much more then this.
>
> 2. Can we flush the data table to disk in that time? We are typically only
> talking about maybe a few dozen kbytes of data. If not I think we are
> looking at requirements for some kind of battery backed ram. I cannot see
> any way the project is practical w/o this capability.
>
> 3. The softPLC folks (and wonderware and others) remember the last states.
> How do they do it? They run in NT. If NT can do it Linux can do it
> (probably better).

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

But, .....

SQL interfacing is going to be a must in future ....

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

Personally I would be against using anything like this. If we have MySQL up and running we have another daemon on the competing for CPU time, another set of complexities inherent in the LinuxPLC, how robust the database to
non-orderly shutdowns, amongst other reasons I can think off. Let's keep the PLC machine as simple posible. I see it running the OS, inetd (maybe telnet, maybe ftp, but very little else), the PLC daemons and that's about it. ...<clip>

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Tue Jan 18 08:43:09 2000 Simon Martin wrote...
>
>Personally I would be against using anything like this. If we have MySQL up
>and running we have another daemon on the competing for CPU time, another
>set of complexities inherent in the LinuxPLC, how robust the database to
>non-orderly shutdowns, amongst other reasons I can think off. Let's keep the
>PLC machine as simple posible. I see it running the OS, inetd (maybe telnet,
>maybe ftp, but very little else), the PLC daemons and that's about it.
>

We will eventually need a databse for the documetation/programing engine. However this does not have to run on the same computer.

BTW, I vote for Postgres. We will need a real relation model here.


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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
Mark Hutton wrote:
>
> Just brainstorming.
>
> But, .....
>
> SQL interfacing is going to be a must in future ....
>

Absolutely -- for the HMI stuff. I doubt the low-level I/O and the logic engines will be able to use an SQL database. (Unless SQL queries are a
whole lot faster than I think they are.<g>)

Mark

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Simon Martin
>
> Personally I would be against using anything like this. If we have MySQL up
> and running we have another daemon on the competing for CPU time, another
> set of complexities inherent in the LinuxPLC, how robust the database to
> non-orderly shutdowns, amongst other reasons I can think off. Let's keep the
> PLC machine as simple posible. I see it running the OS, inetd (maybe telnet,
> maybe ftp, but very little else), the PLC daemons and that's about it. <clip>
>
> ----- Original Message -----
> From: Mark Hutton
>
> How fast is MySQL (reckoned as one of the fastest SQL servers) compared to
> InSQL Server?
>
> Can required persistence be implemented using an existing product, modified
> or otherwise?
>
> (note: MySQL Server is not GPL, but is free depending on how the end user
> obtains it.)
>
> How about a scheduled disk write, writing a small block of the persistant
> data to the file each cycle (or any variation of)? This would lower the risk
> of loosing data, while minimising the effect on performance. A totally
> configurable system could use this as a stepping stone between no saved data
> and ALL data saved EVERY scan.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D
> From: Stan Brown [mailto:[email protected]]
> Subject: Re: LinuxPLC: Shared memory / persistence / io polarity

> We will eventually need a databse for the documetation/programing
> engine. However this does not have to run on the same computer.

I wouldn't be too sure of that. I've yet to see a set of progamming tools based on a relational database that was fast enough to use pleasantly. If persistence is the issue, an OODB may work better. Otherwise I suspect that a custom solution will be best. Of course, all of this is up to whoever writes the tools...

Relational database connectivity for HMI and corporate data access is another subject. IMHO, that will eventually be required.


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

Johan Bengtsson

Uhh... well if the UPS stops delivering power because of a lightening strike it is either a really strong strike or a badly designed UPS.

However this is solveable buy storing subsequent "versions" after each other using up the space after some time. Each version should be consistency checked with a CRC and marked with a version number. This number have to have enough
bits to bake it absolutely clear wich one is newest when a counter wraparound occurs (preferably at least one bit more than the number necesary to hold the number of simultaneously
stored versions)


Example

store 3 version of the data, use 4 bits for version counting

slot version number CRC
1 15 OK
2 0 OK
3 14 OK

the one in slot 2 is the newest completely stored


slot version number CRC
1 15 OK
2 any BAD
3 14 OK

the one in slot 2 was about to be written, but not completed
slot 1 is used

this can be expanded / shrinked as far as you want...

/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
 
K
On Tue, Jan 18, 2000 at 11:59:56AM -0600, Mark Bayern wrote:
> Mark Hutton wrote:
> >
> > Just brainstorming.
> >
> > But, .....
> >
> > SQL interfacing is going to be a must in future ....
>
> Absolutely -- for the HMI stuff. I doubt the low-level I/O and the logic
> engines will be able to use an SQL database. (Unless SQL queries are a
> whole lot faster than I think they are.<g>)

Assuming the low level stuff has some suitably defined protocol for queries, an application could interface to an SQL database to the PLC
without needing to build that capability into the PLC.

--
Ken Irving
Trident Software
[email protected]


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

Phil Covington

Sigh...

At least some of the soft PLC companies have dealt with the problem of hard/firm/soft realtime
behavior of the operating system they run on. For the most part, these problems seem to be ignored here (on the list) so far... Dealing with this issue, I think, is fundamental for the success of the LinucPLC project.

Phil Covington
vHMI

----- Original Message -----
From: "Mark Hutton" <[email protected]>

> One design issue (which is obviously fundemental to this list) is the fact
> that no matter how you skin the cat, a machine (PC) designed as a general
> purpose tool is just one big compromise and is never going to be as good as
> purpose designed/built tools (PLC).
>
> You have to look for the benefits elsewhere, and this list (or the
> Automation list) has made some good arguments, which is part of the reason
> atleast, that this project exists.

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

Phil Covington

The normal Linux kernel ( with its jiffy granularity of 10 ms ) is not going to give you scan times that fast with the Ladder Engine running in userland...

Phil Covington
vHMI

----- Original Message -----
From: "Hurd, David L (GEA, 053698)" <[email protected]>

> Guys,
> In regards to scan times; As a long time PLC user, I always try to keep PLC
> scan time below 20 msec. On large processes this is not always possible and
> I've had a few scan time as large as 50 msec. But remember that a PLC is
> emulating relays which can operate in 1 power cycle, so let's try to
> maintain that speed as a point of reference.
>
> > -----Original Message-----
> > From: [email protected] [SMTP:[email protected]]
> >
> > In a message dated 1/17/00 9:06:14 AM Pacific Standard Time, [email protected] writes:
> >
> > > >My guess is that this approach would be acceptable for the vast majority of
> > > >applications. For the few that it is not, we need some way to write the data
> > > >table into a faster storage medium (like battery backed RAM) on the fly.
> > > >This should not be too difficult to implement.
> > >
> > > I don't think we can do this, and achieve the speed of scan required for
> > >this project to be viable in many applications.
> > >
> > A couple observations/questions.
> >
> > 1. How fast does the scan need to be to be viable in most applications? ...<clip>

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

Phil Covington

Dealing with the I/O updates along with a Logic Engine solving logic makes it all the more imperative that some kind of real time extension be taken into consideration for this project. Unless people can live with an extremely slow (in PLC terms) LinuxPLC.

Phil Covington
vHMI

----- Original Message -----
From: "Mark Hutton" <[email protected]>

> One power cycle is (at 50Hz) 20mS.
>
> Contactors regularly take upto 50mS to operate.
>
> PLC Scan times can usually be kept below 20mS, typically 10-20, (though I
> did have a PLC3 app. that averaged 200mS).
>
> Program scan times are not the end of the story though, I/O and network
> update must also be taken into acount.
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Hurd, David L (GEA, 053698)

> Guys,
> In regards to scan times; As a long time PLC user, I always try to keep PLC
> scan time below 20 msec. On large processes this is not always possible ...<clip>

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Tue Jan 18 21:56:00 2000 wrote...
>
>Uhh...well if the UPS stops delivering power because of a
>lightening strike it is either a really strong strike or a badly designed UPS.
>
>However this is solveable buy storing subsequent "versions"
>after each other using up the space after some time.
>Each version should be consistency checked with a CRC and
>marked with a version number=2E This number have to have enough
>bits to bake it absolutely clear wich one is newest when a
>counter wraparound occurs (preferably at least one bit more
>than the number necesary to hold the number of simultaneously stored versions)
>
>Example
>
>store 3 version of the data, use 4 bits for version counting
>
>slot version number CRC
> 1 15 OK
> 2 0 OK
> 3 14 OK
>
>the one in slot 2 is the newest completely stored
>
>
>slot version number CRC
> 1 15 OK
> 2 any BAD
> 3 14 OK
>
>the one in slot 2 was about to be written, but not completed
>slot 1 is used
>
>this can be expanded / shrinked as far as you want...
>

Do you understand the speed issues here?

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Tue Jan 18 13:09:44 2000 Dan Pierson wrote...
>
>> From: Stan Brown [mailto:[email protected]]
>
>> We will eventually need a databse for the documetation/programing
>> engine. However this does not have to run on the same computer.
>
>I wouldn't be too sure of that. I've yet to see a set of progamming tools
>based on a relational database that was fast enough to use pleasantly. If
>persistence is the issue, an OODB may work better. Otherwise I suspect that
>a custom solution will be best. Of course, all of this is up to whoever
>writes the tools...

Lets see, ICOM AI, and a little tool called ProDoc come to mind.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
Whatever (MySQL is faster), but I think that it would be as silly to tie ourselves into one database manager as it would be to limit ourselves to one programming language, one I/O protocol etc.

I was thinking about interfaces to Enterprise wide functions MES,MRP,ERP etc.

No matter what we think, some people will want to interface to Windows and even MS-SQL Server. We would be at a disadvantage (in marketing terms) if we couldn't easily interface to these systems.

This is, of course, a discussion for future consideration.

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

On Tue Jan 18 08:43:09 2000 Simon Martin wrote...
>
>Personally I would be against using anything like this. If we have MySQL up
>and running we have another daemon on the competing for CPU time, another
>set of complexities inherent in the LinuxPLC, how robust the database to
>non-orderly shutdowns, amongst other reasons I can think off. Let's keep the
>PLC machine as simple posible. I see it running the OS, inetd (maybe telnet,
>maybe ftp, but very little else), the PLC daemons and that's about it. <

We will eventually need a databse for the documetation/programing engine. However this does not have to run on the same computer.

BTW, I vote for Postgres. We will need a real relation model here.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
I agree. But you should see the times claimed for Wonderware's InSQL Server!

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

Mark Hutton wrote:
>
> Just brainstorming.
>
> But, .....
>
> SQL interfacing is going to be a must in future ....
>

Absolutely -- for the HMI stuff. I doubt the low-level I/O and the logic engines will be able to use an SQL database. (Unless SQL queries are a
whole lot faster than I think they are.<g>)

Mark

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

Johan Bengtsson

If the priority is high enough (I really don't know how priorities work in Linux, my experience is from win32) it should be possible to have a scan time not that far from 20-30ms

The I/O mapper have to run too and it is really the time from input changed to output changed that is interesting, but I still think that should be possilbe. It does of course depend
on the computer load too.

A question to those who have investigated the kernel code closer:
What happens when a process say "I do not want to run again until xxx ms have passed" or some similar. This is what will happen when the logic solver (or whatever) have completed one pass, most often in a lot less than 10ms


In WinNT this granularity is about 16ms and around 30ms scan time (including I/O update in another thread) is possible. It is not really reliable since it may take more time sometimes but that is an issue about determinism.

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

The normal Linux kernel ( with its jiffy granularity of 10 ms ) is not going to give you scan times that fast with the Ladder Engine running in userland...

Phil Covington
vHMI



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

Johan Bengtsson

I agree but do not have enough real knowlege about the linux kernel to suggest something really useful.

I have a kind of halfway between soft and firm realtime implementation in my other programs working like this:

The threads priorities (translate to process priorities) is quite high. Mostly in the range as or above most of the operating systems own threads.
1. They do their work.
2. At the end they measure the time since last expected start of a scan and calculates the amount of time to sleep
3. They sleep that amount of time (if it was positive)
4. Repeat from 1

This is probably not really enough and it is definitely not enough for all applications. (On the other hand is the whole project probably not right for some of the most demanding applications anyway)


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

Sigh...

At least some of the soft PLC companies have dealt with the problem of hard/firm/soft realtime
behavior of the operating system they run on. For the most part, these problems seem to be ignored here (on the list) so far... Dealing with this issue, I think, is fundamental for the success of the LinucPLC project.

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

Johan Bengtsson

Speed for what? calculate the CRC or store the data? The calculation is really much faster than storing but I guess that was not your question.

The biggest question is: is it important to save
EVERY time a scan is at the end and before the next one is allowed to start or is it enough if you have a reasonably fresh scan saved (say max 100ms old) - I can probably do 1s on a floppy and about 100ms should not be impossible on a harddrive.
The second biggest question is: how much data? Is it really necesary to save all data?

I have seen a lot of arguing about those two answers and I realize you have different points of view in this matter.

I think it should be (in the end) configurable.

Another point though: will the harddrive be worn out because of all this saving? Ie will it withstand saving to the same sector 10 times each second for say 1 year = 315224000 times or does this have to be counted in too.


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


>However this is solveable buy storing subsequent "versions" after each other using up the space after some time. Each version should be consistency checked with a CRC and marked with a version number. This number have to have enough
bits to bake it absolutely clear wich one is newest when a counter wraparound occurs
(preferably at least one bit more than the number necesary to hold the number of simultaneously
>stored versions)
>
>Example
>
>store 3 version of the data, use 4 bits for version counting
>
>slot version number CRC
> 1 15 OK
> 2 0 OK
> 3 14 OK
>
>the one in slot 2 is the newest completely stored
>
>slot version number CRC
> 1 15 OK
> 2 any BAD
> 3 14 OK
>
>the one in slot 2 was about to be written, but not completed
>slot 1 is used
>
>this can be expanded / shrinked as far as you want...
>
Do you understand the speed issues here?


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Tue, Jan 18, 2000 at 09:15:33PM -0500, Stan Brown wrote:
> On Tue Jan 18 21:56:00 2000 wrote...
> >
> >Uhh... well if the UPS stops delivering power because of a lightening
> >strike it is either a really strong strike or a badly designed UPS.
> >
> >However this is solveable buy storing subsequent "versions" after each
> >other using up the space after some time. Each version should be
> >consistency checked with a CRC and
...
>
> Do you understand the speed issues here?

Stan, do you have a solution you can offer for this problem?

If yes, please post it / check it into the CVS.

If no, don't shoot down "best possible with given h/w" solutions.


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
 
[email protected]:
> A question to those who have investigated the kernel code closer: What
> happends when a process say "I do not want to run again until xxx ms have
> passed" or some similar.

When you are sleeping you don't get scheduled.

> This is what will happen when the logic solver (or whatever) have
> completed one pass, most often in a lot less than 10ms

If you want the logic solver to be in lockstep, you can use a semaphore. (A semaphore will wake you up when it's your turn.)


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
 
Top