Fw: shared memory

On Wed Jan 19 22:10:18 2000 Phil Covington wrote...
>
>----- 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). <

Hmm, wasn't there a second choice in the realtime flavors that used POSIX calls?

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

> Hmm, wasn't there a second choice in the realtime flavors that used
> POSIX calls?

RTAI is based on RTLinux and adds a POSIX style API... In Ver 2.0 of RTLinux, NMT adopted a POSIX style API like RTAI. Version 2 also supports
SMP

Version 1 of RTLinux runs with the Linux 2.0 kernel. Version 2 of RTLinux runs with the Linux 2.2 kernel.

Phil Covington
vHMI


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Tue, Jan 18, 2000 at 09:45:00PM -0500, Stan Brown wrote:
> 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?

Individual outputs would be assigned either to a specific logic engine, or a specific semaphore.

A given semaphore can protect any number of outputs.

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
 
On Wed, Jan 19, 2000 at 11:03:18AM +0000, Dave West wrote:
> 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.

That's because it's poor terminology.

There may be one thing that's properly a logic engine, another thing written in C doing FFTs or something, and maybe even an HMI [*].

Now, try inventing a word that covers all of those :)

(I tried using the word "module", but some people took that as "I/O module" rather than the software kind. It can also mean kernel module, so maybe it isn't such a good word anyway.)


[*] Yes, HMI will probably blow out the scan times. But the linuxPLC core can also serve as a linuxHMI core - you just don't give it any critical tasks and load the HMI thing.


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
 
On Thu, Jan 20, 2000 at 01:29:49AM +1030, LouisKriek wrote:
> 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.

It's not a big jump at all - just output C code (with appropriate #line directives) and call gcc.

I've got a Perl script somewhere that I wrote in an afternoon that can translate the text-version of ladder (non-structured) like that. I'll post
it if there's interest (or check it into the CVS).

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
 
On Thu Jan 20 20:31:24 2000 Jiri Baum wrote...
>
>On Thu, Jan 20, 2000 at 01:29:49AM +1030, LouisKriek wrote:
>> 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.
>
>It's not a big jump at all - just output C code (with appropriate #line
>directives) and call gcc.
>
>I've got a Perl script somewhere that I wrote in an afternoon that can
>translate the text-version of ladder (non-structured) like that. I'll post
>it if there's interest (or check it into the CVS).
>

I think he meant too big a jump for user acceptance.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Thu Jan 20 19:40:46 2000 Jiri Baum wrote...
>
>
>[*] Yes, HMI will probably blow out the scan times. But the linuxPLC core
>can also serve as a linuxHMI core - you just don't give it any critical
>tasks and load the HMI thing.

Actually I am much more likely to deploy a Linux HMI first before a Linux PLC. However IMHO that's a whole separate project.

Lets not get so much stuff on our plate, that we never produce a system at all.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Thu Jan 20 18:50:15 2000 Jiri Baum wrote...
>
>Individual outputs would be assigned either to a specific logic engine, or
>a specific semaphore.
>
>A given semaphore can protect any number of outputs.
>

Any thoughts on the issue of number of semaphores that are reasonable? I have a Factory Link application with about 50K, come to think of it. Never mind, should not be a problem.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
From: Jiri Baum <[email protected]>

>That's because it's poor terminology.
>
>There may be one thing that's properly a logic engine, another thing
>written in C doing FFTs or something, and maybe even an HMI [*].
>
>Now, try inventing a word that covers all of those :)
>
>(I tried using the word "module", but some people took that as "I/O module"
>rather than the software kind. It can also mean kernel module, so maybe it
>isn't such a good word anyway.)
>


How about using the word "task" to represent independently operating software "parts"?

Ron Davis
[email protected]


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Wed, 19 Jan 2000, Phil Covington wrote:
<clip>
> 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" <

Sorry, I picked the wrong message to try and make my point. I agree entirely with what you are trying to say regarding how long it takes the
logic engine to process it's instruction programme once. Yes it can take a relatively long time due to scheduling and as such I think the logic engine may probably end up being some sort of real time task. However, I think the arguments for or against real time are pointless at this stage. Although not trivial to port a task to real time it will be far easier to write things as normal linux tasks and get the logic sorted then optimise for speed and convert what needs to be converted to real time (around about version 2.0).

To explain my original point a little further: A lot of people are confusing issues in the logic engine area with statements like "it must run ladder" or "it would be nice if it ran C". Such statements are confusing many people on the list as to what does what, when and where. I would like everyone to think more carefully about what the logic engine will do and understand that it will have no knowledge of ladder, C, BASIC,
or any other language that describes a logical processing sequence. Just for clarity of thought :cool:


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
 
Saved me the job of explaining some of the more basic principles. Thanks.

Oh and his point about monitoring makes it all the more obvious that a real PLC compiles the programme into some internal instruction set for
what is most likely an emulated machine.

On Thu, 20 Jan 2000, LouisKriek wrote:

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

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
 
So is it time to decide on some - - very limited - - specifications for the
first LinuxPLC.
Just do PLC alone, Leave HMI till later.
Treat it as only a practice_run, version 0.0000000000000000000000000001
;-)
This is our "throw away", or a "tutorial" version.

Here is a simple specification that everyone will recognise or is familiar with:
Just a small 10in,8out shoe-box plc only doing bit banging relays, timers, counter with no retentivity yet (IL not yet LD). 1K instructions max.
Something like a SLC503. Leave the HMI till latter, for just use whatever AB software you already have to download and monitor. Or pick on a brand that we know is not popular but is extremely easy to simulate, and the HMI is cheap.

We can argue, and produce a better specification while we are leering by doing the simple thing.
For most of us, there are an awful lot of things to learn just doing this much. Not many of us have many compilers designs to our name.

If we eventually decide to make the LinuxPLC be a (6)1131 compliant device, we are going to have to become competent in a lot of computer science, by
starting simple first. I suggest that we -do- the "very simple" version first almost right now, and simultaneously hold discussions about the best
architecture that the first real LinuxPLC. Learn to make the first real LinuxPLC, by doing, on the "too simple", "throw-away", "getting started",
version.


Yes/No/Maybe/Never/Good/Bad/Indifferent?

<clip>
Lets not get so much stuff on our plate, that we never produce a system at all.

--
Stan Brown [email protected]

<clip>


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri, 21 Jan 2000, Jiri Baum wrote:

> On Wed, Jan 19, 2000 at 11:03:18AM +0000, Dave West wrote:
> > 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.
>
> That's because it's poor terminology.
>
> There may be one thing that's properly a logic engine, another thing
> written in C doing FFTs or something, and maybe even an HMI [*].
>
> Now, try inventing a word that covers all of those :)
>
> (I tried using the word "module", but some people took that as "I/O module"
> rather than the software kind. It can also mean kernel module, so maybe it
> isn't such a good word anyway.)
>
> [*] Yes, HMI will probably blow out the scan times. But the linuxPLC core
> can also serve as a linuxHMI core - you just don't give it any critical
> tasks and load the HMI thing.

What has the HMI got to do with the logic engine aprt from querying it for data from time to time?

As for the poor terminology why do can't we give things names and use them. In my opinion we should have the following items:

Scheduler, a programme that sequences the execution of tasks (we could call it PLCsched).
Input scanner, a programme to scan the physical input devices and make a copy in a data table (say PLCIscan).
Logic engine, a programme to scan the machine logic (say PLCengine).
Output scanner, a programme to take an output data table and pass the values on to real output drivers (say PLCOscan).
Communication handler, a programme to handle requests for data from other programmes EG. HMI or monitor programme or logic compiler (say PLCcomm).

Agreed each of these is a software module that makes up the entire PLC system but the HMI, monitor programme and logic compilers are not. They are tools for accessing the system.

Any way I think we are spending too much time discussing terminology simply because most of us (myself included) are lazy typists and try to
describe something in as few key strokes as possible :cool:


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 Fri, 21 Jan 2000, Jiri Baum wrote:

> On Thu, Jan 20, 2000 at 01:29:49AM +1030, LouisKriek wrote:
> > 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.
>
> It's not a big jump at all - just output C code (with appropriate #line
> directives) and call gcc.
>
> I've got a Perl script somewhere that I wrote in an afternoon that can
> translate the text-version of ladder (non-structured) like that. I'll post
> it if there's interest (or check it into the CVS).

I struggle to see how we could impliment this. Consider the following. the PLC is running and we want to upload a programme from a remote
device as we would with a real PLC. Our soft PLC accepts the programme as data and writes it into a data segment as defined by the Linux kernel
(Code segments are not writable). How do we then tell the kernel that the data segment should now become a code segment and it can schedule it for
execution. Unless there is a system call to do this it will simply cause a SEGFLT. As far as I know only the kernel can do this and thus for us to do it we would have to write the soft PLC as a kernel module. Alternatively we could compile to a real full blown elf executable and run that but that opens a whole new can of worms.

If someone has more insight as to how this loading of executable code modules can be done from a user process could they let me know as I don't.


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 Fri Jan 21 10:00:11 2000 LouisKriek wrote...
>
>So is it time to decide on some - - very limited - - specifications for the
>first LinuxPLC.
>Just do PLC alone, Leave HMI till later.
>Treat it as only a practice_run, version 0.0000000000000000000000000001
>;-)
>
>Yes/No/Maybe/Never/Good/Bad/Indifferent?
>

Yes.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri, 21 Jan 2000, Ron Davis wrote:

> To me, one main feature of PLCs that separate them from other computer-based
> systems is their ability to support "on-line programming." Support for this
> feature needs to be considered at this early stage in the design. Talk of
> "compiled" code worries me that this is not being considered.

You've got me here Ron. Why does "compiled" code make you believe that on-line programming will not be possible. If you are talking about code
compiled to x86 machine language that is executed directly by the CPU then I can see your concerns, however, it is still not impossible, your linux
or Windoze box does it every day. If you are talking about code compiled to run on our virtual machine (the logic engine) then how do you see there being any dificulty after all a real PLC does 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 Fri Jan 21 09:32:11 2000 Ron Davis wrote...
>
>From: Jiri Baum <[email protected]>
>Date: Friday, January 21, 2000 3:00 AM
>Subject: Re: Fw: LinuxPLC: Fw: shared memory
>
>>That's because it's poor terminology.
>>
>>There may be one thing that's properly a logic engine, another thing
>>written in C doing FFTs or something, and maybe even an HMI [*].
>>
>>Now, try inventing a word that covers all of those :)
>>
>>(I tried using the word "module", but some people took that as "I/O module"
>>rather than the software kind. It can also mean kernel module, so maybe it
>>isn't such a good word anyway.)
>
>How about using the word "task" to represent independently operating software "parts"?

Task is good since it could be a process or a thread.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
I was reading some of the information about (6)1131-3 and the newer 61499 drafts, available from the ab ftp site someone mentioned recently on this
list. I have been reading so much from there, that I have lost track of excactly where I saw it. Sorry I can't be sure of the documents name. I do clearly remember that the word "task" has a paragraph explaining how it is to be understood, sorry I can't remember enough to go into print about it, but it caught my eye because it allows me to think about a super fast way but unorthodox way of doing the logic solver. This note is only to say, be aware of that the IEC wants to put a very specific meaning to the word "task".
Enough for now.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri Jan 21 10:31:58 2000 Dave West wrote...
>
>On Fri, 21 Jan 2000, Ron Davis wrote:
>
>> To me, one main feature of PLCs that separate them from other computer-based
>> systems is their ability to support "on-line programming." Support for this
>> feature needs to be considered at this early stage in the design. Talk of
>> "compiled" code worries me that this is not being considered.
>
>You've got me here Ron. Why does "compiled" code make you believe that
>on-line programming will not be possible. If you are talking about code
>compiled to x86 machine language that is executed directly by the CPU then
>I can see your concerns, however, it is still not impossible, your linux
>or Windoze box does it every day. If you are talking about code compiled
>to run on our virtual machine (the logic engine) then how do you see there
>being any dificulty after all a real PLC does it.
>

I don't know about Ron, but I for one would be willing to accept any technology that accomplished what he is asking for.

I do agree with him that this is basic non negotiable functionality, even in version 1.0

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

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