Sample rates for your industrial applications?

  • Thread starter Edgar F. Hilton
  • Start date
E

Thread Starter

Edgar F. Hilton

I recently came across a paper from a leading factory automation control software vendor that claims that most PLCs and industrial automation sampling and deterministic requirements are in the order of a minimum of 2-5ms (that is 2-5ms sampling, and AVERAGE interrupt latencies in the order of 2-4 milliseconds also) and that most users will never need anything less in industrial automation. While the sampling rate assertion may be true for some industries, I find at least the interrupt latency assertion incredibly hard to swallow even for most industries. This implies that, for example, when an alarm signal is triggered that the controlling computer is allowed to ON AVERAGE respond 2-4 milliseconds AFTER the signal arrives. And again note the "On-Average" statement, which means that it could easily be even more -- orders of magnitude more. More importantly, when a rotating shaft triggers its key phasor once per revolution, that we are willing to live with a large error in the calculated spin speed. Especially when safety is concerned, I think that these numbers are extremely large. In my experience 2-4 milliseconds is an eternity for turbomachinery, magnetic suspension systems, and steam/fluid pipe applications, especially when we are talking about safety. Also, for most of my applications I have usually used sampling rates in the order of no more than 1ms. However, maybe I am too much in a niche industry. Thus, in an attempt to get a better grasp of others' realities, I would like to poll the group: 1. what industry are you in? 2. what sampling rates do you typically use in your application? 3. how long do you think is an acceptable latency for a control application? or alternatively how long do you think that a computer system should take before it responds to an emergency shutdown request? Any other information that you think might be of interest to this discussion is more than welcome. Please respond either here or directly to [email protected]. Thank you for your time. - Edgar
 
J

James Trounson

Hi Direct Motion builds PC based CNC systems. We close all servo loops with PC CPU under win98. I know win98 is not real time and this can't work. Tell our hundreds of customers that. Anyway We do all DC servos no brushless yet. Our servo update rate is 1 ms. We will be looking at brushless motors with much higher torque to inertia ratio. I can imagine needing 4Khz even 8 KHz if acceleration rates get high enough. Machine tool control requires keeping motors on the tool path under variable speed and acceleration conditions. The latency is interrupt response time, typically a few microseconds. When we control motors from a pulse generator, to move machine around by hand. We ratio the pulse generator pulses and control the motor in an exact real time proportion. In this case we have real time input which requires the same sampling rate as the servo. Other switches might work OK at lower sampling rate but we sample them and act on them at the servo rate anyway. I just got off the phone with opto22. Their remote termination I/O systems have latency in the range of 2 milliseconds. I guess that is OK for some things because they are selling alot. For our requirements, faster the better a 2 milli sec delay would simply not work for us. We are now trying to remote our termination away from the PC to simply the programming station and improve its packaging. We still want to do all the real work in the PC CPU because of the great programming tools available for the PC. If anyone is working on this kind of thing let us know. Regards Jim
 
Here is my response: > 1. what industry are you in? - Machinery; - Process industry like food (milk and stuff...). > 2. what sampling rates do you typically use in your application? - For machinery we typically are running with PLC scan rates of 5 to 20ms with a I/O input response of about 0,1ms (interrupt) to 8 ms. Because the machinery has to correspond to european law all emergency functions must be redundant and functional outside the PLC (so emergency functions work without PLC control). - For process we have PLC scan rates of 1 to 100ms and we alse use clocking functions of 1 sec (in this case the PLC only calculates every 1 second) a fast response can than only made by interrupts but is not often used). Emergency functions will be handeld the same way as in machinery. > 3A. how long do you think is an acceptable latency for a control application? - This totaly depends on the response of the field equipment like cylindes, valves and pumps. A typical pneumatic or hydrolic cylinder have movement responses of 100ms to almost 1sec so 20ms does not have to be much of the movement that is made after a needed stop response. Even a braking electric pomp needs more than 50ms to stand still. Today a communication bus for remote I/O will also take up 2 to 12ms to deliver a response to the field. > 3B or alternatively how long do you think that a computer system should take before it responds to an emergency shutdown request? - Like told in 3A I make my choice on the law (like emergency regulations for machinery) and the response rate of the field equipment that needs to respond on the emergency. So if I need to close a valve in 1ms and it can close in 0,5ms (never met one.....) I choice for a computer system that can make a respons rate of less than 0,5ms. Typical application I meet in machinery and proces are fine with 2 to 20ms. Greetings, Sisko Bos Application engineer [email protected]
 
You are so right Edgar: > turbomachinery, magnetic suspension systems, and steam/fluid pipe applications, especially when we are talking about safety. Nuclear, hazardeous gas industries,dynamite ... Hydro distribution, they all need separate alarm management, not necessarily faster than your milliseconds above. But hat they can address all the safety within that time period. Up last few years ago, not one system (PLC, DCS) could do it. In some manner, most of them ended reading plant data in ring type sequence instead of star sequence. In studying one of the major DCS (1982) we ended up with 15 seconds delay before appropriate action would occur. In the same week, touring the major suppliers, we choked another one: the emergency shutdown alarm never came !!! The dynamite plant had three control rooms and many independent systems watching each other. It finaly exploded, killing 4. Some years ago, a sudden magnetic storm killed the entire province. From the media, it's not clear whether a faster monitoring would have limited the damage or not ? Fact is: something has been done about it (better or not ? ) Chernobyll nuclear plant: was it vendor design ? (may be ?) I spent my life designing and watching after: rarely, vendors would come close. Have a good day now Edgar: make sure your ejectable seat is faster than 5 ms ! Regards <[email protected]>
 
T
On the control.com web site under the BULL! luminary, there is a paper entitled "Update Times". This deals with servos and the updating of commands and the several closed loops in a typical servo. Tom Bullock [email protected]
 
M

Michael Griffin

At 17:04 05/01/01 -0500, Edgar F. Hilton wrote: <clip> >I recently came across a paper from a leading factory automation control >software vendor that claims that most PLCs and industrial automation >sampling and deterministic requirements are in the order of a minimum of >2-5ms (that is 2-5ms sampling, If you are talking about PLCs and the majority of typical industrial automation applications, this number is an order of magnitude too low, i.e. a PLC scan rate (the more typical way of specifying this) of 20-50ms is not unreasonable or unacceptable. Furthermore, most applications do not require deterministic response. >and AVERAGE interrupt latencies in the >order of 2-4 milliseconds also) and that most users will never need >anything less in industrial automation. <clip> Most users never use or require interupts with PLCs. The internal operation of the controllers may require certain internal performance requirements in order to function, but that is a product designer's concern, not something the person applying it has to worry (or know) about. I think you are confusing the problems a controller designer has to solve in order to say build a PLC, and the problems a machine designer has to solve when applying the PLC to a machine. The first may have some tight timing constraints he has to meet which the second will not be concerned with or even aware of. The design and application of a controller are two completely separate issues. The majority of people on this list apply controllers, while there are only a few who design them. For example, if I am controlling a pneumatic pick and place with a PLC, I may have the following situation. First, there is no need for determinism, since the cylinders will simply wait at the end of their stroke until the PLC decides what to do next. Second, a very long scan time may affect overall machine cycle time, but it will have to be very long to be noticable. For example, with a scan rate of 20ms, and a 10 step sequence, the delay caused by the scan would be 20ms/2 * 10 steps = 100ms. If I had an overall machine cycle time of 10 seconds, this is a scan rate induced delay of only 1 per cent. There is not much economic advantage to reducing scan rate in this sort of application. I did recently work on a project which performed approximately 50 steps in 30 seconds, and saved 4 seconds because the new PLC happened to be faster (due to faster I/O), but this was an unusual case (and the cycle time reduction was a bonus, not a project objective). There are a few applications in which faster PLCs are an advantage or even necessary, but these situations are rare. For example, a faster PLC may be able to detect parts moving quickly past a sensor without needing a pulse stretcher or a high speed counter. In most cases though, I am not impressed by the binary instruction execution times which seems to be a favourite numbers game recently. I certainly wouldn't be prepared to pay extra for a PLC faster than the ones I am using today in general applications. ********************** Michael Griffin London, Ont. Canada [email protected] **********************
 
B
At 05:04 PM 1/5/2001 -0500, you wrote: >Thus, in an attempt to get a better grasp of others' realities, I would >like to poll the group: > >1. what industry are you in? I work with industrial machinery and motion controls. Most of my customers are OEM equipment manufacturers. >2. what sampling rates do you typically use in your application? It varies, of course, but when you are talking 5-40 millisecond scan times and 1-5 millisecond interrupt response you are in typical PLC territory. Event driven interrupts are rare in PLC's. I have used timed interrupts or 1 to 10 milliseconds to get a steady polling rate. Motion control is an application that typically needs faster response than a typical PLC can handle. We use motion controllers, embedded controllers, or specialized PC's to get these speeds. I have written programs that polled at 50 microseconds for specialized applications. Interrupt response can be well below 1 millisecond, possibly as low as a few microseconds, depending on the type of computer and software. Many 8 bit microcontrollers have interrupt response that is far faster than the average desktop PC, due to the simpler software structure. Small and simple code is important for high speed. >3. how long do you think is an acceptable latency for a control >application? or alternatively how long do you think that a computer >system should take before it responds to an emergency shutdown request? As fast as necessary for the application. The response must be deterministic as well. This is generally referred to as hard real time control. Where if the control is late, then damage is done. Very important when safety is concerned. Critical timing must be planned for when specifying a control system. Bill Sturm
 
Jim, very nice your 2ms latency, but the original question was about PLC's (like in 80286 or 386 at the most) Pat.
 
Top