# Editorial help

D

#### Dan Pierson

A magazine editor in our field (sorry, I can't remember which mag) asked us for a picture of open source control. After some discussion, a sort of architectural block diagram of what we've been planning on this list seemed like the most useful response.

Would anyone like to look at http://puffinplc.org/plc_pic1.html and comment
on it? Is it reasonable for a pretty non-technical magazine article? Would it be useful on the site as something to orient newcommers? Is there something major we've missed?

Dan Pierson, <control.com>

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

P

#### Phil Covington

Hi Dan,

This would definitely be something useful to include on the site. I envisioned that the I/O drivers and the Logic Engines/UI would interact with shared memory though a manager interface that would arbitrate the virtual (shared) memory to device I/O translation.

Logic Engine --> Memory Manager <--IO Drivers
|
Shared Memory

Does your diagram imply that I/O drivers and the Logic Engine have direct access to shared memory?

Regards,

Phil Covington

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

P

#### Phil Covington

My diagram below may not show up as I intended :-O

I intended for the Shared Memory to be connected to and placed below the Memory Manager... So that the drivers and LE/UI only accesses Shared Memory through the Memory Manager... Oh well...

Phil Covington

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

D

#### Dan Pierson

The diagram was meant to show the Logic Engines and Input and Output manager tasks talking to shared memory and the IO drivers talking the Input and Output managers.

I must have missed the idea of a separate memory manager. At first thought a memory manager library would be reasonable but irrelevant to the diagram which is at higher level. A separate memory manager task smells of bottleneck to me, but maybe I'm missing something.

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

J

#### Jiri Baum

Phil Covington:
> I envisioned that the I/O drivers and the Logic Engines/UI would interact
> with shared memory though a manager interface that would arbitrate the
> virtual (shared) memory to device I/O translation.

I think the box labelled shared memory' includes both the manager and the memory itself... It's a box diagram: it doesn't say *how* the parts relate
to one another, just whether or not they do.

> Logic Engine --> Memory Manager <--IO Drivers
> |
> Shared Memory
[fixed spacing in your diagram - should show up better to most people]

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

J

#### Jiri Baum

Dan Pierson:
> Would anyone like to look at http://puffinplc.org/plc_pic1.html and
> comment on it? Is it reasonable for a pretty non-technical magazine
> article? Would it be useful on the site as something to orient
> newcommers? Is there something major we've missed?

What do the Input and Output tasks do? I've always visualised it without them, like this
http://www.onthe.net.au/~baum/jiri/LinuxPLC2-jiri.gif

Calling the drivers "digital I/O" and "analog I/O" is a bit misleading; I've always pictured them as being "Y&Z driver" and so on, but I guess for a simplified diagram it's reasonable. Similarly for additional bus drivers, web servers, logging tools and the kitchen sink.

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

J

#### Jiri Baum

Dan Pierson:
> I must have missed the idea of a separate memory manager. At first
> thought a memory manager library would be reasonable but irrelevant to
> the diagram which is at higher level. A separate memory manager task
> smells of bottleneck to me, but maybe I'm missing something.

As I see it, the shared memory manager' refers to two things:

- a library for accessing the shared memory in a uniform, safe manner, and
- a task providing miscellaneous services related to the shared memory, including putting it up at start and taking it down at the end, access control information, etc.

Note that if the library is a shared library, there'll only be one copy of it in memory, mapped into the execution spaces of all the other tasks.

As you note, though: all this is irrelevant to the diagram which is at a higher level.

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

C

#### Curt Wuollet

Hi all

There will have to be some task responsible for translating the reads and writes to and from a char driver, for example, to the memory map. It will have to know how to deal with all the various types of I/O which might be as diverse as user space networking drivers or a 8255 kernel module. Traditional Linux drivers provide mechanism but no policy. I see the need for an I/O task to handle policy. In the original concept the engines on either side of the memory map would be seperate, synchronizing through the map. That way the logic solver can be modular and need only know how to deal with the map. It sounds like we still don't agree on how this things gonna work. I never did get the purpose of the memory manager, maybe that's where all the detail of dealing with physical I/O was gonna go. I see two main processes, one on either side of the mmap. All the nastiness would be in the I/O task and the solver/UI side would be clean. That's what I'm coding for. I would entertain the idea of a subtask for each I/O driver, but that has some ugly aspects. How were you thinking the thing would work?

cww

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

J

#### Jiri Baum

Curt Wuollet:
> There will have to be some task responsible for translating the reads and
> writes to and from a char driver, for example, to the memory map.

That's OK. I was thinking linuxPLC-native drivers, which don't need any such translation: they just know' the input and write it to the shared memory (or read an output from the shared memory and make it so).

> It will have to know how to deal with all the various types of I/O which
> might be as diverse as user space networking drivers or a 8255 kernel
> module.

I'd favour separate tasks for separate drivers, for simplicity's sake.

Much easier to write a dedicated 8255 driver than to write a combined, do-everything behemoth. (Which is not to say that there won't eventually be a shared library to help all the drivers do their stuff.)

> I never did get the purpose of the memory manager, maybe that's where all
> the detail of dealing with physical I/O was gonna go.

Once it crystalizes, the memory manager will probably be doing very little; some init, some closedown, a few of miscellaneous functions; and there'll be a library to access the shared memory.

> I see two main processes, one on either side of the mmap. All the
> nastiness would be in the I/O task and the solver/UI side would be clean.
> That's what I'm coding for.

Hopefully, all the sides would be clean

As clean as possible, anyway. The solver/UI side cleanly interfaces to the SMM. Each I/O driver cleanly interfaces to the SMM. And so on.

> I would entertain the idea of a subtask for each I/O driver, but that has
> some ugly aspects. How were you thinking the thing would work?

What ugly aspects were you thinking of? Because a subtask for each I/O driver was exactly what I was thinking... (I'd love to know if there's
something I missed.)

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

C

#### Curt Wuollet

Jiri Baum wrote:

> Curt Wuollet:
> > There will have to be some task responsible for translating the reads and
> > writes to and from a char driver, for example, to the memory map.
>
> That's OK. I was thinking linuxPLC-native drivers, which don't need any
> such translation: they just know' the input and write it to the shared
> memory (or read an output from the shared memory and make it so).

The reasons I see a go-between for the drivers are that it allows us to use exixting drivers and others to use our drivers for other purposes. In any case the init code and setup for counters, latches, etc. would want ioctl's to the register level. Bear in mind that we may have to use binary only standard drivers in some cases. With some proprietary I/O schemes that's the best
we can hope for. Last, and this is a biggie, the IO task should be in user space and many drivers will need to be in kernel space for interrupts etc. It's the *nix way of doing things. I started thinking the other way too.

> > It will have to know how to deal with all the various types of I/O which
> > might be as diverse as user space networking drivers or a 8255 kernel
> > module.
>
> I'd favour separate tasks for separate drivers, for simplicity's sake.

We can do it that way, or we could have a library that we add to incrementally. We need something in overall control to handle the vast differences in speed between say, modbus and an ISA card. And to account for the fact that it's magnitudes easier to use the existing facilities for TCP and serial comms. I have been thinking of using a scan divisor so fast I/O is hit every scan and slow I/O every nth scan to allow for the speed difference. It still doesn't help latency and the case of an equation that uses a fast input and a slow input. But, I think it would be better than having the entire scan wait for the slowest IO type. What do you think?

> Much easier to write a dedicated 8255 driver than to write a combined,
> do-everything behemoth. (Which is not to say that there won't eventually be
> a shared library to help all the drivers do their stuff.)
>
> > I never did get the purpose of the memory manager, maybe that's where all
> > the detail of dealing with physical I/O was gonna go.
>
> Once it crystalizes, the memory manager will probably be doing very little;
> some init, some closedown, a few of miscellaneous functions; and there'll
> be a library to access the shared memory.
>
> > I see two main processes, one on either side of the mmap. All the
> > nastiness would be in the I/O task and the solver/UI side would be clean.
> > That's what I'm coding for.
>
> Hopefully, all the sides would be clean

Clean in this case would be architecture independent. I'm still hoping for enough modularity to scale from embedded platforms to at least uniproc Alpha machines. Spinlocks and such would raise Hell with determinism.

> As clean as possible, anyway. The solver/UI side cleanly interfaces to the
> SMM. Each I/O driver cleanly interfaces to the SMM. And so on.
>
> > I would entertain the idea of a subtask for each I/O driver, but that has
> > some ugly aspects. How were you thinking the thing would work?
>
> What ugly aspects were you thinking of? Because a subtask for each I/O
> driver was exactly what I was thinking... (I'd love to know if there's
> something I missed.)

Init, mapping, and map coherence come to mind. That's why I was thinking about a scan divisor scheme as it allows us to be synchronous. Hey List! how do the commercial PLC guys handle this? If you want predictable output ordering for motion control, etc,. we need some syncronism. I was thinking we could let the solver ignore equates that are waiting on slow I/O. I'm very open to other suggestions on maintaining PC speed while allowing very diverse I/O. If we do completely seperate tasks, theres a lot of IPC to keeping coherent. I don't know, maybe PLC's simply ignore timing differences and hope for the best or chain everything (slow).

cww

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

C

#### Curt Wuollet

Oh, and please remember I'm really starting with a clean sheet of paper. I am not familiar with PLC internals and that could be good or bad depending on your point of view and how dumb I am. I don't want my DMA'd micro second response local I/O to always wait on a 2400 baud serial OIU or such. Please bear with me.

cww

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

J

#### Johan Bengtsson

As I see it the I/O driver tasks is exaclty what you are talking about in this case. (at least if I understood you correctly) Each I/O driver knows how to access the shared memory manager, what I/O points to process (by some kind of configuration of course)

If the particular I/O dirver task needs a more general Linux driver (TCP/IP, general network, 8255, COM-port, whatever) it may do so, if it can handle everything by itself well ok then.

As I see it there is no "sides" at all of the memory manager, all processes I/O-drivers as well as logic solvers and so on simply reads some points in the shared memory and sets others. To the memory manager an I/O process and a logic solver is equal.

The talk about inputs and outputs are not strictly interesting to the memory manager but just a convention to make it easier for us stupid
humans *grin*.

/Johan Bengtsson

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

R

#### Rob Martin

Curt,
Do you have StarOffice? I haven't tried opening the file in StarOffice (as I'm mostly tied to NT at work) but it may work. If you don't have it, I can recommend it... if for no other reason than that the browser is more stable than Netscape

Rob Martin

----- Original Message -----
From: Curt Wuollet <[email protected]>

> No.
>
> Jack Gallagher wrote:
>
> > Will it help if I re-send it as a Rich Text Format document?

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

C

#### Curt Wuollet

Hi All

Since we're drawing pictures. Here's what I working from. We should start a new thread. It sounds like the blind men describing the elephant. Maybe a pictorial is a simple way to get some convergence. Sure would be handy to
have a common format we could see and mark up. I'm using Xfig and exporting to gif. Is there anything common to Linux and winXX?

Curt W.

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

J

#### Jiri Baum

Looks OK from first viewing. I'll make a detailed response later this weekend.

> We should start a new thread. It sounds like the blind men describing the
> elephant. Maybe a pictorial is a simple way to get some convergence.

Very true. I'll dig up some of the old `architecture' posts and draw them as I see them. (For instance, I'd draw the SMM as a round, multi-sided thing.)

> Sure would be handy to have a common format we could see and mark up. I'm
> using Xfig and exporting to gif. Is there anything common to Linux and
> winXX?

I think xfig is too large for my screen :-(

Probably best to stick with GIFs; everyone can see them. We just have to be careful not to overrun people's mailboxes (I'll post mine on the web, since it's so easy for me).

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

K

#### Ken Crater

>Probably best to stick with GIFs; everyone
>can see them. We just have to be
>careful not to overrun people's mailboxes
>(I'll post mine on the web, since it's so easy
>for me).

We can certainly post anything like this to the project website, too. It's a good use for the site and, as this discussion shows, richer forms of presentation tend to communicate ideas better. If anyone wants to have such material posted, send it along to me and I'll put it on the site.

Ultimately, we hope to have a provision for self-posting of such material.

Ken
--
Ken Crater
[email protected]

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