Real Time Linux Overview

On Sat Jan 22 06:09:29 2000 Dave West wrote...
>
>Good responses.
>
>Ok, guys we need to build in some good profiling functions as well so end
>users can check all aspects of scan times and optimise code or buy a
>faster processor as required.
>

Yes, and these should be visible to the application program in S (status) data table files, as someone else mentioned earlier.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri Jan 21 21:17:34 2000 Alan Locke wrote...
>
>First of all, thank you for giving us some real data to mull over. If I read
>this correctly, this data came from the average loop time though a simple loop
>for 21 processes running for 10 seconds. I don't think that this would come
>very close to modeling the code involved in a PLC logic engine for even the
>most simple of ladder logic. Was other activity was going on when the data was
>gathered (disk serial port, network, other apps)? This data differs so far
>from the info previously posted from some others who are familiar with the real
>time extensions that we need to put things in context. I would question whether
>this test alone is enough to justify abandoning the use of real time
>extensions, although we may come to that conclusion anyway for a mix of reasons.

We are not proposing to abandon real time extensions, just make them optional, and not a part of the base V 1.0 system.

This test is enough for em to know that I can deploy a Linux based PLC system, that will be useful for a large portion (but not all) of the
applications that I have presently deployed.

Given that I would like to come to a consensus to proceed with a prototype design without real time extensions. Bearing in mind that we do eventually want to include them. I posted earlier my recommendations regarding this.

I strongly support Dave's position on this.

>Most applications can deal quite well with a lot of jitter in scan time. But
>this is relative. If the scan is say 20 msecs +/- 10 msecs it likely will not
>matter (real PLCs have scan times that vary a lot too). But if it is
>20 msecs -10/+200 msecs due to disk activity or something it can
>be a real problem for many applications. Average scan time is important but so

Do you have any real reason to suggest 200 msec jitter is to be expected? If so I would like to see it.

>is range. I can't immediately recall any PLCs that I've used that didn't give
>max scan time as well as the current scan time.

Correct. Most if not all keep a max scan time value. Quite often it is very high. Usually the extended scans are cause by some combination
of:

1. Start up intilazation.

2. on line editing

3. unusual execution paths.

--
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 test is very interesting..

> #include <signal.h>
>
> int done = 0 ;
>
> void alarmer(void);
>
> void main(void)
> {
> long count = 0;
>
>
> signal(SIGALRM, alarmer);
> alarm(10);
> for(;done == 0;)
> {
> count++;
> printf("a");
> }
> printf("\n\n result is %f msec/scan\n", 1 /((float)count / 10.0) * 1000);
> }
>
> void alarmer(void)
> {
> done = 1 ;
> }

But it may not show the full story.

Linux can pull things out for over 100mS under load.

Sorry to keep on about the Real Time Stuff but if you try the measurements test in RTAI you will have access to some direct time measurements from the cpu clock. You will also find hardware (pc104 etc ) access much easier with some module code.


I would say that you would be at risk from , say, net traffic or disk activity if you do not use the Real Time systems available.
They are meant for hard deadline activity.

It is true you may not need sub millisecond accuracy but you do not need 100ms occasionally.
This is where something works for weeks and then self distructs with no apparent reason.

Look at the results displayed on
http://www.zentropix.com/support/document/testdata.html

If for nothing else the Real Time extensions give you access to far better timers than is available in the regular code.

My reason for being persistent is that I see a good match here. The Realtime guys have some nice code tricks and the PLC guys are going to come up with some neat application helpers.

For Example add some PLC type logic at run time to some data collection application.


In any case I normally run my tests for days on end and then collect and histogram the data.

If you put your code into a neat clean function and do not have any system calls embedded in it then the same code can run in a realtime module and also a piece of user code.

If you like send me a simple function and I'll patch it all up for you.

If this is just generating excess network noise tell me to hush up and I'll drop the topic.
NO hard feelings.

Regards
Phil Wilshire

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

Phil Covington

Hello Phil,

Glad to see at least one other person who understands the problem! Unfortunately most here seem to not want to see reality, so you may find
that the information that you are offering will fall on deaf ears. There is plenty of test data published on the internet concerning these problems for anyone who wants to take the time to understand it. But soon enough, when it comes to actually coding and running the code on real hardware, reality will rear its ugly head. I, myself, give up on trying to convince anyone...

Phil Covington
vHMI

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
I don't really think that is a correct statement Phil. You have convinced me that it will be neccessary to go real time eventually. I just think that now is not the time to do it.

Seeing as how yourself and Phil Wilshire appear to be the two resident experts on this can you confirm or correct my understanding of this
problem.

1. A tight loop routine that does not call any system calls will be scheduled out after 10 msec provided some other process is ready to run.
2. Any process that makes a system call will be scheduled out if another process is ready to run.
3. When scheduled out our process can expect to regain control after (n-1) * 10 msec at the latest. Where n is the total number of processes on the computer. This seems to be born out by this next piece of code which results in a bearable but noticeable reduction in system performance from a users point of view.

##########


#include <signal.h>

int done = 0 ;

void alarmer(void);


void main (void)
{
int count;
for (count = 0 ; count < 20 ; count++)
{
if (!fork())
{

signal (SIGALRM, alarmer);
alarm (10);
for(;done == 0;)
;
}
}
}

void alarmer(void)
{
done = 1 ;
}

##############

If this is correct then, for the time beeing, we can simply limit processes to the bare essentials such as:
Logic engine
I/O reader
I/O writer
Communication handler
Getty (for user access)

OK, when someone logs in and starts executing hings the system performance will be degraded but the rest of the time the system will perform at
optimum speed.

I think this because each process is either waiting for a syscall to complete or processing the result of a syscall. The logic engine issues a
syscall to lock the shared memory for reading, copies it and issues another syscall to release it. The logic engine then processes the logic
programme issuing similar syscalls to update the internal data table. These locks are required so that the I/O and communication processes do not update or read the tables when the logic engine is accessing them.

The I/O reader waits for data from the real I/O devices so spends most of its time on a wait queue in the kernel. When data is available from the I/O it is read and the I/O reader then waits in a kernel wait queue for the data table to be available for writing, writes the data and loops. The read I/o process only get scheduled in when it has read data from real I/O then waits for the data table lock and is then scheduled in to update the table. This causes the logic engine to be scheduled out only when it needs to be. Similar applies to the other processes in the system.

Basically I believe the kernel will run our tasks full tilt boogie giving sub 1 msec scan times of the logic programme (not the I/O as we may be
waiting for slow I/O devices).

If I have missed something in my scanning of the kernel code that will affect this can you please advise me. The worst thing I can see is where
the kernel may go and sit in the system idle process for 10 msec in which case that would be a serious kernel bug.


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 Fri, 21 Jan 2000, Phil Wilshire wrote:

> HI,
> This test is very interesting..
>
> > #include <signal.h>
> >
> > int done = 0 ;
> >
> > void alarmer(void);
> >
> > void main(void)
> > {
> > long count = 0;
> >
> >
> > signal(SIGALRM, alarmer);
> > alarm(10);
> > for(;done == 0;)
> > {
> > count++;
> > printf("a");
> > }
> > printf("\n\n result is %f msec/scan\n", 1 /((float)count / 10.0) * 1000);
> > }
> >
> > void alarmer(void)
> > {
> > done = 1 ;
> > }
>
> But it may not show the full story.
>
> Linux can pull things out for over 100mS under load.

Agreed, so we simply remove the load. We don't need nor want the majority of processes that run on the average box. If somebody does want them then they shouldn't be expecting sub 50 msec scan times (A real PLC can't have them. inetd etc do not run on real PLC's).

> Sorry to keep on about the Real Time Stuff but if you try the
> measurements test in RTAI you will have access to some direct time
> measurements from the cpu clock.
> You will also find hardware (pc104 etc )
> access much easier with some module code.

Good, so RTAI etc may bring other advantages. This requires further investigation.

> I would say that you would be at risk from , say , net traffic
> or disk activity if you do not use the Real Time systems available.
> They are meant for hard deadline activity.

What net traffic? What disk activity? The only thing this box will do is what it needs to do in pursuance of the task of controlling the machine
(Anybody that hangs a control system network off the normal day to day office network is a serious idiot and I would not employ them.

> It is true you may not need sub millisecond accuracy but you do not need
> 100ms occasionally.
> This is where something works for weeks and then self distructs with
> no apparent reason.
>
> Look at the results displayed on
> http://www.zentropix.com/support/document/testdata.html
>
> If for nothing else the Real Time extensions give you access to far better timers
> than is available in the regular code.

Ahh, another advantage. Good !

> My reason for being persistent is that I see a good match here.
> The Realtime guys have some nice code tricks and the PLC guys
> are going to come up with some neat application helpers.
>
> For Example add some PLC type logic at run time to some data collection
> application.

Oh I agree entirely the two do seem to be a good match for the future.

> In any case I normally run my tests for days on end and then collect and histogram the data.
>
> If you put your code into a neat clean function and do not have any system calls embedded in it then the same code can run in
> a realtime module and also a piece of user code.

Ok so your saying that anything that makes a system call we should wrap in a small function and place the defenition of that wrapper in a seperate file thus making it easier to port to RT at a later date. Good, just the kind of thing I wanted to here. tell us more.

> If you like send me a simple function and I'll patch it all up for you.

Goodie, goodie, Phil will fix all our bugs :cool:
No seriously, thanks for the offer. It is much appreciated and is probably the best way to teach some of us the way to do it for RT. You know, before and after.

> If this is just generating excess network noise tell me to
> hush up and I'll drop the topic.
> NO hard feelings.

Well I'm learning and I want to keep on for now at least. It may seem that I am challenging yourself and Phil Covington(I think) from time to time but it's not meant that way. It's just my style of learning.


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
 
Dave West wrote:
>What net traffic? What disk activity? The only thing this box will do is what it needs to do in pursuance of the task of controlling the machine
(Anybody that hangs a control system network off the normal day to day office network is a serious idiot and I would not employ them.<

I'm not sure that Phil was talking about net activity on an office network. There are control systems that use ethernet for HMI comminications as well as traffic to lower speed I/O. There's also been on and off discussions about using the machine disk for data persistence reasons (I'm not advocating this position here though).

On another subject, let's keep a level of courtesy in our discussions please. If I were Phil, I might read your post as calling him a serious idiot that should not be employed in a field in which he no doubt sucessfully employed
If you have a point, there is no reason to make it in a potentially offensive manner - it only reduces the impact of your point. All of us here are volunteers after all and deserve to be respected.

Alan Locke
Controls Engineer, Boeing
Neither a serious idiot nor unemployable in the controls field according to my employer, but I nonetheless I'll write....

"My opinions are my own and not necessarily those of my employer"

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

Phil Wilshire

Hello again,
Thanks for the debate , I was expecting to get flamed out here. Taking Dave West's points.

> 1. A tight loop routine that does not call any system calls will be
> scheduled out after 10 msec provided some other process is ready to run.
> 2. Any process that makes a system call will be scheduled out if another
> process is ready to run.
Interrupts may cause a reschedule.
Any task regardless of priority can be then scheduled.

> 3. When scheduled out our process can expect to regain control after
> (n-1) * 10 msec at the latest. Where n is the total number of processes on
> the computer.
NO netscape or any poorly written driver can bring the whole thing to its knees for seconds.
Not so with RT code you WILL have the CPU when you want it ( within a few 10s of microsecs )
> This seems to be born out by this next piece of code which
> results in a bearable but noticeable reduction in system performance from
> a users point of view.
>

I have been trying to put some kind of PLC system together under linux for 4 years.
I have not completed any project because of the scheduling issue. Linux is Great but it is NOT REAL TIME. The simple point is this if you design a system that does not use the Real Time extensions you will find youselves an easy target for the SOFTPLC type of competition.
You will keep open the door for all the broken stuff out there that relies on Windows hacks to keep running.

Given that these linux realtime extensions are just about the best stuff in the business
and they are all available for you to use AND free help is available to get you going why turn the offer down....

At this point in time it would be trivial to take the steps to use the RT extensions.
A week of so of pain to get your first module runnning and then its much easier to code with.

This is especially true when you have HW IO to deal with.

Write a whole bunch of code ignoring these extensions then you are in a world of hurt later.

On another point
I have created some REAL time demo systems ( stepper motor drivers etc )
One of the demos I did was to REBOOT the linux box with the demo runnning.
The stepper motor keeps on running even when ALL of Linux has closed down.
The system runs right until the bios finally resets the system.
This , to me, is the sort of "hard logic " behavior you need for the PLC solution.

Remember you will have a great time producing this work for yourselves but there is a wider audience out there that need this project. The
managers and sceptics will be looking for any reason not to continue with your solution. If you have Hard Real Time then another argument
against LinuxPLC is dissolved.

So my advice is to take a look at the RT stuff and see how hard it really is to use.
Then come back and discuss your findings.
At that point in time continue the use RT or not debate.

As always I will withdraw the noise if so asked. I do think this is a serious issue though.

Another Dave West point..
>
> What net traffic? What disk activity? The only thing this box will do is
> what it needs to do in pursuance of the task of controlling the machine
> (Anybody that hangs a control system network off the normal day to day
> office network is a serious idiot and I would not employ them.
>
True unless there is a system that can handle it...
In any case the embedded world may not agree with you...
There is an increasing need to have a remote real time function connected to a bigger world.

I'll be on this group ( monitoring Digests ) all this week then I'll be silent for two weeks.
I'm going to Paris ( Linux-expo ) and then England.
I'll get mail but not be able to respond.
So if I go quiet watch out I'll be back mid Feb.

I enjoy this debate so keep up the challenges..
Nothing anyone can say will upset me for long either. 8->>
You have a great project here.

Regards
Phil Wilshire

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat Jan 22 11:24:49 2000 phil wilshire wrote...
>
>I have been trying to put some kind of PLC system together under linux
>for 4 years.
>I have not completed any project because of the scheduling issue.
>Linux is Great but it is NOT REAL TIME.
>The simple point is this if you design a system that does not use the
>Real Time extensions you will find youselves an easy target for the
>SOFTPLC
>type of competition.

Question, is that a bad place to be for V 1.0? If we can get to be acceptable for the type of applications that you would consider a SOFTPLC for, and still have not locked ourselves out of using the real time extensions, is this a "bad thing" (tm).

I say no. I say that if we can get there, then we can use it as a stepping stone on the way to world domination :)

>You will keep open the door for all the broken stuff out there that
>relies on Windows hacks to keep running.
>
>Given that these linux real time extensions are just about the best stuff
>in the business
>and they are all available for you to use AND free help is available
>to get you going why turn the offer down....

I don't want to turn the offer down.

What I do want to do is build something that can be demonstrated, and useful for many applications, _without kernel hacks_. This will get a much larger number of people who have that ability to/ are willing to try out the software.

It will also allow the software to be tried out on a much more divergent set of hardware.

Is this a bad this? I say no.

And we have not locked ourselves out of using the real time extensions to further improve the project, as long as you and the other people who are familiar with the real time extensions continue to provide the valuable guidance to the rest of us, to avoid us falling into traps that will prevent us using these extensions.

>At this point in time it would be trivial to take the steps to use the
>RT extensions.
>A week of so of pain to get your first module runnning and then its much
>easier to code with.

I disagree here. I for one don't have a machine that I can run a hacked kernel on.
>
>This is especially true when you have HW IO to deal with.
>
>Write a whole bunch of code ignoring these extensions then you are in a
>world of hurt later.

Could you please be specific in your concerns here?
>
>On another point
>I have created some REAL time demo systems ( stepper motor drivers etc )
>One of the demos I did was to REBOOT the linux box with the demo
>runnning.
>The stepper motor keeps on running even when ALL of Linux has closed
>down.
>The system runs right until the bios finally resets the system.
>This , to me, is the sort of "hard logic " behavior you need for the PLC
>solution.

This is most definitely not the kind of thing I want my PLC to do. If I have lost the controller, I want it to _STOP_!

>Remember you will have a great time producing this work for yourselves
>but there is a wider audience out there that need this project. The
>managers and sceptics will be looking for any reason not to continue
>with your solution. If you have Hard Real Time then another argument
>against LinuxPLC is dissolved.

Maybe, maybe not. I can just here my managers. Linux, yes I have heard of that. Does it run under RedHAT? Well no sir, I have to hack the kernel a bit.
>
>So my advice is to take a look at the RT stuff and see how hard it
>really is to use.
>Then come back and discuss your findings.
>At that point in time continue the use RT or not debate.

I have looked, and I have come to the conclusion that I do not need it for at least 75% of my existing applications, and the remaining 26% are so critical that I am unlikely to use anything other than dedicate hardware for them anyway.

Now, I am not saying thats true for everyone, so I do Nat to allow the choice of using the real time extensions, but, I DO NOT WANT to make them mandatory.

Can we agree on this?

>As always I will withdraw the noise if so asked. I do think this is a serious issue though. <

No, please continue to speak your mind. I think almost everyone who has posted here has had valuable thinking to contribute.



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

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

> Hello again,
> Thanks for the debate , I was expecting to get flamed out here.
> Taking Dave West's points.
>
> > 1. A tight loop routine that does not call any system calls will be
> > scheduled out after 10 msec provided some other process is ready to run.
> > 2. Any process that makes a system call will be scheduled out if another
> > process is ready to run.
> Interrupts may cause a reschedule.
> Any task regardless of priority can be then scheduled.

Is that the timer interrupt or an interrupt based on an I/O device? I ask because the timer interrupt won't allow a lower priority process be scheduled, will it?

> > 3. When scheduled out our process can expect to regain control after
> > (n-1) * 10 msec at the latest. Where n is the total number of processes on
> > the computer.
> NO netscape or any poorly written driver can bring the whole thing to
> its knees for seconds.

So it is possible to write a userland process that can prevent re-scheduling based on the timer interrupt without any RT extensions?
Either way we don't run Netscape and we fix poorley written drivers that should be fixed anyway.

> Not so with RT code you WILL have the CPU when you want it ( within a
> few 10s of microsecs )

Erm, what was this in response to?
Any way, what your saying is that an RT module can say "I want at least x usec to run and I want to run every y usec", yes?

> > This seems to be born out by this next piece of code which
> > results in a bearable but noticeable reduction in system performance from
> > a users point of view.
>
> I have been trying to put some kind of PLC system together under linux for 4 years. <

Can you post any of your code then?

> I have not completed any project because of the scheduling issue.
> Linux is Great but it is NOT REAL TIME.

Never said it was real time.

> The simple point is this if you design a system that does not use the
> Real Time extensions you will find youselves an easy target for the SOFTPLC type of competition.
> You will keep open the door for all the broken stuff out there that
> relies on Windows hacks to keep running.

A very valid point indeed.

> Given that these linux realtime extensions are just about the best stuff
> in the business
> and they are all available for you to use AND free help is available
> to get you going why turn the offer down....

Not turning it down. Just sort of saying "thanks, great, but we can't quite grasp the concepts yet. Can we come back to this when we understand a little more about our methods and goals and existing/apearing code and there's less sh*t floating around in our heads. Meanwhile it would be real nice if you could keep an eye on our coding and point out anywhere we do something that will make it real hard/impossible to convert to RT at that later date".

> At this point in time it would be trivial to take the steps to use the
> RT extensions.
> A week of so of pain to get your first module runnning and then its much
> easier to code with.

Is it really that easy?
If we go straight into RT coding what debug facilities are available to us? Obviously the most common "printf("Got here\n"); " is not an option.

> This is especially true when you have HW IO to deal with.
>
> Write a whole bunch of code ignoring these extensions then you are in a
> world of hurt later.
>
> On another point
> I have created some REAL time demo systems ( stepper motor drivers etc )
> One of the demos I did was to REBOOT the linux box with the demo
> runnning.
> The stepper motor keeps on running even when ALL of Linux has closed
> down.
> The system runs right until the bios finally resets the system.
> This , to me, is the sort of "hard logic " behavior you need for the PLC solution.

Yes that is quite impressive and should provide for more robustness.

> Remember you will have a great time producing this work for yourselves
> but there is a wider audience out there that need this project. The
> managers and sceptics will be looking for any reason not to continue
> with your solution. If you have Hard Real Time then another argument
> against LinuxPLC is dissolved.
>
> So my advice is to take a look at the RT stuff and see how hard it
> really is to use.
> Then come back and discuss your findings.
> At that point in time continue the use RT or not debate.

The debate isn't really about how difficult RT is to use but really more about how portable. What happens when we port our system to WIN32, AIX,
Free BSD, BE OS, OS2, RISC OS etc?

> Another Dave West point..
> >
> > What net traffic? What disk activity? The only thing this box will do is
> > what it needs to do in pursuance of the task of controlling the machine
> > (Anybody that hangs a control system network off the normal day to day
> > office network is a serious idiot and I would not employ them.
> >
> True unless there is a system that can handle it...
> In any case the embedded world may not agree with you...
> There is an increasing need to have a remote real time function
> connected to a bigger world.

Agreed so you write the communication functions in a manner so as not to interfere noticeabley. If the standard tool works fine good, but the point is your control system doesn't run anything you don't know about or expect. Thus it doesn't interfere unexpectedly and cause problems.

> I'll be on this group ( monitoring Digests ) all this week then I'll be
> silent for two weeks.
> I'm going to Paris ( Linux-expo ) and then England.
> I'll get mail but not be able to respond.
> So if I go quiet watch out I'll be back mid Feb.

Lucky begger...

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 Fri Jan 21 19:20:12 2000 Phil Wilshire wrote...
>
>HI,
>This test is very interesting..
>
>Linux can pull things out for over 100mS under load.
>
>Sorry to keep on about the Real Time Stuff but if you try the
>measurements test in RTAI you will have access to some direct time
>measurements from the cpu clock.
>You will also find hardware (pc104 etc )
>access much easier with some module code.

Phil, let me ask you a question.

Are you convinced that we can not build a useful PLC for a fair percentage of typical PLC applications without real time extensions?

I for one am not convinced of this, and I would like to get a first cut of this project out without the added complexity, and non portability of having to have a modified kernel.

Do you honestly feel that this is not achievable?

I am not trying to steer away from the possibility of having the real time extensions, either as an a build time option, or _perhaps_ required for some later version of the project.

I am however, absolutely convinced that requiring these for the first version will significantly lower the number of people who are willing to take a look at using this project.

please consider this before you answer.

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

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

Phil Wilshire

Ok,
Good debate.

You can buy a "standard RedHat" distro for $50 with Real TIme ready to
run.
http://www.zentropix.com

In Kernel Debuggers are also on the same disk.

>
> Are you convinced that we cannot build a useful PLC controller for a
> large percentage of typical PLC applications without some sort of real
> time extensions?
You will open the door to your critics that's all.
>
> If you are not, why do you object to doing that first,

No objection just trying to make you think..

> and then adding
> in the extra complexity, and non portability, later in the project?
without care this may be tough.
If you use some services that are not avaialble ( yet ) in the RT side
it may be tough to add later.

> I fell strongly that we need to develop something that can be tries out
> without having to modify your kernel, for reasons I have outline
> elsewhere, but will elaborate on if needed. NO need. I have a compromise.
>

SO what I suggest is that you do quick prototype of your system. No real meat just a code sketch We can add details later. Let Some RT guys take a look at it and offer suggestions.

(My Code is on a batteryless laptop. I'll get it wound up if I can this week.)

Send me some simple code snippets etc and I'll see what I can do.

Enough debate ... you want to get started...

Thanks for listening.
Phil

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat Jan 22 11:15:56 2000 Alan Locke wrote...
>
>Dave West wrote:
>>What net traffic? What disk activity? The only thing this box will do is
>>what it needs to do in pursuance of the task of controlling the machine
>>(Anybody that hangs a control system network off the normal day to day
>>office network is a serious idiot and I would not employ them.
>
>I'm not sure that Phil was talking about net activity on an office network.
>There are control systems that use ethernet for HMI comminications as well as
>traffic to lower speed I/O. There's also been on and off discussions about
>using the machine disk for data persistence reasons (I'm not advocating this
>position here though).

Yet another nail in the "deterministic or nothing" argument. AB is finding that a lot of people are doing communication over TCP/IP Ethernet, because it's a standard, and not ControlNET. They seem to be in shock about this, and keep waving the "deterministic" flags. It's got a lot of cannon holes in it from all the successful project done over TCP/IP. tho.

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


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Let me pose the same question to you, that I did to the Phil.

Are you convinced that we cannot build a useful PLC controller for a large percentage of typical PLC applications without some sort of real time extensions?

If you are not, why do you object to doing that first, and then adding in the extra complexity, and non portability, later in the project?

I feel strongly that we need to develop something that can be tries out without having to modify your kernel, for reasons I have outline
elsewhere, but will elaborate on if needed.

--
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 11:31:22 2000 Dave West wrote...
>
>Not turning it down. Just sort of saying "thanks, great, but we can't
>quite grasp the concepts yet. Can we come back to this when we understand
>a little more about our methods and goals and existing/apearing code and
>there's less shit floating around in our heads. Meanwhile it would be real
>nice if you could keep an eye on our coding and point out anywhere we do
>something that will make it real hard/impossible to convert to RT at that
>later date".

Well said, Dave.

You have been able to state very clearly onions which I agree with wholeheartedly.

I guess I just am not saying them as clearly.
>
>Is it really that easy?
>If we go straight into RT coding what debug facilities are available to
>us? Obviously the most common "printf("Got here\n"); " is not an option.

We also have to have machines that we can dedicate to this project, on which to install hacked kernels.

>> At that point in time continue the use RT or not debate.
>
>The debate isn't really about how difficult RT is to use but really more
>about how portable. What happens when we port our system to WIN32, AIX,
>Free BSD, BE OS, OS2, RISC OS etc?

One of my strongest objections to _requiring_ any of the real time extensions.

>Agreed so you write the communication functions in a manner so as not to
>interfere noticeabley. If the standard tool works fine good, but the point
>is your control system doesn't run anything you don't know about or
>expect. Thus it doesn't interfere unexpectedly and cause problems.

Well that just standard well written communications code. No rocket science here.


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

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

For what it's worth, the real time extensions are a really good habit to get into. Most of the strong objections seem to come from people who have not done time critical programming on Linux.
I design and build test equipment that runs on Linux and I can verify that the only way you can achieve consistant timing is by controlling all the variables. You are all correct in your
context. (diplomatic, eh?) I want in the worst way to just get something simple in code, understanding the limitations and that it will be replaced. I am also absolutely sure that the
features being discussed will introduce variables that will blow that simple model right out of the water. The reason I have been willing to do the realtime thing at this point is that certain individuals declare that a scan time over 10ms
makes the project utterly useless and I want to keep them on board. Some of those same individuals are arguing strongly against the complexity of guaranteeing what they need. I am
not prepared to discuss kernel internals as I have been too damn busy selling Linux in the real world to read much kernel code lately. What I know, from experience, is that, once you get a mix of networking, interrupt driven IO, some sort of a display and those daemons necessary to run a normal Linux environment running at the same time, you are going to have timing variations that you won't want to track down and solve.
Yes, you can run a test in isolation and get good results. Yes, my test times are fairly consistant. But, add datalogging or simply load a large bit of code or remote administration and
you _will_ get variations. This is in the design of Linux, it is not a bug or defect. It has a "fair" scheduler that tries to do exactly that, "fairly" divide the resource among the
processes.

This isn't speculation, I know this to be true. I have designed my code to be tolerant of the nature of the beast. You probably can't always do that in PLC applications, where machinery doesn't
give a damn if you're ready or not. We will need real time or at least another scheduler. Possibly we won't need to go whole hog, the easiest thing we can do may be enough. For the first pass we don't need it at all, but, should make sure we don't do anything to prevent it.

I have been marginalized for trying to introduce some reality into the process. Perhaps it is too early to get serious and we need the ideas, but, we do need some organization and process. You all understand process :^). I started this thing and have been amazed at the acceptance and willingness and earnest offers that have been forthcoming. We are losing people and turning
people off with chaos and circular debate. I am getting a little discouraged myself because everybody's talking and only a few can be working. I am going to try again to be heard above the din.

We need a group of people WHO CAN CODE to get a IO driver interface defined. The bare essentials to start with, so those who have the various types of IO can get some test drivers written we can use for testing. To do this we need a map to write to. I strongly suggest that for the first
pass, the discussion on this be limited to people who can put their points in C code, or we have chaos again. Let the debate rage on elsewhere, but let's get this first chunk, the stone for the stone soup, progressing without fail. This attitude may piss some people off, but, I think all can see that we need to do it. Since nobody recognizes the thought I put in before embarking on this adventure, I can only suggest that those who wish to be a part of this group come with an open mind and accept that this part is strongly
influenced by the platform and reality. This is so important that I will bail and simply lurk rather than dissent and would ask others to do the same so we can get the very basics moving. Please indicate your commitment to do this and I or someone else can make a list. KEN C. We may need a developers only list to get this done.

Regards

Curt Wuollet,
Wide Open Technologies

P.S. Go ahead and tell me where I'm wrong.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat Jan 22 07:30:57 2000 Curt Wuollet wrote...
>
>Hi, All
>
>For what it's worth, the real time extensions are a really good habit to get into. Most of the strong objections seem to come from people who have not done time critical programming on Linux.
>I design and build test equipment that runs on Linux and I can verify that the only way you can achieve consistant timing is by controlling all the variables. You are all correct in your
>context. (diplomatic, eh?) I want in the worst way to just get something simple in code, understanding the limitations and that it will be replaced. I am also absolutely sure that the
>features being discussed will introduce variables that will blow that simple model right out of the water. The reason I have been willing to do the realtime thing at this point is
>that certain individuals declare that a scan time over 10ms makes the project utterly useless and I want to keep them on board. Some of those same individuals are arguing strongly against the complexity of guaranteeing what they need. <

Sounds like he is talking about me :)

However I don't remember saying that a system with a scan > 10ms was useless. In fact I have been saying that for a high percentage of my applications, I can live with. let's say average scan times up to maybe 50 ms, and jitter that extends this up to maybe 150ms on occasion.

I believe that e can do this without any real time extensions.

> I am
>not prepared to discuss kernel internals as I have been too damn busy selling Linux in the real world to read much kernel code lately. What I know, from experience, is that, once you
>get a mix of networking, interrupt driven IO, some sort of a display and those daemons necessary to run a normal Linux environment running at the same time, you are going to have
>timing variations that you won't want to track down and solve. Yes, you can run a test in isolation and get good results. Yes, my test times are fairly consistant. But, add datalogging or simply load a large bit of code or remote administration and you _will_ get variations. This is in the design of Linux, it is not a bug or defect. It has a "fair" scheduler that tries
>to do exactly that, "fairly" divide the resource among the processes.
>
>This isn't speculation, I know this to be true. I have designed my code to be tolerant of the nature of the beast. You probably can't always do that in PLC applications, where machinery doesn't
>give a damn if you're ready or not. We will need real time or at least another scheduler. Possibly we won't need to go whole hog, the easiest thing we can do may be enough. For the first pass
>we don't need it at all, but, should make sure we don't do anything to prevent it.
>
>I have been marginalized for trying to introduce some reality into the process. Perhaps it is too early to get serious and we need the ideas, but, we do need some organization and process.
>You all understand process :^). I started this thing and have been amazed at the acceptance and willingness and earnest offers that have been forthcoming. We are losing people and turning
>people off with chaos and circular debate. I am getting a little discouraged myself because everybody's talking and only a few can be working. I am going to try again to be heard above the din.
>
>We need a group of people WHO CAN CODE to get a IO driver interface defined. The bare essentials to start with, so those who have the various types of IO can get some test drivers written we can use for testing. To do this we need
>a map to write to. I strongly suggest that for the first pass, the discussion on this be limited to people who can put their points in C code, or we have chaos again. Let the debate rage on elsewhere, but let's get this first chunk,
>the stone for the stone soup, progressing without fail. This attitude may piss some people off, but, I think all can see that we need to do it. Since nobody recognizes the thought I put in before embarking on this adventure, I can
>only suggest that those who wish to be a part of this group come with an open mind and accept that this part is strongly influenced by the platform and reality. This is so important that I will bail and simply lurk rather than dissent and
>would ask others to do the same so we can get the very basics moving. Please indicate your commitment to do this and I or someone else can make a list. KEN C. We may need a developers only list to get this done.
>

Calm down, I for one am not belittling your contributions. I think we are on the same wavelength, as far as getting something out the door,
here.

Somebody needs to put together a design spec. Do you want to volunteer for this task.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Stan Brown wrote:
>
> Calm down, I for one am not belittling your contributions. I think we are on the same wavelength, as far as getting something out the door, here. <

I am quite calm and deadly serious. As for contributions, I have none save for starting the project and making a few people believe that we
can do this. Contributing driver code has been impossible because the target changes wildly every time I read the mail. I had a model in mind
when I started the project. I tried to describe the model and the list went wild, covering every facet of PLC design and philosophy. It made
several rotations and gyrations and remarkably little flame was seen. After a few loops and a barrel roll or two, we seem to be converging
remarkably close to that original plan and model. This was aided by a few Linux programmers that are aware of the Linux programming environment, it's benefits and it's constraints. Reality has set in.

> Somebody needs to put together a design spec. Do you want to volunteer for this task. <

I have posted my few definite ideas previously. Since then, amid the clamor, I have seen that there are probably better candidates than
myself to do that. The only points that I am resolute on are that we use the memory outside Linux per Fred's paper so that we don't exclude
RTLinux, that we code in C, and that we keep the first pass simple enough that it can be readily used for developing device drivers and testing the time and scheduling issues without major rework. This will be the tool that enables work on all facets to proceed. I will participate, but, it will be agreed upon by the developers who will be writing to it. We need a target to write to.

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

Johan Bengtsson

I agree.

As I have said before, RT is something a lot of you will need but the actual implementation of it can wait until after the first "up and doing something" version is ready. I do not see
coding for RT (at least not the KURT track) as something THAT hard to do, but I beleve it have to be optional to the user at least as a compile time selection.

I am willing to help with this first step (if I can find the time).

I have, as I have said before, experience in programming control programs (in Windows true, but most of the problems about RT in an operating system not originally designed for RT are the
same) I have done this coding towards simulating as well as real I/O handling but the problemes are quite similar anyway.

I have however quite low linux experience and (almost :) ) no coding experience under linux (I finally got time enough to at least get "Hello World" compiled and running, not a big thing
but no I am going for it. What I lack most is what all the system calls are called and what
they are doing. My next step is to port the test code I posted before to a rough linux equivalent, about 70% done already.


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

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