55ms
Each node on a LabVIEW data flow diagram will execute at some point
after its inputs are valid. That simple specification is sufficient
to guarantee that the computation for each node is correct. A program is
a collection of nodes. If all of the computations for all of the
nodes in your program are correct, can your program be incorrect?
Yes. When your program is interacting with the real world, it starts
dealing with another aspect of programming: time. Until LabVIEW 7.1,
time was not mentioned in the LabVIEW language. Libraries might have
mentioned it, but the language did not.
The way a diagram executes in time has always been a side-effect of
the way LabVIEW happens to work. LabVIEW uses data flow rules to
schedule parallel nodes to run in parallel. You notice this most when
two traditional "for" or "while" loops run in parallel. There is no
specification on how these loops will run with respect to each other.
While there is no spec, you probably should know how it actually
behaves. On the desktop, LabVIEW will ping-pong between loops every
55ms unless the loops have explicit wait primitives in them.
If you are writing a program that is communicating over the serial
port and has to respond to an incoming character in 30 ms, you need
to write your program in a special way to make sure things happen the
way you want them to. Here are a few rules to live by
1) Desktop operating systems tend to "hiccup" at undesirable times.
Windows will occasionally steal control for 100ms from applications.
While drivers like NI-DAQ can take steps against this, applications
like LabVIEW can only avoid that problem by running on a
deterministic OS such as the one used in LabVIEW Real-Time.
2) In LabVIEW 7.0 and before, run your time critical code in a
separate VI and set the execution system to a high priority (but not
subroutine). VIs in higher priority execution systems do not ping-
poing with VIs in lower priority execution systems. The higher
priority VI can take all of the time it wants.
3) In LabVIEW 7.1, take advantage of the timed loop. It allows just
that part of a diagram to run at high priority.
4) If you can't use high priority VIs or timed loops, then you need
to do it the hardest way. You need to make sure that no element of
your code can take more time than your minimum response time (30ms)
in this case. All library calls, all loops, etc.. must either
complete in less than 30ms or must yield time by doing a "wait".
posted by Joel @ 8:25 PM
3 Comments:
Can you comment on differences in timing with Fieldpoint Modules?
Hello. I'm a senior software engineer in the FieldPoint group and technical lead on FieldPoint RT controllers. With FieldPoint I/O, the timing equation becomes a little more complicated, due to the fact that FieldPoint modules each have a microcontroller that is continuously polling the inputs (or converting outputs) at a fixed rate. This rate is published in the documentation for each module.
When developing a real-time application for FieldPoint, you must take the polling period of the module as a worst-case bound for response time. If you are doing closed-loop control, then you have to add the polling period of the input module to that of the output module.
One way to mitigate this effect in closed-loop control is to use a combination input/output module such as the AIO-610. These modules are capable of sampling inputs and converting outputs in a single poll cycle. When used in conjunction with the FieldPoint Write/Read VI (available in LabVIEW 7.1), the closed-loop jitter becomes the polling period of the single I/O module, which is roughly a millisecond in the case of the AIO-610 (the exact figure escapes me right now).
This jitter I've talked about is all in hardware, but FieldPoint modules also have an ability to induce software jitter. Each module has a "semaphore" that controls whether the network module or IO module has access to the shared memory that holds the I/O values. The time it takes to acquire the semaphore varies from module to module, and is not published. In general, it is less than or equal to the polling period of the module. The FP Read or Write VIs might block for up to the maximum sempahore acquisition time, and only one VI can hit the FieldPoint IO at a time. For this reason, it's advisable to create tags that have several data items in them, which allows the read or write to be done in one semaphore acquisition.
Many new and under-development IO modules are seeking to mitigate many of these problems. The new AI-118 for instance has a guaranteed zero-jitter semaphore. We are also experimenting with modules that trigger an aquisition when the semaphore is requested, which eliminates jitter between the software and hardware. Stay tuned.
Thanks for the Fieldpoint insight! Great technical info....=)
Post a Comment
<< Home