|
ADwin systems are used in many industrial and scientific applications requiring deterministic real-time performance. In most cases, ADwin systems are working in cooperation with a Windows®-based PC, but each system is performing completely different tasks within the application:
- The job of the ADwin system is to execute processes quickly and deterministically. The ADwin processor is responsible for acquiring measurement data on analog/digital/... inputs, performing online calculations based on the measured data in every single sampling step directly after the acquisition, then responding to the results. One response could be writing values to the outputs in order to build a open- or closed-loop controller with the ADwin system. Another response could be saving the pre-calculated or raw data in the local memory of the ADwin system.
- The job of the Windows PC is running user interfaces for applications, visualization of data, database access, network connections, etc. These are all standard Windows functions, which are very well accepted by users worldwide. Unfortunately, most Windows users are also familiar with the operating system's non-deterministic software execution, and with Windows crashes that lead to the “Blue Screen of Death.” To avoid these Windows-related problems, there is a clear job sharing: all processes that require deterministic timing run on the ADwin system, while the Windows PC runs a program that handles the user interface with the application, databases, and networks.
Why short Real-Time response times?
Various processes with different priorities are usually executed simultaneously on the ADwin real-time system. The response time describes the time for a complete change from one process of lower priority to a process of higher priority. This change is initiated when a defined event occurs, such as an event generated by an internal periodic timer or by an external random trigger source (e.g. incremental encoder). The actual execution of the process commences only after the change in process has taken place. The following example clarifies the relationship between the ADwin's 300ns response time and the influence on the implemented application.
No of Processes |
ProcessFrequency |
Cycle Time |
Percentage of Reaction Time |
1 |
1 kHz
|
1000 µs
|
0.03% |
1 |
10 kHz |
100 µs |
0.3% |
1 |
25 kHz |
40 µs |
0.75% |
1 |
100kHz |
10 µs |
3% |
1 |
500 kHz |
2 µs |
15% |
4 |
4x 10 kHz |
4x 100 µs |
1.2% |
4 |
4x 50 kHz |
4x 20 µs |
6% |
10 |
10x 25 kHz |
10x 40 µs |
7.5% |
Examples of processes, any other combination in number of processes and cycle times is possible too |
If you run a single process, or 10 processes on an ADwin system, the most performance is free to handle the application, just a fraction of the CPU performance is necessary to coordinate all theses processes. Processes at different speeds can run on the ADwin systems, including processes running at some kilohertz, processes running at hundreds of kilohertz, and processes running at megahertz. As a result of this, the faster a process is to be executed or parallel processes on the same system are taking place, the shorter the response time of the real-time system must be in order to provide the maximum amount of CPU performance for the execution of the processes. A response time of "0" would be ideal, but is understandably impossible. However, ADwin systems come extremely close to this value.
|