Damien,
You might get more replies by posting on the LabVIEW Board. It gets much more traffic than this one, which is primarily for issues related to hardware counter/timer cards.
Several methods are in common use for timing code. One is to use the Tools >> Profile >> Performance and Memory menu item. This opens a window which allows you to get information about the time each VI and subVI takes to execute along with quite a bit of other useful information. It is quite helpful for idenitfying those portions of the code which are taking the largest amount of time. Then you can focus your efforts to improve the code where they will do the most good. If your code does not use subVIs, (well, it should), then this will not help much.
A way to test the time of small segments of code, subVIs or not, is to include the code in a 3-frame sequence structure. The first and last frames have Tick Count functions. In the middle frame is the code under test, often inside a For loop so that it can be repeated many times to capture the time of code which may execute in nanoseconds or microseconds. After the sequence structure completes the two tick counts are subtracted to get the elapsed time for the code in the middle. There are many posts in the LV Board about pitfalls and how to optimize this technique.
As for limiting the time, this can be more problematic. Assuming that you are not running on a Real Time operating system, it is hard to guarantee a maximum time. I think timed loops will report that they finished late. The key is to break up the code so that no section takes very long. Then a supervisory module can stop a process after any section if the total time approaches or exceeds your limit. For example if your database is offline, you need to make sure that the code which acquires the parameters has a timeout mechanism so the program does not wait forever for data it may never get.
Lynn
