LabVIEW

WebDAV File Transfer

It is often the case with embedded applications that log files are saved directly on the real-time system. However, due to memory limitations, we need to retrieve these files to view the information, archive the files, and alleviate memory space on the real-time system. The following article describes the process for efficiently transferring files from a CompactRIO chassis to a Windows PC using the WebDAV toolkit for LabVIEW.

Modifying the DDS Engine

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.

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.

In my previous post, I introduced the concept of object-oriented inheritance. I also suggested that, as a regular G developer, you already know enough to start writing your own object-oriented code.

Maintaining this same (I hope empowering) perspective, let’s dive into the next foundational principle of object-oriented programming: encapsulation. Look for a post covering the final principle (polymorphism) shortly.

You Already Know Enough to Get Started

If you do not currently leverage object-oriented programming techniques in your LabVIEW code (believe it or not) you likely know more than enough to get started. Object-oriented programming is not magic—it is a programming style built for modularity, and maintainability. As a regular G developer, you probably encounter clusters, libraries, type definitions, property nodes, and polymorphic VIs on a daily basis.