Real Time? Was: Shared memory / persistence / io polarity

On Fri Jan 21 04:34:41 2000 Curt Wuollet wrote...
>
>Yes, I did some more reading last night. As often happens it raised more
>questions than answers. I need to study it more but, a nagging concern
>was raised. We are wanting to schedule tasks that take appreciable time
>to complete. We will probably have several. IF we switch to RT mode, will
>we ever get switched back to run "normal" tasks. If all resources are
>devoted to RT, in our case, that won't neccesarily speed things up.
>Fieldbus IO, for example will take it's sweet time regardless of how
>many machine cycles we make available. IF these overlap due to external
>causes, we may not leave RT mode. Slow serial I/O is not well suited
>for this model. We may need an interesting mix of RT tasks for fast IO
>and interrupt driven processes for the rest. The interaction should
>prove interesting. Traditionally this is met with a top end that
>executes quickly and a bottom end that waits for the result. It
>would help to get an idea of the turn around time of the various type
>of I/O supported. Does anybody know enough about it yet to put these
>concerns to rest?

Right, that's why the I/O scanners do not need to run as real time processes.

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

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

phil wilshire

Hi,
This is where I can really help.

The RTAI realtime modifications are just what you want for the PLC system.
http://www.rtai.org

The LXRT system allows userlevel control and communications with real time modules.

You can have generic realtime tasks waiting to execute lists of instructions.

These lists, in shared memory, and the tasks running them can all be manipulated from user tasks.

The realtime tasks are all kernel modules and can be loaded / unloaded at will.
This makes for a really dynamic system.
Kernel changes and execution list changes can all be done on the fly...


If you add the low latency patches into the kernel then the max kernel latency is under 3mSecs. The 2.4 kernels look like having this performance anyway.


What I have used in the past , and would advocate using again, is a simple function code interpreter. I have simulated a GE Distributed Micro Controller running a complicated
instruction sequence. This runs in interpreted mode in under 1mS . The original DMC took over
100mS to run the same code even though it was coded in assembler. ( 286 cpu I know )


Just ready to dive in and help here.

Phil

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri Jan 21 11:26:31 2000 phil wilshire wrote...
>
>Hi,
>This is where I can really help.
>
>The RTAI realtime modifications are just what you want for the PLC
>system.
>http://www.rtai.org

Interesting, I will go look at this.
>
>What I have used in the past , and would advocate using again, is a
>simple function code interpreter.
>I have simulated a GE Distributed Micro Controller running a complicated
>instruction sequence.
>This runs in interpreted mode in under 1mS . The original DMC took over
>100mS to run the same code even though it was coded in assembler. ( 286
>cpu I know )

This is great news.

>Just ready to dive in and help here.

Yes, it is starting to be time to code. I think someone needs to write up a summary of what we have concluded, and what are still open issues, so that we can generate a design spec. This will allow us to start coding.

I can do this, but maybe someone else should, as i seem to be becoming a bit controversial :)

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

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

Johan Bengtsson

What?
They are as important to run in real time as the controlling engine. It makes no sense at all to solve the logic at regular intervals it no data is exchanged with the rest of the world.

All I/O task do not need real time, but whenever the controlling engine do the I/O need it too. (and the other way around).


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

On Fri Jan 21 04:34:41 2000 Curt Wuollet wrote...
>
>Yes, I did some more reading last night. As often happens it raised more
>questions than answers. I need to study it more but, a nagging concern
>was raised. We are wanting to schedule tasks that take appreciable time
>to complete. We will probably have several. IF we switch to RT mode, will
>we ever get switched back to run "normal" tasks. If all resources are
>devoted to RT, in our case, that won't neccesarily speed things up.
>Fieldbus IO, for example will take it's sweet time regardless of how
>many machine cycles we make available. IF these overlap due to external
>causes, we may not leave RT mode. Slow serial I/O is not well suited
>for this model. We may need an interesting mix of RT tasks for fast IO
>and interrupt driven processes for the rest. The interaction should
>prove interesting. Traditionally this is met with a top end that
>executes quickly and a bottom end that waits for the result. It
>would help to get an idea of the turn around time of the various type
>of I/O supported. Does anybody know enough about it yet to put these
>concerns to rest?

Right, that's why the I/O scanners do not need to run as real time
processes.


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

Johan Bengtsson

I have some experience in this, we are supporting
I/O thru I/O-cards plugged into the computer (based on 8255) toghether with some analog parts. A quite fast solution. The turnaround time is mostly depending on the controlling engine in this case. We do also support Profibus DB using the standard serial port on the PC. Top speed with the conversion cable is 19200 and the drivers we got with it do not support "Sleep until response" in a good way. so we have to sleep
a pre set time and that makes the I/O being the slow part. We end up around 50-100ms turnaround time and that is definitively getting near of beeing too much for some of even our applications.

If the timings are inproperly set up the result can quickly get worse but never worse than one scan cycle in the controlling engine + 2 I/O scan times (one for input and one for output)


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

Yes, I did some more reading last night. As often happens it raised more questions than answers. I need to study it more but, a nagging concern
was raised. We are wanting to schedule tasks that take appreciable time to complete. We will probably have several. IF we switch to RT mode, will we ever get switched back to run "normal" tasks. If all resources are devoted to RT, in our case, that won't neccesarily speed things up.
Fieldbus IO, for example will take it's sweet time regardless of how many machine cycles we make available. IF these overlap due to external
causes, we may not leave RT mode. Slow serial I/O is not well suited for this model. We may need an interesting mix of RT tasks for fast IO and interrupt driven processes for the rest. The interaction should prove interesting. Traditionally this is met with a top end that
executes quickly and a bottom end that waits for the result. It would help to get an idea of the turn around time of the various type of I/O supported. Does anybody know enough about it yet to put these concerns to rest?

Curt W
Wide Open Technologies

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat Jan 22 00:32:44 2000 wrote...
>
>What?
>They are as important to run in real time as the controlling
>engine. It makes no sense at all to solve the logic at regular
>intervals it no data is exchanged with the rest of the world.
>
>All I/O task do not need real time, but whenever the controlling
>engine do the I/O need it too. (and the other way around).
>

if reading in the inputs for a given piece of hardware takes 3 seconds (not unreasonable for some devices). Then it does not need to be run in real time.

I think you misunderstand real time in this context. Substitute "deterministic" and see if things don;t get clearer.

--
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 00:19:07 2000 wrote...
>
>I have some experience in this, we are supporting
>I/O thru I/O-cards plugged into the computer (based on 8255) toghether with some analog parts. A quite fast solution. The turnaround time is mostly depending on the controlling engine in this case. We do also support Profibus DB using the standard serial port on the PC. Top speed with the conversion cable is 19200 and the drivers we got with it do not support
>"Sleep until response" in a good way. so we have to sleep
>a pre set time and that makes the I/O being the slow part.
>We end up around 50-100ms turnaround time and that is
>definitively getting near of beeing too much for some of even our applications. <

This is really not the type of I/O that would be used by a PLC.

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

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

Johan Bengtsson

You won't get it any faster than the plugged in I/O card whatever you do. Profibus will certanly be connected, most often not to the serial port, but anyway. This was meant as an somewhat short
example about what could happen when some part is slow.

Btw. what is really wrong with having I/O:s based on a 8255? or is it only the com-port that is your concern?


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

On Sat Jan 22 00:19:07 2000 wrote...
>
>I have some experience in this, we are supporting
>I/O thru I/O-cards plugged into the computer (based on
>8255) toghether with some analog parts. A quite fast
>solution. The turnaround time is mostly depending
>on the controlling engine in this case.
>We do also support Profibus DB using the standard serial
>port on the PC. Top speed with the conversion cable is 19200 and the drivers we got with it do not support "Sleep until response" in a good way. so we have to sleep a pre set time and that makes the I/O being the slow part. We end up around 50-100ms turnaround time and that is definitively getting near of beeing too much for some of
>even our applications.
>

This is really not the type of I/O that would be used by a PLC.

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

Johan Bengtsson

My point is: if the I/O:s don't need real time the controlling engine won't need it either.


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

On Sat Jan 22 00:32:44 2000 Johan Bengtsson wrote...
>
>What?
>They are as important to run in real time as the controlling engine. It makes no sense at all to solve the logic at regular intervals it no data is exchanged with the rest of the world.
>
>All I/O task do not need real time, but whenever the controlling engine do the I/O need it too (and the other way around).
>

if reading in the inputs for a given piece of hardware takes 3 seconds (not unreasonable for some devices). Then it does not need to be run in real time.

I think you misunderstand real time in this context. Substitute "deterministic" and see if things don;t get clearer.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat Jan 22 01:38:55 2000 wrote...
>
>My point is: if the I/O:s don't need real time the controlling
>engine won't need it either.
>

Oh well you and I agree on that. However it is not all that clear cut. Some I/O can be rally fast, for example AB RIO can be well less than 10 msec update time for a single rack.

However I have now come to the conclusion that we do not need real time (as in deterministic) for the base project anyway.

So I guess we agree on this :)

Oh BTW thanks very much for changing to non MIME format. It makes my life much easier, Thanks very much.

--
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 01:36:35 2000 wrote...
>
>You won't get it any faster than the plugged in I/O card whatever you do.
>Profibus will certanly be connected, most often not to the
>serial port, but anyway. This was ment as an somewhat short
>example about what could happen when some part is slow.
>
>Btw. what is really wrong with having I/O:s based on a 8255?
>or is it only the com-port that is your concern?

The I/O used by PLC's is industrially hardened. For example it typically has an isolation level of 1500V, ad the outputs are rated for several amps . It's also easy to wire for the electricians. And works at typically 120VAC levels. Often each point has to be individually isolated.

See where I am coming from now?

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

8255 (along with other circuits) is suitable for making inputs and outputs interfaced by a microprocessor. This circuit is fairly standard and easily interfaced from a PC.

The thing you need is nothing you can connect directly to the bus of the PC anyway, is it?

Here it goes:
you have the PC bus
to that you connect some interface circuits
to them you connect optocouplers if you want that
to them you connect relays or transistors if you want that

And so on....

The point is: one way to make fast I/O connected to a PC with exactly the prperties you want, is to use a 8255 connected to other circuits (like optocouplers and transistors or relays). Most other forms of I/O will be slower no matter what you do.


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

On Sat Jan 22 01:36:35 2000 wrote...
>
>You won't get it any faster than the plugged in I/O card whatever you do.
>Profibus will certanly be connected, most often not to the serial port, but anyway. This was ment as an somewhat short
>example about what could happen when some part is slow.
>
>Btw. what is really wrong with having I/O:s based on a 8255?
>or is it only the com-port that is your concern?

The I/O used by PLC's is industrially hardened. For example it typically has an isolation level of 1500V, ad the outputs are rated for several amps . It's also easy to wire for the electricians. And works at typically 120VAC levels. Often each point has to be individually isolated.

See where I am coming from now?

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat, 22 Jan 2000 [email protected] wrote:

> 8255 (along with other circuits) is suitable for making inputs
> and outputs interfaced by a microprocessor. This circuit is
> fairly standard and easily interfaced from a PC.
>
> The thing you need is nothing you can connect directly to the bus of the PC anyway, is it?
>
> Here it goes:
> you have the PC bus
> to that you connect some interface circuits
> to them you connect optocouplers if you want that
> to them you connect relays or transistors if you want that
>
> And so on....
>
> The point is: one way to make fast I/O connected to a PC with
> exactly the prperties you want, is to use a 8255 connected to
> oter circuits (like optocouplers and transistors or relays)
> Most other forms of I/O will be slower no matter what you do.

Hehe, well put.

Stan, I take it you have never designed any I/O hardware.

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 Jan 22 13:11:04 2000 wrote...
>
>8255 (along with other circuits) is suitable for making inputs
>and outputs interfaced by a microprocessor. This circuit is
>fairly standard and easily interfaced from a PC.
>
>The thing you need is nothing you can connect directly to the
>bus of the PC anyway, is it?
>
>Here it goes:
>you have the PC bus
>to that you connect some interface circuits
>to them you connect optocouplers if you want that
>to them you connect relays or transistors if you want that
>
>And so on....
>
>The point is: one way to make fast I/O connected to a PC with
>exactly the prperties you want, is to use a 8255 connected to
>oter circuits (like optocouplers and transistors or relays)
>Most other forms of I/O will be slower no matter what you do.
>

Yes, but this is not readily accepted in industry. Thee are some SCADA applications that do this, but this project needs to be targeted at a far more robust position than most SCADA systems to really call itself a PLC.

I believe that there are existing Linux based SCADA systems already out there. I don't use SCADA, so I have never really looked into them.

--
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:53:54 2000 Dave West wrote...
>
>Stan, I take it you have never designed any I/O hardware.

That would be correct, and I have no intention of starting now.

One of the things one pays for in the PLC world, is commercially designed, hardened, and supported hardware.

As a matter of fact, it is well known that PLC vendors (such as AB) real income stream comes from the I/O. The probably loose money on the processor.

This is my ray of hope for support for this project, to some limited degree, by major PLC hardware vendors. What they want to do is keep selling I/O hardware. Now there are lots of other reasons for them not to support us (can you say liability, and NIH?), bit if we achieve some
success, then this will be the argument that may sway them in our direction.

Also a lot of PLC I/O hardware has a good bit of on board intelligence, such as analog input modules that can do real time sampling, digital filtering, and scaling. Also motion control modules, and PID execution modules, just to name a few.

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

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

Johan Bengtsson

Ehh, exactly what in my statement is not readily accepted in industry? It is really not that much difference from what you find in the PLC:s anyway.

Sorry, I don't really understand what SCADA have to do with this.

And... I did not give this as the final I/O solution that everyone is going to use. I originally mentioned this as the fastest possible
I/O system for us in the PC, and that was not really the topic either (go back and check) but merely a comparision of something you surely already know but perhaps not everyone of the other people reading this that I/O speed may differ depending on how it is implemented and most important: how it is going to affect control.

/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]]
n Sat Jan 22 13:11:04 2000 wrote...
>
>8255 (along with other circuits) is suitable for making inputs
>and outputs interfaced by a microprocessor. This circuit is
>fairly standard and easily interfaced from a PC.
>
>The thing you need is nothing you can connect directly to the
>bus of the PC anyway, is it?
>
>Here it goes:
>you have the PC bus
>to that you connect some interface circuits
>to them you connect optocouplers if you want that
>to them you connect relays or transistors if you want that
>
>And so on....
>
>The point is: one way to make fast I/O connected to a PC with
>exactly the prperties you want, is to use a 8255 connected to
>oter circuits (like optocouplers and transistors or relays)
>Most other forms of I/O will be slower no matter what you do.
>

Yes, but this is not readily accepted in industry. Thee are some SCADA applications that do this, but this project needs to be targeted at a far more robust position than most SCADA systems to really call itself a PLC. ...<clip>

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat Jan 22 17:32:48 2000 wrote...
>
>Ehh, exactly what in my statement is not readily accepted in
>industry? It is really not that much difference from what you
>find in the PLC:s anyway.

Pretty much all of it :)

PLC's a re _industrial_ devices, they need to survive some pretty tough conditions, and be worked on by some rather brute force types.

>Sorry, I don't really understand what SCADA have to do with this.

SCADA systems, in my experience, tend to have much lighter duty I/O.

>And... I did not give this as the final I/O solution that everyone
>is going to use. I originally mentioned this as the fastest possible
>I/O system for us in the PC, and that was not really the topic
>either (go back and check) but merely a comparision of something you
>surely already know but perhaps not everyone of the other people
>reading this that I/O speed may differ depending on how it is
>implemented and most important: how it is going to affect control.

But if we are going to get, what I consider our target audience, to view us with any credibility, then we need to support industrial I/O from day one.

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

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

Reality time. Directly attached IO cards are the only "native" IO this project has. If you want the best performance, this is what you will be using. No fieldbus, no network, will ever come
close to what you can expect from optimised IO on the bus. Every PLC comes with native IO and this is ours. That said, we should be looking at some. In a sense, Ethernet IO is "native" since networking is a big part of Linux, but, It is very early in it's development and not at all standardized. Use IO boards where you would use IO modules on a standard PLC and you will gain all the same benefits, simplicity, speed, and function.

Almost all use an 8255 or some other uP support chip. We should research the cards that provide isolation, AC, motion control and the other special functions that PLC users expect. We need
this as a base until all the "foreign" protocols are supported.

Curt Wuollet,
Wide Open Technologies


[email protected] wrote:
>
> 8255 (along with other circuits) is suitable for making inputs
> and outputs interfaced by a microprocessor. This circuit is
> fairly standard and easily interfaced from a PC.
>
> The thing you need is nothing you can connect directly to the bus of the PC anyway, is it?
>
> Here it goes:
> you have the PC bus
> to that you connect some interface circuits
> to them you connect optocouplers if you want that to them you connect relays or transistors if you want that
>
> And so on....
>
> The point is: one way to make fast I/O connected to a PC with
> exactly the prperties you want, is to use a 8255 connected to
> oter circuits (like optocouplers and transistors or relays)
> Most other forms of I/O will be slower no matter what you do.

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

Johan Bengtsson

I have never said industrial I/O shouldn't be supported from day one. As a matter of fact I think that is already taken care of. Wasn't that the thing that set of the entire project?

Do you have any idea of what a 8255 is?

Are you sure you don't have them or something similar in your industrila devices I/O rack?

I am quite sure you do have something similar in them :)

This is not something we really don't agree about, (totaly regardless of if you think that or not) but we are actually talking about more or less different parts of the I/O rack and from different points of view.


Let's drop this discussion it does not lead anyware in the current state of the project. We can resume it at a later stage if you want.


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

On Sat Jan 22 17:32:48 2000 wrote...
>
>Ehh, exactly what in my statement is not readily accepted in
>industry? It is really not that much difference from what you find in the PLC:s anyway.

Pretty much all of it :)

PLC's a re _industrial_ devices, they need to survive some pretty tough
conditions, and be worked on by some rather brute force types.
>
>Sorry, I don't really understand what SCADA have to do with this.

SCADA systems, in my experience, tend to have much lighter duty I/O.
...<clip>


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat Jan 22 08:00:32 2000 Curt Wuollet wrote...
>
>Hi All
>
>Reality time. Directly attached IO cards are the only "native"
>IO this project has. If you want the best performance, this is
>what you will be using. No fieldbus, no network, will ever come
>close to what you can expect from optimised IO on the bus.
>Every PLC comes with native IO and this is ours. That said, we
>should be looking at some. In a sense, Ethernet IO is "native"
>since networking is a big part of Linux, but, It is very early
>in it's development and not at all standardized. Use IO boards
>where you would use IO modules on a standard PLC and you will
>gain all the same benefits, simplicity, speed, and function.

AB makes cards that allow a computer (that;s us) to be the I/O scanner for thire RIO. I ension supporting this very early in the project.

Dont' other PLC vendors make such cards?


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


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