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.

--
Stan Brown [email protected] 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
[email protected]
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 [email protected] 843-745-3154
Westvaco
Charleston SC.
--

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

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

Johan Bengtsson

>> 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: [email protected]
Internet: http://www.pol.se/
----------------------------------------


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

Phil Covington

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


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

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


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

Johan Bengtsson

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: [email protected]
Internet: http://www.pol.se/
----------------------------------------


-----Original Message-----
From: MIME :[email protected] [SMTP:MIME :[email protected]]
Sent: Friday, January 21, 2000 9:52 PM
To: [email protected]
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
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
[email protected]:
> 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 <[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
 
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 <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sun Jan 23 12:53:56 2000 Jiri Baum wrote...
>
>[email protected]:
>> 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 [email protected] 843-745-3154
Westvaco
Charleston SC.
_______________________________________________
LinuxPLC mailing list
[email protected]
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 [email protected] 843-745-3154
Westvaco
Charleston SC.

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