Fw: shared memory

S

Thread Starter

Simon Martin

Ok gentleman, this is what I see as the basics for my assumed task.

1) SharedMemoryManager

This process creates the SharedMemory space. The memory space is allocated taking into account all the memory specified by the VirtualIO configuration files. I can ignore the PhysicalIO configuration files as these must be mapped into the VirtualIO map for them to be used, providing independance of the PLC Engines from the IO configuration itself.

The SharedMemoryManager is responsible for data persistence. All registers in the VirtualIO map must have a persistance priority assigned to them
(something like critical, important, normal) allowing flexibility in the volume of data to be written.

2) VirtualIO configuration

The VirtualIO are the IO points available to the PLC Engines. At the start of a scan the PLC Engine will request a copy of the Input data, at the end of a scan the PLC Engine will submit it's output data. The SharedMemoryManager is responsible for extracting/merging this data.

The VirtualIO would be defined by something like

<io type> <element> . <sub element> <tag> <description>

A PLC Engine may request the current value of a single IO point, or a set of IO points, or the next updated value of an IO point/set of IO points.

Questions:

Can each PLC Engine have its' own VirtualIO table that maps onto the global IO table?
What is the harm of more one process updating an output (apart from the programmers sanity)?
Any more ideas before I start coding?

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

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


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri Baum:
> >I'm assuming that each semaphore would be used for many different
> >points. Modules would hand over to each other whole sections of the
> >machine (or the whole machine altogether).

> >If two modules need to work on the same point at the same time, they
> >should either communicate with each other, or use intermediate coils
> >which are then explicitly ORed or ANDed together.

Oops, terminology clash! Terminology clash!

I'm using module to mean "logic engine or such other program".

Stan Brown:
> I still don't think we are in synch here. I envision ownership of
> an output being permanent (for the life of the run time). It can
> only be changed which the system down. So it should be possible to
> arbitrarily assign a given output within a card to a given logic
> engine. Although I can see that this may not be feasible, and we
> may need to only allow assignments at the whole module level.

> In real PLC's it's done at the entire rack level, BTW>

I meant that - for the semaphore-protected outputs - there would be a relatively small number of semaphores, each of which would protect a whole section of the machine.

Permanently-owned outputs are permanently-owned, nothing to talk about there. (Permanently-owned points don't even have any performance penalty
relative to free-for-all writing.)


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
 
P

Phil Covington

Lets forget about "determinism" and talk about FAST (as Stan Brown defined it in another post as 35 ms scan times and under). The normal Linux kernel is not going to be able to give you a FAST PLC as defined above. So the question is what is a minimum scan time that people can live with? I am talking about scan times assuming a Ladder Logic Engine running. I would like to see sub 15 ms scan times... What about everyone else?

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

> In my experience there is an argument (of sorts), not as big as the
> ladder/no ladder argument, amongst PLC programmers on this very point.
>
> Some of us make the program run as fast as possible by only scanning
> appropriate ladder, i.e. don't scan the lift logic if the lift is not in
> operation.
>
> Others scan everything in the hope of achieving more consistent scan
times.
>
> Even in the latter case PLC operation is not particularly deterministic
and
> scan times can very greatly depending on the state of an input. In most
> cases this does not affect the resulting application.
>
> RT would be a great option, but IMHO not necessarily for an early release.
>
> Of course, logic dictates that an understanding of the requirements of RTL
> is necessary to avoid painting ourselves into a corner over RT
> implementation at a later date.
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Stan Brown
>
> On Mon Jan 17 19:33:41 2000 Curt Wuollet wrote...
> >
> >This is just the discussion I would like to see. Do we accomodate RTL or not.
> >If we need realtime we need to think this through.
> >cww
>
> I would like to get something out the door, without adding in the
> complexities of RTL.
>
> Hardware PLC's are not determininistic, they are just FAST. I have written
> a
> application where the response time is sub 90 msec. response time in
> this case includes the actual operation of 15KV power breakers, which
> have an operation type of 3 power line cycles (16.5 ms per cycle).
>
> So as you can see, the response can be kept in a reasonable range by a
> careful application programmer.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
-----Original Message-----
From: Phil Covington <[email protected]>
To: [email protected] <[email protected]>
Date: 19, January 2000 10:20
Subject: Re: Fw: LinuxPLC: Fw: shared memory

>Lets forget about "determinism" and talk about FAST (as Stan Brown defined
>it in another post as 35 ms scan times and under). The normal Linux kernel
>is not going to be able to give you a FAST PLC as defined above. So the
>question is what is a minimum scan time that people can live with? I am
>talking about scan times assuming a Ladder Logic Engine running. I would
>like to see sub 15 ms scan times... What about everyone else?


I think that a few issues are involved -

a) 35 ms does not look very fast, at least for a short program

b) 10 ms would be "medium fast" in my opinion

c) there is likely to be some "fixed overhead" regardless of length of
program - how much?

d) how much is speed affected by more complex processing

e) there should be some means for optimization - at least a "speed counter" - which would tell average scan time over last ten (?)scans and
longest scan time over configurable period


Petr

--
Petr Baum <[email protected]>




_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Tue Jan 18 07:47:09 2000 Jiri Baum wrote...
>
>Jiri Baum:
>> >I'm assuming that each semaphore would be used for many different
>> >points. Modules would hand over to each other whole sections of the
>> >machine (or the whole machine altogether).
>
>> >If two modules need to work on the same point at the same time, they
>> >should either communicate with each other, or use intermediate coils
>> >which are then explicitly ORed or ANDed together.
>
>Oops, terminology clash! Terminology clash!
>
>I'm using module to mean "logic engine or such other program".
>

Module in this context can be read as a peice of I/O hardware.

So how do we protect access to an individual output, or at a minimum to a whole output module?

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Mon Jan 17 16:40:53 2000 Curt Wuollet wrote...
>
>Stan Brown wrote:
>>
>> On Mon Jan 17 15:02:29 2000 Curt Wuollet wrote...
>> >
>> >Hi Stan,
>> >
>> >We're fortunate here in that the only concession we need to make to allow
>> >RTL in the future is to use memory accessable by both. Not using that type
>> >of memory excludes use of RTL unless we use fifos. Fifos are not a good
>> >fit for what we are doing. That's why I asked (indirectly) if all this
>> >magic will work with that type of memory. Real world, we will probably
>> >want it or need it. As long as we stay with that form we won't have to
>> >rewrite if we need RTL. We can stay in userland for now, indeed the
>> >driver I'm writing uses the kernel networking services and I'm not even
>> >gonna try to figure out how to do that from RTL. We can play around
>> >with the jiffy timer some, but really fast performance may require both.
>> >I was making this assumption initially, but, in the ensuing discussion
>> >I am hearing things that I'm not sure are doable this way. Maybe, but
>> >I'm not sure. Those who are writing code need to check this out.
>> >
>> I am afraid I have lost the point of this thread. What were you asking, relative to this?
>You were saying you wanted to get something out without the complexities
>of RTLinux. I am saying I agree, but, we want to preserve that option
>because we may need it. That requires that we stick with the original
>shared memory scheme. I'm not sure some of the things proposed are
>compatible with that. Since much of the detail is known only to the
>coder, they will need to check it out if we are to preserve that functionality. <

I am no longer certain that we can produce a useful project without resorting to some form of real time extension.

I _really_ hate this, as the design I was proposing would have worked on almost any flavor of *NIX. Something I was really wanting to accomplish.

While Linux is nice, when my stuff really just must stay up, I use FreeBSD.

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

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

Curt Wuollet

Stan Brown wrote:
>
> I am no longer certain that we can produce a useful project without resorting to some form of real time extension.<

I don't think it's as bad as all that, but it will take tight efficient programming to get the most out of the platform. If that isn't fast enough then we would want to try the utime and KURT for critical portions. There will always be things that simply can't be too fast and we have RTLinux for those. Pity RTL and KURT are at the moment, not compatible with each other.
There are POSIX real time facilities that should be checked out. If we can keep the chrome and tailfins out of the core, we should be competitive.

>
> I _really_ hate this, as the design I was proposing would have worked on almost any flavor of *NIX. Something I was really wanting to accomplish. <

I would prefer a "normal" non critical environment also, but, Linux is a general purpose OS. If I was aiming for a straight, all out PLC, I would start out with ECOS. I see this as a largely networked controller. The latency and speed of fieldbus IO may end up predominating the cycle time anyway.

> While Linux is nice, when my stuff really just must stay up, I use FreeBSD.

I like *BSD also, but their cathedral development turns me off.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Mon, 17 Jan 2000, Stan Brown wrote:

> On Mon Jan 17 12:37:41 2000 Jiri Baum wrote...
> >
> >Simon Martin:
> >> >> If a logic engine requests write permission for a point that another
> >> >> registered logic engine alread has write permission for then the
> >> >> request will fail.
> >
> >Jiri Baum:
> >> >I don't think we should be implementing this - we should make use of
> >> >semaphores if we need handover of outputs between modules. Semaphores
> >> >are the Right Thing for this job. No point re-inventing them.
> >
> >Stan Brown:
> >> Question, I am thinking of "ownership" of an output being
> >> implemented on a per point basis, as opposed to say an I/O scanner
> >> or a "rack' basis. Given this wouldn't we have a lot of semaphores
> >> to deal with here?
> >
> >I'm assuming that each semaphore would be used for many different points.
> >Modules would hand over to each other whole sections of the machine (or the
> >whole machine altogether).
> >
> >If two modules need to work on the same point at the same time, they should
> >either communicate with each other, or use intermediate coils which are
> >then explicitly ORed or ANDed together.
>
> I still don't think we are in synch here. I envision ownership of an
> output being permanent (for the life of the run time). It can only be
> changed which the system down. So it should be possible to arbitrarily
> assign a given output within a card to a given logic engine. Although I
> can see that this may not be feasible, and we may need to only allow
> assignments at the whole module level.
>
> In real PLC's it's done at the entire rack level, BTW>

Exactly why I think this whole idea of ownership and more than one logic engine controlling a single I/O point is complete silliness. What happened to KISS. For the purposes of my description a logic engine is the equivelant to a PLC rack. and there should be one perlogic programme and it handles its own I/O which no other can access. If you want more than one logic engine on the same Linux box then simply
run another task with the same restrictions, it has it's own I/O that no other can access.
Some people keep talking about different logic engines running different languages. How daft does this sound to other system programmers out there. It sounds very misconcieved to me. Surely there will be only one logic engine that executes one programme in it's own internal instruction set
(Somewhat analogous of a CPU. A CPU does not run BASIC or C or RLL, it runs only it's own instruction set or machine code). Yes PLC manufacturers do make and sell different "processors" for different languages but does
that make it the correct thing to do? Surely the language (RLL, C, function block, etc) is a userland thing only and will be compiled by the
programming enviroment into and executable for the logic engine to process. Result: one logic engine and lots of languages for developing the
application (AKA KISS).


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, 18 Jan 2000, Phil Covington wrote:

> Lets forget about "determinism" and talk about FAST (as Stan Brown defined
> it in another post as 35 ms scan times and under). The normal Linux kernel
> is not going to be able to give you a FAST PLC as defined above. So the
> question is what is a minimum scan time that people can live with? I am
> talking about scan times assuming a Ladder Logic Engine running. I would
> like to see sub 15 ms scan times... What about everyone else?

Why do most people keep refering to the logic engine as though it will run one particular language, as you said above "Ladder Logic Engine". If the logic engine is constructed in such a manner then it will simply be a high
level language interpretter and be so slow it will take half a day to do anything :cool:. The logic engine should not interpret ladder, or BASIC or C or any other high level language. That is the job of a compiler. The logic engine should only interpret it's own internal instruction set (yet to be defined) similar to byte code or p-code or machine code. If the internal instruction set is carefully planned then it can do anything reasonably fast.

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 Wed Jan 19 06:11:45 2000 Dave West wrote...
>
>On Tue, 18 Jan 2000, Phil Covington wrote:
>
>> Lets forget about "determinism" and talk about FAST (as Stan Brown defined
>> it in another post as 35 ms scan times and under). The normal Linux kernel
>> is not going to be able to give you a FAST PLC as defined above. So the
>> question is what is a minimum scan time that people can live with? I am
>> talking about scan times assuming a Ladder Logic Engine running. I would
>> like to see sub 15 ms scan times... What about everyone else?
>
>Why do most people keep refering to the logic engine as though it will run
>one particular language, as you said above "Ladder Logic Engine". If the
>logic engine is constructed in such a manner then it will simply be a high
>level language interpretter and be so slow it will take half a day to do
>anything :cool:. The logic engine should not interpret ladder, or BASIC or C
>or any other high level language. That is the job of a compiler. The logic
>engine should only interpret it's own internal instruction set (yet to be
>defined) similar to byte code or p-code or machine code. If the internal
>instruction set is carefully planned then it can do anything reasonably
>fast.

This misses the basic point of a PLC. A PLC allows run time examination, and editing of the program statements, and data table. Thus it is inherently not a traditional compiled language. The closest thing to a compiled PLC I have ever seen is AB's PI. In theory it does compile the statements, but if it does, it's totally invisible to me as an application programmer.

Of course uncompiling might explain why backing mine up takes over an hour :)

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Wed Jan 19 06:03:18 2000 Dave West wrote...
>
>Exactly why I think this whole idea of ownership and more than one logic
>engine controlling a single I/O point is complete silliness. What happened
>to KISS. For the purposes of my description a logic engine is the
>equivelant to a PLC rack. and there should be one perlogic programme and
>it handles its own I/O which no other can access.
>If you want more than one logic engine on the same Linux box then simply
>run another task with the same restrictions, it has it's own I/O that no
>other can access.
>Some people keep talking about different logic engines running different
>languages. How daft does this sound to other system programmers out there.
>It sounds very misconcieved to me. Surely there will be only one logic
>engine that executes one programme in it's own internal instruction set
>(Somewhat analogous of a CPU. A CPU does not run BASIC or C or RLL, it
>runs only it's own instruction set or machine code). Yes PLC manufacturers
>do make and sell different "processors" for different languages but does
>that make it the correct thing to do? Surely the language (RLL, C,
>function block, etc) is a userland thing only and will be compiled by the
>programming enviroment into and executable for the logic engine to
>process. Result: one logic engine and lots of languages for developing the
>application (AKA KISS).

How you use the project, as an application programmer is entirely up to you.

I have used PI's with multiple logic processors quite a bits, and would miss this functionality.

As for different logic engines running different languages in the same node, I can see many uses for this. Data handling is a very poor fit in ladder diagram, on the other hand ladder is the best way to do machine control. Take an automotive assembly plant selectivity system. Lots of conveyers, loft tables, elevators etc that need machine control, _and_ a huge amount of build data to be handled.

I would do this with 2 different logic engines running 2 different languages, given the choice.

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

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

Phil Covington

Dave West wrote:

>On Tue, 18 Jan 2000, Phil Covington wrote:

>> Lets forget about "determinism" and talk about FAST (as Stan Brown defined
>> it in another post as 35 ms scan times and under). The normal Linux kernel
>> is not going to be able to give you a FAST PLC as defined above. So the
>> question is what is a minimum scan time that people can live with? I am
>> talking about scan times assuming a Ladder Logic Engine running. I would
>> like to see sub 15 ms scan times... What about everyone else?
>
>Why do most people keep refering to the logic engine as though it will run
>one particular language, as you said above "Ladder Logic Engine". If the
>logic engine is constructed in such a manner then it will simply be a high
>level language interpretter and be so slow it will take half a day to do
>anything :cool:. The logic engine should not interpret ladder, or BASIC or C
>or any other high level language. That is the job of a compiler. The logic
>engine should only interpret it's own internal instruction set (yet to be
>defined) similar to byte code or p-code or machine code. If the internal
>instruction set is carefully planned then it can do anything reasonably
>fast.

Dave,

Drop the word "Ladder" and re-read my previous post. I am afraid you are missing the point. I don't care if you write the "Logic Engine" in
assembly language and the actual logic is hard coded, there are still problems with a periodic task running ( in user space) with the normal linux kernel. Your statement "If the internal instruction set is carefully planned then it can do anything reasonably fast" is meaningless in the context of scheduling issues with the normal
Linux kernel. This is an operating system issue.

I used the words "Ladder" and "scan" so that we could relate these OS issues to a real PLC. Replace the word "scan" with periodic task and the problems are the same.

Take a look at the thread "LinuxPLC: Real Time? Take Two"

Phil Covington
vHMI






_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
>The logic engine should not interpret ladder..."

I can't speak about Allen-Bradley. If you download a program from an Allen-Bradley PLC you will receive much more information about your program than you will from other brands. They seem to store a lot. Who knows if they interpret the Ladder, or the mnemonics, or op-code.

For other brands, when you download a Ladder to a PLC, the Ladder is first automatically converted to Mnemonics, which is then fed through an
Assembler to create the code pattern to be sent to the PLC. You are able to write the mnemonic direct if you wish. Like any Dos/Linux mnemonics text file sent through an Assembler, the result has no comments, only the bare essentials. Like a Dos/Linux assembler the result is a hex listing of op-codes that the microprocessor can understand. Like in Dos/Linux there is a one for one correspondence between the three characters "AND" as a written instruction in the Mnemonics style, and the one byte -call it a token, call it an op-code if you will. Likewise you would expect that "OR", "ANDLOAD", "ORLOAD" all have their own specific byte value or op-code. Just like x86 op-codes, you would expect some onebyte, some two byte, some multiple byte op-codes, and further like x86 op-codes you would expect some of the data to be packed as two or three or four nibbles or what ever the microprocessor's instruction list demands.

The key point here is that for brands other than Allen-Bradley, it is possible to glean that the PLC microprocessor Does operate on a piece of
code that has been downloaded to it from the Laptop's Ladder editor, - - - in the form of the microprocessor's op-code language - - -.
If the microprocessor is a 502,Z80,6809,68000,X86 or some custom made one, it could be expected to be fed by a program in its own op-code Hex pattern. If you were really mad keen you could hand code the Hex code (like you could x86) and transmit it to the PLC, but who is that mad.

Now, are we going to go that far that the LinuxPLC is going to run x86 op-codes. That is probably too big a jump at first.


Second topic of discussion:
> This misses the basic point of a PLC. A PLC allows run time examination,
> and editing of the program statements, and data table. Thus it is
> inherently not a traditional compiled language.

When you look at the Laptop, and monitor the on of states of the rungs, then you are never actually monitoring the rung. Again I can't speak for how Allen-Bradley does it, for other brands what actually happens is that a small message is sent to the PLC to enquire either about a single address, or the message may be stated so to ask for the status of a quantity of
addresses starting from address so and so. Scada packages or home made software can be written by following the communication protocol given in
manual by the PLC manufacturer. The Laptop with it Ladder monitor merely asks a dozen questions of the PLC if there are a dozen contact showing on
the screen. If it should happen that there is some nearness in the addresses, then the Ladder monitor might have some smarts which get it to
ask fewer questions to the PLC. The result is a good impersonation of a Ladder monitor that is monitoring the actual workings of the Ladder Logic. In fact there in no difference in degree of difficulty, for the Ladder monitor to ask for and display widely separated and unrelated "bits" as it would be for the questions to be asked about bits on a single rung. It gives the appearance of a separate/independent task/thread that answers questions about the value of particular bits from a data table, quite
separate it seems the logic engine. (Of course regardless of what multitasking is being emulated, there is but one microprocessor).


> On Wed Jan 19 06:11:45 2000 Dave West wrote...
> >
> >On Tue, 18 Jan 2000, Phil Covington wrote:
> >
> >> Lets forget about "determinism" and talk about FAST (as Stan Brown
defined
> >> it in another post as 35 ms scan times and under). The normal Linux
kernel
> >> is not going to be able to give you a FAST PLC as defined above. So the
> >> question is what is a minimum scan time that people can live with? I am
> >> talking about scan times assuming a Ladder Logic Engine running. I would
> >> like to see sub 15 ms scan times... What about everyone else?
> >
> >Why do most people keep refering to the logic engine as though it will run
> >one particular language, as you said above "Ladder Logic Engine". If the
> >logic engine is constructed in such a manner then it will simply be a high
> >level language interpretter and be so slow it will take half a day to do
> >anything :cool:. The logic engine should not interpret ladder, or BASIC or C
> >or any other high level language. That is the job of a compiler. The logic
> >engine should only interpret it's own internal instruction set (yet to be
> >defined) similar to byte code or p-code or machine code. If the internal
> >instruction set is carefully planned then it can do anything reasonably fast.< <
>
> This misses the basic point of a PLC. A PLC allows run time examination,
> and editing of the program statements, and data table. Thus it is
> inherently not a traditional compiled language. The closest thing to a
> compiled PLC I have ever seen is AB's PI. In theory it does compile the
> statements, but if it does, it's totally invisible to me as an
application programmer.
>
> Of course uncompiling might explain why backing mine up takes over an
hour :)
>
> --
> Stan Brown [email protected]
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
H

Hurd, David L (GEA, 053698)

Phil and all,
The faster the better. The new PLC CPUs can produce scan times around 5 - 6 msec and there is a noticeable improvement in machine performance. I'd would set 20 msec as a reasonable maximum.
Dave Hurd
GE Appliances

> -----Original Message-----
> From: Phil Covington
>
> Lets forget about "determinism" and talk about FAST (as Stan Brown defined
> it in another post as 35 ms scan times and under). The normal Linux
> kernel
> is not going to be able to give you a FAST PLC as defined above. So the
> question is what is a minimum scan time that people can live with? I am
> talking about scan times assuming a Ladder Logic Engine running. I would
> like to see sub 15 ms scan times... What about everyone else?
>

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
This has been stated before, several times.

My vote (and my logic solver (let's see how many names we can find for the same thing)) is to interpret tokenised instruction list. My
complier/tokeniser is built in to the TCP/IP programming port - enabling consistent programming (using IL) from a text terminal.

Ladder, STL, FBD and other language support is provided by editors which save their output in IL. This works for Siemens, Omron, Mitsubishi and even AB to some extent.

The only other native support that may be required is for SFC states.

-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of Dave West

On Tue, 18 Jan 2000, Phil Covington wrote:

> Lets forget about "determinism" and talk about FAST (as Stan Brown defined
> it in another post as 35 ms scan times and under). The normal Linux kernel
> is not going to be able to give you a FAST PLC as defined above. So the
> question is what is a minimum scan time that people can live with? I am
> talking about scan times assuming a Ladder Logic Engine running. I would
> like to see sub 15 ms scan times... What about everyone else?


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
Actually, many PLC use compiled or tokenised code (even AB) when you work online with these systems , the terminal software translates the compiled
view to the original ladder diagram. Which is why, when going online to an SLC it uploads the program onto your PC, it then translates the compiled code back to ladder.


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

On Wed Jan 19 06:11:45 2000 Dave West wrote...
>
>On Tue, 18 Jan 2000, Phil Covington wrote:
>
>> Lets forget about "determinism" and talk about FAST (as Stan Brown defined
>> it in another post as 35 ms scan times and under). The normal Linux kernel
>> is not going to be able to give you a FAST PLC as defined above. So the
>> question is what is a minimum scan time that people can live with? I am
>> talking about scan times assuming a Ladder Logic Engine running. I would
>> like to see sub 15 ms scan times... What about everyone else?
>
>Why do most people keep refering to the logic engine as though it will run
>one particular language, as you said above "Ladder Logic Engine". ...<clip>
>

This misses the basic point of a PLC. A PLC allows run time examination, and editing of the program statements, and data table. Thus it is
inherently not a traditional compiled language. The closest thing to a compiled PLC I have ever seen is AB's PI. In theory it does compile the
statements, but if it does, it's totally invisible to me as an application programmer.

Of course uncompiling might explain why backing mine up takes over an hour :)



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

Johan Bengtsson

>
>I think that a few issues are involved -
>
>a) 35 ms does not look very fast, at least for a short program
>
>b) 10 ms would be "medium fast" in my opinion
>
>c) there is likely to be some "fixed overhead" regardless of length of
>program - how much?

The schedulers granuality (10ms) is the big part here some multiple of this, depending on a lot of things about the process priority and to some degree the overall load of the computer.
I would make a rough guess about 20-30ms but in that time is the I/O mapper run and a fairly long ladder (or anything else) solved + some time left to all the other processes in the computer.

>d) how much is speed affected by more complex processing

As I said above I don't think it will be much for
small to medium programs, really large programs
is however going to need more time. A modern
processor like for example a pentium II @ 350MHz
could be executing about perhaps 4 000 000 assembler instructions in 10ms (yes they can execute two instructions at the same time)

>e) there should be some means for optimization - at least a "speed
>counter" - which would tell average scan time over last ten (?)scans and
>longest scan time over configurable period
>

A speed counter is the easy part.


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

Johan Bengtsson

>Some people keep talking about different logic engines running different
>languages. How daft does this sound to other system programmers out there.
>It sounds very misconcieved to me. Surely there will be only one logic
>engine that executes one programme in it's own internal instruction set
>(Somewhat analogous of a CPU. A CPU does not run BASIC or C or RLL, it
>runs only it's own instruction set or machine code). Yes PLC manufacturers
>do make and sell different "processors" for different languages but does
>that make it the correct thing to do? Surely the language (RLL, C,
>function block, etc) is a userland thing only and will be compiled by the
>programming enviroment into and executable for the logic engine to
>process. Result: one logic engine and lots of languages for developing the
>application (AKA KISS).

I do not agree!

Everything in ladder (LD) of function block (FBD) is translateable to and from instruction list (IL) possibly also structured text (ST) but I am not entirely that sure here. Grafcet (SFC) is easily translateable to the oter languages but not
as easily translated back (it is possible but not if anyone have made some certain changes)

All this is easily solved by the same logic solver from some kind of byte code, and this will be really fast

However, translating SFC to the same byte code will work, but it would be a *lot* faster to run this from another logic solver specially written for SFC.

Calcualting a PID loop could also be done from the samy byte code but that one would also be a *lot* faster if compiled (from C) to the processors own machine code handling the complete PID algorithm just reading and writing the I/O:s etc.

Result: some logic engines and some other engines for solving non logic stuff (for example PID loops, fuzzy logic, whatever) and a lot more languages for developing applications.

Some people even want to make programs in C and compile them to run directly against the global memory (or whatever)

If what you really thought was something like "compile everything to pure machine code and let the processor just run" that would definitely be the fastest but probably not the most practical thing to do.


/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
 
On Wed Jan 19 08:12:52 2000 Phil Covington wrote...
>
>Drop the word "Ladder" and re-read my previous post. I am afraid you are
>missing the point. I don't care if you write the "Logic Engine" in
>assembly language and the actual logic is hard coded, there are still
>problems with a periodic task running ( in user space) with the normal linux
>kernel. Your statement "If the internal instruction set is carefully
>planned then it can do anything reasonably
>fast" is meaningless in the context of scheduling issues with the normal
>Linux kernel. This is an operating system issue.
>
>I used the words "Ladder" and "scan" so that we could relate these OS issues
>to a real PLC. Replace the word "scan" with periodic task and the problems
>are the same.
>
>Take a look at the thread "LinuxPLC: Real Time? Take Two"
>


Are you asying we can't get to an _average_ scan time in the 10's of milliseconds with the standard scheduler? Or are you concerned that some scans may be long? If so by about how much?

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

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

Phil Covington

----- Original Message -----
From: "Stan Brown" <[email protected]>

<snip>

> Are you asying we can't get to an _average_ scan time in the 10's of
> milliseconds with the standard scheduler? Or are you concerned that
> some scans may be long? If so by about how much?
>
> --

Unfortunately I am saying that even with the POSIX soft realtime support in the normal linux kernel you are not going to see scan times under 20 ms on an unloaded system. With increasing system load the scans will be even longer by an unpredictable amount and will jump around all over the place (jitter).

Phil Covington
vHMI



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