Today is...
Friday, September 22, 2017
Welcome to the Modbus Community, about
the world's leading automation protocol.
Editorial help
A magazine editor in our field (sorry, I can't remember which mag) asked us for a picture of open source control.
By Dan Pierson on 30 March, 2000 - 5:47 pm

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 31 March, 2000 - 9:37 am

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 31 March, 2000 - 9:43 am

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Dan Pierson on 31 March, 2000 - 12:07 pm

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jiri Baum on 3 April, 2000 - 11:43 am

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 <jiri@baum.com.au>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 3 April, 2000 - 11:47 am

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jiri Baum on 3 April, 2000 - 12:55 pm

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 <jiri@baum.com.au>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 3 April, 2000 - 1:00 pm

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 3 April, 2000 - 1:04 pm

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jocelyn Boily on 4 April, 2000 - 11:34 am

Hey List!

> > how do the commercial PLC guys handle this? If you want predictable
> > output ordering for motion control, etc,. we need some synchronism. Iwas
> > thinking we could let the solver ignore equates that are waiting on slowI/O.
> > I'm very open to other suggestions on maintaining PC speed whileallowing
> > very diverse I/O. If we do completely separate tasks, there's a lot ofIPC to
> > keeping coherent. I don't know, maybe PLC's simply ignore timing
> > differences and hope for the best or chain everything (slow).

There is many different way to approach the problem, and commercial PLC usually have option.
Usually, ALL the Inputs are scanned first. Then the logic is Executed using and Image Register in memory (not going directly to the I/O, but merely
looking at what the were the last time they have been updated). And then the Outputs are written to the Hardwire I/O, strictly copying the Output
registers to the Output Drivers. Some PLC would also handle the communication in a synchronously to the scan.

Some function Are allowing a Immediate Access to some of the I/O (Only the one that the processor has a fast access to), to allow a controlled sequence or more then one I/O scan per logic scan. These functions are seldom required, but I had to use them often to solve some particular problems over the past 20 or so years.

Most of the time the application do not require a predictable sequence of the inputs. You usually have logic that sound like this:if PB1 is PRESSED
and if MotorPermissive1 is ONand if Overload1 is OKthen Start Motor1 The PB1 will be pressed by the operator for at least 1/2 a second, If the
I/O are updated within that time, the logic will work. It does not matter if on input or the other happen first. Actually, creating a logic that requires a certain timing is bad design, after all you interface with mechanical hardware that work within second timeframe while the logic can act in uSeconds. There is usually a way to make the logic work perfectly without to worry about timing.

However, It is sometime not possible and we then have to be careful how the various rungs are entered and executed. Most PLC (but not all!) allow you to control the sequence of the logic execution. Timing problems are often at the heart of costly project start-ups and are not always understood be the programmer, technician or engineers that work on the projects.

Sometime, I have seen logic that work perfectly by sheer luck of the draw, with logic entered at random by an unwise programmer. I also seen machines work 10 time slower for these same random timing reasons. Too often the technician would not care about the logic timing, in this is because it work OK most of the time without carring.

Mr Jocelyn Boily, P. Eng.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 4 April, 2000 - 10:47 am

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

----------------------------------------
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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jack Gallagher on 4 April, 2000 - 11:14 am

Attached is a UML diagram of what I think Phil is trying to show.



_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 4 April, 2000 - 11:16 am

Hi all

Do I have any way to look at this on my linux box?

cww


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jack Gallagher on 4 April, 2000 - 11:19 am

Curt,

Will it help if I re-send it as a Rich Text Format document?


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Rob Martin on 4 April, 2000 - 11:21 am

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 <wideopen@ecenet.com>

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


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 31 March, 2000 - 9:45 am

Looks OK to me

cww


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jiri Baum on 31 March, 2000 - 8:45 pm

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 <jiri@baum.com.au>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jiri Baum on 31 March, 2000 - 9:02 pm

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.

So just that one comment about the Input and Output tasks.


Jiri
--
Jiri Baum <jiri@baum.com.au>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 4 April, 2000 - 11:24 am

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jiri Baum on 4 April, 2000 - 11:26 am

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 <jiri@baum.com.au>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Ken Crater on 4 April, 2000 - 11:28 am

>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
ken@control.com

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc