We are going to build a critical Data acquisition and control system. We are currently in the system design stage. We are considering a PLC based system. but it is posing some implementation problems.
Our control system is required to be interfaced to GPIB devices and we are considering Ethernet to GPIB converters for driving these GPIB based
devices. Most of the drivers for ENET-GPIB converters are available for Windows platforms. So we are forced to think for an alternative like a PC based system on Win NT or so.
I have read somewhere else not through this
site about reliability of Win NT based system and I am of the view that Win NT may crash at any time so not reliable for critical control systems.
Even VxWorks is also not ruled out but then again ENET-GPIB driver is not available and we have to develop a driver. More over VxOPC (OPC compatible
product on VxWorks) is extremely costly. So that is the reason we are assessing the reliability and performance of a control system on NT platform.
What do you automation guys comment on the reliability of such a control system running on NT. Are there any critical systems built on NT providing performance like PLC?
> What do you automation guys comment on the >reliability of such a control system
> running on >NT. Are there any critical systems built on NT >providing performance
> like PLC?
Yes, there are. Particularly, the automotive manufacturers, especially GM, use NT based control systems. My company has shipped a number of Windows-based control systems that are "critical". Also, if you go to NASA's Johnson Space Center in Houston you will see that the control room consists entirely of Windows-based systems.
However, what do you mean by "critical?" If you are running a nuclear power plant or controling a jet airplane, I would not use NT. It's true that NASA uses Windows on the ground, but the International Space Station is run on QNX, not Windows. If something is going to blow up due to a crash, I would say Windows is not your best
In particular for the problem you are talking about (lots of GPIB and Ethernet) there is a programming language called LabView that runs on NT. National Instruments will be happy to tell you about all the critical systems they are
running around the world based on LabView. They also offer alternatives if you are still nervous about NT.
Hope that helps,
Sage Automation, Inc.
Again, let's distinguish between PC control and control using NT. I have found PCs to be very reliable. At least on par with PLCs and perhaps better in our environment. But then, I don't use the world's least reliable family of operating systems as a basis for automation and control.
I'm sure the DOS, QNX, SoftPLC, and other Linux users will concur. I have yet to hear of a PC basher who has used them with reliable software and I would be very interested in hearing from them. The choice of Windows has severely inhibited the use of PCs in automation and for some reason the blame always falls on the hardware.
I have had 1 hardware failure in the last 4 years and that was because a cabinet cooler leaked water on the motherboard. I suspect this would kill your typical PLC as well. It is a crucial distinction to make as we go forward. I have found that even the problems normally attributed to hardware,(bad hdd, spontaneous reboots, comm dropouts, video, etc.) are much less prevalent on the Linux machines. Some of this, no doubt, is due to the fact that there is far less software running on my normal Linux installation or the other alternatives but, shouldn't that be the case for a dedicated machine? That is probably _why_ PLCs are so reliable. I just get tired of the PC platform getting a bad rap because of irrational engineering decisions. It's indefensible to pick the least reliable option for marketing reasons.
And from my research, the automakers weren't demanding NT, they were demanding Open Systems and they still don't have them. All they were offered were systems running on Windows or totally closed systems and they empted for the slightly more open choice. It's still a vast
opportunity providing them with what they really want. It's a great opportunity waiting for the first large provider of truly open systems.
I hear FOrd in Europe is evaluating Linux.
the quick and dirty (from my opinion and experience) is no, never, wouldn't try it for a critical application. NT provides too much overhead and instability. Also, for any critical application i have had to do, I NEED the processor and did not want unknowns in terms of processor usage and memory manangement. NT also does not provide a secure and 100% reliable way to kill and launch processes when the system
hangs (or worse, the BSOD).
If you are doing DAQ with a large amount of data you will want to look into compartmentalizing the data collection locally. (maybe even embedded WIN CE) Several nodes performing data collection will reduce ETH overhead and allow the control system to operate reliably. I am not directly familiar with GPIB, but have read that there is an Ethernet wrapper for it which should be in the marketplace somewhere.
You mention critical, HOW critical? Level 4/4 endangerment (i.e. presses, etc.)? Critical in terms of rapid response?
Linux is very robust (which is why over 60% of web servers are running it) but has drawbacks in the development area. Also, I have not heard of a Linux system COMPLETELY crashing. Services and applications running on the OS will crash, but
overall you would not need to reboot the system to handle relaunching these apps.
Please feel free to contact me directly.
When I see the word GPIB I think the control system will be placed in a lab. When putting together a control system with DAQ cards GPID and TCP/IP your in for heavy system engineering and maintenance.
Please take a look at some small DCS systems like the Emmerson DeltaV or Yokogawa's CS1000 or Stardom. It reduces your engineering cost, its easy to maintain and runs on NT.
Further is it also important to know how many people will want to look at te control system. If this are many people or when the proces is very critical you might consider to install a unix based control system.
If this is a critical system I wouldn't run NT. Do you need more than one GPIB bus because the instruments are spread out? GPIB can be
interesting for a critical system as well. IF you don't need too many seperate busses, another approach would be to use an SBC or PC as a data concentrator/messager and send the results back on ethernet. Most instruments also have at least a serial option and this may be a better bet for distributed instruments and considerably cheaper as well. I've found IEE488 or GPIB to be at it's best for a cluster of equipment in one location. It helps a lot if the equipment is all made by the same manufacturer as well. I've not found mixing and matching to be a high reliability option and the cabling can be very particular. UNLISTEN UNTALK. I know how I'd do it, but it sounds like you've kinda decided and want post-decision support. Good Luck!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Consultancy: Wide Open Technologies: Moving Business & Automation to
We did a data acquistion system based on NT a little over two years ago. The system is composed of six PC's spread over a plant floor collecting data from 1200 knitting machines. Four digital inputs are provided for each knitting machine. Each PC is responsible for monitoring from 150 to 250 machines. The inputs are fed to the PC's via Profibus. There are approx 50 Profibus nodes. The information is sent to a SQL Server database. The system
experiences 750,000 to 1.5 million records added to the SQL Server each 24 hours. For safety's sake we provided a hot backup PC for each of the six data collection PC's - the system also generates employee payroll reports based on production. For the over two year period that the system has been in operation, NT has been a very stable platfom - even given operator errors
and events such as unplanned power outages, etc.
Hope this helps,
In your mail you state that there are only NT based drivers for the GBPI-ENET converter. Some years ago however I have used a GPIB-ENET converter from National Instruments with a driver running on Sun Solaris and on IBM AIX (both Unix platforms). I think this driver will still be available. If the only reason for going to NT is the unavailability of GPIB drivers on other platforms I would advice to do some further
investigation before making NT as your final choice.
NT and Windows 2000 seems to be fairly stable if you use them solely for a SCADA application. If you add all kind of other applications (like office application) your system will become unstable.
Furthermore how do you define critical? Is it a nuclear power plant or a building management system or something else. When you mention critical you should consider the probability of a failure of your system and the impact of the failure. A failure of a system controlling a nuclear power plant can be very desastrous. A failure of a system controlling the airco in your building will have less impact (only some inconvenience).
Two points need to be considered here:
1. Critical control system...usually safety and lives are at stake, forget NT for this. M$ did not make NT for a 24/7/52 zero downtime application.
2. Critical Data Acquisition...Whole other ballgame: NT is acceptable since safety and lives are not at stake (usually).
What you probably need to do is to split your architecture in some way, logging data is not the same as controlling a process. Some people say NT is OK to be used for controls. If NT were OK, why not use it in nuclear plants, or burner management or any other critical system.
The fact remains that NT is NOT used for critical controls (zero downtime) in automation. If it is, please let me know the locations so that I can stay well clear of them.
So use NT for monitoring and data acquisition but leave the real controls to a PLC or DCS.
> If NT were OK, why not use it in nuclear
> plants... The fact remains that NT is NOT used for
> (zero downtime) in automation. If it is, please let
me know the
> locations so that I can stay
> well clear of them.
Well, I know of at least one application where NT is used running a mill for machining nuclear materials for reactors. Each part can cost over $1M, so that control is considered pretty critical. I often run into high end machines where PLC and DCS performance is simply too limited and computer based control of one flavor or another is used. WinNT happens to be one of the more popular (and stable) of the platforms
in those cases. Various UNIX flavors (QNX, Linux,
HP-UX, Solaris to name some I've seen) also are used. Most PLCs do very well at process control or simple motion, but are very difficult or impossible to integrate as primary controllers in high end motion and machine vision applications.
Delta Tau Data Systems
A lot of the problem I've seen is predicting if a given NT configuration will be stable. I've seen more than one roll out where obstensibly the same package on the same hardware produced different levels of stability. When the offending machines were reloaded one worked fine and one still didn't. And countless times an upgrade produced variable results. I suppose these issues can all be resolved or explained but, there's so much going on that's hidden from view, most people just keep loading and hoping for the best. And six months down the road all bets are off as configurations get changed, problems fixed etc. Very strange. It'd be great if you could just eliminate everything you don't need but it's a package deal. And a huge package at that. I don't envy the Windows guys. Linux lets me install very little for the stuff I do which is a very good thing. But then Linux seldom does weird stuff anyway and installs usually produce the same results even on different machines. Much less stressful on roll outs. So installing that NT based system you had going in the lab might be half an hour. I'd bring a change of clothes just in case.
> The fact remains that NT is NOT used for >critical controls (zero downtime) in
> automation. >If it is, please let me know the locations so >that I can stay well
> clear of them.
I'm not sure that "critical" and "zero-downtime" mean the same thing. An example from my line of work; a press runs 24/7 for two weeks, then shuts down for 3 days while the operators do a mechanical make-ready for the next job. This gives plenty of time to reboot the PC, make backups, or even upgrade hardware without impacting production.
If PC-based control really makes you that nervous, you'd better "stay well clear" of Detroit. The Detroit auto manufacturers are really the birth place of PC-based control systems. When the operations guys at the car makers get upset they make nuclear melt-downs look tame. So if those guys are willing to use PC-based control you know it's a pretty stable system.
I see your point, though; if NT doesn't scale up to the REALLY important stuff, why use it for anything at all? I won't go into all the reasons people chose Windows when they can, but I will say that there are a lot of people doing it. Not nearly as many as pick PLC's, mind you, but still a lot.
Sage Automation, Inc.
It depends on what you mean by critical. Are lives on the line? Does the potential exist for a major environmental event? PC hardware isn't the most reliable around.
As for NT, NT reliability is a hotly debated issue, and there is a great deal of mythology out there about the infamous blue screen of death. However, the only things that can cause the BSOD are PC hardware failures (in which case you probably want the machine to halt anyways), problems with NT code at ring 0(a very rare cause), or problems with drivers written by 3rd party vendors (far and away the most common culprit, although NT usually gets the blame). To be fair, MS should get some of the blame because they won't expose their OS mechanics so vendors can make better software.
When a fault occurs in NT the exception dispatcher checks to see if a driver or application was operating. If an application was running and no fault handler exists the application is terminated, the BSOD does not occur. If it was an ISR or DSR (ie: drivers) you can get the BSOD if the exception handler cannot clear the fault.
If you use drivers and software that have been througly tested and proven, you won't have many problems. Thats why if you talk to people you'll find some who has problems with it (because they use poor software) and others who dont. Another hot item with NT is determinism, or the ability of an OS to guarantee execution of a task on a fixed time period. Even real time OSs like QNX can be deterministic only to the highest priority task and only if one task has highest priority, and only if that task can run in the allotted time, anything else can be pre-empted. With modern processors determinsm requirements can often be met in NT by a priority 31 task. Acutators take time to move and the modern controller is usually more than fast enough. You'll have to evaluate that for youself for your particular application however.
If you want to use a plc there is a company called pro-soft technology that makes a variety of communication interfaces for PLCs. I don't know if they have a GPIB instrument interface card or not, but it wouldn't hurt to check.
If you get the right software and system design, you will not want to return to traditional PLC style systems. You can read about two major industrial installations that went fully IT-based v.s. PLC/DCS at the link below.
Obviously distributed components and embedded devices have their place, and that is why they are so widely used. IT based applications replace the hardware components with software, and change their location from field to server. I don't see such an upheaval in the way we do things except a quantum leap in value and convenience.
In cases where devices must be located remotely or cycle times prohibit a server-based component, fully integrated PLC-like or controller devices are the solution. What is key from a systems design standpoint is the management and accessibility to those devices within the IT system. Except in proprietary DCS, the market has had little to offer in this regard. Stay tuned.
Paul Jager, CEO
Free Trials! http://www.mnrcan.com/newsdetail.phtml?idno=30
Something interesting happened to me today. I plugged a set of speakers into a WinNt 4.0 machine just to make sure they worked.
Then I double clicked on a wav file.
The system immediately locked up, even the mouse would not move.
I left it like that for a while (maybe ten minutes) thinking it might come back to life, but ended up cycling power on it.
A real nice, brand new Dell.
It seems that every time I start to get comfortable around WinNT it does this to me.
Well, it's okay. The Evil Empire has declared Win NT4 and Win98 unsupported products after June 30 anyway. (grin)
---------SPITZER AND BOYES, LLC-------------
"Consulting from the engineer
to the distribution channel"
21118 SE 278th Place
Maple Valley, WA 98038
253-709-5046 cell 425-432-8262 home office
You probably have a conflict with your sound card/software and some other software/hardware on the system. It happens, and the blame is not with
Paul Jager, CEO
If you install a software on a desktop PC and then play with internet, e-mail etc., maybe also trying sometimes pieces of downloaded software, soon or late the PC crashes because the OS becomes unstable or just swallowed a virus.
A so-called PLC or DCS, is more robust because of:
- a dedicated piece of hardware
- an embedded OS wich does not allow you to play
Well, you can do the same with a PC. Pick up an Industrial PC well suitable for rough environment, add Windows NT Embedded with no keyboard nor video (headless) and bundle it with your software. To me at this point it is the same of a dedicated hardware/software. Only accessible through safe interfaces (e.g. ethernet) with a security protocol based on TCP/IP. No viruses nor "alien" software allowed.
But IPC hardware is more powerful in terms of calculation power; furthermore, differently from other solutions, it is up-to-date with the technology, ad often at a lower price. IPCs make hardware just a commodity. And NTE, thanks to the old "wintel" story, offers a very good degree of adaptability.
I have hundreds of 24/7 critical applications using this approach (and lots of happy customers).
Although not in your case, many people wrongly think that the result will be cheaper and better with a PC than the use of dedicated control hardware. Today you can get small process controllers and high level PLC's with inbuilt ethernet communication for about 2/3 the price of a decent desktop PC. These include the realtime operating system and is fully supported by the manufacturer who accepts responsibility for what he is selling, something impossible when connecting an interface to a PC running Microsoft Windows with third party software drivers.
Having worked with many control systems for industrial processes, our experience is that Windows NT et al, is fine for project software development and operator interfaces, or non critical applications, but should NEVER be used for time critical process control using soft controllers etc. Its stability is never quite good enough and its subsystem is always doing "something else", including memory management, threading and interrupts, in a way that only Microsoft understand. Ever wondered why the mouse doesn't move smoothly across the screen when the modem is on?
Your time critical process control (eg loop control in 500mS)is just "one more task" to the Windows operating system.
Our golden rule for the application is "What happens when the PC fails or locks up?"
Our experience is that applications start out fine, but as they grow the PC's resource management always become a problem
I understand the temptation to use NT for the driver library for Windows, but if the application is serious and the protocol is open and well documented, then it should be possible to implement it in any control language that has proper ethernet support.
Ask the supplier what facilities exist in the application language to open and control ethernet sessions and to develop protocols to 3rd party devices. Suppliers who have this functionality available at the application level are only to pleased to talk about it. Those who have nothing are not.