Ok, we have a map, it's not a perfect map, it's certainly not complete, but it will do to lead into the questions that choked the mail server earlier. All the map does is stores enough values to deal with a fairly large machine or cell. I took the liberty of making a couple of design decisions which are open for debate. I'm gonna attach the map because this editor sucks for
code and the quoting and back and forth destroys the formatting. I believe most readers will let you see this inline, but MS users will have to let me know.

The data map for this phase will store only dynamic data. (The Data);
The analog values for now will appear in the map scaled, folded, spindled and mutilated so I can write: if(algi[37] < 13.75) ......

Proposed: Since the scaling data, assignment of physical I/O to map index, which inputs are counters, etc. is ~static and tied to the
hardware, this should belong to and be maintained by the I/O system. It should be both on disk or NVRAM and an in core table for those apps which need to know and for use by the drivers. This table would be created with a setup utility that knows about the physical hardware and and also creates any tables or data needed by the hardware driver on init.

regards

cww

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

 

Curt Wuollet:
> Ok, we have a map, it's not a perfect map, it's certainly not complete, but
> it will do to lead into the questions that choked the mail server earlier.
...
> struct map
> {
> unsigned short ins[256];
> unsigned short outs[256];

I thought there was agreement long ago that there ain't no such thing as inputs and outputs?

In the map, all points are created equal...


(See late January / early February in the archives.)


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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

 

Jiri Baum wrote:

> Curt Wuollet:
> > Ok, we have a map, it's not a perfect map, it's certainly not complete, but
> > it will do to lead into the questions that choked the mail server earlier.
> ...
> > struct map
> > {
> > unsigned short ins[256];
> > unsigned short outs[256];
>
> I thought there was agreement long ago that there ain't no such thing as
> inputs and outputs?
>
> In the map, all points are created equal...

Fair enough, we were looking at some fairly complex schemes at the time. My thinking here is that we can have simple parallel arrays for
attributes that differ between inputs and outputs. For example, counters. Does it cause you a problem for right now? I'll take a look.
That might be for pass 2.

I looked at your code to allocate a map in SysV shmem. Right now, for simplicty I've been talking about user space arrays but we should be able to map in user, shmem, or outside shared memory mmap()ed into user space eventually, to accomodate realtime Looks good. to me. probably in pass 2. I want to get a simple case described completely
and perhaps even coded so we can get some concepts nailed down without descending into the minute detail that stalled things.


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

 

I think that we should keep the initial programming goal as simple as possible. A few generic structs, one or more I/O drivers (a file I/O driver or a simulated I/O driver would be useful), and a simple logic engine. We can then build on a working model. I think that progress has been slower than expected because we started out trying to make the LPLC do too much..

I'll try to get more involved with coding, as I seem to have more time these days.

Bill Sturm
Livonia, Michigan

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

 

I am using MS Outlook Express and I could read the map structure pretty well inside the reader.

Regards

----- Mensaje original -----
De: Curt Wuollet <[email protected]>
Para: <[email protected]>
Enviado: jueves, 04 de mayo de 2000 19:53
Asunto: LinuxPLC: Step 2


....
> most readers will let you see this inline, but MS users will have to let
me
> know.
.....



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

 

Jiri Baum:
> > I thought there was agreement long ago that there ain't no such thing
> > as inputs and outputs?

> > In the map, all points are created equal...

Curt Wuollet:
> Fair enough, we were looking at some fairly complex schemes at the time.
> My thinking here is that we can have simple parallel arrays for
> attributes that differ between inputs and outputs. For example, counters.
> Does it cause you a problem for right now? I'll take a look. That might
> be for pass 2.

Well, it means that all the code must be in one process. The idea behind the shmem was that different I/O drivers and the logic engine would all be in separate processes, and thus wouldn't trip over one another.

Separate processes also means they run concurrently, so a slow I/O can plod along while the logic engine and any fast I/O run along.

> I looked at your code to allocate a map in SysV shmem. Right now, for
> simplicty I've been talking about user space arrays but we should be able
> to map in user, shmem, or outside shared memory mmap()ed into user space
> eventually, to accomodate realtime Looks good. to me. probably in pass
> 2.

Since the SMM code is quite advanced now, I guess I don't see the point of coding another structure... And I'm hoping that the API, as it stands, is simple enough (I don't see any way of simplifying it).

(Note: the shmem may or may not be good for realtime, but that's not its point - the point is that it allows the various modules to be in separate processes, thus simplifying things.)

> I want to get a simple case described completely and perhaps even coded
> so we can get some concepts nailed down. without descending into the
> minute detail that stalled things.

Actually, what stalled things was that first one person volunteered to do the SMM and didn't get around to it, and then I volunteered to do the SMM
and didn't get around to it until now - sorry about that.

However, the API now exists, and the implementation is almost there. My next coding session ought to see it finished. With any luck, this time next week it'll be ready.

Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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