Scan Times

G

Thread Starter

Gerry Hagberg

Hi,

There have been a number of posts like 'scan should be less than 20 msec.' which are somewhat meaningless without further definition - akin
to 'how long is a piece of string?'.

PLC manufacturers make statements like '1 msec per K of (ladder) program'. This is, of course, only vaguely indicative because each
instruction has a different execution time for true, false, integer, float, word, file, etc. The longest (program) scan I've experienced was on a PLC3 - 350 msec. It was a large and complex program, but the only obvious effect of the scan time was that the operators needed to be very
definite about pressing a push button.

The upshot is - if your application is large and requires low scan times, then you need multiple PLC's.

A propos: I determined empirically many years ago that I could easily operate a push button and beat a 100 msec scan, I could often beat a 50
msec. scan, but I could not beat a 20 msec. scan.

Gerry





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

Locke, Alan S

Gerry Hagberg wrote:
>There have been a number of posts like 'scan should be less than 20msec.' which are somewhat meaningless without further definition - akinto 'how long is a piece of string?'. <

True enough, but I believe the thread was considering the implications of scheduling precision with regard to standard Linux versus real time Linux.

It seems some of the data available for scheduling precision is from using a bare minimum I/O transition program, so maybe a better look at this might be scan time for a single rung setting an output on receipt of an input using a signal generator and oscope. I've seen vendors
demonstrate their PLC speed using this method before (using just standard rung instuctions), and it does give a pretty good look at how much time the housekeeping cycle eats up. PLCs I've seen are well under 10 msec scan with that setup (one was around 300 usecs!).

This certainly doesn't provide much data on how fast a real ladder program will execute given the wide variety of instruction and rung lengths, but it does provide a baseline minimum possible scan time. Certainly if standard linux isn't providing reliable sub 10 msec for a simple process, there's reason to look toward RTLinux/KURT/UTIME Linux.

I hope those few in the list with RTLinux/KURT/UTIME Linux experience will continue to help us drive these issues out while the rest
are in the learning curve.

Alan Locke
Controls Engineer, Boeing

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Wed Jan 19 07:08:40 2000 Peterc wrote...
>
>Has anyone considered the speed fix that Dick Morley used when designing the
>first PLC? It might be worthwhile to look at his article on the history of the PLC, at ww.barn.org/FILES/historyofplc.html. Is it possible that the best solution would be a coprocessor?
>
The idea of this project is to not require an special hardware.
--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
[email protected]lc.org
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Wed, 19 Jan 2000, you wrote:
> On Wed Jan 19 07:08:40 2000 Peterc wrote...

> >Has anyone considered the speed fix that Dick Morley used when designing the first PLC? It might be worthwhile to look at his article on the history of the PLC, at www.barn.org/FILES/historyofplc.html. Is it possible that the best solution would be a coprocessor?
> >
> The idea of this project is to not require an special hardware.

If I may interject here:
When the first PLC was created, 8 bit processors (Z-80, 6502, 6809) were the high in high-technology. 4 Mhz was blazingly fast and 4 k of memory was more than most people needed. Of course a co-processor helped. At the same time,
the help was needed.

Keep in mind that a 'modern' Allen Bradley PLC5/40 uses the Motorola 68030 CPU, roughly the equal of an Intel 80486-33. Yes, the PLC5's use co-processors, but only to handle things like communications with the outside world. Things that need reliability in their own right but can not be allowed to interrupt the potentially critical process the PLC proper is handling.

Ron Gage - Saginaw, MI
([email protected])
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

"Locke, Alan S" wrote:
>
> Gerry Hagberg wrote:
> >There have been a number of posts like 'scan should be less than
> >20msec.' which are somewhat meaningless without further
> >definition - akinto 'how long is a piece of string?'.
>
> True enough, but I believe the thread was considering the
> implications of scheduling precision with regard to
> standard Linux versus real time Linux.
>
> It seems some of the data available for scheduling
> precision is from using a bare minimum I/O transition
> program, so maybe a better look at this might be scan time
> for a single rung setting an output on receipt of an
> input using a signal generator and oscope. I've seen vendors
> demonstrate their PLC speed using this method before
> (using just standard rung instuctions), and it does
> give a pretty good look at how much time the housekeeping
> cycle eats up. PLCs I've seen are well under 10 msec scan
> with that setup (one was around 300 usecs!).

This is why I contend that we should get a bare minimum configuration up first. That would provide a test bed for obtaining this information and provide clear direction for the future. Instead we seem to be getting bogged down in
very high level details and philosophy. Nothing wrong with that, I guess, but much of it could be moot if basic design constraints dictate another approach. I am still proceeding along this path in the absence of like minded individuals.
From what I'm hearing we will have major subsystems designed before we know what we are going to run them on.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Wed, 19 Jan 2000, Locke, Alan S wrote:

> Gerry Hagberg wrote:
> >There have been a number of posts like 'scan should be less than
> >20msec.' which are somewhat meaningless without further
> >definition - akinto 'how long is a piece of string?'.
>
> True enough, but I believe the thread was considering the
> implications of scheduling precision with regard to
> standard Linux versus real time Linux.
>
> It seems some of the data available for scheduling
> precision is from using a bare minimum I/O transition
> program, so maybe a better look at this might be scan time
> for a single rung setting an output on receipt of an
> input using a signal generator and oscope. I've seen vendors
> demonstrate their PLC speed using this method before
> (using just standard rung instuctions), and it does
> give a pretty good look at how much time the housekeeping
> cycle eats up. PLCs I've seen are well under 10 msec scan
> with that setup (one was around 300 usecs!).
>
> This certainly doesn't provide much data on how fast a real
> ladder program will execute given the wide variety of instruction
> and rung lengths, but it does provide a baseline minimum
> possible scan time. Certainly if standard linux isn't providing
> reliable sub 10 msec for a simple process, there's reason
> to look toward RTLinux/KURT/UTIME Linux.
>
> I hope those few in the list with RTLinux/KURT/UTIME Linux experience
> will continue to help us drive these issues out while the rest
> are in the learning curve.

I'm no real time expert but I do understand the principals and I have been reading the rtl mail list for a while now.

I agree it will be a problem and we will have to use some sort of real time technique but at the moment it scans once every 20 years :cool:.

What I'm trying to say nicely is I think we need to get our soft PLC concepts sorted first (logic engine, io scanners, tools etc) and then
progress to speed of execution, scheduling and such heavy duty stuff.

So can you guys tell us all what effect RT will have on our coding techniques and function calls available to us and sugest what type of
routines should be grouped in seperate source files to allow easier conversion when the time comes.


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 Wed, 19 Jan 2000, Curt Wuollet wrote:

> "Locke, Alan S" wrote:
> >
> > Gerry Hagberg wrote:
> > >There have been a number of posts like 'scan should be less than 20msec.' which are somewhat meaningless without further definition - akinto 'how long is a piece of string?'.< < <
> >
> > True enough, but I believe the thread was considering the implications of scheduling precision with regard to standard Linux versus real time Linux.< <
> >
> > It seems some of the data available for scheduling precision is from using a bare minimum I/O transition program, so maybe a better look at this might be scan time for a single rung setting an output on receipt of an input using a signal generator and oscope. I've seen vendors
demonstrate their PLC speed using this method before (using just standard rung instuctions), and it does give a pretty good look at how much time the housekeeping cycle eats up. PLCs I've seen are well under 10 msec scan with that setup (one was around 300 usecs!). < <
>
> This is why I contend that we should get a bare minimum configuration up first. That would provide a test bed for obtaining this information and provide clear direction for the future. Instead we seem to be getting bogged down in very high level details and philosophy. Nothing wrong with that, I guess, but much of it could be moot if basic design constraints dictate another approach. I am still proceeding along this path in the absence of like minded individuals. From what I'm hearing we will have major subsystems designed before we know what we are going to run them on. <

Ok, for a simple and crude scheduling test lets write a programme that starts and runs for say 10 seconds. During that 10 seconds we loop
incrementing a counter and printing a char to the screen. At the end of the run we divide the counter by 10 and that gives us scans per second we can easily get a scan time from this.

Someone is bound to say that is not a real test as our PLC will be operating on internal data during the scan. This of course is not true as
the scan is the entire read io scan write i/o cycle which will take longer than this simple test.


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 11:22:39 2000 Dave West wrote...
>
>Ok, for a simple and crude scheduling test lets write a programme that
>starts and runs for say 10 seconds. During that 10 seconds we loop
>incrementing a counter and printing a char to the screen. At the end of
>the run we divide the counter by 10 and that gives us scans per second we
>can easily get a scan time from this.

An interesting experiment, however I think you will find this one dominated by screen update time.

>Someone is bound to say that is not a real test as our PLC will be
>operating on internal data during the scan. This of course is not true as
>the scan is the entire read io scan write i/o cycle which will take longer
>than this simple test.

Ah, but it's a good example of prototyping in the grand UNIX tradition.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Per my other post: LinuxPLC prototype, this is kinda what we need to answer some very basic questions and set some important directions.
And, even more important, let driver writers get a start. As we go forward, driver writers could use this basic tool to test and profile without dealing with the whole tree.

Curt W.


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

So how about a whole set of tests with loop counts and include all of the variables like writing to disk that we've been thinking about. Put it up on the site and we can all download it and report the results for our machines along with our machine details.

Post the results and compile stats.

Ray


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

Johan Bengtsson

What really is interesting is how often the logic is solved, to a lesser degree (it is not unimportant) how long time it takes. What really is the interesting part must be response time, ie the time from changing an input until the result is seen on the output. Everything in between should be quite uninteresting.

Since the actual solving will be quite fast it is the time from start-start (or actually end-end) that should concern people the most.

In a normal PLC the time from end-start is shorter (or should be, exceptions exist) than we could expect from the normal scheduler in Linux. (We *must* do a sleep or something similar,
other applications need processor time too and will have it anyway)


/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]ear.net.nz]

If I interpret Phil Covington's posts on RTL et al correctly:
- standard Linux allocates 10 msec slices of CPU time
- no user process can expect to get consecutive slices
- the interval between any one process' time slices could easily
vary from 10 - 100 msec
...<clip>

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

> What really is interesting is how often the logic is
> solved, to a lesser degree (it is not unimportant) how
> long time it takes.
> What really is the interesting part must be response time,
> ie the time from changing an input until the result is seen
> on the output. Everything in between should be quite
> uninteresting.
>
> Since the actual solving will be quite fast it is the time
> from start-start (or actually end-end) that should concern
> people the mest.
>
> In a normal PLC the time from end-start is shorter (or should
> be, exceptions exist) than we could expect from the normal
> scheduler in Linux. (We *must* do a sleep or something similar,
> other applications need processor time too and will have it
> anyway)

What other applications??????

We do not need to sleep at all. Are you a Windoze programmer perchance? We only have to do a syscall of any kind to allow another process a shot at the processor.

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
 
J

Johan Bengtsson

Actually yes, most of my programming have been for windows. It is however more a question of terminology since you dont get processor time until that syscall returns and other processes are running. That will make your process "sleep".


/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
 
On Sat, Jan 22, 2000 at 11:24:07AM +0000, Dave West wrote:
> On Sat, 22 Jan 2000 [email protected] wrote:
...
> > (We *must* do a sleep or something similar, other applications need
> > processor time too and will have it anyway)
>
> What other applications??????
>
> We do not need to sleep at all. Are you a Windoze programmer perchance?
> We only have to do a syscall of any kind to allow another process a shot
> at the processor.

That's why you don't do those kinds of syscalls in a time-critical process, no? (Only blocking calls should yield the processor, and most of those have an option for failing with EAGAIN instead.)

AFAIK if your process is running with static priority > 0, you by default starve anything with lower priority (SCHED_RR) or anything with lower or equal priority (SCHED_FIFO).

Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
<clip>
> > What other applications??????
> >
> > We do not need to sleep at all. Are you a Windoze programmer perchance?
> > We only have to do a syscall of any kind to allow another process a shot
> > at the processor.
>
> That's why you don't do those kinds of syscalls in a time-critical process,
> no? (Only blocking calls should yield the processor, and most of those have
> an option for failing with EAGAIN instead.)

Not true. Blocking calls *must* yield the processor. For non blocking it can depend on all sorts of stuff mainly the timer tick. Any way if you know that you must complete within 1 msec and it takes 10 usec to run you code wich calls say 5 syscalls but you also know that each one will return within 5 usec because no ther process takes longer than that to run before blocking then the standard kernel will allow you to complete well before deadline.

BTW can you name one blocking call that return EAGAIN and under which circumstances.

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, 22 Jan 2000 [email protected] wrote:

> Actually yes, most of my programming have been for windows
> It is however more a question of terminology since you dont
> get processor time until that syscall returns and other
> processes are running. That will make your process "sleep".

Yes definately terminology.
sleep is a standard function call (syscall).
A process that does not have the processor is not asleep it is waiting for some kernel service be it I/O or the processor or whatever. Thus the
process does not sleep it "waits".

Semantics yes I know, but it beats confusion any day :cool:

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, 2000 at 04:01:14PM +0000, Dave West wrote:
> BTW can you name one blocking call that return EAGAIN and under which
> circumstances.

open(2), read(2), write(2), maybe other related - when the O_NONBLOCK or O_NDELAY option was given to open(2) (not sure if open(2) itself can return
EAGAIN, but it certainly won't block)

semop(2) - when given the IPC_NOWAIT option and the operation would normally cause sleeping on the semaphore

msgsnd(2) - given IPC_NOWAIT and a full queue

msgrcv(2) - given IPC_NOWAIT and no message in the queue, but it will fail with ENOMSG rather than EAGAIN

Probably others, too. See section 2 of the manual. Basically, the
O_NONBLOCK/O_NDELAY/IPC_NOWAIT options turn blocking syscalls into non-blocking ones.

Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Actually, all the words are used for that concept :)

sleep(3) and wait(2) are both system calls [*].

However, the words "sleep" and "wait" are also used generically in the sense of waiting for some service, while other times the words "blocked" or
"suspended" are used. Presumably "pause" may be used in the same sense too, because of pause(2), but I don't recall seeing it anywhere.

See eg the manpages for semop(2), open(2) or wait(2).


Jiri
[*] technically, sleep(3) is a library call rather than a system call
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

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