How can I make my LabVIEW motion program execute faster?

[Greg Schmid]

I am using LabVIEW 6.0 and an older Pentium computer (32MB RAM, Windows 95) to communicate with and command three external motion controllers (RS232 conection) that control a 3-dimensional linear translation stage (three stacked, linear translation stages for XYZ motion; each controller controls one stage). In my application, the stage has a photo detector attached to it, and the LabVIEW program is designed to keep the photo detector at the brightest location in front of a light source.
To achieve this, the LabVIEW program commands (ASCII commands) each controller to continuously read the voltage signal from the photo detector (analog input) and move its stage such that the voltage signal is maximized.
The current version of my LabVIEW program consists of three parallel WHILE loops, each commanding the motion of one stage. In each WHILE loop, the voltage signal is read, compared to the previously read voltage signal, and - depending on whether the difference is positive (signal increases) or negative (signal decreases), the stage is moved either back or forth by a given small distance. The program per se works fine, except that the execution is way too slow. It takes about 3 seconds to execute all three WHILE loops once. Thus, a given stage moves only about every three seconds. However, I need each stage to move at least once per second or less (at least 3 times faster). How can I can increase the speed /responsiveness of my feedback loop program? Is there a more efficient way to program the motion? Or is the hardware limiting the speed? When entering motion commands through “Hyperterminal”, the stages respond immediately. Any advice is greatly appreciated.

[EdDickens]

Without actually seeing your applications code, it's really hard to say what might be slowing it down. You should be able to send several commands per second over the serial port.

One thing to look out for would be common VIs in the different loops that are blocking the other loops from running. It could even be the type of analog input you are doing that is slowing things down.

Is it possible to post your code, or a stripped down version of your code so we can see what's going on?

Ed

[altenbach]

This definitely should go much faster, so something is wrong. Is each controller on its own serial port?
32MB is a little low, even for Windows 95. Make sure nothing else is running or you will start swapping. I recommend 64MB but you should not go higher because most P1 motherboards can only cache up to 64MB.

I would also make sure that each while loop contains a small "wait next ms", else each loop might run multiple times before the next loop gets a chance.

How do you communicate with the serial port? Could it be your commands are not terminated properly?

[johnsold]

Greg,

I agree with Ed. Posting your code will ehlp us help you.

One thing to look for is how you control your serial ports. (I am assuming you have at least 3 different ports). Initialize them once outside your loops and close them after completing all usage. Re-initializing each time using high level VIs can be very time consuming. Another key to speeding serial communications is to use the Bytes at Port functions and only read the number of bytes available.

Lynn

[Greg Schmid]

Thanks for the replies and helpful suggestions. In contrast to what I described, the three motion controllers (and stages) communicate with the PC through one single serial port set up in the RS485 mode, and they are connected in series. Each controller has its unique address (address 1, 2 and 3). At the third and last motion controller, the RS485 connection is terminated with a jumper according to a recommendation by the controller manufacturer. In the LabVIEW program, all stages are initialized first. Thereafter, the feedback loop motion of each stage is programmed within one single WHILE loop. A stripped down version of the program is attached (motion.vi). Because there is only one WHILE loop, I believe that the addition of a "wait x ms" module would slow down the motion program rather than speed it up. What keeps my program from executing faster and the stages from responding earlier? Thanks a lot for your help.

[altenbach]

Well, you know that it only do one thing with the serial port at any given time, but you try to talk to it in parallel. Maybe things step on each others toes?

Why don't you use e.g. the error cluster to ensure that all ducks are aligned and only one thing happens at once (For example as in the image. Sorry I no longer use LabVIEW 6.0). I would still put a small delay in the loop, it won't slow you down but will make other things more responsive.

See if this makes a difference.

(Of course you should also probably stop the loop if an error occurs.)

Message Edited by altenbach on 04-07-2005 09:57 AM

[Greg Schmid]

I have implemented the modifications that you suggested (see attached motion1.vi), and they made the execution somewhat faster. Are there other changes in the LabVIEW program that might help to further speed up the program execution, or could the hardware (PC, motion controllers) be the limiting factor? Thanks for your time and advice.