LabVIEW is a great tool for developing test and measurement systems. The graphical nature of the LabVIEW programming language allows scientists and engineers to visualize the program flow very quickly.
As the saying goes, if you can draw your program on a flowchart, you can probably program it in LabVIEW.
Flowcharts providing visualization to LabVIEW code
So, why would engineers need to control motion from LabVIEW? Here are top 5 reasons of why you need motion control with LabVIEW.
In many test and measurement applications, sensors tend to collect data from a single point. If you think of a temperature sensor, or a force sensor, the sensor is only capable of giving you data from a limited range. A camera or a 3D LIDAR sensor might have more range and field of view, but the fact remains the same … there is no sensor that can give you unlimited range.
Of course, if you had the money to do so, you could buy many sensors and form a “sensor array” to give you more range, but that may not always be practical. For expensive cameras and/or LIDAR sensors, even one can cost over $10,000 USD, let alone an entire array.
The next best option (and the most practical option) is to move the sensor. All you need to do to identify how you would like the sensor to sweep or scan, and the distances and resolution of movement involved.
A good source for motion stage information is Oriental Motor. They offer various motion stages, motor sizing information, and customization services if needed.
After you’ve identified your motion stage, simply mount the sensor or camera on the stage, and use GECO Motion to easily control movement from LabVIEW, while also collecting sensor data from LabVIEW at the same time.
Linear and rotary motion stages
Using motion to expand the effective range of a measurement sensor or probe is a very effective way of getting the most value from your test system. LabVIEW will also give you the added benefit of being able to visualize the program flow between measurements and motion, which makes it much simpler to debug when issues should arise.
The flip side of moving the sensor is … you guessed it! Moving the DUT (device under test.) In many testing applications, you need to move the position or the angle of the device you are testing. A great example of this is RF antenna testing.
The manufacturer of an RF antenna would like to know how the antenna will perform when the signal is coming from different distances and directions. One way to do this is to move the signal source on a track, but … wouldn’t it be easier just to move or rotate the antenna?
Ideally, the RF antenna should perform equally well with the signal coming from all directions. Can you imagine a mobile phone with good reception by holding it in a particular angle, and bad reception in another angle? That would be unacceptable to consumers.
Similar testing can also be found in aerospace applications, where engineers need to maintain the same level of communication performance for signals coming from different directions to the airplane or satellite.
Another case of manipulating the unit under test would be a tensile tester, such as an Instron machine. In this case, the specimen is clamped tight and slowly pulled until failure.
You need motion to be synchronized with the time of each force measurement, in order to plot a stress-strain curve.
The same concept can be applied for any physical test system, such as bending and flexing a PCB board to see stress concentrations, or even aircraft sheet metal. There are many possibilities, and LabVIEW already gives you a head start for the test and measurement aspect of things.
By using GECO Motion in a physical test system, you can leverage the benefits of LabVIEW directly and not have to worry about LabVIEW compatibility issues.
In simple applications, motion movements tend to be pre-defined. For example, the motion of a 3D printer is pre-defined.
When you load a part into 3D printing software, the software will calculate the series of moves necessary to print the part.
When you press “start”, the motion system will execute that series of moves, step-by-step.
There is really no need to for the motion controller to take different paths based on different sensor inputs.
3D printer running a pre-defined motion script
However, for advanced applications, the motion movement is not pre-defined, but rather calculated in real-time. This is much like a football player needing to decide where to move next, based on many different factors, such as where the opponents are, where the ball is, where the goal is, etc.
For example, a flight cockpit simulator will need to move the cockpit’s roll, pitch, and yaw based on how the pilot is controlling the plane.
6-axis flight cockpit simulator, based on stewart platform
In this case, the application software will play a big part in deciding how the system needs to move, because it has to fulfill these functions:
With modern programming languages such as python or C, it’s not hard to find software libraries or packages that can do steps 2 and 3. However, it’s really hard to find software packages that can do all of them at the same time!
The challenge is really steps 1 and 4, as they primarily deal with interfacing with hardware devices. And this is where LabVIEW really shines. TENET has coached customers in the past to use apply LabVIEW for advanced robotics that combine sensors, algorithms, and control. It just so happens that LabVIEW is a great tool that can do all three tasks in one package.
*By the way, if you don’t believe the statement about interfacing with hardware to be challenging, just look up or search for “Arduino”.
This platform pretty much took care of the messiness of interfacing with hardware, which is what made it so wildly popular. 😀
The points proposed above have referred to motion control applications with LabVIEW. Now let’s discuss the workflow and ease-of-use benefits of keeping all the programming under one roof: LabVIEW.
As mentioned previously, LabVIEW provides great integration for hardware devices, whether they may be sensors, instruments, or outputs. From a system level view, if motion control (or other sub-systems) need to be implemented outside of the LabVIEW environment, this inherently brings some disadvantages:
The rosy picture of LabVIEW is to have one environment that can integrate everything, as well as one environment to go from development straight to deployment.
This may not always be possible when integrating components from different vendors, given every vendor’s proficiency level with LabVIEW will be different, but when the software interface between LabVIEW and the component is well defined, this becomes a FORCE MULTIPLIER in efficiency gains.
For example, imagine if every time you used a poorly designed VI to open a connection to the device, there might be a 20% chance that the VI doesn’t work … that’s insanely counterproductive. (Please see point 5 for more elaboration.)
Well-defined and intuitive nature of GECO API
Being able to program, configure, and deploy code directly all from LabVIEW makes the value of LabVIEW very attractive. However, the robustness and the completeness of the LabVIEW API would be the most critical factor for this consideration. We’re proud to say that the engineers at TENET have specifically spent development time to make sure that “everything just works in LabVIEW” with GECO Motion.
Sometimes engineers just need simple movements to be controlled by LabVIEW. It could be raising an elevator platform, opening or closing a gate, or even constant velocity control for a semiconductor sputtering plate.
Most motor vendors will provide some LabVIEW interfaces, but they can be tricky to figure out. In some aspects, this detracts from the value of LabVIEW, as LabVIEW users are accustomed to intuitive software interfaces.
Generic LabVIEW motion driver API
This isn’t really a big deal … or is it? If you’re not under time pressure to make things happen, perhaps this is acceptable. But if you are under the gun, and your boss/professor/colleagues are expecting you to complete this “simple” motion control task in LabVIEW, you need a tool that can get the job done.
With an open and general purpose interface, the GECO Motion allows you to connect to motors and drives of various different vendors to prevent lock-in.
Instead of debugging the not-so-well written LabVIEW VIs provided by other vendors for each individual project, you can have simple and total control over your motion with the GECO API that was specifically designed for LabVIEW users.
GECO API, with test panels for fast debug and motion Express VIs
If you will be encountering motion control needs on a regular basis, it makes sense to invest in a easy-to-use, user-friendly, and powerful motion controller for LabVIEW.
For academic researchers, graduate students, or even a systems builder who just loves using LabVIEW, GECO Motion will extend the ease-of-use benefits of LabVIEW into the area of motion control.
LabVIEW offers many virtual instruments (VIs) to control data acquisition devices and instruments. The user can just use an example VI or drag and drop an Express VI, then they can start to interact with their hardware device very easily and fast.
This is perhaps one of the best benefits of using LabVIEW. The TENET GECO Motion control solution builds upon this foundation, and makes a great tool LabVIEW even better, allowing many integration possibilities between measurements and motion.