Shared memory / persistence / io polarity

M
How fast is MySQL (reckoned as one of the fastest SQL servers) compared to InSQL Server?

Can required persistence be implemented using an existing product, modified or otherwise?

(note: MySQL Server is not GPL, but is free depending on how the end user obtains it.)

How about a scheduled disk write, writing a small block of the persistant data to the file each cycle (or any variation of)? This would lower the risk of loosing data, while minimising the effect on performance. A totally configurable system could use this as a stepping stone between no saved data and ALL data saved EVERY scan.


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

Phil Covington

----- Original Message -----
From: "Jiri Baum" <[email protected]>

<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
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D
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
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri, Jan 28, 2000 at 05:56:14PM -0600, [email protected] 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
[email protected]


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

R A Peterson

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

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

Darryl L. Palmer

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

R A Peterson

A couple observations/questions.

1. How fast does the scan need to be to be viable in most applications? 100 msec? I'd guess the overwhelming majority of PLC applications do not require much more then this.

2. Can we flush the data table to disk in that time? We are typically only talking about maybe a few dozen kbytes of data. If not I think we are looking at requirements for some kind of battery backed ram. I cannot see any way the project is practical w/o this capability.

3. The softPLC folks (and wonderware and others) remember the last states.
How do they do it? They run in NT. If NT can do it Linux can do it (probably better).


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


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