Modifying the DDS Engine
You are here
What Makes a DDS Engine?
What is DDS?
The objective of DDS is to provide a highly flexible and accurate analog/digital output generation mechanism. It excels at producing signals with extremely sensitive timing requirements, like frequency sweeps and high-frequency voltage switching (>1MHz). Before learning how to design a basic DDS engine, let's review the basics of traditional output engines and the pitfalls they present with highly dynamic output requirements.
Upcoming New Features
EFT version 2.2 is coming soon with loads of new features to further increase productivity and reduce test development time. While there are dozens of new features and improvements to the EFT Module for TestStand, let’s take a look at five of the most exciting updates.
How Bloomy’s Manufacturing Operator Interface for TestStand provides feedback tools to improve operator efficiency.
When developing automated tests for a product, we as test engineers typically focus on what we see as the two most important tasks: ensuring the test works properly, and ensuring appropriate results are collected. Because of this, the person who spends the most time on the system, the test operator, can often be forgotten.
Why Develop Code for Reusability?
All software developers appreciate the value of code reuse. It allows for faster development and creates more time-tested and reliable code. It gives added value to code with possible bonus features beyond customer requirements, etc. The only potential downside is that this code can take longer to design and develop initially. However, the main requirement for reusability is modularity, and this is good practice anyway.
In the past, we have showed you how to use the Actor Framework to create highly modular and easily scalable applications in LabVIEW.
In this article, I’d like to share a few tips that have helped me when working with another popular framework in NI’s product line-up: TestStand.
As LabVIEW developers, we are comfortable developing in LabVIEW. However, sometimes we need to leverage code from other languages. This is where DLLs come in. For those of us that are less than comfortable with coding languages outside of LabVIEW, using DLLs can be daunting and frustrating. The Import Shared Library Wizard can make your life easier, however, it is not very reliable when using custom data types. This forces us to use Call Library Function nodes (CLNs) for DLL calls, which can bring up a whole bunch of problems with no intuitive debug strategy.
If you attended my presentation at NI Developer Day back in March, you probably recognize the content of this three-part blog series. The premise of my presentation was simple and rather obvious given its title “You Already Know How to Use LabVIEW Classes.” In the end, object-oriented LabVIEW is simply a programming style that encourages software modularity and reuse. The doing is easy because it requires mostly bits and pieces with which we are already familiar.