Fw: shared memory

On Fri Jan 21 10:11:37 2000 Dave West wrote...
>
>What has the HMI got to do with the logic engine aprt from querying it for
>data from time to time?

Absolutely correct. And once again, I think the HMI is a big enough project (or 2 projects) all it's own.

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

Agreed,

>Input scanner, a programme to scan the physical input devices and make a
>copy in a data table (say PLCIscan).

Agreed, but we need multiple ones of these. If only to support different brands of hardware.

>Logic engine, a programme to scan the machine logic (say PLCengine).

Agreed, but again, we need to allow for multiple ones of these, for instance to process different languages.

>Output scanner, a programme to take an output data table and pass the
>values on to real output drivers (say PLCOscan).

I think this can be combined with the input scanner.

>Communication handler, a programme to handle requests for data from other
>programmes EG. HMI or monitor programme or logic compiler (say PLCcomm).

Probably at some point in time. I am not certain we need this for V1.0

Additional tasks as I see them:

Timer execution task(s)
Counter execution task(s).
PID execution task(s).
Motion control execution task(s).
Editor/monitor/documentation package.

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

Guilty as charged :-(

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri Jan 21 10:07:29 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.
>

A must have feature. Even for V 1.0.

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

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

Ok, since I don't know what SFC is I will, provisionally, conceed this point for this language. Although I don't see why a special SFC engine would be faster. If it were then the SFC compiler to the traditional byte code is crap!!! or rather the optimiser. I suppose it may be that the byte code doesn't support the correct operations in which case we add the correct operations. I just can not see why a special engine would be a LOT faster.

Still without knowledge of SFC I can argue no further and must conceed.

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

This is not a logic engine it is I/O implemented in software. The logic engine tells the PID engine some data and the PID engine does whatever it needs to. Basically the logic engine Outputs data to a software device.

Unless you mean the PID engine reads it's own data and does it's own thing in which case it is a controller in it's own right and only communicates with the logic engine for go / stop type data via the provided communication mechanisms.

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

Languages for developing applications has got nothing to do with what a logic engine executes.

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

See my other post on this. I don't think this is viable at all.


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
 
P

Phil Covington

Simon:

While the details can be argued ad infinitum, I think that it is important that we get some code in our hands to look at before interest is lost in
this project. What you have outlined looks good to me, so I say go for it! It will probably take a few iterations, but someone has to get it started.

To All:

So far, from reading the messages here, we seem to have the following people actually coding or volunteering to code certain parts:

1. Drivers: Curt Wuollet -Modbus/TCP , Mark Bayern - Modbus or ProMux, possibly Ron Gage ? - AB Ethernet. I would like to work on Ethernet/PLC
Direct I/O and hacking the GE Ethernet stuff similar to what Ron is doing with AB.

2. Shared Memory (Virtual Memory) Management: Simon Martin

3. Logic Engines: Any volunteers?

As I see it, coding the Logic Engines is going to be the most difficult part. Without a logic engine this project isn't much more that what has
already been done with projects like NIST's EMC, NASA's Airborne Laser System, or the Triton ETD Project to name a few. There many examples of
driver code and how to use shared memory to draw from. The graphical display of Ladder Logic will be a challenge in itself.

Comments?

Phil Covington
vHMI

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri Jan 21 12:49:16 2000 Dave West wrote...
>
>> 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.
>
>This is not a logic engine it is I/O implemented in software. The logic
>engine tells the PID engine some data and the PID engine does whatever it
>needs to. Basically the logic engine Outputs data to a software device.

Right, the PID execution engine reads data from the appropriate data table file(s) and outputs the results to the appropriate files. By
doing it this way, if the PID execution engine really needs to deal directly with I/O, it can, by being so configures. however as I see it, the far more common application will be for the data table to be simply an interface to a login engine, which will then move data to/from the I/O data tables.

>Unless you mean the PID engine reads it's own data and does it's own thing
>in which case it is a controller in it's own right and only communicates
>with the logic engine for go / stop type data
> via the provided communication mechanisms.
>
>> 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.
>
>Languages for developing applications has got nothing to do with what a
>logic engine executes.

Fair enough. As long as this is transparent to the application programmer in _all_ ways. He/she should _never_ need to know that it is not their code that is actually being executed.

>> 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. <<
>
>See my other post on this. I don't think this is viable at all.<

i wouldn't do it either, but as long as they use the shared memory access routines we supply, then they should be able to do it. Now
whether they can get any users to accept it, thats a whole different question.


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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
-----Original Message-----
From: Dave West <[email protected]>
>
>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 was only concerned about code compiled directly to native machine language.

Ron Davis
[email protected]



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

Johan Bengtsson

There is another point about this, both ways will probably be supported eventually. Online changes will be needed by some users, but not everybody.
I think it would be a lot easier to support that with a byte coded "sub-language" and a fast interpreter for the byte code than compiled C. Compiled C will of course be faster on the
other hand.


/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 Fri Jan 21 23:39:15 2000 wrote...
>
>There is another point about this, both ways will probably
>be supported eventually.
>Online changes will be needed by some users, but not everybody.
>I think it would be a lot easier to support that with a byte
>coded "sub-language" and a fast interpreter for the byte code
>than compiled C. Compiled C will of course be faster on the
>other hand.

Are we building a PLC, or some sort of computer based home automation cotroler?

This is _BASIC_ PLC functionality!

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

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

Johan Bengtsson

>> 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.
>
>Ok, since I don't know what SFC is I will, provisionally, conceed this
>point for this language. Although I don't see why a special SFC engine
>would be faster. If it were then the SFC compiler to the traditional byte
>code is crap!!! or rather the optimiser. I suppose it may be that the
>byte code doesn't support the correct operations in which case we add the
>correct operations. I just can not see why a special engine would be a LOT
>faster.
>
>Still without knowledge of SFC I can argue no further and must conceed.

SFC is the same as Grafcet. If you (or anyone else) still do not know it it is a kind of "flow" chart.

You define the whole operation as some series of steps and conditions similar to this:
Consider you want to open a door:

+============+
||go to door||
+============+
|
+ at the door
|
+---------------+
|check if locked|
+---------------+
|
+--*-----------------------+
| |
+ locked + not locked
| |
+--------+ |
|find key| |
+--------+ |
| |
+ key found |
| |
+--------+ |
| unlock | |
+--------+ |
| |
+ door unlocked |
| |
+--+-----------------------+
|
+-------+
|open it|
+-------+
|


In a "normal" PLC every piece of tjis is evaluated every scan this is really not necesary since only a small number of steps
are active at once (in the example only one, but more than one can be active at the same time in other circumstances)

By only evaluating the conditions following active steps the amount of time could be drastically reduced.

>> 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.
>
>This is not a logic engine it is I/O implemented in software. The logic
>engine tells the PID engine some data and the PID engine does whatever it
>needs to. Basically the logic engine Outputs data to a software device.
>
>Unless you mean the PID engine reads it's own data and does it's own thing
>in which case it is a controller in it's own right and only communicates
>with the logic engine for go / stop type data via the provided
>communication mechanisms.

In some cases (in real PLC:S) this is done using the byte code for that particular PLC, not something necesary (but still possible) in the byte code used by "our" logic engine.

>> 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.
>
>Languages for developing applications has got nothing to do with what a
>logic engine executes.

Correct.

>> 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.
>
>See my other post on this. I don't think this is viable at all.

Perhaps not to you, but others may like it and there is really nothing stopping them from doing that (and should not be)

/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

yes and yes and yes!

It is going to be a PLC, a computer based general controller AMD it will have the ability to online changes.


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

Are we building a PLC, or some sort of computer based home automation controler?

This is _BASIC_ PLC functionaality!

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

> On Fri Jan 21 12:49:16 2000 Dave West wrote...
> >
> >> 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.
> >
> >This is not a logic engine it is I/O implemented in software. The logic
> >engine tells the PID engine some data and the PID engine does whatever it
> >needs to. Basically the logic engine Outputs data to a software device.
>
> Right, the PID execution engine reads data from the appropriate data
> table file(s) and outputs the results to the appropriate files. By
> doing it this way, if the PID execution engine really needs to deal
> directly with I/O, it can, by being so configures. however as I see
> it, the far more common application will be for the data table to be
> simply an interface to a login engine, which will then move data
> to/from the I/O data tables.

Agreed.

> >Unless you mean the PID engine reads it's own data and does it's own thing
> >in which case it is a controller in it's own right and only communicates
> >with the logic engine for go / stop type data via the provided communication mechanisms.
> >
> >> 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.
> >
> >Languages for developing applications has got nothing to do with what a logic engine executes.
>
> Fair enough. As long as this is transparent to the application
> programmer in _all_ ways. He/she should _never_ need to know that it
> is not their code that is actually being executed.

Ohhh, absolutely!!!
It will be documented though.

<clip>

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, Ron Davis wrote:

> -----Original Message-----
> From: Dave West <[email protected]>
> >
> >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 was only concerned about code compiled directly to native machine language. <

OK.

Something we all seem to have missed about compiling to native machine language is it is non portable. The programming tool needs to know what
kind of processor the PLC is running on and therefore should be disregarded entirely. Well for the immediate future anyway.

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 Sat, 22 Jan 2000 [email protected] wrote:

<clip>
> You define the whole operation as some series of steps
> and conditions similar to this:
> Consider you want to open a door:
>
> +============+
> ||go to door||
> +============+
> |
> + at the door
> |
> +---------------+
> |check if locked|
> +---------------+
> |
> +--*-----------------------+
> | |
> + locked + not locked
> | |
> +--------+ |
> |find key| |
> +--------+ |
> | |
> + key found |
> | |
> +--------+ |
> | unlock | |
> +--------+ |
> | |
> + door unlocked |
> | |
> +--+-----------------------+
> |
> +-------+
> |open it|
> +-------+
> |

I don't see how this differs from any othe pure logic form (eg. ladder), it's just a bunch of "if then else" statements or contact---contact---coil. Just a prettier way of displaying same.

I will therefore assume a massive over simplification in your explanation as you seem very strongly convinced that it will be better run by a special engine.

> In a "normal" PLC every piece of tjis is evaluated every scan
> this is really not necesary since only a small number of steps
> are active at once (in the example only one, but more than one
> can be active at the same time in other circumstances)
>
> By only evaluating the conditions following active steps the
> amount of time could be drastically reduced.
>
> >>
> >> 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.
> >
> >This is not a logic engine it is I/O implemented in software. The logic
> >engine tells the PID engine some data and the PID engine does whatever it
> >needs to. Basically the logic engine Outputs data to a software device.
> >
> >Unless you mean the PID engine reads it's own data and does it's own thing
> >in which case it is a controller in it's own right and only communicates
> >with the logic engine for go / stop type data via the provided
> >communication mechanisms.
>
> In some cases (in real PLC:S) this is done using the byte code for that particular PLC, not something necesary (but still possible) in the byte code used by "our" logic engine. <

Yes, I have implimented PID using ladder which was converted to byte code by the programming tool. Specifically MEDOC on a Mitsubishi A1SJH PLC. Not fast but good enough for the job.
I don't recomend this aproach though, I would have used a proper device (software or hardware) had it been available at a reasonable price at the
time.

> >> 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.<< <
> >
> >Languages for developing applications has got nothing to do with what a
> >logic engine executes.
>
> Correct.

I know :cool:

> >> 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.
> >
> >See my other post on this. I don't think this is viable at all.
>
> Perhaps not to you, but others may like it and there is
> really nothing stopping them from doing that (and should
> not be)

Hmm, You seem to know a way of getting a userland process to load data
(machine executable binary) over a communication link and run it in the
same process context. Please enlighten us.

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

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
 
J

Johan Bengtsson

>> >> 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.
>> >
>> >See my other post on this. I don't think this is viable at all.
>>
>> Perhaps not to you, but others may like it and there is
>> really nothing stopping them from doing that (and should
>> not be)
>
>Hmm, You seem to know a way of getting a userland process to load data
>(machine executable binary) over a communication link and run it in the
>same process context. Please enlighten us.

Actually I don't. It would not really be needed to be able to run compiled C code.

If I can write a program in C interpreting a logic byte code I can write a program in C doing the logic directly. The main differences (from my point of view) it that the former will be a lot easier to change online and the latter
being somewhat faster. Changing the logic in the second way can be done by stopping the control application, recompile and start it again, this will not suit everybody but some people may use it because of the little additional extra
speed. The door is open!

I would prefere the first solution myself, but I am not the entire (or even a major part) of the target for this project.


/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 Sat Jan 22 15:04:28 2000 wrote...
>
>Actually I don't. It would not really be needed to be able to run compiled C code.
>
>If I can write a program in C interpreting a logic byte code
>I can write a program in C doing the logic directly.
>The main differences (from my point of view) it that the
>former will be a lot easier to change online and the latter
>being somewhat faster. Changing the logic in the second way
>can be done by stopping the control application, recompile
>and start it again, this will not suit everybody but some
>people may use it because of the little additional extra speed. The door is open!
>
>I would prefere the first solution myself, but I am not the
>entire (or even a major part) of the target for this project.

Stopping the execution of a PLC in many applications is totally unacceptable. There are basically 3 classes of PLC application from this
point of view:

1. Continuo (process plant, power generation etc0. We might be able to shut it down, say once every 18 months or so.

2. Semi continuous (auto assembly line) can shutdown on weekends or maybe 3rd shift.

3. machine control. cab stop for short periods of these at the completion of a cycle.

I presently have mostly class 1 and 2 applications. I do work pretty hard on the class one apps to provide some sort of manual fail over
backup (free standing PID CMA stations), and motor start, and motor stop outputs, with local pushbuttons). This allows me to put the PLC in
program to create new data table files (something I want to be able to do online for ours) for short periods of time.

Obviously these are not hard and fast classes, but the lines between them blur. For instance my paper machines run 24x7 with a shutdown about every 3 weeks, so they fall somewhere between class 2 and 1.


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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat Jan 22 06:21:08 2000 Dave West wrote...
>
>I don't see how this differs from any othe pure logic form (eg. ladder),
>it's just a bunch of "if then else" statements or
>contact---contact---coil. Just a prettier way of displaying same.
>
>I will therefore assume a massive over simplification in your explanation
>as you seem very strongly convinced that it will be better run by a special engine. <

It helps to know how this is implemented. In an AB controller, each of those boxes is a program file, in addition to what he showed, there are transition steps. AS a result only a few of the total number of program files are being executed at any one time, instead of scanning all of them. You can achieve the same thing without SFC, but properly structuring your program.


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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat Jan 22 04:47:22 2000 Dave West wrote...
>
>Something we all seem to have missed about compiling to native machine
>language is it is non portable. The programming tool needs to know what
>kind of processor the PLC is running on and therefore should be
>disregarded entirely. Well for the immediate future anyway.

A very good point. I for one want to be able to run this on X86, and PA-RISC.
--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri, Jan 21, 2000 at 03:23:37PM +0000, Dave West wrote:
> 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 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.

- the data segment shouldn't be executable, but I have a suspicion that it is (judging by comments in src/linux/mm/mmap.c)
- shared libraries can be loaded on-demand (or we can call mmap ourselves)
- full blown executable, as you write

But you are right that this is a serious problem. On-line changes of compiled programs are decidedly non-trivial (unless you go for the simple "kill it at the end of a scan and let the new one rip").

However, it may be acceptable as a trade-off: either you get on-line changes, or the efficiency of machine-native compilation, but not both. (But that would mean implementing both.)

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
 
<clip>
> >Hmm, You seem to know a way of getting a userland process to load data
> >(machine executable binary) over a communication link and run it in the
> >same process context. Please enlighten us.
>
> Actually I don't. It would not really be needed to be able to run compiled C code.
>
> If I can write a program in C interpreting a logic byte code
> I can write a program in C doing the logic directly.
> The main differences (from my point of view) it that the
> former will be a lot easier to change online and the latter
> being somewhat faster. Changing the logic in the second way
> can be done by stopping the control application, recompile
> and start it again, this will not suit everybody but some
> people may use it because of the little additional extra speed. The door is open!

Hmm, well, erm, Ok. I suppose it's reasonable if not very elegant.


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 Sun, 23 Jan 2000, Jiri Baum wrote:

> On Fri, Jan 21, 2000 at 03:23:37PM +0000, Dave West wrote:
> > 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 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.
>
> - the data segment shouldn't be executable, but I have a suspicion
> that it is (judging by comments in src/linux/mm/mmap.c)
> - shared libraries can be loaded on-demand (or we can call mmap ourselves)
> - full blown executable, as you write
>
> But you are right that this is a serious problem. On-line changes of
> compiled programs are decidedly non-trivial (unless you go for the simple
> "kill it at the end of a scan and let the new one rip").
>
> However, it may be acceptable as a trade-off: either you get on-line
> changes, or the efficiency of machine-native compilation, but not both.
> (But that would mean implementing both.)

Doesn't bear thinking about yet 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
 
Top