Since then, NI released XNET. XNET is a modernized, unified, and easier to use API for CAN, LIN and Flex Ray interfaces and is to be used with NI’s XNET hardware family. 

NI’s move to XNET prompted DMC to develop a second generation of J1939 drivers using the new API.  

What’s new?

These updated drivers run on modern XNET CAN modules and include new features such as multi-packet and DM (Diagnostic Message) functionality. 

Though DMC previously provided only a trial version of the software, the drivers are now completely free and open source.

Who is this useful for?

These new J1939 drivers are intended to be used in automated testing and hardware in the loop (HiL) simulation. However, they are generic enough to serve a wide range of potential use cases. 

Also, since the drivers are now open source, developers can customize them to better fit their applications and/or implement functionality that isn’t currently supported. 

To make adding additional application layer functionality easier, these drivers expose a generic data link (J1939-21) API for handling multi-frame messages.

What do I need to start developing?

Since these drivers are built on the NI XNET API, XNET compatible hardware is needed to use them. See the CAN hardware in this table (below) for available options.

Source: www.ni.com

Compatibility

The drivers are compatible with LabVIEW 2015 – 2017 and NI XNET 15.0 – 17.0.

Where can I get these?

Learn more about downloading the drivers.

The post Open Source J1939 CAN Drivers appeared first on DMC, Inc..

We use LabVIEW DMA FIFOs for typical FPGA applications that acquire data to be sent to an RT target(Host). There are a lot of ways to use FIFOs for transporting data from the FPGA to the RT target. We will outline several of these options and present a generalized data transfer mechanism for synchronized DAQ on multiple chassis.

Let's start by outlining our requirements and then build then up a solution which considers several different options for transferring data from the FPGA to the host.

Outlining the Requirements

Requirements:

1. The system has a high channel count.


2. There are a variety of different data types in the channels being acquired.


3. Channels may be acquired from different loops that execute at different loop rates.


4. Channel data acquisition times must be synchronized across multiple chasses.

Schemes for Transferring Data

The DMA FIFO is the fundamental block for lossless transfer of data between an FPGA application and the host.

Using this building block, let’s discuss the progression of a generalized DAQ architecture starting with a single chassis implementation.

Single Channel Data Transfer

The simplest scheme for transferring channel data is when you’re acquiring data for a single channel.

In this scenario, you can write the data into the FIFO as it’s being acquired. As the host is acquiring data from the FPGA, it is guaranteed to be a sequential, ordered series of samples for that channel.

Multi-Channel Data Transfer

In most instances, we will want to acquire more than (1) channel of data, so the natural next step for this is to interleave the data that is being written to the FIFO. For a fixed channel list, this interleaved ordering can be pre-defined. That data can then be decimated using that ordering when it is read from the host.

Example FIFO ordering: 

[channel 1 – sample 1, channel 2-sample 1, ch3-s1, … , chN-s1],

[channel 1 – sample 2, channel 2-sample 2, ch3-s2, … , chN-s2],

… ,

[channel 1-sample N, channel 2-sample N, ch3-sN, …, chN-sN]

Differing Acquisition Rates

In the most generalized approach, it is not guaranteed that every channel will be acquired at the same rate. If you only have a few different acquisition rates, you could potentially use a separate FPGA-to-Host FIFO for each acquisition loop/rate.

If you can only use a single FIFO for transferring data or have more DAQ loop rates than FIFO channels, we would like to be able to use a single FIFO for acquiring data from all of the different sources/loops in our application.

In the example shown below, we have a 1Khz control loop that may contain some output channels or internal calculated channels that we would like to acquire as well as a more standard DAQ loop running at 5Khz.

Including Additional Information

We can no longer assume what the ordering of the channels written to the FIFO will be, so we need to include additional information along with each channel’s sample value to identify it on the Host. By setting the FIFO data type to be u64, we can pack additional information to be included with each channel.

In the example below, we can include a channel ID in addition to the channel data’s value so the Host can parse which value is associated with which channel ID.

What About Timing?

With the single channel acquisition or interleaved approach, we can infer the time delta between each sample. When capturing channels throughout a general FPGA application, we should have a strategy for capturing timing information with the samples we’re acquiring. One way to achieve this is to include a base clock value that is packed along with the channel ID and channel value:

Another option, if your application can tolerate less resolution per channel, would be to periodically send a special timestamp channel value at a regular interval. This unique timing channel can be used on the host side for determining when to aggregate a set of channel data. It can attach a single timestamp to all of the channel values received since the last timestamp value was received through the FIFO.

Considering Scale

The final step for this architecture is to consider how it scales with multiple FPGA chassis. In the previous section, we were able to generate a synchronized base clock value across all chassis. By using this synchronized base clock as the time stamp included with the channel values, we can achieve synchronized data acquisition across multiple chassis.

In the diagram below, you can see what this architecture might look like on the RT/Host side. Multiple parallel loops will be used for acquiring data from the FIFOs, Scaling the data, and then aggregating the data to be disseminated throughout the RT-Host application.

The last part of the architecture considers how to share data between chassis without involving the RT.

Stay tuned for synchronous data sharing between FPGA chassis using NI 9853 CAN module!

Learn more about DMC's FPGA programming expertise.

The post NI LabVIEW Part 2: Synchronized Data Acquisition across Distributed FPGA Chassis appeared first on DMC, Inc..

As a quick overview of what we’ll discuss, we’ll be working towards an architecture shown below. Part 1 of this series will review how to achieve timing synchronization between the FPGA chassis using National Instruments 9469 time sync modules. Part 2 will look at how to integrate synchronized data acquisition with an RT host application. Part 3 will review how to achieve data sharing between FPGA chassis using NI 9853 CAN modules.

Unfortunately, National Instruments hasn’t released the 60-slot mega chassis yet, so we’ll strive to achieve similar function and capabilities using multiple chassis with timing synchronization and data sharing. 

Part 1 of 3: Distributed FPGA Chassis Time Synchronization Using NI 9469 C Series Module

The first step to building up this architecture is to synchronize the clocks between the different FPGA chassis. We’ll achieve this using the NI 9469 time sync module that was designed specifically for synchronization requirements like this. 

The NI 9469 synchronization module is essentially a high-speed digital I/O module that encapsulates the underlying digital signals to provide a simple API for synchronization functionality.

In general, you configure the 9469 module to operate as a node in one of several “Single Master, Multiple Slave” topologies. Every chassis that you use will have one of these 9469 modules. A few of these different topologies are shown here:

The master chassis in this configuration can send a trigger (digital pulse) to one or more slaves, which upon receiving the triggers can perform some action(s) synchronously.

The API for the 9469 module includes two invoke nodes that are used in your FPGA code.

For Sending Triggers from a Master:

An example of this is shown below. Here, the base clock is divided into multiple different clock rates that are used throughout the FPGA application. The event divider VI counts the number of iterations it is called and outputs true on an interval that is wired into its input. Here, a divider of 1 yields the same frequency, 100 KHz. A divider of 20 yields 5Khz, etc. If we have multiple loops that will run at a particular frequency, then we can set multiple occurrences as in the 5Khz clock in this example. 

In addition to driving different loop rates, we will also be incrementing a base clock register. This base clock register can then be used for time stamping channel values, which will be described in Part 2: Synchronized Data Acquisition Across Distributed FPGA Chassis.

Since each chassis has its own copy of the base clock register, they are all incrementing off the same triggers from the master chassis. The base clock register values will always be the same across all chassis.

On initialization of the FPGA chassis, it is helpful to sync up the base clock registers via a procedure on RT. In general, a routine from the host application that follows the following steps will sync up the base clock registers on startup:

1. Disable all triggers
2. Reset base clock register to 0 on all chassis
3. Enable “Wait on Trigger” loops on all slave chassis
4. Enable “Send Triggers” loop on master chassis

We’ve now completed reviewing the core components of timing synchronization between chassis. In addition to what we’ve reviewed here, you can augment these components with additional fault handling:

1. If a chassis is missing trigger pulses, we need to make sure this is detected and that loops will continue to execute in absence of triggers being received from the master. You would need to switch to using the local clock in this scenario.
2. Use an additional trigger line for verifying the base clock trigger line. For example, if you send a trigger on the second trigger line once for every 1,000 triggers on your base clock trigger line, then you can count and ensure you’re always receiving 1,000 triggers between triggers you receive on that second trigger line.

That wraps it up for Part 1, stay tuned for Part 2: Synchronized Data Acquisition Across Distributed FPGA Chassis!

Learn more about DMC's FPGA programming expertise.

The post NI LabVIEW Part 1: Building Distributed and Synchronized FPGA Applications with Multiple C Series Chassis appeared first on DMC, Inc..

We gathered at Navy Pier on a beautiful fall day, ready to enhance our technical knowledge, connect with other local NI users, and introduce visitors to DMC. Our tilt table demo proved to be a popular draw and DMC's team had a great time showing it off at the booth. 

As always, meeting and developing relationships with National Instruments and peer integrators was a highlight of the day. We even raffled off a Fitbit Charge HR. Congratulations to our winner, Sonny Mitric of Omron!

There were plenty of insightful technical sessions to choose from throughout the day. The Advanced DAQmx Property Modes presentation offered a deep technical dive into a useful topic that's applicable in many different applications. We also attended sessions on LabVIEW for Embedded Systems and gained hands-on experience using CRIO for Real-Time and FPGA application. Another course demonstrated good electrical engineering wiring practices, shielding, and noise reduction.

DMC is an active participant in the Chicagoland LabVIEW User Group, so we were excited to see the Midwest User Group at NIDays. We stopped by the Midwest User Group booth and met up with users from across the region at a lunch meeting. 

We wrapped up the event with a fun exercise as part of the closing keynote session. Building a LEGO duck as a demonstration of stem execution was an enjoyable way to end a valuable day of learning and networking. 

Don't miss DMC at NIDays Boston 2015 on November 17!

Learn more about DMC's Test & Measurement Automation services.

The post Duck, Duck, DAQmx: NIDays Chicago 2015 Recap appeared first on DMC, Inc..

Configuration
As mentioned above, the Linux cRIOs have WebDAV and SSL support enabled by default. To confirm, open NI-MAX, and expand Remote Systems. Expand the cRIO, then Software, then NI CompactRIO. You should see SSL Support and WebDAV Server listed, as in Figure 1.

Figure 1: A properly-configured cRIO includes SSL Support and the WebDAV Server.

As long as those are available, you’re already configured.

Establishing a Connection in Windows
If a WebDAV server is running on the cRIO, then you can connect directly in Windows as if it were a traditional network shared directory. Both Windows 7 and 8 have built-in WebDAV clients. So, let’s say the cRIO’s IP address is 192.168.10.200 (and your PC is on a subnet with the cRIO):

• Open Windows Explorer
• In Windows 8, click the Computer menu, then Map Network Drive.
• In Windows 7, press Alt to expose the menu bar, then click Tools, then Map Network Drive.
• Select a drive letter.
• Uncheck Reconnect at logon, since the cRIO may not always be available.
• In the “Folder:” field, type “http://192.168.10.200/files”
  • Use your cRIO’s IP address, of course.
  • Don’t forget the “/files” at the end! This isn’t a placeholder for the filename you’re looking for, it is the literal string “/files.”
• Click finish, and give it a second. It will then ask you for a username and password.
  • These are the same credentials used to log in to the cRIO over SSH, or in NI-MAX.
  • By default, the username is “admin” and the password is blank.
• Hit OK, give it another couple seconds, and you should be presented with an Explorer window showing the files on the cRIO’s hard drive.

If this works, then you know WebDAV is working fine on your PC client and your cRIO server.

A Few Brief Words about File Paths
Note that you cannot write files anywhere you like on the cRIO’s hard drive. If you’re familiar with Linux, the hard drive layout will look familiar. /home/lvuser/natinst/bin is where we’ll make files in this example. /C/ni-rt/startup is a symbolic link to /home/lvuser/natinst/bin in order to preserve some compatibility with the conventions of older cRIOs. If none of this makes sense to you, don’t worry about it, just keep your files in /home/lvuser/natinst/bin until you get it figured out.

Transferring files in LabVIEW
If you’ve been able to connect in Windows, then you should be able to connect programmatically in LabVIEW. A complete example VI is show below in Figure 2. Note that this VI runs on the PC, so the transfer is in terms of “getting” the file from the cRIO. The example takes all of its VIs from LabVIEW’s WebDAV palette, which you can access from the Data Communication palette → Protocols palette → WebDAV palette → WebDAV Synchronous.
 
   

Figure 2: A demo program that transfers a file from the cRIO to the PC, then deletes the file on the cRIO. Note that this VI runs on the PC side. 

The Asynchronous VIs will also work, but will return before the operation completes. This is nice if you want to tell WebDAV to get multiple files, and then just let your program move on while those transfer in the background. However, in this example, I want to get my file and then delete it from the cRIO. I therefore use the Synchronous VIs so I know the “get” operation is complete before deleting.

The important information here is the following:

• The “host uri prefix” input of the Open Session VI is exactly the same as what you used to connect in Windows Explorer. Don’t forget, you need the literal “/files” part at the end.
• The “username” and “password” inputs of Open Session are the same as what you used in Windows Explorer also.
• The “verify server” input of Open Session can be used for higher-level authentication, but for the cRIO, set it to false.
• The “relative uri” input of Get is the path to the file you want to get, using the UNIX file path convention.
• The “local file path” input of Get is where your file will go on your PC, using the Windows file path convention.
  • You cannot just give it a directory path. This VI is not smart enough to know that you want to put it there and keep the same filename. Your “local file path” must be a path ending in a file name.
  • It will be happy to overwrite a file on your local drive, if a file already exists at “local file path.”

Conclusion
Since the cRIO hosts the WebDAV server, the PC is acting as a client that connects, gets the files it wants, then disconnects. This is completely different than having the cRIO send (or “put”) files to the PC, but has the advantage of being already configured by default. For more information, see the online manuals for the synchronous and asynchronous VIs.

The post Using WebDAV to Transfer Files from a Linux cRIO appeared first on DMC, Inc..

DMC is honored to demonstrate our expertise by having the most LabVIEW Certified Architects in the Midwest, as well as an all over strong team of LabVIEW Certified engineers.

NI has three different levels of LabVIEW Certification: Associate Developer, Developer and Architect.

Recently, we added five new engineers to our roster of LabVIEW proficient employees. DMC now has a total of nine Certified LabVIEW Architects, three Certified Professional Instructors, two Certified LabVIEW Developers and three Certified LabVIEW Associate Developers. Check out our full LabVIEW team below:

CLAs (Certified LabVIEW Architects):

• Patrick Corcoran 
• Eric West 
• Ashley Enderlin 
• Mark Locascio 
• Jeremy Green 
• Nick Aroneseno 
• Jesse Batsche 
• Leon Grossman 
• Darren Jones 

CPIs (Certified Professional Instructors)

• Darren Jones
• Patrick Corcoran
• Nick Aroneseno

CLDs (Certified LabVIEW Developers):

• Matt Goedke
• Jason Mayes

CLADs (Certified LabVIEW Associate Developers):

• Devon Fritz
• Bill Sowerine
• Elizabeth Rapport
• Katherine Czaplicki
• Spencer Glesmann

Learn more about DMC’s LabVIEW programming services.

The post DMC Congratulates LabVIEW Certified Architects and Developers appeared first on DMC, Inc..

That capability is extremely powerful. A hardware implementation of any particular algorithm is generally faster than a software implementation. FPGAs reap the speed benefits of hardware processing, but also give an engineer the ability to not only program a generic silicon die, but to reprogram it to fix bugs or improve performance. Furthermore, given enough space on the array, multiple stages of a calculation can be processed at once, either purely in parallel, or in a pipeline.

Designing the gate layout of an FPGA may seem daunting, but it is, of course, not done by hand. In fact, during NI Week 2013, National Instruments has held a number of helpful information sessions that introduce the tools available for specifying that layout. To begin, LabVIEW itself has supported FPGA programming using a subset of its G programming language since 2003. A LabVIEW programmer can simply write an algorithm using a constrained set of functions, and LabVIEW will interface with Xilinx software to produce the hardware description that will then be used to define the connections on the chip.

Due to the nature of FPGAs, however, familiar programming constructs such as loops, array operations, and floating-point operations must be used sparingly, if at all. Writing truly optimized algorithms can be tedious and error-prone, and writing un-optimized algorithms may waste a lot of gates unnecessarily, restricting the throughput and decreasing the amount of parallel processing that can be done.

One of the tools NI introduced at NI Week 2013 was the LabVIEW IP Builder, which features optimization technology from Xilinx. IP Builder provides more access to typical programming features, using smart algorithms to apply pipelining, loop-unrolling, and parallelization rules to standard LabVIEW algorithms. This way, you only need to make a few tweaks to your programming style to write an FPGA-friendly algorithm.

The rest of the optimization is achieved by specifying “directives” that tell IP Builder which optimizations you’d like to apply. On FPGAs, multiplier circuits are scarce. If you know that your algorithm needs them, but simultaneous uses are not possible, you can instruct the algorithm to use the same multiplier in several parts of the code to conserve that resource. Perhaps you know that your algorithm takes arrays as inputs, but that the entire array isn’t needed all at once. Directing the hardware synthesis in this way allows IP Builder to properly allocate the FPGA’s resources and increase throughput.

The crowd chimed in with a few good tips and design practices. Some optimizations due to poorly chosen directives can cause your algorithm to behave differently than intended. It was recommended that you run an un-optimized version of the FPGA code and compare it to an optimized version to ensure that the algorithm’s output is as expected. This is especially true if the algorithm requires conversions from fixed-point to floating-point values. The FPGA experts agreed that IP Builder could be a valuable tool for computing polynomials, FIR filters, integrators, and the like.

Xilinx has also developed a new “system on a chip” (SoC) called Zynq, which couples two ARM processor cores with an FPGA on a single die. Zynq is featured on NI’s new cRIO-9068. Combining general-purpose CPUs and a dedicated FPGA on the same chip means the parts can all easily exchange data. Certain parts of the code can be taken off the CPU, and the burden placed on the FPGA, allowing both to focus on tasks for which they are most capable, and generating significant performance improvements all around.

The significant improvement in usability and performance makes FPGAs even more attractive. We’re looking forward to giving these new technologies a test drive here in the DMC offices!

DMC at NI Week 2013

NI Week 2013 Recap

Learn more about DMC’s LabVIEW programming for real-time and FPGA expertise.

The post New FPGA Tools from NI and Xilinx at NI Week 2013 appeared first on DMC, Inc..

The aim of this discussion is to outline key questions that will be helpful in selecting and asset management solution for projects involving multiple National Instruments targets. I have taken specific focus on Real-Time and FPGA platforms, as they are most commonly deployed in large quantities. Let’s begin with some basic understanding of asset management:

What is asset management?

Asset management is generically described as a system that monitors valuable resources.

In large volume deployments, it is critical to have an understanding of the state of critical components to properly maintain and optimize the uptime of a given system. For example, a common application of asset management technology surrounds fleet vehicles. For a large number of vehicles, say sanitation trucks, a central monitoring system is often used to monitor routes, break downs, and track maintenance schedules which ensure each vehicle is optimized for continuous use.

How does asset management relate to National Instruments?

As larger volume systems are deployed, groupings of PXI controllers, multiple cRIO embedded systems, OEM SBRIO integrated products; it becomes critical to understand the technology available within the LabVIEW platform that describes a given target, and grants the ability to manage it. National Instruments customers are familiar with Measurement and Automation Explorer, which is NI’s approach to asset management in smaller lab settings.

CHALLENGE:

Refresh the Remote Systems sub-section of MAX with 10+ Real Time Targets connected to a network. Configure their IP addresses to place them in a common subnet.

EXTRA CREDIT:

Update each of those targets to run the same version of LabVIEW Real-Time and your custom program.

If you accepted my challenge and were emboldened to complete the extra credit, you will note that this task is tedious, time-consuming, and not optimal for long term support procedures.

What are my options for managing large deployments of NI Real-Time Targets?

National Instruments released its first response to the question of asset management in 2010. The System Configuration API is a suite of programmatic tools designed to allow access to target information through driver level experts. This API directly exposes the nature of a given targets configuration for consumption by a given application.

Now, to answer your first question, yes this directly leads to custom code development. There is not currently an offering by National Instruments that acts as a robust central monitoring service for Real-Time Targets. However, the System Configuration API can be coupled with the power of LabVIEW Web Services to create a highly scalable framework for asset management.

By utilizing the power of Web Services, native to LabVIEW, the System Configuration API can populate Restful Web Services that provide agnostic connectivity any number of Commercial Off the Shelf (COTS) asset management tools. As NI hardware can now be described in common XML, it may be addressable by any subsystem that can provide/consume Restful Web Methods. Some example technologies include Microsoft SQL Server/Sharepoint, Oracle, and IBM.

How do I calculate my Return on Investment (ROI) for an asset management solution?

As National Instruments does not offer a comprehensive solution for asset management, there is a significant time investment required to implement a scalable and robust infrastructure. Things to always consider at the beginning of development:

1. How many systems do I anticipate deploying?
2. Will my deployment be locally networked, or globally deployed?
3. What is the impact of a single failure? Multiple failures? Fault detection time?
4. What is the anticipated maintenance requirement for a deployed system?
5. How often might this system require updates during field use?
6. What is the cost of continuous field personnel versus remote monitoring application software?
7. What type of system security must be maintained?

It’s important to point out that smaller subsystems have a number of options for basic application management. National Instruments systems engineering has produced a reference design for image management on Real-Time targets. The Real Time Application Deployment Utility offers a comprehensive example of how application software can be managed and maintained for multiple targets. This solution, however, does have a number of scaling concerns, especially as network complexity increases. 

As deployed systems and embedded targets become common place, National Instruments hardware will require integration with more scalable and maintainable solutions than Measurement and Automation Explorer. The joining of the System Configuration API and native LabVIEW Web Services begins to offer developers and system administrators a pathway to integrating National Instruments hardware into common asset management technologies. 

Further Reading

Welcome to the NI System Configuration API

LabVIEW Real-Time Application Deployment (RTAD) Reference Application

Microsoft Software Asset Management

SharePoint Consulting Services

SharePoint Dashboards

Learn more about DMC’s LabVIEW programming for real-time and FPGA services.

The post National Instruments Real-Time Target Asset Management appeared first on DMC, Inc..

PLC History

Traditional PLC platforms are based on a reliable and easy to use scanning architecture. PLC software has historically been confined to a sequence of scanning inputs, running control code, updating outputs, and performing housekeeping functions. Automation programmers only develop the control code because the other functions (input cycles, output cycles, and housekeeping cycles) are all concealed. This rigid architecture allows engineers to quickly and efficiently design and program basic control systems. However, the PLC’s greatest strength, a robust and rigid scanning architecture, can become its most obvious weakness, inflexibility when custom applications require advanced operations.

PAC Advances

• Incorporate extremely high speed measurements (hundreds of thousands or millions of samples per second)
• Vision acquisition and processing
• Software defined hardware (by incorporating FPGA, field programmable gate arrays)

Most important, a Real-Time PAC platform can incorporate vision, high speed measurements and other data acquisition with logic and motion control and eliminate the need for engineers to integrate multiple dissimilar hardware and software platforms. Instead, all these functions are designed and programmed within a single software environment. This makes RTOS PAC software adaptable and appropriate for complex applications that require advanced structures, programming techniques, or hardware level control, but more difficult for basic applications.

Summary

The “80/20 rule” can be used to simplify this dilemma. In general, 80 percent of industrial automation tasks can be efficiently completed using a basic PLC to provide digital I/O, a small number of analog I/O points, and generic programming techniques (i.e. ladder logic). The other 20 percent of applications, however, require advanced programming algorithms, extremely high loop rates, deterministic execution, and access to low level hardware drivers for customization. Programmable Automation Controllers running Real-Time operating system are designed for the “20 percenters” who need more freedom and functionality to solve complex control problems.

RT-301: Capabilities of Distributed LabVIEW Real-Time

Learn more about DMC’s LabVIEW programming for Real-Time and FPGA.

The post RT-201: PLCs vs. Real-Time Systems appeared first on DMC, Inc..

As we’ve learned, the major benefits of running a Real-Time system are determinism and robust operation. These benefits can be realized in a very powerful way: distributed execution. Distributed execution allows the programmer to separate tasks by function and by level of criticality. A necessary component to keep things going is a good communication structure, allowing independent pieces to share information and status. One simple analogy for distributed execution can be found in your home. Your household appliances perform well because they have two important qualities: simple on the outside but complex (yet capable!) on the inside.

Capabilities

• Independent operation of critical sub-systems
• Highly available data collection
• Task dedication

Many capabilities are realized with dependable, asynchronous nodes. For one, they allow independent control and monitoring of critical systems. A real-time controller can be put in place to monitor safe/unsafe conditions in a variety of environments, including a manufacturing line, an R&D facility, or out in the field. Following the home analogy, the fire alarm in your home should “just work”, providing monitoring and alarming around the clock, with a simple and effective interface.

Another capability is ongoing and highly-available data collection. “Availability” is an important concept in reliability theory that indicates the level to which a system is operable and in a committed state. There are many applications that require highly-available data collection. For example, performing potentially destructive testing on a one-of-a-kind sample is a one-time deal—if you miss it (or lose the data), you’re out of luck and often back to building another potentially very expensive sample. This concern is even more important when the test needs to run around-the-clock, and any datapoint along the test could be valuable.

Task dedication is another important capability. The safety system I discussed above will continue to run even when other nodes on the system are compromised. Larger systems can have many parallel operations, from a higher supervisory level to low level execution. Separating these tasks to independent devices allows for continuity of operation when other parts may be under maintenance, upgrade, or error condition.

We at DMC are avid users and experts in National Instruments LabVIEW for Real-time, which can run on a variety of platforms including PXI, compactRIO (cRIO), PC, Embedded Vision System, Smart Cameras, and more. We’ve employed these tools successfully in a variety of projects, including the following Case Studies:

Appliance Test System with Power Measurements

Explosion-proof Equipment Testing with LabVIEW

LabVIEW Programming

The post RT-301: Capabilities of Distributed LabVIEW Real-Time appeared first on DMC, Inc..