New

  • Thread starter Peter Wurmsdobler
  • Start date
P

Thread Starter

Peter Wurmsdobler

Hi,

First, let me introduce myself: Since August 1 I am control.com's open control lab director. Before that I was a PostDoc in France, where I mainly developed a RTLinux based measurement system. This is why I started to organize the real
time linux workshops and co-founded the real time linux foundation,
http://www.realtimelinuxfoundation.org,
a resort for all interested in real time linux variants. The events section will give some information about the upcoming workshop in Milano, Italy.

A few weeks ago I was in Houston at the ISA show and hat the chance to meet Juan Carlos Orozco. He explained me the idea behind matPLC and I
immediately liked it a lot for its modular architecture. In order to go further into detail, I downloaded the white paper article from the cvs doc archive, and I took a look into the code. So I like it even more.

Even though I am not a user for the moment, nor an active matPLC programmer, I would be happy to participate in your project in an area where I can. On the other hand, I would really like to understand the concept more, in more detail and the implications of real time constraints.

best regards,
peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax

_______________________________________________
MAT-devel mailing list
[email protected]

https://lists.sourceforge.net/lists/listinfo/mat-devel
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc


 
M

Mario de Sousa

Peter Wurmsdobler wrote:

> Even though I am not a user for the moment, nor an active matPLC
> programmer,
> I would be happy to participate in your project in an area where I can.

That would be great!

> On
> the other hand, I would really like to understand the concept more, in
> more
> detail and the implications of real time constraints.

How can we help?

Cheers,


Mario.

--
----------------------------------------------------------------------------
Mario J. R. de Sousa
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
MAT-devel mailing list
<EMAIL: PROTECTED>
https://lists.sourceforge.net/lists/listinfo/mat-devel
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Welcome Pete,

The more the merrier.

Regards

cww


--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to
Linux.

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

Peter Wurmsdobler

Mario,

> How can we help?

I did not understand correctly the library implementation and the sychronisation. Are here standard UNIX IPC mechanisms used?

Then there is the real time issue. How did you address the fact that a simple "ls -R /" can preempt the control process for long periods?
How can you guarantee a certain performance and response time in standard Linux, not in the average case, but the worst case.

peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax

_______________________________________________
MAT-devel mailing list
<EMAIL: PROTECTED>
https://lists.sourceforge.net/lists/listinfo/mat-devel

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Mario:
> > How can we help?
Peter:
> I did not understand correctly the library implementation and the
> sychronisation. Are here standard UNIX IPC mechanisms used?

The library is a shared library (.so), as produced by libtool.

All synchronisation is done with SysV semaphores, and SysV shared memory is used for communication. We do not at present have a message passing
mechanism, but it'll probably again be SysV. That said, though, it wouldn't take much work to port it to a different semaphore or shared memory API.

> Then there is the real time issue.

At present, we haven't; however, soft real-time is easily achieved by setting the scheduler policy and static priority (see sched_setscheduler(2) and friends), and perhaps tweaking the scheduler granularity.

Hard real-time is a bit more difficult, but if the recent discussions about RTAI-LXRT are accurate, we can just use that.


Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sf.net

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

Mario de Sousa

Peter Wurmsdobler wrote:

> Mario,
>
> > How can we help?
> I did not understand correctly the library implementation and the
> sychronisation. Are here standard UNIX IPC mechanisms used?

Synchronisation is based on sysV semaphores. I'm not sure we can achieve the same functionality using POSIX sempahores (e.g. is it possible to atomically signal and wait on the same semaphore?).

Timing (scan period) is based on POSIX timers.


> Then there is the real time issue. How did you address the fact that
> a simple "ls -R /" can preempt the control process for long periods?
> How can you guarantee a certain performance and response time in
> standard Linux, not in the average case, but the worst case.

We have not addressed these issues yet. As you certainly know, it is not possible to give these QoS guarantees using standard Linux.

We prefer to address the issues one at the time. If we were to wait for a general architecture that took all this into acount, we would never
get any code done.

It seems the time has come to start addressing them... ;-)

Cheers,

Mario.


----------------------------------------------------------------------------
Mario J. R. de Sousa
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
MAT-devel mailing list
<EMAIL: PROTECTED>
https://lists.sourceforge.net/lists/listinfo/mat-devel_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc


 
P

Peter Wurmsdobler

Jiri,

> At present, we haven't; however, soft real-time is easily achieved by
> setting the scheduler policy and static priority (see sched_setscheduler(2)
> and friends), and perhaps tweaking the scheduler granularity.

I tried that too with the Infoteam run time system, like

struct sched_param p;
error = sched_getparam( 0, &p );
if ( error < 0 )
{
printf("count not get sched_param\n");
exit(1);
}
p.sched_priority = sched_get_priority_max( SCHED_FIFO );

error = sched_setscheduler( 0, SCHED_FIFO, &p );
if ( error < 0 )
{
printf("count not set priority SCHED_FIFO\n");
exit(1);
}

However, this brute force approach does not release the CPU for anything other than kernel threads and other kernel activity. Here it was still subject to latencies due to, e.g. ping flood: 200us black-out when using the control software to read a sine wave from an analog input and put it through to the analog output on a scope.

Even this solution is still bad as if there is ahother process doing communication, there is to my knowledge no means to "budget" time
consumption for ther processes. I thought of something like:

max 100us max 100us
|<---->|
|<---->|
| | | |
+---------------------+------+----------------------+------+------>
| | | | |
| PLC tasks | rest | PLC tasks | rest |

The only thing real time linux implementation which claims to do it is REDLinux, by RedSonic. I did not try it yet, but I will soon.

> Hard real-time is a bit more difficult, but if the recent discussions about
> RTAI-LXRT are accurate, we can just use that.

Both RTLinux and RTAI offer something like soft real time in user space, PSC and LXRT, respectively. The problem however, is that executing in the real time context limits your code, or you fall back to the linux context when some linux code is executed. I used RTLinux for a long time with no problem for hard real time, but I stayed there in a kernel module. If the LinuxPLC run time modules use only POSIX calls and you can make sure that no non-real time code is used, you couild do it in a symmetric way.
Write your code and test it in user space, if you need hard real time, compile it as kernel modue. In either case you must only communicate by the same means, FIFOs for example.

I am still searching for a framework which allows to implement different types of control at different levels of real time. Depending on what you wnat, you take standard linux or any other real time implementation. But the framwork should remain. Only I don't know how it looks like.
peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax

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

Mario de Sousa

Peter Wurmsdobler wrote:
> Even this solution is still bad as if there is ahother process doing
> communication, there is to my knowledge no means to "budget" time
> consumption for ther processes. I thought of something like:
>
> max 100us max 100us
> |<---->|
> |<---->|
> | | | |
> +---------------------+------+----------------------+------+------>
> | | | | |
> | PLC tasks | rest | PLC tasks | rest |
>
> The only thing real time linux implementation which claims to do it is
> REDLinux, by RedSonic. I did not try it yet, but I will soon.


Last time I had a look at timesys's (www.timesys.com) solution they seemed to support (cpu) resource reservation, but I have just browsed through their site and it seems they are now selling it as an add-on.

Anyway, it probably won't hurt to read the detailed documentation.

Mind you, last time I tried it, the lowest supported period was 500 us, and processes were still interrupted by top-half interrupt handlers.

Cheers,

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

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

 
[sched_setscheduler(2)]

Peter:
> However, this brute force approach does not release the CPU for anything
> other than kernel threads and other kernel activity.

Leaving time for the rest of the system could be done in two ways in the MATplc:

- make all modules periodic, and ensure their periods are long enough to
leave time for the rest, or

- synch all the modules, and have one process that just goes to sleep (the
other processes would be blocked on a semaphore at that stage, so
priority 0 processes would get a go).

> Here it was still subject to latencies due to, e.g. ping flood: 200us
> black-out when using the control software to read a sine wave from an
> analog input and put it through to the analog output on a scope.

Yes. Well, it's *soft* real time. And, admittedly, for a lot of applications 200us isn't even noticeable - relay switching times are
measured in ms, a lot of machine operations in tenths of a second.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R

Robert Schwebel

On Mon, 1 Oct 2001, Peter Wurmsdobler wrote:
> Both RTLinux and RTAI offer something like soft real time in user
> space, PSC and LXRT, respectively.

LXRT is even _hard_ realtime in user space. Just give it a try :)

Robert
--
+--------------------------------------------------------+
| Dipl.-Ing. Robert Schwebel |
| Linux Solutions for Science and Industry |
| Braunschweiger Straße 79, 31134 Hildesheim, Germany |
| Phone: +49-5121-28619-0 Fax: +49-5121-28619-4 |
+--------------------------------------------------------+


_______________________________________________
MAT-devel mailing list
<EMAIL: PROTECTED>
https://lists.sourceforge.net/lists/listinfo/mat-devel


 
P

Peter Wurmsdobler

Robert,

> LXRT is even _hard_ realtime in user space. Just give it a try :)

I have to try it! I only was told that it is soft real time, so I did not consider it for further use. But it still does not what I had in mind: budgeting CPU usage to Linux with limited time.

peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax

_______________________________________________
MAT-devel mailing list
<EMAIL: PROTECTED>
https://lists.sourceforge.net/lists/listinfo/mat-devel
 
P

Peter Wurmsdobler

Jiri,

The general problem for me with PLCs is their classical paradigm: run loops as fast as possible. Everybody familiar with digital control knows that this is neither necessary nor reasonalbe to carry out pseudo-continuous control. Any plant living in the anlalog world can be transformed to a time discrete representation; so periodic scheduling of
the appropriate algorithm will do the job. Maybe another reason why PLCs scan inputs as fast as it
is possible is to react to discrete signals. By using an operating system, this job can be detached and executed in the framework of interrupts, which are sporadic tasks in the OS world. If you know the worst case occurance of sporadic tasks and periodic ones, as well as their execution time, lots of literature tells you whether the set is schedulable or not. Then, depending on the timing accuracy of the underlying OS, an implementation is possible. I guess in standard Linux the limit is 10ms, using LXRT or PSC (RTLinux version) better resolutions are possible.

Bottom line: replace PLC paradigm by reasonable control strategies, not simulation of a PLC which itself emulates relay control.
peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax

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

Mario de Sousa

Peter Wurmsdobler wrote:

> Bottom line: replace PLC paradigm by reasonable control
> strategies, not simulation of a PLC which itself emulates
> relay control.

(NOTE: I believe Jiri has answered this question already, but I got to read all the emails in the wrong order this morning, so I'm not really
sure...)


Yes, we already do that.

We leave it up to the user to choose between:
- normal PLC paradigm (scan as fast as possible)
- scan at a user specified rate (i.e. period)
- any combination of the above for any combination of modules.
- even more complex than any combination of the first two, for example having module C run once every time either module A or B finish their
scan, and module D run once when both module A and B have finished their scan. Using a Petri net to synchronise the modules allows us to do the
above with very little effort!

Cheers,

Mario.
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

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

Peter Wurmsdobler

Mario,

> scan. Using a Petri net to synchronise the modules allows us to do the
> above with very little effort!

Yes, Juan had explained to me, and this is the reason why I liked it immediately. It's well designed.
peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax

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

Mario de Sousa

Peter Wurmsdobler wrote:
>
> Robert,
>
> > LXRT is even _hard_ realtime in user space. Just give it a try :)
> I have to try it! I only was told that it is soft real time, so I
> did not consider it for further use. But it still does not what I
> had in mind: budgeting CPU usage to Linux with limited time.
>

It shouldn't be too hard to include it in the scheduling mechanisms.

The main difficulty in RT Linux is guaranteeing pre-emptability. Once this is done, it is very easy to write new scheduling algorithms.

Just choose one of the resource reservation algorithms that have already been published, and code it! I would love to do it myself, but I
really do have my hands full at the moment.

Cheers,

Mario.


----------------------------------------------------------------------------
Mario J. R. de Sousa
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
MAT-devel mailing list
<EMAIL: PROTECTED>
https://lists.sourceforge.net/lists/listinfo/mat-devel


 
G
> > Here it was still subject to latencies due to, e.g. ping flood: 200us
> > black-out when using the control software to read a sine wave from an
> > analog input and put it through to the analog output on a scope.
>
> Yes. Well, it's *soft* real time. And, admittedly, for a lot of
> applications 200us isn't even noticeable - relay switching times are
> measured in ms, a lot of machine operations in tenths of a second.

No system ever designed covers all applications. If you design a reliable system, and publish it's specifications/limitations then people can decide
if it's applicable to their problem. You will most likely not achieve specs that make everyone happy, and deliver everyones other requirements.

Personally I think that using a piece of wire between the analog input and the scope would be a better solution than using a computer running Linux or any other OS.

--
Gary James
[email protected]
http://home.twcny.rr.com/embedded/
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Well, that's four people who will understand it :^)

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.

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