Home > Archive > Matlab > November 2005 > Re: Output data at a very precis time
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Output data at a very precis time
|
|
| Rob Purser 2005-11-29, 7:07 pm |
| Hi Eric:
I've enclosed my standard response on "real time" below. Depending on the
tecnique you choose, you could achieve a fairly reasonable level of
accuracy. I'm not sure where you're getting your time reference from, so
that would be a large source of latency. It's pretty straightforward to
create a timer in MATLAB to check the time on a regular basis -- the rate at
which you check the time would likely be the largest source of latency. If
you use a manual trigger to output your analog output signal, latency would
probably be well under 100ms.
-Rob
--
Rob Purser
Data Acquisition Engineer
The MathWorks
rob.purser@mathworks.com
What is "Real Time" and are Mathworks products real time?
"Real time" is really about system response. Real time acquisition and
control guarantees that the system will generate the correct response within
a set time, no excuses, no mistakes. For instance, the software and hardware
that controls anti-lock braking systems might guarantee that it will read
its sensors every 200 microseconds and generate a brake control response.
That's hard real-time. Real-time operating systems sacrifice everything in
the interest of system response.
Typically, data acquisition products trade acquisition rate for latency,
which is the measurement of response time to an event. At a given price, you
can aim for high acquisition rates, or low latencies, but not both.
The Data Acquisition Toolbox is based on ring 3 Windows, which is a consumer
operating system. Consumer operating systems balance a lot of different
factors, and system response (we're talking milliseconds here) is a low
priority for these products. These operating systems do not guarantee that a
process (like the MATLAB and the Data Acquisition Toolbox) will get CPU time
on a regular or consistent basis. Thus, we cannot guarantee response in a
control loop. So, unless you're doing something with a long time constant
(like heating a large volume of water), I wouldn't recommend a ring 3
windows-based control application. Even then, I'd supervise it!
To combat this problem, most PC based data acquisition cards provide an
internal, high accuracy clock internally that they use to pace acquisition.
They store the data they collect in local memory, and then transfer the
samples to main computer memory either using interrupts or DMA in a
leisurely (if every millisecond is considered "leisurely") fashion. This
work is done by Ring 0 Windows device drivers, which are closer to "hard"
real-time. The timing of samples acquired this way is excellent, and these
cards can guarantee that the data acquired was acquired at the sample rates
requested, and that no samples were dropped. The maximum sampling rates are
(essentially) governed by the data acquisition cards, not the PC.
Currently, DAT supports cards that acquire 5,000,000 samples per second and
more. It does this by moving data in large blocks, rather than one point at
a time, which is much more efficient. Keeping up with data flows like these
may take your PC to the limit, but if it does, it won't drop points. DAT is
all about high throughput, though latency is all over the map.
Mathworks offers three PC-based products that cover the gamut from "soft"
real time to "hard" real time closed loop control: Data Acquisition Toolbox
(http://www.mathworks.com/products/daq/index.html), Real-Time Windows Target
(http://www.mathworks.com/products/rtwt/), and finally, xPC Target
(http://www.mathworks.com/products/xpctarget/index.html). Real-Time Windows
Target is a near real-time solution that run concurrent with Windows, and
xPC Target has a custom real-time operating system to allow development of
guaranteed response control loops. These products offer much lower
throughputs, since they typically acquire a single data point at a time
without using the on-board clocks, but offer extremely low latency.
"Van Lancker Eric" <eric.vanlancker@iav.ch> wrote in message
news:438c582e$1_2@news.bluewin.ch...
> Hello,
>
> I want to issue output data at a very precise clock (ex : 11h00m00s).
> Do anyone know the precison (in ms) I can expect using
> Matlab DAQ 2.8, Win2000 and NI boards ?
>
> In other words, how realtime is matlab DAQ ?
>
> Thanks in advance.
> Eric
| |
| Van Lancker Eric 2005-11-29, 7:07 pm |
| Thanks Rod,
Now my question is how stable the latency is ?
Is it 100ms +/- 1ms or 100ms +/-10ms ?
My need is to output a 200Hz signal synchronous to a reference 200Hz
external independant signal. So I need to control the latency the best
as I can.
Eric
Rob Purser wrote:
> Hi Eric:
>
> I've enclosed my standard response on "real time" below. Depending on the
> tecnique you choose, you could achieve a fairly reasonable level of
> accuracy. I'm not sure where you're getting your time reference from, so
> that would be a large source of latency. It's pretty straightforward to
> create a timer in MATLAB to check the time on a regular basis -- the rate at
> which you check the time would likely be the largest source of latency. If
> you use a manual trigger to output your analog output signal, latency would
> probably be well under 100ms.
>
> -Rob
>
|
|
|
|
|