Shared memory / persistence / io polarity

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: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
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: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Tue Jan 25 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 [email protected] 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
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
[email protected]
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 [email protected] 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
[email protected]
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 [email protected] 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
[email protected]
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 [email protected] 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
[email protected]
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
[email protected]
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: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
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
[email protected]
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 <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
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
[email protected]

_______________________________________________
LinuxPLC mailing list
[email protected]
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 [email protected] 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R
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
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
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
[email protected]
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 [email protected] 843-745-3154
Westvaco
Charleston SC.

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