How to compose PCs for semi-real time control.

  • Thread starter Yamashita Taiichiro none
  • Start date
Y

Thread Starter

Yamashita Taiichiro none

Hi, lists.
This is Yamashita, from Japan.

I want to ask you that what kind of composition should be for semi-real time control ?

I got an advice that if I use WinNT on PCs for semi-real time control of my productive equipment, the boot HDD should not be IDE but SCSI.

Because if I use IDE HDD for boot drive, some interupt could happen to prevent my process for semi-real time control, about 100ms time frame.

I'm not a PC's engineer but PLC's, so I don't know exactly about what he said, but is it right ?

And are there anything to attention for my purpose ?

I decide to use some industrial PC, may be Advantech which from Taiwan, so I could make up the PC freely.

Would you give me advice, please ?

Best regards.
------
Yamashita
 
J
If you need semi-real time control, you need an operating system to support that. WinNT out of the box does not, regardless of what sort of hard drive you use. There are many things that can cause NT to drop your process and ignore it for several seconds. Print drivers, disk access, rebuilding the desktop, etc.

Are you going to be writing your own control software, or evaluating different packages? If you are going to buy something off the shelf,
I would suggest getting one that adds real-time extensions to NT. I can not give any recommendations, as I personally would not trust
NT (or any PC control packages, for that matter) to run any off my processes. ( We are a dairy processing facility, and ANY glitch puts us down for about 6 hours at a minimum.)

I have heard rumors that Win2000 is supposed to be more stable. Perhaps you could evaluate real time control systems on Win2000?

If you are writing your own logic from scratch, I would suggest one of the real time versions of Linux. Linux is more stable, and if you
are writing your own controls from scratch, and are trying to do semi-real time, it would definitely be an advantage to have an operating system that supports realtime at the kernel.

just my $.02....

--Joe Jansen
 
C

Curt Wuollet

Hi Yashimata.

Yeah, Don't use NT alone if unpredictable delays are a problem. If timing is at all critical I'd use one of the RTOS under NT solutions or better yet, KURT or RTLinux.

Regards

Curt Wuollet, Owner
Wide Open Technologies
 
R

Ranjan Acharya

Semi-RT Control?

What do you mean by this?

For real-time control that means you cannot miss any stimulus -- for example if an event occurs at a 1kHz frequency then you must be scanning at a frequency of at least 2kHz -- so that you can
guarantee a response to every stimulus within a pre-defined amount of time. "A real-time system is one where the correctness of the computations not only depends on the logical correctness of
the computation but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred".

For non real-time control, then it does not matter if you miss the event -- the next one will do. The system is not deterministic and the delay to a stimulus may be so long that the next stimulus is missed.

As a controls engineer, I either want one or the other (typically the first).

Windows NT is not a real-time OS -- even Microsoft will tell you that. However, with a good choice of hardware (well engineered and
so on) it can be fairly robust -- witness Allen-Bradley's PC-based RSLogix system that uses plain-NT. Or there are hacks for NT that make it real-time somehow -- either running NT under a true
RT-OS (iRMX or INTime) or actually fiddling with NT (RTX). There is a lot of literature on the web about this -- some of it a little biased. I
personally do not hold with AB's statement that an OS crash is just like the good old stop light on the PLC. My problem with this is that PLC's really do not stop that often once you have everything laid our properly. Windows NT on the other hand has a mind of its own -- stable under only a very rigorous regime.

What is your choice of PC-based control? Talk to the engineers who wrote the package and ask them what they recommend. Your system must also be able so survive a system crash, hard-drive crash and based on a proven real-time engine.

The problems are not just IDE or EIDE versus SCSI but delayed interrupts -- the bane of real-time control under Windows NT (called a Deferred Procedure Call or DPC).

RJ
 
R

Ralphsnyder, Grayg

Why do you want to use a PC instead of a PLC for your application? Especially since you have PLC experience and recognize that there might be some problems that could interfere with your process.

Grayg Ralphsnyder
 
Joe Jansen responded to Yamashita:

-> -----Original Message-----
-> From: Yamashita Taiichiro none
[mailto:[email protected]]

-> -> Hi, lists. -> This is Yamashita, from
Japan. -> -> I want to ask you that what kind of composision
should be for -> semi-real time control ? -> -> I got an advice that if
I use WinNT on PCs for semi-real time control -> of my productive
equipment, the boot HDD should not be IDE but SCSI.

>If you need semi-real time control, you need an operating system to support that. WinNT out of the box does not, regardless of what sort of hard drive you use. There are many things that can cause NT to drop your process and ignore it for several seconds. Print drivers, disk access, rebuilding the desktop, etc.<

[Bill Code]

I am not sure about the above, if you code something like that below and run it (not everthing you need to do that is shown) Thread will consume all available CPU resource, not a single thing will happen on the desktop. There will be no response to keyboard or mouse input. This is what I would expect to happen in the case of a high priority thread in an endless loop. I expect (assume?) that the scheduler is running (and other parts of the OS). I understand the OS will boost the priority of UI threads, but not high enough to prevent this high pri one from
hogging all available CPU resource.

CWinThread* CWorker::Create()
{
if ( m_pthrdWorker == NULL )
{
m_pthrdWorker = AfxBeginThread( Thread, this,
THREAD_PRIORITY_NORMAL,
0, CREATE_SUSPENDED, NULL );

::SetPriorityClass( ::GetCurrentProcess(), REALTIME_PRIORITY_CLASS );
m_pthrdPLCCommWorker->SetThreadPriority( THREAD_PRIORITY_TIME_CRITICAL );
}
}

DWORD CWorker::Start()
{
ASSERT( m_pthrdWorker != NULL );
if ( m_pthrdWorker != NULL )
{
dwRetVal = m_pthrdWorker->ResumeThread();
}
}

void CWorker::WorkerThread()
{
while ( 1 )
{
// ::Sleep( 1000 );
}
}

static UINT Thread( LPVOID pParam )
{
CWorker* pPW = (CWorker*)pParam;
pPW->WorkerThread();
return 0;
}

[Bill Code] This is cut out of MS VC++ on-line doc:

REALTIME_PRIORITY_CLASS Specify this class for a process that has the highest possible priority. The threads of the process preempt the threads of all other processes, including operating system processes performing important tasks. For example, a real-time process that executes for more than a very brief interval can cause disk caches not to flush or cause the mouse to be unresponsive.

[Bill Code] End of MS VC++ doc. You could remove comment from the call to Sleep() and use
process viewer to see the priority of this thread at 31. In its current form the UI is not responsive so you couldn't see it. Caveat: I ran this test in the past. But the code is lost.
The eaxample code above was cut out and skeletonized from one of my applications. I did not compile the example, but the app it came from is running at several sites. If I get the time in the near future I will get the example running again. It needs the usual Win32 infrastructure to create and start the thread. But, it gives you the idea of what I did. Note that Thread is a friend of CWorker class.

>Are you going to be writing your own control software, or evaluating different packages? If you are going to buy something off the shelf,
I would suggest getting one that adds real-time extensions to NT. I can not give any recommendations, as I personally would not trust
NT (or any PC control packages, for that matter) to run any off my processes. ( We are a dairy processing facility, and ANY glitch puts us down for about 6 hours at a minimum.)<

[Bill Code] If you are writing your own, then control tasks can be
implemented with deamons having above structure, but using events
to signal execution when required. If you can live with a response
window of 10mS-20mS (about the same as a PLC) the above structure
will be fine.

>I have heard rumors that Win2000 is supposed to be more stable. Perhaps you could evaluate real time control systems on Win2000? <

>If you are writing your own logic from scratch, I would suggest one of the real time versions of Linux. Linux is more stable, and if you are writing your own controls from scratch, and are trying to do semi-real time, it would definitely be an advantage to have an operating system that supports realtime at the kernel.<

Bill Code
MPM Engineering Ltd.
4-6240 202nd St., Langley, B.C., Canada, V2Y-1N2
Phone: 604-534-6605 Fax: 604-534-6693
E-Mail: [email protected] WWW: http://WWW.MPM-ENG.COM
 
Y

Yamashita Taiichiro

Hi, Mr. and Lists.
This is Yamashita.

First of all, I cannot use the RT-Linux, because I/O driver is not compatible for Linux. Control processes would be made from scratch by me, but the I/O driver be purchased from OMRON.

Anyway, you said that you refered to print drivers, disk access, rebuilding the desktop, etc, but will they interupt my process cyclicly or suddenly or some occasion which I dont wanna do that ?

In the case of print drivers, I guess, if we dont use printer, it will do nothing. #I don't know exactly about what happened inside of the WinNT, because I'm just an user, not developer.

How about HDD ? Are there any differences between IDE and SCSI ? And what the heck is the rebuilding the desktop ?

Would you mind if I ask you to explain from the technical point of view ?

Best regards.
----
Yamashita.
 
R

Ranjan Acharya

<clip>
How about HDD ? Are there any differences between IDE and SCSI?
</clip>

Why all the focus on the hard drive?

There are tons of differences between IDE and SCSI -- for example are you going to use a SCSI array accelerator and move your drive control (with RAID options) away from your OS into hardware.

But why are you putting all your focus on the hard drives? As outlined by other members -- do not forget the mouse, keyboard, DPCs et cetera. The underlying problems with Windows NT and real-time operation are considerably more than just the hard drives.

Again, Windows NT is not a real-time operating system. If you want true real time then consider iRMX or other enhancements to NT as already
mentioned -- then you do not have to worry about SCSI drives or EIDE/IDE drives.

Also, do you need real-time operation or not -- you originally mentioned semi-RT which is a little befuddling.

RJ
 
V

Vladimir Bunyakin

Hi,

Yamashita Taiichiro wrote:

> I want to ask you that what kind of composision should be for
> semi-real time control ?
>
> I got an advice that if I use WinNT on PCs for semi-real time control
> of my productive equipment, the boot HDD should not be IDE but SCSI.
>
> Because if I use IDE HDD for boot drive, some interupt could happen to
> prevent my process for semi-real time control, about 100ms time frame.

According to my tests maximum delay caused by system activity (extensive disk and video operations) was 1 ms for REALTIME_PRIORITY_CLASS process, THREAD_PRIORITY_TIME_CRITICAL thread. System: Intel CA810EA motherboard, Celeron 466 processor, IDE disk, NT4 SP4. Test lasted approximately 8 hours.

> I'm not a PC's engineer but PLC's, so I don't know exactly about what
> he said, but is it right ?

No, it isn't. At least among tested systems I haven't seen delays greater than 18 ms (all systems were IDE, not SCSI; not slower than P133).

> And are there anything to attention for my purpose ?
>
> I decide to use some industrial PC, may be Advantech which from
> Taiwan, so I could make up the PC freely.
>
> Would you give me advicis, please ?

If you are PLC engineer and have an intention to use NT for 'semi-real time control', you can find interesting general information here:

http://www.openautomation.com/controlpak/helpers/scripts/producthome.asp?product=sl5

and testing results here:

http://www.openautomation.com/controlpak/products/sl5/Softlogix5Performance.asp

You can find figures like 1 - 20 ms in this paper, but definitely not N x 100 ms.

--
Sincerely,
Vladimir Bunyakin.
 
J
-> -> Hi, Mr. and Lists.
-> This is Yamashita. -> -> First of all, I cannot use the RT-Linux,
because I/O driver is not -> compatible for Linux. Control processes
would be made from -> scratch by me, but the I/O driver be
purchased from OMRON. -> -> Anyway, you said that you refered
to print drivers, disk access, -> rebuilding the desktop, etc, but will
they interupt my process -> cyclicly or suddenly or some occasion
which I don wanna do that ?

Sporadically. A lot of it depends on what users on the system do. If a user opens up a window, and then closes it again, the OS takes time away to redraw all of the icons, wallpaper, and other
eye-candy on the screen. Usually this is pretty quick. Occasionally, and for reasons beyond me, it has to retry several times to get it right. your app is in a unknown state during this.

-> In the case of print drivers, I guess, if we dont use
-> printer, it will -> do nothing. #I don't know exactly about what
happened inside of the -> WinNT, because I'm just an user, not
developer. -> -> How about HDD ? Are there any differences between IDE and SCSI?

Yes. SCSI is faster transfer rate, and lets you put more of them in the system. IDE is typically limited to 4 devices, and moves data slower. Unless you are doing a lot of data logging, however, this should not matter to your app. More at issue are unpredictable OS activity. Especially if this system is open for the users to play with. If you can lock down the system away from operators, you can get a better chance of keeping things running predictably.

-> ? And what the heck is the rebuilding the desktop ?

See above
 
A
Yamashita.

We have supplied an extension to WindowsNT called RTX, produced by VenturCom (www.venturcom.com). This extension makes NT more deterministic and robust, and hence suitable for real-time control
(though depending upon the specifics of your application your results may vary). The people at CICS Automation (www.cicsauto.com.au) who make
a package called UNAC that uses VenturCom RTX have some good war stories of using this package.

I hope this helps


Andy [email protected]___

Advanced Control Technology Club, Industrial Systems and Control Ltd.,
50 George Street, Glasgow, G1 1QE Tel: (+44) 0141 553 1111
http://www.isc-ltd.com/actclub.html Fax: (+44) 0141 553 1232
 
J
-> [Bill Code]
->
-> I am not sure about the above, if you code something like
-> that below and run it
-> (not everthing you need to do that is shown) Thread will
-> consume all available
-> CPU resource, not a single thing will happen on the desktop.
-> There will be no
-> response to keyboard or mouse input. This is what I would
-> expect to happen in the
-> case of a high priority thread in an endless loop. I expect
-> (assume?) that the
-> scheduler is running (and other parts of the OS). I
-> understand the OS will boost
-> the priority of UI threads, but not high enough to prevent
-> this high pri one from
-> hogging all available CPU resource.

<code snipped>

So if it hogs the entire system, what do you gain over a PLC? You have no HMI functionality, you lose all of the multi-tasking function, you basically have a locked system that has "no response to keyboard or mouse input" as you put it. It least with a PLC I can drag a laptop over and plug in to see what is going on. I couldn't even do that with this.

-> [Bill Code] This is cut out of MS VC++ on-line doc:
->
-> REALTIME_PRIORITY_CLASS Specify this class for a process
-> that has the highest possible
-> priority. The threads of the process preempt the threads of
-> all other processes, including
-> operating system processes performing important tasks. For
-> example, a real-time process
-> that executes for more than a very brief interval can cause
-> disk caches not to flush
-> or cause the mouse to be unresponsive.

Please read the above again carefully.

If you give a timeslice back to the OS to do it's thing, you risk losing it.
I stand by all of my earlier statements.

--Joe Jansen
 
Bill Code writes:

Please refer to the code in the original post.

The point was missed here...
The technique elucidated in the code is one I use frequently. I stated that it must run in response to an event. And in a real system the duty cycle must be less than 100% or, yes the system will be 'locked up'. The example is meant to show that an
application programmer can implement threads that will not be pre-empted by OS activities on the desktop, etc. Instead of the endless loop, picture some code that executes in about 5mS and
has to run about every 20mS. It would not be pre-empted by NT rebuilding desktops (taken to mean UI stuff), and if it is not blocked at the end of quantum n it would run in the quantum n+1 .

In the example, if the code in the loop executes in 10mS and then we put the thread to sleep at the bottom of the inner loop for 30mS then 75% - ( % used by scheduler small ) is available for UI and the stuff MS warns about below. System remains responsive to the user.

-> [Bill Code]
->
-> I am not sure about the above, if you code something like
-> that below and run it
-> (not everthing you need to do that is shown) Thread will
-> consume all available
-> CPU resource, not a single thing will happen on the desktop.
-> There will be no
-> response to keyboard or mouse input. This is what I would
-> expect to happen in the
-> case of a high priority thread in an endless loop. I expect
-> (assume?) that the
-> scheduler is running (and other parts of the OS). I
-> understand the OS will boost
-> the priority of UI threads, but not high enough to prevent
-> this high pri one from
-> hogging all available CPU resource.

<code snipped>

So if it hogs the entire system, what do you gain over a PLC? You have no HMI functionality, you lose all of the multi-tasking function, you basically have a locked system that has "no response to keyboard or mouse input" as you put it. It least with a PLC I can drag a laptop over and plug in to see what is going on. I couldn't even do that with this.

[Bill Code] A real application would not have the endless loop in the hi-priority thread. The example was intended to show that it is possible for an application to not yield to all of NTs threads. My experience with PLCs is that a scan period of 20ms-40mS is typical. The same order of response is available in NT. I am not claiming that NT is real-time, the original post specified "semi real-time". I am assuming that time periods discussed within are "semi real-time". Other discussions on the list describe "real-time" response to be less than the periods we are talking about here.

-> [Bill Code] This is cut out of MS VC++ on-line doc:
->
-> REALTIME_PRIORITY_CLASS Specify this class for a process
-> that has the highest possible
-> priority. The threads of the process preempt the threads of
-> all other processes, including
-> operating system processes performing important tasks. For
-> example, a real-time process
-> that executes for more than a very brief interval can cause
-> disk caches not to flush
-> or cause the mouse to be unresponsive.


Please read the above again carefully.

[Bill Code] Read it many times and practice it frequently. I have developed many installed systems running 24/7 on NT 4.0 Workstation. Typically they have several hi-pri threads as described within. Obviously, they are designed so no thread hogs the processor resource. Otherwise I probably would have only sold one, and hypothetically that one have been returned to me and someone would have wanted their money back.

If you give a timeslice back to the OS to do it's thing, you risk losing it. I stand by all of my earlier statements.

[Bill Code] The thread would get it back at the start of the next quantum if its priority is still high.

--Joe Jansen
 
P

Phil Covington

FWIW I have collected the following data since Jan 1999 on PC systems that I have worked with:

The test program was set at REALTIME_PRIORITY_CLASS +
THREAD_PRIORITY_TIME_CRITICAL priority.

The system descriptions follow the test data. As you can see, the PC's hardware is nothing special...

Regards,

Phil Covington


Standard Desktop "Workstation" PCs ranging from PII 350s to PIII 550s

OS: NT4 and W2K

Running Test Logic Solver Program (1000 instructions)

Scan Rate: 20 ms Logic Solve: 5 ms Running Time: 4 hours
Priority: REALTIME_PRIORITY_CLASS + THREAD_PRIORITY_TIME_CRITICAL

Soft PLC running alone
System Min Max Ave

1 19 21 20
2 19 22 20
3 19 21 20
4 19 21 20
5 19 21 20
6 19 21 20
7 19 21 20
8 19 22 20
9 19 21 20
10 19 21 20
11 19 21 20
12 19 21 20
13 19 22 20
14 19 21 20
15 19 21 20
16 19 22 20
17 19 21 20
18 19 22 20
19 19 21 20
20 19 21 20
21 19 21 20
22 19 22 20
23 19 22 20

Soft PLC running w/ disk activity (Copying 500 MB file)

System Min Max Ave

1 19 23 20
2 19 24 21
3 19 22 20
4 19 25 20
5 19 23 20
6 19 20 20
7 19 25 21
8 19 24 20
9 19 23 20
10 19 23 21
11 19 22 20
12 19 22 20
13 19 24 20
14 19 23 20
15 19 21 20
16 19 21 20
17 19 22 20
18 19 21 20
19 19 22 20
20 19 22 20
21 19 22 20
22 19 22 20
23 19 21 20

Soft PLC w/ Heavy File, Network, and GUI Operations

System Min Max Ave

1 19 43 22
2 19 44 23
3 19 40 21
4 19 39 21
5 19 41 21
6 19 42 20
7 19 41 21
8 19 44 22
9 19 43 21
10 19 43 21
11 19 42 20
12 19 43 21
13 19 41 20
14 19 39 20
15 19 41 21
16 19 40 22
17 19 37 20
18 19 36 20
19 19 39 20
20 19 38 20
21 19 32 20
22 19 33 20
23 19 35 20


System 1 (1/28/1999) S/N:02844980
CPU: PII 350 Slot 1
RAM: 64 MB PC100 (8x64)
HD: IBM IDE/UDMA 10.1 GB 5400 rpm
MB: GA-6BXC Slot 1
VID: SIS 6326 2X AGP 8MB
OS: NT4

System 2 (2/8/1999) S/N: 02862432
CPU: PII 350 Slot 1
RAM: 64 MB PC100 (8x64)
HD: Quantum IDE/UDMA 10.2 GB 5400 rpm
MB: GA-6BXC Slot 1
VID: SIS 6326 2X AGP 8MB
OS: NT4

System 3 (2/8/1999) S/N: 02862431
CPU: PII 350 Slot 1
RAM: 64 MB PC100 (8x64)
HD: Quantum IDE/UDMA 10.2 GB 5400 rpm
MB: GA-6BXC Slot 1
VID: SIS 6326 2X AGP 8MB
OS: NT4

System 4 (2/19/1999) S/N: 02873313
CPU: PII 350 Slot 1
RAM: 64 MB PC100 (8x64)
HD: IBM IDE/UDMA 10.1 GB 5400 rpm
MB: GA-6BXC Slot 1
VID: SIS 6326 2X AGP 8MB
OS: NT4

System 5 (2/22/1999) S/N: 02875861
CPU: PII 350 Slot 1
RAM: 64 MB PC100 (8x64)
HD: IBM IDE/UDMA 10.1 GB 5400 rpm
MB: GA-6BXC Slot 1
VID: SIS 6326 2X AGP 8MB
OS: NT4

System 6 (2/24/1999) S/N: 02879146
CPU: PII 350 Slot 1
RAM: 64 MB PC100 (8x64)
HD: IBM IDE/UDMA 10.1 GB 5400 rpm
MB: GA-6BXC Slot 1
VID: SIS 6326 2X AGP 8MB
OS: NT4

System 7 (3/15/1999) S/N: 901085
CPU: PII 350 Slot 1
RAM: 64 MB PC100 (8x64)
HD: IBM IDE/UDMA 10.1 GB 5400 rpm
MB: GA-6BXC Slot 1
VID: SIS 6326 2X AGP 8MB
OS: NT4

System 8 (4/20/1999) S/N: 003040688
CPU: PII 400 Slot 1
RAM: 64 MB PC100 (8x64)
HD: WD IDE/UDMA 10 GB 5400 rpm
MB: GA-6BXC Slot 1
VID: ATI 3D AGP 8MB
OS: NT4

System 9 (4/20/1999) S/N: 003040686
CPU: PII 400 Slot 1
RAM: 64 MB PC100 (8x64)
HD: WD IDE/UDMA 10 GB 5400 rpm
MB: GA-6BXC Slot 1
VID: ATI 3D AGP 8MB
OS: NT4

System 10 (4/22/1999) S/N: 003040705
CPU: PII 400 Slot 1
RAM: 64 MB PC100 (8x64)
HD: Quantum IDE/UDMA 10.2 GB 5400 rpm
MB: GA-6BXC Slot 1
VID: ATI 3D AGP 8MB
OS: NT4

System 11 (6/3/1999) S/N: 003137066
CPU: PII 400 Slot 1
RAM: 64 MB PC100 (8x64)
HD: Quantum IDE/UDMA 10.2 GB 5400 rpm
MB: GA-6BXC Slot 1
VID: SIS 6326 2X AGP 8MB
OS: NT4

System 12 (6/3/1999) S/N: 003137077
CPU: PII 400 Slot 1
RAM: 64 MB PC100 (8x64)
HD: Quantum IDE/UDMA 10.2 GB 5400 rpm
MB: GA-6BXC Slot 1
VID: ATI 3D AGP 8MB
OS: NT4

System 13 (6/23/1999) S/N: 003154561
CPU: PII 400 Slot 1
RAM: 64 MB PC100 (8x64)
HD: Quantum IDE/UDMA 10.2 GB 5400 rpm
MB: Soyo SY6BA Slot 1
VID: ATI 3D AGP 8MB
OS: NT4

System 14 (10/25/1999) S/N: 003240141
CPU: PIII 450 Slot 1
RAM: 64 MB PC100 (8x64)
HD: Quantum IDE/UDMA 10.2 GB 5400 rpm
MB: GA-6BXC Slot 1
VID: ATI 3D AGP 8MB
OS: NT4

System 15 (11/24/1999) S/N: 003282341
CPU: PIII 500 Slot 1
RAM: 128 MB PC100 (16x64)
HD: Quantum IDE/UDMA 8.4 GB 5400 rpm
MB: GA-6BXC Slot 1
VID: Clabs 3DFX AGP 16MB
OS: NT4

System 16 (11/24/1999) S/N: 003282340
CPU: PIII 500 Slot 1
RAM: 128 MB PC100 (16x64)
HD: Quantum IDE/UDMA 8.4 GB 5400 rpm
MB: GA-6BXC Slot 1
VID: Clabs 3DFX AGP 16MB
OS: NT4

System 17 (2/17/2000) S/N: 003425652
CPU: PIII 500 Slot 1
RAM: 128 MB PC100 (16x64)
HD: Quantum IDE/UDMA 13 GB 5400 rpm
MB: P6PROA+ Slot 1
VID: Clabs 3DFX AGP 16MB
OS: W2K

System 18 (2/17/2000) S/N: 003425653
CPU: PIII 500 Slot 1
RAM: 128 MB PC100 (16x64)
HD: Quantum IDE/UDMA 13 GB 5400 rpm
MB: P6PROA+ Slot 1
VID: Clabs 3DFX AGP 16MB
OS: W2K

System 19 (2/17/2000) S/N: 003425654
CPU: PIII 500 Slot 1
RAM: 128 MB PC100 (16x64)
HD: Quantum IDE/UDMA 13 GB 5400 rpm
MB: P6PROA+ Slot 1
VID: Clabs 3DFX AGP 16MB
OS: W2K

System 20 (2/17/2000) S/N: 003425651
CPU: PIII 500 Slot 1
RAM: 128 MB PC100 (16x64)
HD: Quantum IDE/UDMA 13 GB 5400 rpm
MB: P6PROA+ Slot 1
VID: Clabs 3DFX AGP 16MB
OS: W2K

System 21 (3/28/2000) S/N: 003477643
CPU: PIII 550 S370
RAM: 128 MB PC100 (16x64)
HD: Quantum IDE/UDMA 10 GB 5400 rpm
MB: Apollo Pro 133 S370
VID: nVidia Vanta AGP 16MB
OS: W2K

System 22 (3/28/2000) S/N: 003477642
CPU: PIII 550 S370
RAM: 128 MB PC100 (16x64)
HD: Quantum IDE/UDMA 10 GB 5400 rpm
MB: Apollo Pro 133 S370
VID: nVidia Vanta AGP 16MB
OS: W2K

System 23 (3/30/2000) S/N: 003484182
CPU: PIII 550 S370
RAM: 128 MB PC100 (16x64)
HD: Quantum IDE/UDMA 10 GB 5400 rpm
MB: Apollo Pro 133 S370
VID: nVidia Vanta AGP 16MB
OS: W2K
 
"semi-real time"

What on earth do you mean by this statement? I am familiar with Hard Real-Time and Soft Real-Time, but semi? Out of the box Windows NT does support Soft Real-Time. What it doesn't do out of the box is meet Hard Real-Time requirements. I've written a timing application and ran it as a Real-Time process in Windows NT and then banged the keyboard and mouse, had a process that went through every drive and directory on the system and cataloged all the files on the system, another application transferring data from a network machine. I set a schedule of 10ms for my Real-Time application to update. It updated in 10ms approximately 90% of the time. In no situation did it miss the schedule by more than 20% (12ms) This fails miserably when you are looking for Hard Real-Time control, however for Soft Real-Time or what you would call "semi" it is acceptable.

Drop the Windows NT Real-Time process for several seconds? Nothing that would normally happen on a PC will do that.

Dale Ross
Mitsubishi Electric Automation

WinBBS +1.704.588.2669
http://WinBBS.DynIP.com/ telnet://WinBBS.DynIP.com:8080

"These are my opinions and not necessarily those of Mitsubishi
Electric Automation"
 
P

Phil Covington

----- Original Message -----
From: "Jansen, Joe" <[email protected]>

> <code snipped>
>
> So if it hogs the entire system, what do you gain over a PLC? You have no
> HMI functionality, you lose all of the multi-tasking function, you
basically
> have a locked system that has "no response to keyboard or mouse input" as
> you put it. It least with a PLC I can drag a laptop over and plug in to
see
> what is going on. I couldn't even do that with this.

In the real world with modern PC hardware, the logic execution time is going to much less than the scan time. So if in your soft PLC you set the scan time to be 20 ms and your logic execution time is 2 ms, you have 18 ms to Sleep() The system is not locked then...

<snip>

> If you give a timeslice back to the OS to do it's thing, you risk losing
it.
> I stand by all of my earlier statements.
>
> --Joe Jansen

True, but see my other post to this list about the actual tests I have done with standard off-the-shelf PC hardware running NT4 and W2K. Under very heavy disk, network, and GUI activity ( an artificial worst case situation ) the maximum scan time that I have seen is 45 ms in testing 23 systems for a desired scan time of 20 ms. This 40+ ms peak usually happened for only a few scans out of a four hour test period. While not terrible, this definitely demonstrates the non-real-time nature of NT. Even in this worst case the *average* scan time over a four hour period was very close to the 20 ms target. Older hardware with their associated drivers are responsible for the 100+ ms claims made in the literature available on NT for control. Usually the offending items were certain manufacturers video cards and older IDE controllers. People seem to forget that PC hardware is advancing at a
faster pace than authors can write papers about their test findings on the hardware. A lot of the info out there on NT running on PC hardware for control is outdated now.

The more typical case of running an HMI, normal network activity, opening and copying large files, the peak scan times were around 24 ms. The other lower priority applications were still very responsive and the CPU utilization of the real-time program was 18-23%. The average scan time over a four hour period was right at the 20 ms target. So under normal conditions, using modern PCs and NT, reasonable PLC-like scan times can be achieved...

There are many cases where I would not use a PC for control instead of a PLC. But in cases where scan times in the 20-50 ms range are acceptable and the process/machine your are trying to control is not extremely critical or life threatening, I would not hesitate using bare W2K for control. There are many successful applications running out there right now.

Regards,

Phil Covington

PS I was one of the people on the LinuxPLC list that argued in favor of using RT-Linux or KURT early on (back in Jan...)
 
P
Dale Ross mentioned the results of a test of the real time determinacy that he did on NT. It was an encouraging result. I do not know the inside workings of NT but if the clock that his program was using to time its accuracy of execution was a software clock, the result is suspect. Better to use a hardware clock of some kind or output
a signal on a digital output and measure the times with external equipment.

What was the time resolution of the clock? For how long was the test run?

Peter Clout

Peter Clout
Vista Control Systems, Inc.
176 Central Park Square
Los Alamos, NM 87544-3012
(505) 662-2484
FAX (505) 662-3956
[email protected]
http://www.vista-control.com
 
Y

Yamashita Taiichiro

Hello friends, this is Yamashita.

My system is a combination of PLC and WinNT.
For "real" real-time control, PLC could be used, and for user interface and for data strage and data transefer, WinNT used.

So, I don't need real time response for WinNT, but when PLC request for data, it should respond in about 100ms to 1000msec time frame.

I'm using "Sysmac board", which is same as C200HX, OMRON's PLC, and connected to PC via ISA bus, and there is a bottleneck in this driver,
so the data transeaction should over 100ms at least.

If my process always work under this time frame, 100ms to 1000msec, there might be no problem, but if there are some unpredictable interruption from hardwares or OS and stop my process over 1 sec or
more, PLC will decide WinNT hung up and the fail-safe system should work.

So, I used the term *semi-* real time for WinNT used this purpose.

I know WinNT don't grantee the real time response, so when I write a code below, it cannot trust i should really be done in every 1000msec
time frame.

while (1) {
Sleep(1000);
}

That is a problem for me.

I should appologize if I make you all confuse to use the phrase *semi-*, but I just know how to compose to make decrease the risk to interrupt my process.

That's all.

BTW, basically, I don't trust the WinNT, so, I don wanna use WinNT, or Microsoft-made OS which is not provided source code for industrial
control system.

In this case, I seek a combination of RTOS + softwarePLC, but in Japan, to use PC for industrial control purpose, so only QNX and IsaGraf is available from only one distributer.

To use PC for our productive equipment is the first experiance for our factory, so this situation is great anxiety.

That's reason which I decided to use the combination of WinNT + PLC.

But, from this ML, in other contries, it seems software PLCs wide spreaded, so I want to know more about the combination of RTOS and software PLCs.

Best regards.

------
Yamashita.
 
Did you write this program "Test Logic Solver"? If so which language? Do you mind sharing the code to this program?

Dale Ross
Mitsubishi Electric Automation

WinBBS +1.704.588.2669
http://WinBBS.DynIP.com/ telnet://WinBBS.DynIP.com

"These are my opinions and not necessarily those of Mitsubishi Electric Automation"
 
J
-> I would not hesitate using bare W2K for
-> control. There are many successful
-> applications running out there right now.
->
-> Regards,
-> Phil Covington

Sorry, but i couldn't resist begging the question of 'many' successful W2K apps. ;^} Given the newness of W2K.

All other aside, I concede that W2K is (probably, I haven't seen it yet) much more capable of keeping up. I am amused that for years, MS has been arguing that NT4.0 is amazingly stable, doesn't lock up, blah blah blah, and now all of the marketing for W2K emphasizes how it is 'More stable than NT4.0' and requires less reboots than NT4.0. This makes me somewhat suspect, and amused.
 
Top