M
Michael Griffin
(Originally posted Tue 07/07/1998)
Vladimir E. Zyubin wrote:
<clip>
>At Thu, 2 Jul 1998 00:42:29 -0400, Michael Griffin wrote:
>>For example, consider the following two systems:
>> A) A pneumatically operated pick-and-place.
>> B) A robot driven by electric servo drives.
<clip>
Someone earlier wrote:
>> >Control of the dam gates on a slow moving river may require a
>> >response time no faster than an hour;
<clip>
Vladimir E. Zyubin wrote:
> (?) It seems to me that the first example (dam gates) is
>very close to the case of the system "A" (pneumatically operated
>pick-and-place).
No, I believe that the example of the dam gates is a real time
system, while the pick-and-place is not. The gates are being used to control
the river level in real time. The fact that the response time is very slow
does not affect this fact. If the response from the gates does not meet the
necessary timing criteria, the river level is not controlled. This is
because the river will continue flowing whether the gate control system is
ready for it or not. In this case a late response is just as bad as no
response at all. This is what makes it a real time system.
In the example of the pneumatic pick-and-place, the P&P will sit
there until the control system initiates the next step in the movement
sequence. Control of the P&P does not depend upon meeting certain timing
schedules. Slow or erratic timing of the control will not affect whether the
pick-and-place is able to perform the correct motions. It will only affect
the process cycle time, which is another issue altogether. This is why this
is not a real time system.
>Moreover, I bet that a response time of 1 hour
>is not acceptable for the end user of the system "A", i.e., as
>well as in the case of the system "B", it means a loss of money.
>For the system "A" it means waste of energy. For the system "B" --
>waste of a half-finished product (or rather producing of
>goods we may, but don't agree to use
.
<clip>
We should not confuse the profitability of a production process
(which depends upon many things) with whether or not it is a real time
system. Several people have mentioned economic issues and I wish to state
that this is very much a red herring as far as whether or not something is a
real time system.
To add another twist to this discussion, if I were to use a computer
which had a "real time operating system" (e.g. QNX), and wrote software to
control the above mentioned pick-and-place, this does not suddenly make the
P&P a real time system. An RTOS is something which *may* be used as part of
a control for a real time system, but the mere presense of an RTOS (and
appropriate control software) does not automatically make the system it is
controlling a real time system.
Michael Griffin
London, Ont. Canada
Vladimir E. Zyubin wrote:
<clip>
>At Thu, 2 Jul 1998 00:42:29 -0400, Michael Griffin wrote:
>>For example, consider the following two systems:
>> A) A pneumatically operated pick-and-place.
>> B) A robot driven by electric servo drives.
<clip>
Someone earlier wrote:
>> >Control of the dam gates on a slow moving river may require a
>> >response time no faster than an hour;
<clip>
Vladimir E. Zyubin wrote:
> (?) It seems to me that the first example (dam gates) is
>very close to the case of the system "A" (pneumatically operated
>pick-and-place).
No, I believe that the example of the dam gates is a real time
system, while the pick-and-place is not. The gates are being used to control
the river level in real time. The fact that the response time is very slow
does not affect this fact. If the response from the gates does not meet the
necessary timing criteria, the river level is not controlled. This is
because the river will continue flowing whether the gate control system is
ready for it or not. In this case a late response is just as bad as no
response at all. This is what makes it a real time system.
In the example of the pneumatic pick-and-place, the P&P will sit
there until the control system initiates the next step in the movement
sequence. Control of the P&P does not depend upon meeting certain timing
schedules. Slow or erratic timing of the control will not affect whether the
pick-and-place is able to perform the correct motions. It will only affect
the process cycle time, which is another issue altogether. This is why this
is not a real time system.
>Moreover, I bet that a response time of 1 hour
>is not acceptable for the end user of the system "A", i.e., as
>well as in the case of the system "B", it means a loss of money.
>For the system "A" it means waste of energy. For the system "B" --
>waste of a half-finished product (or rather producing of
>goods we may, but don't agree to use
<clip>
We should not confuse the profitability of a production process
(which depends upon many things) with whether or not it is a real time
system. Several people have mentioned economic issues and I wish to state
that this is very much a red herring as far as whether or not something is a
real time system.
To add another twist to this discussion, if I were to use a computer
which had a "real time operating system" (e.g. QNX), and wrote software to
control the above mentioned pick-and-place, this does not suddenly make the
P&P a real time system. An RTOS is something which *may* be used as part of
a control for a real time system, but the mere presense of an RTOS (and
appropriate control software) does not automatically make the system it is
controlling a real time system.
Michael Griffin
London, Ont. Canada