Real-Time Systems and DAPL

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.

Facilitating real-time response

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

sampling at less than maximum rates on a limited number of channels,
avoiding intensive number crunching that would consume CPU capacity in large chunks,
limiting the number of processing tasks for the DAPL system to manage.

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.

If you are familiar with PLC controllers and think 1/60 second updates are fast, a Data Acquisition Processor is screaming fast.
With 250 updates per second, you should have no trouble updating 32 or more channels, never missing an update deadline.
You should be able to support about 2500 updates per second on 4 channels with no late updates.
If you can tolerate an occasional late update, you might be able to operate up to 8 channels at 10000 updates per second.

A lot of successful control applications think that this is plenty fast for their needs.

Eliminate real-time problems by not causing them!

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.