Today is...
Thursday, March 23, 2017
Welcome to Control.com, the global online
community of automation professionals.
Featured Video...
Featured Video
Wiring and programming your servos and I/O just got a lot easier...
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Shared memory / persistence / io polarity
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.
By Simon Martin on 15 January, 2000 - 10:45 am

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: smartin@isys.cl

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


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 18 January, 2000 - 10:41 am

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: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]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: PETERSONRA@aol.com
>
> In a message dated 1/17/00 9:06:14 AM Pacific Standard Time, stanb@awod.com 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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 18 January, 2000 - 10:42 am

Just brainstorming.

But, .....

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

-----Original Message-----
From: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Bayern on 18 January, 2000 - 1:00 pm

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: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Dan Pierson on 18 January, 2000 - 1:10 pm

> From: Stan Brown [mailto:stanb@awod.com]
> 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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 18 January, 2000 - 4:03 pm

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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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
jkirving@mosquitonet.com


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 18 January, 2000 - 6:12 pm

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" <mark.hutton@vogal.demon.co.uk>

> 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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 18 January, 2000 - 6:24 pm

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)" <DAVID.HURD@APPL.GE.COM>

> 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: PETERSONRA@aol.com [SMTP:PETERSONRA@aol.com]
> >
> > In a message dated 1/17/00 9:06:14 AM Pacific Standard Time, stanb@awod.com 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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 18 January, 2000 - 6:32 pm

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" <mark.hutton@vogal.demon.co.uk>

> 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: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]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
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Tue Jan 18 13:09:44 2000 Dan Pierson wrote...
>
>> From: Stan Brown [mailto:stanb@awod.com]
>
>> 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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 19 January, 2000 - 3:32 am

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: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 19 January, 2000 - 3:32 am

I agree. But you should see the times claimed for Wonderware's InSQL Server!

-----Original Message-----
From: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 19 January, 2000 - 12:35 pm

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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


-----Original Message-----
From: MIME :phil@philcovington.com [SMTP:MIME :phil@philcovington.com]

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 19 January, 2000 - 12:35 pm

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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


-----Original Message-----
From: MIME :phil@philcovington.com [SMTP:MIME :phil@philcovington.com]

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 19 January, 2000 - 2:07 pm

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: johan.bengtsson@pol.se
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
LinuxPLC@linuxplc.org
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 <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

johan.bengtsson@pol.se:
> 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 <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Thu Jan 20 19:15:23 2000 Jiri Baum wrote...
>
>>
>> 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, this gentleman clearly lives in a nice ivory tower, and has never seen a production floor. We need to try to focus the discussion on this list to useful input.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--
Windows 98: n.
useless extension to a minor patch release for 32-bit extensions and
a graphical shell for a 16-bit patch to an 8-bit operating system
originally coded for a 4-bit microprocessor, written by a 2-bit
company that can't stand for 1 bit of competition.
-
(c) 2000 Stan Brown. Redistribution via the Microsoft Network is prohibited.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

The problem with this is that Input statuses don't need to be persistent at all, unless we allow storage bits to be placed in the input image table, a practice that I discourage. Output status to need to be persistent (for latches), but in general it's a poor idea to program a real output as a latch anyway. On the other hand internal data tables (non I/O) are where we must have this persistence.

This does not map well to the model you are suggesting.


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

I agree. Inputs bits and output bits should not be used in this manner.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

I agree with Stan on this point. I expect any Inputs I examine to be real-time direct from an input scan, not saved from earlier. And I expect
all outputs to be cleared on power up until initialized by my program. I only use retentive internals when absolutely necessary to carry over the status of an operation that has been completed and cannot be repeated until something else takes place ( such as the fact that a screw has been loaded into the gun and you don't want to load a second one). Register data, however, is important to maintain at all times.
Dave Hurd
GE Appliances


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Yes, thanks for more clearly stating my point.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By R A Peterson on 21 January, 2000 - 4:25 pm

I agree. I like the convention where prior to the scan starting the PLC scans the logic and clears all bits referenced by a coil, but leaves all others alone (including latches). if you want to power up and know where you are at then just save it in a register or latch.

This is really something the PLC RLL interpreter should handle. perhaps it could be made optional for those who don't want it. Or since we sort of
agreed on IEC1131 style RLL, maybe we should follow whatever std that std has for such things.

as to data file types (from another thread). I find the file system in AB PLC5 and SLCs to be the easiest of all the PLCs to use. It allows for very simple ways to organize data, and provides a means for very powerful indirect
addressing. i would ahte to loose that capability.

one thing I do want to see in the RLL engine (if we can call it that) is the capability of using function blocks. Being able to create a piece of code and then reuse it over and over again is a very powerful way of organising your code. In fact, its probably the only PLC thing they really "should" have put in that is missing.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sat Jan 15 20:43:27 2000 wrote...
>
>I agree. I like the convention where prior to the scan starting the PLC
>scans the logic and clears all bits referenced by a coil, but leaves all
>others alone (including latches). if you want to power up and know where you
>are at then just save it in a register or latch.
>
>This is really something the PLC RLL interpreter should handle. perhaps it
>could be made optional for those who don't want it. Or since we sort of
>agreed on IEC1131 style RLL, maybe we should follow whatever std that std has
>for such things.

Maybe, why do you think it should be optional?

>as to data file types (from another thread). I find the file system in AB
>PLC5 and SLCs to be the easiest of all the PLCs to use. It allows for very
>simple ways to organize data, and provides a means for very powerful indirect
>addressing. i would ahte to loose that capability.
>
>one thing I do want to see in the RLL engine (if we can call it that) is the
>capability of using function blocks. Being able to create a piece of code
>and then reuse it over and over again is a very powerful way of organising
>your code. In fact, its probably the only PLC thing they really "should"
>have put in that is missing.
>

Oh absolutely. I see 2 different ways of doing this, and I think we should implement both eventually.

Method 1, and the one that should go in version 1.0 IMHO is subroutines. I see these as working a lot like AB subroutines, with the
enhancement, that you can pass to, and return much bigger chunks of data than AB allows, probably including user defined structs, and arrays of the same.

Method 2, which I think should wait for version 2.0. is user defined function blocks. One of the reasons for delaying this, is that I have
not seen an implementation of these that I like, so I would like us to think about it a bit, and have some experience with the implementation,
before we take this on.


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 3 February, 2000 - 3:47 pm

<clip>
one thing I do want to see in the RLL engine (if we can call it that) is the capability of using function blocks. Being able to create a piece of code and then reuse it over and over again is a very powerful way of organising your code. In fact, its probably the only PLC thing they really "should" have put in that is missing.
</clip>

missing from what?

Function Blocks are included in IEC 1131-3 and are one of its most important features.

If you mean they are missing from the LinuxPLC, they are not because there has not been much published on the logic engine(s) yet (I hope to remedy that in the near future).

Regards
Mark Hutton
Software Engineer
Vogal Software Services
Regent House, Welbeck Way, Peterborough. UK PE2 7WH
Tel: +44 (0)1733 370789 Fax: +44 (0)733 370701
mark.hutton@vogal.demon.co.uk

============P-P-Puffin' Power=======


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 21 January, 2000 - 4:27 pm

Hello All,

I was curious as to how existing PC based "soft PLCs" handled retention of data. Think and Do 's web site http://www.thinkndo.com/application/appnotes.html ) has some interesting application notes. Application note 30 discusses retentive data. (Oh, if a message box pops up asking you for an username - password, just hit enter and you can still view the application notes). The package allows you to mark each tag as retentive or non-retentive. When the app starts up the tags marked retentive are loaded from disk and when shut down they are saved to disk. The software allows you to set global events that are periodic and set what event runs at the timeout of the specified period. One event available is to save retentive tags to the disk. The example they gave was set to save the retentive tags to disk every 3600 seconds! I couldn't find any information on what the shortest period is that you can set for a global event and how it would affect system performance.

Phil Covington
vHMI

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Boy, am I glad you brought this up!

This is a great example of how poorly designed existing soft PLC's are. At least in the industries that I am familiar with, they have had
essentially zero % market penetration for this reason.

This is one of the reasons that I am being as hard nosed, as I am about the design of our project. it largely starts out with 1 strike against it anyway in the industrial control world. (where do I buy support). So we need to design, and build something that is just stunningly obviously better than existing soft PLC's.

Thats not to say we should not copy their good points, they do have some, don't they?

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Regarding the persistence issue:

This PLC needs to support a couple of differing types machine integrator applications.

One application is where the process being controlled is fairly slow and the end user can live with fairly long scan times and where latency isn't really critical. In this case, data can be retained to disk every scan (I'm talking about user data such as bit flags, integers etc for machine state as well as counters, timers, etc and the force tables, not about physical inputs and output images). The end user should be able to configure whether all of this data is saved to disk, or just portions of it to optimize for speed. Once the PLC is restarted after power loss, its inputs image will be updated before the first ladder scan and its outputs image will be updated after the first scan
(except for immediate output of course). Why do they need to be saved to disk? My personal opinion is that a machine integrator should not rely on a physical rotating disk for this task (it's slow and other than the CPU fan it's the most failure prone device in the computer), rather they should rely on a battery backed RAM disk, but then again, this decision should be left to the machine integrator.

The other type of application is where speed is critical and possibly latency is of concern too. In this application, saving the user data to anything but the computer RAM may be impractical for speed considerations. In this case, the machine integrator should be able to inhibit saving data to the physical disk or RAM disk card during each scan and instead rely on good electrical design such as a power stabilizer and a solid UPS. The linux PLC would need to
support the typical serial communications to a UPS for orderly shutdown in this application.

Regarding the nomenclature (AB versus GE versus Modicon versus JohnDoePLC), there may be some limitations being designed in with this decision. If we select AB nomenclature (here I assume microLogix/SLC500/PLC5 is what is
considered rather than ControLogix or SoftLogix5), how can the PLC support structures and unions for instance? If each new fancy ladder instruction that gets added (a specialized PID maybe) drives a new data type, a new fixed data type would need to be created anyway. Maybe I'm misreading the discussions so far, but I would prefer to see a set of predefined ladder data types (atomic types to timer structures) and also give the end user the ability to make up
their own data types, such as a structure to encapsulate all the data and actions for a VFD or air driven slide. The actual names of these data types for use in the ladder application should be set up by the end user through a tag database, not by this project. That would allow various users to have their familiar data file naming conventions, or conventions that are driven by
the machine process being controlled.

BTW, I didn't mean to imply ladder only programming for this PLC in the above.

Alan Locke
Controls Engineer, Boeing

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

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sat Jan 15 12:24:35 2000 Alan Locke wrote...
>
>Regarding the persistence issue:
>
>This PLC needs to support a couple of differing types machine integrator
>applications.
>
>One application is where the process being controlled is fairly slow and the end
>user can live with fairly long scan times and where latency isn't really
>critical. In this case, data can be retained to disk every scan (I'm talking
>about user data such as bit flags, integers etc for machine state as well as
>counters, timers, etc and the force tables, not about physical inputs and
>output images). The end user should be able to configure whether all of this
>data is saved to disk, or just portions of it to optimize for speed. Once the
>PLC is restarted after power loss, its inputs image will be updated before the
>first ladder scan and its outputs image will be updated after the first scan
>(except for immediate output of course). Why do they need to be saved to
>disk? My personal opinion is that a machine integrator should not rely on a
>physical rotating disk for this task (it's slow and other than the CPU fan it's
>the most failure prone device in the computer), rather they should rely on a
>battery backed RAM disk, but then again, this decision should be left to the
>machine integrator.

Makes sense. Care to define "fairly slow"? 100ms? .5 sec?
>
>The other type of application is where speed is critical and possibly latency
>is of concern too. In this application, saving the user data to anything but
>the computer RAM may be impractical for speed considerations. In this case,
>the machine integrator should be able to inhibit saving data to the physical
>disk or RAM disk card during each scan and instead rely on good electrical
>design such as a power stabilizer and a solid UPS. The Linux PLC would need to
>support the typical serial communications to a UPS for orderly shutdown in this
>application.

I like this flexibility. However it comes with caveat. if we call this thing a PLC, then where we differ from standard PLC practice, as this would, needs to be flagged wit BIG RED warnings. Also I am somewhat concerned about less experienced application programmers, who may not realize exactly what existing behavior there programming style relies on.

Any thoughts on this?
>
>Regarding the nomenclature (AB versus GE versus Modicon versus JohnDoePLC),
>there may be some limitations being designed in with this decision. If we
>select AB nomenclature (here I assume microLogix/SLC500/PLC5 is what is
>considered rather than ControLogix or SoftLogix5), how can the PLC support
>structures and unions for instance? If each new fancy ladder instruction that
>gets added (a specialized PID maybe) drives a new data type, a new fixed data
>type would need to be created anyway. Maybe I'm misreading the discussions so
>far, but I would prefer to see a set of predefined ladder data types (atomic
>types to timer structures) and also give the end user the ability to make up
>their own data types, such as a structure to encapsulate all the data and
>actions for a VFD or air driven slide. The actual names of these data types
>for use in the ladder application should be set up by the end user through a
>tag database, not by this project. That would allow various users to have
>their familiar data file naming conventions, or conventions that are driven by
>the machine process being controlled.

Oh, I am absolutely in favor of allowing user defined structs, like in C these would really be composites of existing data types. Having said this, I would put this into version 2.x of the project. Lets get 1.x stable and working, and looking as much like an existing PLC as possible. so that we can get some people in the real world looking at deploying, at least, test installations. The we can add the fancy
enhancements, that will draw in the crowd.

>BTW, I didn't mean to imply ladder only programming for this PLC in the above.
>

Right.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

>>One application is where the process being controlled is fairly slow and the
>>end user can live with fairly long scan times and where latency isn't really
>>critical. In this case, data can be retained to disk every scan (I'm talking
>>about user data such as bit flags, integers etc for machine state as well as
>>counters, timers, etc and the force tables, not about physical inputs and
>>output images). The end user should be able to configure whether all of this
>>data is saved to disk, or just portions of it to optimize for speed. Once the
>>PLC is restarted after power loss, its inputs image will be updated before the
>>first ladder scan and its outputs image will be updated after the first scan
>>(except for immediate output of course). Why do they need to be saved to
>>disk? My personal opinion is that a machine integrator should not rely on a
>>physical rotating disk for this task (it's slow and other than the CPU fan
>>it's the most failure prone device in the computer), rather they should rely
>>on a battery backed RAM disk, but then again, this decision should be left to
>>the machine integrator.
>
> Makes sense. Care to define "fairly slow"? 100ms? .5 sec?

A little like trying to define hot and cold. Here it would be relative to what could be achieved with writing to disk every scan included, maybe 100 milliseconds and above.

>>The other type of application is where speed is critical and possibly latency
>>is of concern too. In this application, saving the user data to anything but
>>the computer RAM may be impractical for speed considerations. In this case,
>>the machine integrator should be able to inhibit saving data to the physical
>>disk or RAM disk card during each scan and instead rely on good electrical
>>design such as a power stabilizer and a solid UPS. The Linux PLC would need
>>to support the typical serial communications to a UPS for orderly shutdown in
>>this application.
>
> I like this flexibility. However it comes with caveat. if we call this
> thing a PLC, then where we differ from standard PLC practice, as this
> would, needs to be flagged wit BIG RED warnings. Also I am
> somewhat concerned about less experienced application programmers, who
> may not realize exactly what existing behavior there programming style
> relies on.
>
> Any thoughts on this?

The out-of-the-box configuration needs to be saving user data files to disk every scan so that the end user has to take specific action to cause other behavior which puts the responsibilty on the end user to deal with the decision.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sun Jan 16 11:28:55 2000 Alan Locke wrote...
>
>The out-of-the-box configuration needs to be saving user data files to disk
>every scan so that the end user has to take specific action to cause other
>behavior which puts the responsibilty on the end user to deal with the decision.

Agreed, and the docs need to emphasize that turning this off for performance reasons, carries big risks, which the application programmer needs to really understand before considering doing this.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 21 January, 2000 - 4:01 pm

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

I hope that, what I mean is more like when will I get scheduled next time, certanly not after exactly xxx ms.

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

Yes, or perhaps a little later, it is the "later" part that can be a trouble.

(se my other post from a series of thest runs in NT using Sleep(1))


/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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 21 January, 2000 - 5:34 pm

Hej everybody stop that! I have got the point!

1. I agree this may not be the very best option from all points of view, I never said! But with existing hardware (a normal PC without UPS) that would probably be one of the best options left
that could still do the work.

2. All applications don't have the requirement to save all data after each scan in such a high speed. If they do - buy a UPS or some other hardware like battery backed RAM or something (or a "real" PLC - it will still be an option)! No way of solving this excludes any other way for anyone!

3. I would like to have more experience of everything and I don't doubt for a second you have more experience of "real life" than me.
That don't make me totaly inexperienced. I do probably have a more "wide" view and experience as opposed to "deep". I do not know in what type of industry you are working and since I do not know that I obviously don't know anything of your particular needs either, but hey isn't that the reason we all have to participiate to this work? If do however have knowlege about quite a range of
what you can and may use a PLC for, all of these will NOT be covered by a PC, some not even if you do buy additional hardware.

4. My main employment is directed toward education and not toward production. But I have to learn what I am teaching, I do that out in the "real life" in the swedish industries - in a real wide range from the company making the plastic covers for Ericssons cellular hones or Ericsson themself to pulp and paper mills - quite
different needs!


Keep my key point in mind: Puffin Linux Control is not ONE solution to all problems! It is a RANGE of solutions to a RANGE of problems.


/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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


-----Original Message-----
From: MIME :stanb@awod.com [SMTP:MIME :stanb@awod.com]
Sent: Friday, January 21, 2000 9:52 PM
To: linuxplc@linuxplc.org
Subject: Re: FW: LinuxPLC: Shared memory / persistence / io polarity

On Thu Jan 20 19:15:23 2000 Jiri Baum wrote...
>
>> 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, this gentleman clearly lives in a nice ivory tower, and has never seen a production floor. We need to try to focus the discussion on this list to useful input.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

johan.bengtsson@pol.se:
> 1. I agree this may not be the very best option from all points of view,
> I never said! But with existing hardware (a normal PC without UPS) that
> would probably be one of the best options left that could still do the
> work.

Yes. (I was actually thinking of something similar, but then I saw you already posted it.)

> 3. I would like to have more experience of everything and I don't doubt
> for a second you have more experience of "real life" than me.

Hmm, I sometimes get the impression that Stan's experience is somewhat one-sided. Have you read the sub-thread where someone mentions the 8255?


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

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Stan Brown:
> >> Do you understand the speed issues here?

Jiri Baum:
> >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.

Stan Brown:
> Jiri, this gentleman clearly lives in a nice ivory tower, and has
> never seen a production floor. We need to try to focus the
> discussion on this list to useful input.

Stan, I'm still waiting for *your* suggestions.

Johan's solution may or may not be ideal; but your "ivory tower" comment contributed nothing - Johan is no doubt too mature to be seriously
insulted, and everyone else just gets a poor impression of you.

I see a lot of categorical demands from you as to what a linuxPLC must do, including some quite unreasonable ones[*], but little in the way of
contribution. Perhaps I'm mistaken; some of the points you raise are no doubt valid; but if you don't have a solution, don't insult people who do.

I say again: do you have a solution you can offer for this problem?

(The problem being persistence of data in the face of a UPS-destroying lightning bolt.)

My personal take is that if you need more reliability than a UPS can provide, you should have some sort of multiple-controller setup anyway. Hardware of all kinds breaks down - even a relay can stick. Whether you then have the controllers wrestle for control, like they do on the Space Shuttle, or trust to some sort of electrical voting circuit, I leave up to you.


Jiri

[*] for instance, you demand that a piece of software targeted at linux
must run under *BSD.
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sun Jan 23 12:53:56 2000 Jiri Baum wrote...
>
>johan.bengtsson@pol.se:
>> 1. I agree this may not be the very best option from all points of view,
>> I never said! But with existing hardware (a normal PC without UPS) that
>> would probably be one of the best options left that could still do the
>> work.
>
>Yes. (I was actually thinking of something similar, but then I saw you
>already posted it.)
>
>> 3. I would like to have more experience of everything and I don't doubt
>> for a second you have more experience of "real life" than me.
>
>Hmm, I sometimes get the impression that Stan's experience is somewhat
>one-sided. Have you read the sub-thread where someone mentions the 8255?

OK, it is somewhat one sided.

I have spent the last 25 years selling/applying/maintaining mostly AB PLC based, and DCS based control systems in environments ranging from automotive. to foundries, to batch manufacturing, to paper mills.

I have also deployed HMI's as diverse as PanelViews to large multicomputer (UNIX) Factory Link systems, with lot's of custom code.

I have never designed an I/O module however.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sun Jan 23 12:28:01 2000 Jiri Baum wrote...
>
>I see a lot of categorical demands from you as to what a linuxPLC must do,
>including some quite unreasonable ones[*], but little in the way of
>contribution. Perhaps I'm mistaken; some of the points you raise are no
>doubt valid; but if you don't have a solution, don't insult people who do.
>

I prefer to think of them as suggestions, rather than demands, and no I don;t have th solution to this problem in my back pocket. I am the one that brought it up for discussion in the first place.

I want to make certain that everyone involved, no matter what their background understands the problem. Otherwise we will get a lot of solutions that don't fit the problem.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 24 January, 2000 - 7:30 am

Hear, hear Johann.

>Keep my key point in mind: Puffin Linux Control is not ONE solution
>to all problems! It is a RANGE of solutions to a RANGE of problems.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Mon, 24 Jan 2000, Jiri Baum wrote:

> I say again: do you have a solution you can offer for this problem?
>
> (The problem being persistence of data in the face of a UPS-destroying lightning bolt.)
>
> My personal take is that if you need more reliability than a UPS can
> provide, you should have some sort of multiple-controller setup anyway.
> Hardware of all kinds breaks down - even a relay can stick. Whether you
> then have the controllers wrestle for control, like they do on the Space
> Shuttle, or trust to some sort of electrical voting circuit, I leave up to you.

I sort of agree with this. I would be more extremist though and say that if you need more reliability than a UPS can provide then you need a direct line to God. As you say nothing in this world is 100% reliable.

> Jiri
>
> [*] for instance, you demand that a piece of software targeted at linux must run under *BSD.<

Linux is only supposed to be the development enviroment and the *initial* target so I don't think it is at all unreasonable to say it must run under BSD. It is probably less reasonable to say it must run under Windows but I don't think anyone will argue against running under Windows. A major debate may well ensue on the viability of such and how to do it, but I'm sure everyone agrees it will have to eventually.


Dave West E-Mail: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

<clip>
> >Hmm, I sometimes get the impression that Stan's experience is somewhat
> >one-sided. Have you read the sub-thread where someone mentions the 8255?
>
> OK, it is somewhat one sided.
>
> I have spent the last 25 years selling/applying/maintaining mostly AB
> PLC based, and DCS based control systems in environments ranging from
> automotive. to foundries, to batch manufacturing, to paper mills.
>
> I have also deployed HMI's as diverse as PanelViews to large
> multicomputer (UNIX) Factory Link systems, with lot's of custom code.
>
> I have never designed an I/O module however.

Basically, Although many of us know how to impliment this thing, Stan has a better understanding than some (eg. me) what the rest of the world would want to do with it.


Dave West E-Mail: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Tue Jan 25 05:54:38 2000 Dave West wrote...
>
>Linux is only supposed to be the development enviroment and the *initial*
>target so I don't think it is at all unreasonable to say it must run under
>BSD. It is probably less reasonable to say it must run under Windows but I
>don't think anyone will argue against running under Windows. A major
>debate may well ensue on the viability of such and how to do it, but I'm
>sure everyone agrees it will have to eventually.

My own personal opinion on this is that I would like to see this project run on any modern flavor of *NIX.

I don't like the idea of worrying about windows, if someone really wants that then they can do the port using one of the UNIX emulation
packages available.

I am involved in other software projects, and after they have been ported to windows the programmers feel constrained to not take advantage of the full power of UNIX, but instated constrain themselves to things that work properly in windows. This hurts the software a lot IMHO.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 25 January, 2000 - 1:24 pm

Hi all,

Forgive me for not understanding something, but, are you saying that a PLC power failure, for example, should come up right where if left off?
This might cause some real safety issues. The fieldbus I/O I have seen defaults to off when it loses connection or power. That is predictable.
If you then pretend that nothing happened and restore the state of the I/O, havoc could result. Isn't it safer to come up to a known state and
run recovery routines? Or are you talking about saving state for advisory purposes? I can see saving setup state, but I would think all bets are off on process state if power is interrupted.

cww

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

This issue is a bit more complex that that. Indeed I/O should fail off on loss of communications, and obviously goes off on power fail.

What we are talking about is the state of things in the PLC's data table (memory). All of this is maintained in the last state on power
failure. Things that should not start back up (motors etc.) are programmed to take advantage of the PLC's presacn init. routine. See my earlier posting for this.

Heres an example:

Stop Stat Motor
Button Button Coil

|---||--+------||-----+---------()
| |
| Motor |
| Coil |
| |
+-----||------+

This is a classic "3 wire control scheme" The Stop button is wired
Normally closed, so it is true if not pushed. To start the start button is pushed and as a result the motor "seals itself in". Since the output is a coil the presacn would turn it off, requiring a manual start operation after power fail.

Please be advises this is an overly simplistic example an IS NOT SAFE as shown.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 25 January, 2000 - 1:29 pm

Thanks Stan

So what the debate is about are the means to mitigate those problems? Gotcha

cww

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

The discussion is about how to best handle this. Our project will emulate a dedicate piece of control hardware with a general purpose
computer. The I/O remains basically the same, we are replacing what could be called for lack of a better term, the Central Processing Unit of a
PLC based system.

The dedicate hardware has some advantages for this application, and this is one of them. Their are products on the market called "soft
PLC's". These consist of software packages running on general purpose computers. IMHO the existing ones of these make poor replacements for
the dedicate hardware.

What I am trying to accomplish is to avoid us making the same poor design choices, that these systems have.

Make sense?

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 25 January, 2000 - 2:12 pm

Stan, could you elaborate on what you think are poor design choices on the part of "soft PLC" companies? This might further help in avoiding the same poor design choices for the LinuxPLC.

Phil Covington
vHMI

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sun Jan 16 18:31:18 2000 Phil Covington wrote...

>Stan, could you elaborate on what you think are poor design choices on the
>part of "soft PLC" companies? This might further help in avoiding the same
>poor design choices for the LinuxPLC.
>

I am not as up to speed on them as I should be to address this, perhaps someone else is?

Someone (was it you) had found a link to a site that sounded like it had good information on them, but I am afraid I did not keep the
message, could the person that found that site send it to me?

BTW is this list being archived anywhere?


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 25 January, 2000 - 3:33 pm

> BTW is this list being archived anywhere?

Yes at http://www.linuxplc.org/archives/linuxplc/

Phil Covington
vHMI


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 28 January, 2000 - 5:26 pm

I don't know about Stan, but, I would classify their choice of OS as less than optimal, along with proprietary standards and the registry
that has been mentioned. Also, a lot more people will really understand our machine due to Open Source. We already have the advantage of more
people scrutinizing design decisions. Exception might be granted for the DOS efforts. DOS has few features, but, at least it's fairly well
understood and reasonably verifiable. Some of the RTOS's are small enough to be understood by at least one person.

cww


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

I am trying hard to take an OS neutral position, after having being criticised for bad mouthing a certain unreliable proprietary OS :-)

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 1 February, 2000 - 12:45 pm

You're right of course, but, I didn't mention any specific OS and for this purpose they aren't created equal. I firmly believe Open Source to be a big advantage when you're working at the hardware level.
cww


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

I agree whole heartedly.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 1 February, 2000 - 4:38 pm

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

I think retentive memory is simply something that a standard PLC has but a standard PC does not have. There is a limit to how close we're going to get to a PLC without some of the hardware features of what defines that machine. If registers can be flagged as persistent, or an area of persistent memory can be provided, then that memory could be written to disk on each scan or when a change is made, but there is necessarily a performance hit vs doing a write to high(er) speed RAM.

A hardware fix would be to use an add-on board, but that would certainly have to be a configurable option.

--
Ken Irving
Trident Software
jkirving@mosquitonet.com

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

You may be correct here, but I am not willing to give up the goal of emulating the real PLC hardware, till we have thought about it at length, and even run some test with real code.

I think putting in the hooks for this is very important. It may have to configurable on a per application basis. Some projects may need to
sacrifice the retention for speed, on others the retention may be more important than speed.


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By R A Peterson on 28 January, 2000 - 5:23 pm

Look, if we are going to have a "PLC", then there are a couple things that we really have to have.

One is RLL, the second is retentive memory somehow. Its really not a PLC unless this is the case.

My personal opinion is that retentiveness has to be ensured through some hardware (UPS, battery backed RAM, ???), but it needs to be there or its not a PLC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Mon Jan 17 07:43:08 2000 wrote...

>Look, if we are going to have a "PLC", then there are a couple things that we
>really have to have.
>
>One is RLL, the second is retentive memory somehow. Its really not a PLC
>unless this is the case.

Sorry, I'm not certain what you mean by RLL, cold you clarify.


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By R A Peterson on 28 January, 2000 - 5:32 pm

RLL = relay ladder logic. the (more or less) universal language of PLCs.



_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Oh, you mean the one I psuedo code my C programs in :-)

Guess we need an acronym reference page :-)

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Mon, Jan 17, 2000 at 09:01:22AM -0500, Stan Brown wrote:
> On Mon Jan 17 07:43:08 2000 wrote...
> >
> >In a message dated 01/17/2000 03:07:11 AM Central Standard Time, jkirving@mosquitonet.com writes:
> >
> > I think retentive memory is simply something that a standard PLC has but a
> > standard PC does not have. There is a limit to how close we're going to get
> > to a PLC without some of the hardware features of what defines that machine.
> > If registers can be flagged as persistent, or an area of persistent memory
> > can be provided, then that memory could be written to disk on each scan or
> > when a change is made, but there is necessarily a performance hit vs doing
> > a write to high(er) speed RAM.
> >
> > A hardware fix would be to use an add-on board, but that would certainly have
> > to be a configurable option.
> >
> > --

> >Look, if we are going to have a "PLC", then there are a couple things that we
> >really have to have.
> >
> >One is RLL, the second is retentive memory somehow. Its really not a PLC unless this is the case.< <

I don't think there's any reason it can't be done in a number of ways, whether using battery-backed RAM or write to the journalling file system.
The particulars of how it's done might be left up to a persistent memory driver or component, but the interface/hooks can be the same.

IMHO, instead of I or O (which has been discussed), a better example for retention of information might be for run-timers, statistical
data on the process, etc.

> Sorry, I'm not certsin what you mean by RLL, cold you clarify.<

I read that as Rung Ladder Logic, but YMMV.

> >My personal opinion is that retentiveness has to be ensured through some hardware (UPS, battery backed RAM, ???), but it needs to be there or its not a PLC. < <

But there is room for flexibility, and this project might be useful for tasks which don't necessarily need data retention. I don't really see any problem, unless someone is arguing against supporting persistent memory, which I haven't seen. One example might be a LinuxPLC used to host remote I/O, but with little or no need to maintain state.

--
Ken Irving
Trident Software
jkirving@mosquitonet.com


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

>I don't think there's any reason it can't be done in a number of ways,
>whether using battery-backed RAM or write to the journalling file system.
>The particulars of how it's done might be left up to a persistent memory
>driver or component, but the interface/hooks can be the same.
>
>IMHO, instead of I or O (which has been discussed), a better
>example for retention of information might be for run-timers, statistical
>data on the process, etc.

That is exactly what I have been trying to say.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

I have seen many systems where the machine needs to be able to pick up where it left off after a power cycle. The machine start is generally
initiated by an operator. To do this, the current state when the power failed must be stored.

Bill Sturm

Curt Wuollet wrote:

> Forgive me for not understanding something, but, are you saying that a
> PLC power failure, for example, should come up right where if left off?
> This might cause some real safety issues. The fieldbus I/O I have seen
> defaults to off when it loses connection or power. That is predictable.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 1 February, 2000 - 11:39 am

And how do you know that nothing was moved (by an engineer or maintenance technician) while the power was off. You, the application programmer, nor the PLC application program itself knows why the power was lost, how long it was lost for (solvable), or what was done to the plant or process while the power was down.

Thinking back on it, I remembered that we actually only recovered from the same state after an E-Stop. A think a power cycle did reset the logic. On an E-Stop, we killed outputs, but kept track of which outputs were on with internal coils. The inputs always remained active, so that certain conditions could reset the system.

Bill Sturm
Applied Grinding Technologies

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Scott Jensen on 1 February, 2000 - 1:11 pm

Hi List,
I think Bill Sturm laid out the obvious idea about the system always restarting in an E-Stop condition. This gives you a chance to match existing conditions with what you have on your screen. A lot of the restart safety is
inherently written into the "ladder" program. We have a huge burner system that would never restart with the gas on because there's no flame, so it automatically starts from square one. While on another system that moves huge aircraft skins through a multistage process, it would be a nightmare to lose all the information for each piece and where it is. I think the software should always retain all the information and let the "ladder" program deal with it accordingly.
My 2 cents worth from the factory floor,
Scott Jensen
Boeing

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Just to throw in another interesting example, I have a system that controls power generation, and distribution for a paper mill (approx. 85MW). In the power world everything is upside down from the machine control works. All inputs (including trips) are N. O., all outputs must come on to change the state of a breaker (open or close). However this is critical data that MUST be preserved over power failure.

On the other and I have systems control paper machines. These have N. C. stop buttons,and permissive interlocks, and hold an output on to
cause motors to run.

So the moral of the story s that there a wide variety of diverse applications for PLC's, and we need to try to bear this in mind as we
design this project.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 28 January, 2000 - 5:37 pm

Absolutely.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Darryl L. Palmer on 1 February, 2000 - 11:58 am

I think there is one thing that may cause problems. In some cases, maybe a direct or local lightning strike, the UPS may fry. In case that the computer wasn't completely destroyed and the disk or RAM backed memory device still functions, shouldn't the data there be correct? In which case now you have to deal with the problem of the computer going down when it is writing to the storage device. To solve this problem we could have:

1) two fixed locations on the medium that we are writing two and alternate between them.
2) two random locations on the medium and two location tables on the medium.

The first case is easiest and when a write is completed we can set a flag stating that a "complete" write has occured. For the second case we can allocate the space first for the data, then update the location table, then
write the data. Doing it in this order allows an "intelligent" restore engine to construct partial state information if necessary.

I guess this also solves the other conditions of a clumsy/disgruntled person just turning off the device.

Either way it happens, I am almost certain that a caching write operation is totally unexceptable. This may be interesting.


Darryl Palmer
Cleveland State University


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Mon Jan 17 10:59:49 2000 Darryl L. Palmer wrote...
>
>Either way it happens, I am almost certain that a caching write operation is totally unexceptable. This may be interesting. <

I would say that qualifies as the understatement of the day.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Tue, 25 Jan 2000, Stan Brown wrote:

> On Tue Jan 25 05:54:38 2000 Dave West wrote...
> >
> >Linux is only supposed to be the development enviroment and the *initial*
> >target so I don't think it is at all unreasonable to say it must run under
> >BSD. It is probably less reasonable to say it must run under Windows but I
> >don't think anyone will argue against running under Windows. A major
> >debate may well ensue on the viability of such and how to do it, but I'm
> >sure everyone agrees it will have to eventually.
>
> My own personal opinion on this is that I would like to see this project run on any modern flavor of *NIX.
>
> I don't like the idea of worrying about windows, if someone really wants that then they can do the port using one of the UNIX emulation
packages available.
>
> I am involved in other software projects, and after they have been ported to windows the programmers feel constrained to not take advantage of the full power of UNIX, but instated constrain themselves to things that work properly in windows. This hurts the software a lot IMHO.

Excellent, I agree with everything you have said here Stan.


Dave West E-Mail: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 26 January, 2000 - 10:15 am

I don't care if it ever runs on windows myself. It won't have any big advantage on a proprietary platform and all the low level stuff will be completely different. With device drivers especially, about the best you can hope for is that one gives you the information you need to write the other. We have the opportunity for a design with no black boxes or secrets and I think that's important. If people want a windows version, they should write a bottom end optimised
for windows. We can probably share all the high level stuff though. Systems programming is simply not very portable and a high degree of optimization is desirable here. I am not against the idea, it's just that, below a certain level
they are completely different designs. Portability among *nix flavors is a
far more realistic target.

Curt Wuollet,

Dave West wrote:

> On Tue, 25 Jan 2000, Stan Brown wrote:
>
> > On Tue Jan 25 05:54:38 2000 Dave West wrote...
> > >
> > >Linux is only supposed to be the development enviroment and the *initial*
> > >target so I don't think it is at all unreasonable to say it must run under
> > >BSD. It is probably less reasonable to say it must run under Windows but I
> > >don't think anyone will argue against running under Windows. ...<clip>...
> > My own personal opinion on this is that I would like to see this project
> > run on any modern flavor of *NIX.
<clip>...
>
> Excellent, I agree with everything you have said here Stan.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Jiri Baum:
> > My personal take is that if you need more reliability than a UPS can
> > provide, you should have some sort of multiple-controller setup anyway.
> > Hardware of all kinds breaks down - even a relay can stick. Whether you
> > then have the controllers wrestle for control, like they do on the
> > Space Shuttle, or trust to some sort of electrical voting circuit, I leave up to you.

Dave West:
> I sort of agree with this. I would be more extremist though and say that
> if you need more reliability than a UPS can provide then you need a
> direct line to God. As you say nothing in this world is 100% reliable.

There are things you can do, algorithms that can mask Byzantine faults, etc. But I don't have any personal experience - all I can give you is a
pointer to an article from 1990 and a bunch of WWW bookmarks.

> > [*] for instance, you demand that a piece of software targeted at linux
> > must run under *BSD.

> Linux is only supposed to be the development enviroment and the *initial*
> target so I don't think it is at all unreasonable to say it must run
> under BSD.

His phrasing was rather, shall we say, undiplomatic. To quote: "While Linux is nice, when my stuff really just must stay up, I use FreeBSD."

Now really: this is a project by name, by intention, by everything, targeted at Linux. For many of its participants, Linux is the Platform of
Choice, with all the emotional attachment that implies. And he brushes it off like that?

> It is probably less reasonable to say it must run under Windows but I
> don't think anyone will argue against running under Windows. A major
> debate may well ensue on the viability of such and how to do it, but I'm
> sure everyone agrees it will have to eventually.

Assuming there will be an MS Windows this time next year.


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

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 28 January, 2000 - 5:34 pm

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By R A Peterson on 1 February, 2000 - 11:43 am

I do not like the idea of starting backup after a power down and knowing that some, but not all of the saved data is correct. It would almost be better to have none of it saved then to have just some of it saved. At the very least one would need to know what data was real and what was not. This would introduce another layer of complexity into the system.

I suggest the following approach:

1. Write the entire data table to disk at the end of each scan. On starting the write a flag (call it "refresh complete") is reset. This flag is set once the refresh is complete. In fact once the scan ends this process could be done in parallel with logic solving as long as it gets finished during the following scan. Obviously a memory copy of the data table would have to be created that is what is actually written to disk, as the real DT will be changing during the scan.

2. On shutdown, the scan ends, then the entire data table is refreshed to disk, a flag is set to indicate successful completion, then the logic engine shuts down.

3. On restart, the application program checks to see if the "refresh complete" flag has been set. It then takes appropriate action.

In most cases, people will at the very least put a UPS on the system. A power failure will result in the UPS taking over. Most UPS's can be had with a serial port to notify the OS that power is about to fail to give the OS time to shutdown in an orderly way.

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.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

I don't think we can do this, and achieve the speed of scan required for this project to be viable in many applications.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By R A Peterson on 1 February, 2000 - 12:58 pm

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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

Very few of my PLC projects would work with a scan time this slow. Most I work on require at least a 35MS (faster is better) scan time.


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 1 February, 2000 - 1:53 pm

And hence the need for a real time extension to Linux! Linux jiffie resolution is 10ms...
If you want scan times under 20-30 ms then you'd better get used to the idea of RTL or KURT or at least a UTIME patch to normal Linux.

Phil Covington
vHMI

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Bummer. This is bad news.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Mon Jan 17 07:34:12 2000 Mark Hutton wrote...
>
>How fast is MySQL (reckoned as one of the fastest SQL servers) compared to InSQL Server? <

A database is way to complex a way to maintain persistence. There are however some other possibilities.

We probably need a database for the documenter task tho.


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Simon Martin on 1 February, 2000 - 4:54 pm

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.

Well that's my opinion

Debian GNU User
Simon Martin
Project Manager
Isys
mailto: smartin@isys.cl

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

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 28 January, 2000 - 5:48 pm

----- Original Message -----
From: "Jiri Baum" <jiri@baum.com.au>

<snip>
> > It is probably less reasonable to say it must run under Windows but I
> > don't think anyone will argue against running under Windows. A major
> > debate may well ensue on the viability of such and how to do it, but I'm
> > sure everyone agrees it will have to eventually.
>
> Assuming there will be an MS Windows this time next year.
>

You really think there won't be?

Phil Covington
vHMI




_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By David Wooden on 28 January, 2000 - 6:57 pm

QNX, Anyone?



Jiri Baum:
> > My personal take is that if you need more reliability than a UPS can
> > provide, you should have some sort of multiple-controller setup anyway.
> > Hardware of all kinds breaks down - even a relay can stick. Whether you
> > then have the controllers wrestle for control, like they do on the
> > Space Shuttle, or trust to some sort of electrical voting circuit, I leave up to you.

Dave West:
> I sort of agree with this. I would be more extremist though and say that
> if you need more reliability than a UPS can provide then you need a
> direct line to God. As you say nothing in this world is 100% reliable.

There are things you can do, algorithms that can mask Byzantine faults,
etc. But I don't have any personal experience - all I can give you is a
pointer to an article from 1990 and a bunch of WWW bookmarks.

> > [*] for instance, you demand that a piece of software targeted at linux must run under *BSD.

> Linux is only supposed to be the development enviroment and the *initial*
> target so I don't think it is at all unreasonable to say it must run under BSD.

His phrasing was rather, shall we say, undiplomatic. To quote: "While Linux
is nice, when my stuff really just must stay up, I use FreeBSD."

Now really: this is a project by name, by intention, by everything,
targeted at Linux. For many of its participants, Linux is the Platform of
Choice, with all the emotional attachment that implies. And he brushes it off like that?

> It is probably less reasonable to say it must run under Windows but I
> don't think anyone will argue against running under Windows. A major
> debate may well ensue on the viability of such and how to do it, but I'm
> sure everyone agrees it will have to eventually.

Assuming there will be an MS Windows this time next year.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri, Jan 28, 2000 at 05:56:14PM -0600, david_wooden@omron.com wrote:
>
> QNX, Anyone?

This would probably be a good goal, but surely later in the project.

There is an Open Source project to emulate (?) the QNX message-passing IPC scheme, called SIMPL. This is probably quite different from the shared memory approach that this project is / will be using. See http://www.holoweb.net/~simpl/
for information.

--
Ken Irving
Trident Software
jkirving@mosquitonet.com


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

> <snip>
> > > It is probably less reasonable to say it must run under Windows but I
> > > don't think anyone will argue against running under Windows. A major
> > > debate may well ensue on the viability of such and how to do it, but
> > > I'm sure everyone agrees it will have to eventually.

Jiri Baum:
> > Assuming there will be an MS Windows this time next year.

Phil Covington:
> You really think there won't be?

Sometimes I wonder...


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

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 29 January, 2000 - 6:11 am

Mines going to run on Linux, BSD, Windows, OS/2, in a web browser and my mobile phone ;-)


<tongue firmly in check>


>
> > It is probably less reasonable to say it must run under Windows but I
> > don't think anyone will argue against running under Windows. A major
> > debate may well ensue on the viability of such and how to do it, but I'm
> > sure everyone agrees it will have to eventually.
>
> Assuming there will be an MS Windows this time next year.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 29 January, 2000 - 1:39 pm

Mark Hutton wrote:
>
> Mines going to run on Linux, BSD, Windows, OS/2, in a web browser and my mobile phone ;-)
>

Cool!........er, what are you gonna control with your phone ? :^)
cww

> <tongue firmly in check>

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc