The DAPL system is primarily intended for efficient data acquisition. Though fast, data acquisition speed is a different kind of fast than you care about for real-time systems. For data acquisition, you want throughput speed. For example, a 0.1 second delay transferring data for a graphical display won't be noticed. In contrast, a 0.1 second delay in controlling a hydraulic actuator could result in throwing a heavy object through the far wall, and latency time for delivering results is critical.
As data acquisition devices, Data Acquisition Processor boards do not push individual values through hardware with maximum efficiency. However, they do push values with great regularity. If the delays are acceptable, they will be acceptable every time. This is the predictable and assured response you need for real-time systems.
Long delays can be avoided by
Under these restrictions, there are very few things left to delay the response. But even so, is the response fast enough? You will have to decide.
A lot of successful control applications think that this is plenty fast for their needs.
Data logging applications are considered among the hardest real-time problems. Data must be moved from devices, to buffers, to busses, to other devices, and into physical storage. If any of these operations fails to finish in time, data are lost and the application fails. But, consider this from the application perspective. If data arrive in storage with a 0.1 second delay, or a 1.0 second delay, what's the difference?
Data logging real-time problems are artificially introduced by the devices used for the solution. With Data Acquisition Processors, those constraints are not there. You need to have sufficient channel bandwidth to move the data through, but given this, the intelligent data management in the DAPcell services and the DAPL system will ride over any transient timing conflicts, so that they simply don't matter. No samples are corrupted, no samples are lost – you can't get too much closer to a perfect solution.