The application leverages the Keysight instrument driver library to handle communication and control, while providing a user-friendly graphical interface (GUI) for remote operation. We also integrated the system with NI TestStand, creating a reusable set of custom steps that simplify sequence development.

System Overview

The goal was to design a flexible, modular system that allows an engineer or technician to:

• Configure measurement parameters for each instrument, using either the LabVIEW GUI or the onboard GUI of each device.
• Execute measurements automatically or under manual supervision.
• Collect and log results for analysis.
• Save and recall instrument states for repeatability.
• Integrate the entire workflow into automated TestStand sequences.

The core of the system is a LabVIEW application that acts as both the user interface and the instrument control framework. Each instrument is managed by its own dedicated driver class, responsible for communication, configuration, and data acquisition. All devices are connected to a controller PC that runs the LabVIEW application via LAN interface.

Using Keysight Instrument Drivers

Keysight provides certified LabVIEW drivers for many of its instruments. The libraries used in this application are as follows:

• RFSA: Keysight XSAn library
• RFNA: Keysight NA library
• RFPM: Agilent E441X Series library

These drivers implement a consistent API structure and follow the VISA standard, making them ideal for this type of automation project.

Our application created an Initialize, Calibrate, Configure, Acquire Data, Save/Recall Device State, and Close step for each device, using a parallel structure to the Keysight API for ease of integration. While these steps mirror the basic functionality of the VIs in the libraries, they allow the application to be more customizable by controlling only the settings we need to help streamline TestStand sequence development. The functions of each step are below:

• Initialize: This step creates an instrument handle that will be used by all other Keysight drivers in the device’s lifecycle
• Calibrate: This step allows the user to perform calibration and zeroing steps on the device (only for RFPM)
• Configure: This step allows the user to select specific settings for the measurements and sends them to the device
• Acquire Data: This step will perform a measurement using the settings specified in the previous step and export the data to the application
• Save/Recall Device State: This step allows the user to save or recall all device settings as a configuration file locally on the device’s drive (Only for RFSA/RFNA)
• Close: This step closes the VISA resource for the device to prevent any memory issues when the app closes

Application Design and Architecture

The LabVIEW application uses an object-oriented approach, with each device having a widget class, an abstract class, a Keysight instrument class, and a simulated class. The widget class uses APIs from the abstract class to call the basic steps listed above. Each widget also contains the GUI for device control from the LabVIEW front-end.

The Keysight instrument class contains device-specific drivers, and the simulated class generates random data when hardware is not available. If we replaced our devices with a non-Keysight model, we could easily add another class for that device’s drivers.

GUI Module

The GUI for RFSA has 2 screens, with users able to control basic display settings or recall a state from the device’s settings on the first screen. More settings options are available on the second screen, which is accessible by selecting the “Configure” button. After the user selects their desired settings, they can conduct a measurement using the “Start” button, then set markers using the frequency control or the slider below. The positions of the markers automatically update, and their frequency and amplitude values are displayed below.

The RFNA has a similar GUI but requires fewer settings. It has one screen, allowing the user to control the frequency range and select the test type between Insertion Loss (S12) or VSWR (S11). Like the RFSA, users can recall a device state, start a measurement, and control the marker from this screen.

The RFPM has a different GUI because it only conducts single-channel measurements, as opposed to frequency sweeps. This GUI allows the user to perform a calibration sequence by selecting the type (Calibrate, Zero, or Calibrate & Zero). The user can then select the frequency at which to conduct the measurement and set the resolution for the measurements. When the user selects the “Measure” button, the device conducts a power measurement and displays it both on the device’s onboard GUI and the LabVIEW GUI.

Data Acquisition and Storage

Measurements for each device can be conducted simultaneously, and the data from all three instruments can be automatically logged to local or network drives. For this application, the data is stored in a TDMS file format, but could easily be saved as a CSV or other format as well.

DMC implemented a data tagging system that associates each measurement with metadata such as date, time, operator, device under test (DUT) ID, and test sequence name. This metadata improves traceability and simplifies post-test analysis.

Integration with NI TestStand

DM added an additional layer of efficiency to the RF measurements by integrating them into NI TestStand sequences used across multiple test stations. To achieve this, we created custom TestStand steps that directly call the LabVIEW VIs controlling each instrument. Each step has a wrapper VI that is used to create a TestStand custom step. This allows the user to create sequences in TestStand the same way they would in LabVIEW, but without needing to understand the programming backend. When used in a sequence, the data plots appear in the report generated by TestStand, and the data can be used in pass/fail grading steps during the sequence itself.

TestStand is the foundation of one of DMC’s core battery test platforms for the reasons above and can enhance the accessibility of automation when used in conjunction with well-encapsulated LabVIEW code.

Conclusion

This project demonstrates how combining LabVIEW, Keysight instrument drivers, and NI TestStand creates a powerful and flexible RF measurement automation platform. By automating configuration, acquisition, and reporting for the three devices, we achieved significant gains in efficiency, repeatability, and scalability. The system meets current test requirements and lays the foundation for future automation initiatives. Because of the modular LabVIEW code, we can easily scale the system to add functions, GUI elements, and devices with minimal rework.

The post Automating RF Measurements Using LabVIEW for Keysight CXA, ENA, and EPM Instruments appeared first on DMC, Inc..

The Battery Simulator System delivered by DMC provides the ability to test BMS devices using a Hardware In the Loop (HIL) testing approach. This HIL testing is performed before those devices are fully incorporated into the large battery packs they are designed to monitor and manage. The system provides software-controlled simulated signals for all input sensors connected to the BMS and provides the ability to measure relevant outputs and responses from the BMS. This makes it possible to perform fully automated testing and validation of BMS functionality across any realistic range of input conditions the device may encounter in field operation.

Table of Contents

• System Introduction
• System Details
  • Definitions
• Overview of Hardware System
• System Enclosure
• Battery Stack Simulation
• Cell Voltage / Current Measurement Module (Optional)
• Battery Stack Simulator Connections
• Temperature Sensor Simulation Module
• PXI Chassis to Controller Interface
• Software Driver Libraries for System Control
• Safety / Interlock Functions
• National Instruments / LabVIEW Experience
• Test and Measurement Experience
• Related Past and Current Projects

System Introduction

The Battery Simulator System leverages the DMC Battery Testing Platform hardware and software. DMC’s modular Battery Testing Platform incorporates open software and hardware technologies along with flexible and reliable subsystem components and instruments which are completely customized to the end user’s specifications.

The Battery Testing Platform is built around high-quality off-the-shelf hardware assembled from a variety of vendors, including Pickering Interfaces, National Instruments (NI), Lambda, and Agilent, among others. Selection of individual instruments in the DMC system is based completely on required performance, not allegiance to a single hardware vendor.

The system can simulate a stack of 108 battery cells in series and 50x 4-bit temperature sensors. The system was delivered with source code libraries for low-level driver functions that provide full control over the available functionalities of the Battery Simulator System. This software code is based on pre-existing software modules, which were assembled and customized to accommodate the customer’s specific test system and test application. DMC did not develop a higher-level test execution control application as the customer wished to develop their primary test control application themselves.

System Details

Definitions

• BMS: Battery Management System – An electronic system for managing a rechargeable battery by continuously monitoring the battery state, calculating and reporting data on the battery, performing safety functions in fault conditions, performing cell balancing functions, etc.
• NI: National Instruments, Inc.
• PXI: Programmable eXtensions for Instrumentation – Hardware platform for test and measurement IO
• DMM: Digital Multi-Meter – An electronic measurement device, commonly capable of acquiring high-resolution voltage, current, resistance, or capacitance measurements, as either single-point measurements or waveform captures
• DUT: Device Under Test – Client’s BMS device to be tested

Overview of Hardware System

A high-level functional diagram of the DMC Battery Simulator System is shown below.

System Enclosure

The Battery Simulator System is built upon the Media Director Lectern V2, a portable (wheeled) rack-mount enclosure desk, as shown below.

This mobile desk provides 32U of total rack-mount space in two separate columns for mounting primary system components, including 6U of rack-mount space in the upper portion of the lectern just beneath the desk surface.

Controller and Accessories

The primary controller for the Battery Simulator System is a rack mount PC. This PC serves as the primary controller for the test system and runs a LabVIEW test application developed by customer engineers.

A listing of the performance specifications of this PC is provided below.

• Processor(s): Intel® i7 – 2600 (LGA1155) Quad Core Processor 3.4GHz/8MB Cache
•  2U Riser Card PCIe – x16, x4, x1
• Memory – DDR3: 16 GB DDR3-1333/PC3-10600
• Hard Drive: 2TB SATA III 7200RPM
• Optical Drive: Plextor® PX-890SA 24x DVD±R/W
• Video Card: PCI-EXPRESS RADEON HD6450 1GB/PCIe 2.0 (Dual Monitor)
• Operating System: Microsoft® Windows® 7 Professional 64-bit OE

The system includes a license for the LabVIEW NI Developer Suite package (the most comprehensive and full-featured package offered by National Instruments) to ensure the customer has access to the complete set of LabVIEW functions, toolkits, and capabilities for their development activities. This is the package that DMC uses internally for development, so utilizing this package also ensures that the controller PC will have full access and compatibility with all supporting software provided by DMC.

The system includes dual DellTM UltraSharpTM U2410 monitors that are mounted above the desk surface of the enclosure via a dual flat panel mounting arm.

The system includes the Logitech Wireless Keyboard/Mouse MK710 peripheral devices for user operation of the PC.

Battery Stack Simulation

The Battery Stack Simulation sub-system consists of Pickering PXI 41-752, 6-cell battery simulator cards placed inside a PXI chassis, providing independent cell voltage simulated outputs. The Battery Simulator System includes 18 PXI cell simulator cards, enabling simulation of a battery stack of 108 cells.

The cell simulator current outputs and voltage sense lines from each card connect to a custom-built circuit board which configures the independent simulated cells into a full simulated battery stack. It also handles battery stack management and safety functions. Past this custom circuit board, the cell supply/sense lines route to a single high-density DUT connection on the front panel of the test stand.

The Pickering cell simulator cards offer no direct means of reading back their output current or voltage. As a result, the cards themselves provide no direct capability for voltage supply line leakage current measurement, or for actual cell voltage measurements.

Since these measurements are useful for the characterization and calibration of a BMS device, DMC’s Battery Simulator System provides the capability to acquire independent cell voltage and current output measurements using a high-resolution Cell Current/Voltage Measurement Module. This module consists of an active high-density relay switch matrix that enables measurement of the current flow on any cell line or of the voltage differential between any two cell lines in the battery stack. This high-resolution cell current/voltage measurement module is described in more detail later in this document.

DMC considers the Pickering 41-752 battery simulator card to be an excellent tool for simulating a battery input to a BMS for the following reasons:

1. The 750V isolation barrier allows the outputs to be stacked in series without inducing unintentional ground faults or loops and without voiding the manufacturer’s warranty.
2. The cards are capable of both sourcing and sinking current, just like an actual chemical cell. Accurate testing of BMS cell balancing operations requires this current-sinking function.

The 750V isolation barrier of the Pickering 41-752 card allows it to be used to emulate an entire low power battery stack representative of those used for vehicle propulsion.

The Pickering PXI 41-752 is a PXI based, 6-channel battery simulator module. Each channel of the module can supply up to 7V and 300mA to the load. Each channel is fully isolated from ground and from each other, allowing the channels to be connected in series to simulate batteries arranged in a stacked architecture. The 750V isolation barrier permits the 41-752 to be used to emulate a low power battery stack representative of those used for vehicle propulsion.

Each battery simulator provides independent power and sense connections, allowing the battery simulator to sense a remote load and correct for wiring voltage losses. The battery simulator is designed to respond quickly to dynamic loads, minimizing the need for local decoupling capacitors at the load.

A signal line on the user connector allows the user to shut down all battery simulator channels with a single connection. Multiple module control lines are linked together to provide an easy way of inhibiting voltage generation (E-Stop) when using many series-connected modules that provide high output voltages.

Cell Voltage/Current Measurement Module (Optional)

The Cell Voltage/Current Measurement Module provides independent (DMM based) high-resolution measurement of the voltage between any two cells in the simulated battery stack or of the current on any given cell voltage supply line. These measurements are useful for the characterization (cell balancing functions, power consumption, leakage currents, etc.) or calibration of a BMS device. This module also enables automated calibration of the Battery Stack Simulator device itself.

To deliver this extensive range of measurements in a cost-effective manner, the module utilizes a single high-accuracy digital multimeter in conjunction with an active high-density switching matrix to connect this meter to any desired set of measurement points. The Battery Simulation system contains a NI PXI-4071 Digital Multi-Meter (DMM) installed in one of the PXI chassis. This 7 ½ digit DMM delivers the following measurement capabilities:

• Voltage measurements from ±10 nV to 1000 VDC
• 8 DC current ranges with sensitivity down to 1 pA
• ±500 VDC/Vrms common-mode isolation
• Resistance measurements from 10 µΩ to 5 GΩ
• 1.8 MS/s isolated, 1000 V waveform acquisition

The Cell Voltage/Current Measurement Module uses a single DMM, and thus it is only possible to acquire one particular measurement at a given time (i.e. the specific probe point that the current relay multiplexer state is connecting the DMM to measure). It is very straightforward, however, to set up functions in the test control software to scan through all cell voltage or current measurement points by simply reconfiguring the relay state between each measurement acquired by the DMM.

The switching matrix in this module also makes it possible to simulate a broken connection between a simulated cell and the BMS or to simulate a shorted connection between two adjacent cells; these can be useful fault insertion mechanisms in BMS testing regiments. Similarly, the Voltage/Current Measurement Module also provides the ability to perform complete and total disconnection of the cell simulator from the BMS device under test.

The Cell Voltage/Current Measurement Module utilizes 5-amp relays that can handle cold switching up to 750 V and are thus more than capable of handling the expected total stack voltage generated by many simulated cells in series. 

The Cell Voltage/Current Measurement Module fundamentally consists of multiple removable/swappable relay multiplexing cards that are seated in a 4U (7”) high Vector card cabinet. It is designed to be located either directly above or directly below a PXI chassis containing cell simulator modules (as shown in the image below). Each relay card connects directly to a cell simulator card and handles the measurement multiplexing for those six simulated cells. This design makes it easy to scale the multiplexer module when adding or removing cell simulator cards to increase/decrease the size of the simulated cell stack.

Battery Stack Simulator Connections

Each simulated cell has one supply and one sense line that needs to be routed independently to the Device Under Test (to allow the cell simulator modules to accurately compensate for voltage drop in harness/wiring). Therefore, the complete set of simulated cell connections consists of 108 cell voltage supply lines and 108 cell voltage sense lines. The Battery Simulator System provides two parallel connections to the simulated cells.

Battery Stack Connection 1 is used to interface with the Device Under Test through a pair of connectors that are panel mounted in the system enclosure panel. There are separate connectors (with identical pin-out mappings for consistency) for the simulated cell voltage stack sense and supply lines, as shown below.

Battery Stack Connection 1 utilizes 2x 160 position connectors as depicted below:

Battery Stack Connection 2 provides an auxiliary parallel connection to all simulated cell supply and sense lines for external monitoring, measurement, and diagnostic purposes. This parallel connection has an available standard screw terminal connection for each cell voltage supply and sense line, as depicted below. These breakout terminal connections are mounted facing out the front of the primary system enclosure to make them externally accessible.

Temperature Sensor Simulation Module

The Temperature Sensor Simulation module supports simulation of 50x 4-bit resistive temperature. To enable future flexibility, the module provides the ability to alternatively simulate 25x 8-bit with some minor reconfiguration of built-in jumper points. The figures below illustrate the simulation of either one 8-bit or two 4-bit resistor chains and how the module supports switching from 4-bit to 8-bit simulation through the installation of jumpers. An N-bit simulated temperature sensor essentially consists of N fixed resistors that can be inserted or removed from the simulated temperature sensor circuit using a relay switching matrix. The resistor values that are placed in line with the simulated temperature sensor circuit add with one another (since they are in a series configuration) to produce the desired resistance to simulate a particular temperature reading.

For a 4-bit simulated sensor, there are a total of 2^4 = 16 discrete resistance values (including a short circuit) that can be applied by each simulated sensor. For an 8-bit simulated sensor, there are a total of 2^8 = 256 resistance values that can be generated. The actual resistor values used in the module (which thus affect the total range and the set of overall resistance values that can be generated) are fully configurable and are determined by the requirements of the test application.

The temperature sensor simulation system utilizes a modular motherboard and daughter card architecture. The actual physical resistors that comprise the simulated temperature sensors are all installed on swappable daughter cards that plug into the module’s motherboard. The motherboard handles the “infrastructure” of aggregating independent resistors into simulated temperature sensors, integrating relays to control the simulated temperature circuits, etc. By swapping in and out sets of daughter cards containing different resistor values, different types of temperature sensors or different temperature ranges can be simulated to accommodate varying testing requirements or DUT models.

The relays that are responsible for configuring the desired output state of the simulated temperature sensors are contained on and controlled by two high-density PXI relay cards. Control of the Temperature Sensor Simulation module is accomplished through a set of LabVIEW driver VIs provided along with the system.

The simulated temperature sensor module drivers include algorithms to automatically calculate the optimal combination of resistors that should be inserted into a given simulated temperature sensor circuit to achieve the closest possible resistance to the commanded value. Thus, the interface for controlling the temperature sensor module is simple and abstracts away the lower-level hardware operations. It is simply necessary to specify the desired resistance (corresponding to the temperature reading you want to simulate) to apply to a particular temperature sensor number.

Each simulated thermistor requires two connection lines, and thus for a total of 50 simulated thermistors the system has 100 total connections from the Temperature Sensor Simulation Module to the DUT. The Temperature Sensor Simulation Module has a 104-position connector mounted in the front panel of its enclosure, as depicted in the image below.

PX Chassis to Controller Interface

The Battery Simulator System includes two full 18-slot NI PXI-1045 chassis to house Cell Simulator PXI cards as well as supporting instrumentation and device control cards.

Both of these chassis interface to the controller PXI using an MXI Express interface. A NI PXI-PCIe8362 card is installed in an available PCIe port of the controller PC to provide two MXI interface ports. Each PXI chassis has a NI PXI-8360 MXI Interface card installed in the first slot of the chassis. The MXI ports on the controller PCI card each connect via an included three-meter, high-speed MXI cable to one of the MXI interface cards in the respective PXI chassis to effectively link both chassis to the single PC controller.

This MXI Express interface provides a software-transparent link between the controller PC and the PXI chassis that house system instrumentation and card modules. This linkage allows the Battery Simulator hardware to effectively be available as native or directly connected instrumentation on the controller computer.

Software Driver Libraries for System Control

The Battery Simulator System includes LabVIEW driver libraries (with full unlocked source code) that provide full control over the available functionalities of the Battery Simulator System. DMC did not develop a higher-level test execution control application for this particular system, as the customer wished to develop a primary test control application internally.

DMC has provided the following control drivers (with accompanying documentation) for use on the controller PC:

• DMC custom LabVIEW drivers for full simulated battery stack control and management
• DMC custom LabVIEW drivers for control of Cell Voltage/Current Measurement Module
• DMC custom LabVIEW drivers for control/management of simulated temperature sensors
• DMC custom LabVIEW Digital Multi-Meter Drivers for higher-level DMM functions (waveform capture and analysis, etc.)
• VISA (Virtual Instrument Software Architecture) driver set for direct control of individual Cell Simulator modules and Pickering relay cards
• Direct IO driver set for direct control of individual Cell Simulator modules and Pickering relay cards

Safety/Interlock Functions

Since the Battery Simulator System can generate high voltages (as required for battery stack simulation), it contains both hardware and software-based safety features to disable all voltage output during a safety event.

• Large Red ESTOP button in the middle of the top desk surface of Battery Simulator System enclosure
• External/Remote Interlock connector on the right-side panel of the enclosure
• Software-based disable command to open PC-controlled relay that is in series with safety interlock loop

Activating any of these safety features will immediately turn off all voltage outputs from the Battery Stack Simulator.

Company Overview And Qualifications

DMC is a well-known and established controls engineering and consulting firm focused on the industrial automation market. We develop and implement solutions for a wide range of industries using a variety of technologies. DMC has successfully delivered solutions for hundreds of companies including 3M, Abbott Laboratories, Argonne National Labs, Bosch, BRP, Caterpillar, Chrysler, Fermilab, Ford, John Deere, UL, Wrigley, and Yaskawa. Every solution we develop is based on a solid understanding of engineering principles with the primary objective of helping our client increase profitability and productivity using world-class solutions.

DMC is a certified member of the Control Systems Integrators Association (CSIA). DMC passed a rigorous third-party audit of 200 criteria that span all aspects of business performance in the areas of:

• General Management
• Human Resources Management
• Marketing and Business Development
• Financial Management
• Project Management
• System Development Lifecycle
• Quality Assurance Management

National Instruments / LabVIEW Experience

DMC has been a National Instruments (NI) Alliance member for more than 10 years with one of the largest teams of Certified LabVIEW developers in the country, including several National Instruments Certified LabVIEW Architects (highest level of certification available), and multiple NI Certified LabVIEW Developers.

Test and Measurement Experience

Our Test and Measurement Automation services help clients automate laboratory testing using the latest technologies. We have years of experience delivering world-class solutions to leaders in research, development, production, quality, and certification testing. Our flexible and collaborative approach is proven to deliver efficient, accurate, and robust test systems, as well as the tools to leverage test data for effective results analysis.

DMC has employed LabVIEW in many industries, including product development, test and measurement engineering, R&D, and high-tech manufacturing. We have developed LabVIEW solutions for hundreds of projects at dozens of customers, including:

• Argonne National Laboratories
• Fermi National Accelerator Laboratory (Fermilab)
• Bombardier Recreational Products Bosch
• Underwriters Laboratories
• LG
• Bosch

DMC applies a disciplined and systematic approach to LabVIEW software design. Engineers at DMC employ software conventions and architectures so that code is structured and well-organized. One example of these structures is a LabVIEW state machine that builds a system based on states, events, and actions

DMC has a vast, reliable code library that has been tested and can be used to significantly reduce the development time and risk. Leverage the work we’ve already done to reduce start-up time now and downtime later. We’ve also developed LabVIEW tools for additional features such as HTML and PDF reporting, TDMS file storage, external data viewers, and SQL databases.

The post NASA Battery Simulator System appeared first on DMC, Inc..

DMC is excited to host this quarter’s ALARM LabVIEW User Group meeting on Thursday, April 17, 2025! The ALARM (Advanced LabVIEW Architects of the Rocky Mountains) group brings together LabVIEW enthusiasts to discuss programming techniques, design strategies, updates and share experiences.

This event offers a fantastic opportunity to learn, receive updates on NI and NI Software, network with professionals in the Denver area, and have fun! Food and drinks will be provided, and after the presentations, you’ll have a chance to relax on DMC’s rooftop deck or play a game of pool with the team! If you’re interested in attending, please register here.​

Agenda:

1. Meet and Greet (DMC Food & Beverages Provided)
2. Presentation 1 (Welcome and DMC Overview, Time Permitting: EtherCAT for NI)
3. Presentation 2 (Pickering PXI Demo with Dan R.)
4. Presentation 3 (Time Synchronization with Josh R.)
5. Presentation 4 (Community Sourced)
6. Closeout and socialization time.

Event Logistics:

• Location: DMC Denver, 2601 Blake St., Suite 301, Denver, CO 80205​
• Date: Thursday, April 17, 2025​
• Time: 6:30 PM – 8:30 PM
• Parking: The entrance to DMC’s parking lot is located on Blake St. Please refer to the image below.
  • The main entrance of the office building is outlined in blue.
  • Guest parking is in the red area.
  • If those are taken, it is fine to park in the outlined green area in the image below.
  • Street parking near the office is also readily available and free!

We’re looking forward to a great evening with the Denver LabVIEW community. This event is a chance to connect, share ideas, and learn more about how others are using NI tools in real-world applications. Whether you’re presenting or just joining the conversation, we’re glad to have you be a part of it. 

The post 2025 Denver LabVIEW User Group Meeting at DMC appeared first on DMC, Inc..

DMC is proud to host this quarter’s Chicago LabVIEW User Group (CLUG) meeting on June 26, 2024! The CLUG is a group of LabVIEW users that meet quarterly to discuss new programming techniques, design choices, updates, and share stories about programming experiences or lessons learned. Due to the pandemic, the meetings have been hosted online for the past few years, but we are kicking off the summer season with a long-awaited in person meeting hosted at DMC Chicago! Back in 2019, DMC hosted a CLUG meeting, and we are so excited to invite everyone to this event again.  

This will be a fantastic opportunity to learn, get updates regarding NI and NI Software, network with other professionals in the Chicago area and have fun! Food and drink will be provided, and after the presentations you will have a chance to relax on the DMC rooftop deck.

This quarter’s user group will consist of some exciting presentations and discussions!

Agenda:

• 3:00-3:30 Arrive and settle in
• 3:30-5:30 Welcome & Presentations
  • Inspirations from NI Connect – Kevin Shirey, LabVIEW Champion and DMC Project Engineer
  • NI Software Roadmap – Eli Kerry, NI Software Director
  • Little LabVIEW Stories – Jeff DeBuhr, Staff Engineer at Chamberlain Group
  • Challenge of Champions – Eli Kerry
• 5:30-6:00 Networking and roof time

Event Logistics:

Location: DMC Chicago – 2222 N Elston Ave Ste 200 Chicago, IL 60614

Date/Time: Wednesday, June 26 from 3:30-5:30pm

Arrival: Please try to arrive and get settled in before 3:30pm so we can start on time

Parking: There is a parking lot adjacent to the north side of our building for DMC visitors. If it is full, there’s free street parking in the surrounding area on Elston, Honore, Lister, and Webster.

The post 2024 Chicago LabVIEW User Group Meeting at DMC appeared first on DMC, Inc..

Hardware experts don’t always have hours of time to invest in staying updated on the latest in LabVIEW like we do at DMC. Understandably, this can result in code that doesn’t follow standard architecture or best practices.

We’ve seen every kind of graphical code structure under the sun. It takes time to follow the hundreds of wires and many parallel loops to figure out what makes a program behave the way that it does.

Me analyzing LabVIEW code for the first time

Using OpenAI and LabVIEW

Text-based languages have benefitted from recent advancements in tools used to analyze and write code like Python with tools like GitHub Copilot. NI has been hard at work too, as evidenced by their recent demo of Nigel, but they haven’t yet released it.

In the meantime, I thought I could try something rudimentary to achieve a similar outcome using the GPT API from OpenAI with a few tricks to make it work on VI files (files for LabVIEW written in their G language). I wanted to see if I could use GPT to describe LabVIEW code.

Here are the steps:

1. Convert the LabVIEW graphical code to text-based code.
2. Pass the text-based code to GPT and ask it to analyze the code.

Converting Graphical Code to Text-Based Code

Step 1 basically describes a transpiler which is a compiler that takes code in one language and produces equivalent code in a target language, though as we’ll see that’s easier said than done. For my purposes, I decided to target Python-like code since it isn’t strictly typed and would let me get away with leaving out a lot of information about data types. It’s also likely that GPT is trained on tons of Python code and trying to use a language more equivalent to LabVIEW code would mean implementing more programming constructs in the transpiler or creating a proprietary intermediary language as NI has been doing with Nigel.

The first major hurdle is the fact that LabVIEW code isn’t written as a series of sequential statements. Instead, it is a data-flow language which uses “wires” to transfer information from block to block. This makes it especially great for simple-looking implementations of multi-threaded applications but annoying for our purposes. Luckily, this construct maps well onto the concept of computational graphs and we can try to move from code to a more abstract graph to make our life simpler. We can think of LabVIEW code as a “directed acyclic graph” with a set of start nodes (controls) and end nodes (indicators) connected by edges (wires).

But how do we convert LabVIEW code to a computational graph? Using VI Scripting of course! NI has a library of tools that lets you find all instances of a specified type of LabVIEW programming construct and if we look for all wires and note what pair of objects each one joins, we can build our graph.

We then take the graph and use a custom scheduler algorithm to create a sequence of operations for each of the code blocks and finally use the metadata of each wire’s two terminals to provide some additional data in the transpiled code.

Ask GPT to Analyze the Code

Add in some logic to avoid accidentally using the variable names in multiple places using UIDs and we’re basically done! All we do now is ask GPT to describe the code in terms of what it represents and not the actual variables themselves and we have a crude AI-powered VI analysis tool.

Except that it doesn’t work for:

• For loops
• While loops
• Broken code
• Cases where there are orphaned blocks
• Feedback loops
• Analyzing sub-VIs
• Etc.

You get the idea. Perhaps with a more structured approach to VI scripting and fine-tuning with example code, it might be possible to get more out of this idea, but I think this serves as a useful demo to see what might one day possible!

The post Creating Custom AI Tools to Analyze LabVIEW Code appeared first on DMC, Inc..

After a four-year hiatus, the Test and Measurement team was back at it again to create this season’s best LabVIEW ornaments.

“Four years ago, they had a very similar event, and I think that one was spontaneous. They had a Teams meeting one day and said, ‘oh wow, we could actually make these into ornaments!'” Roman Cyliax, Systems Engineer in Chicago, said. “Rachel is the one who brought it back, and we want to make it an annual event.” 

The holiday ornament-making event was not exclusive to Chicago’s Test and Measurement team, as other regional office team members were included.

“There were approximately 10 people from Chicago, and we had a few team members join in virtually from Texas and Seattle,” Milos Popovic, Chicago Systems Engineer, said. “We used the LabVIEW Development Environment. You can make icons for programs; you draw with this very clunky little icon editor, and you can make a 32×32 pixel image, so it’s very pixelated and grainy, but normally it’s enough information to say what a file does.” 

The team got to work and spent a few hours brainstorming, designing, printing, laminating, cutting, and finally adorning the tree with their festive icons.

“We probably made close to 30 ornaments,” Milos said. “We reused a few from the last time we did it just to fill out the tree.” 

From beginning to end, the ornaments took an extensive period of time to curate.

“You make them in the LabVIEW Icon Editor, which is not necessarily the most intuitive place to make an ornament,” Roman said. “You may spend about an hour drafting ideas and making ornaments. It took another hour and a half to cut and laminate the ornaments. In total, I think it took around 3 hours for our team to make the ornaments.” 

With dozens of ornaments made, a few stood out from the crowd.

“The ornament was a Christmas Constructor. In LabVIEW, you have classes. You construct a class, and it’s kind of like a one-function block. Usually, we have a stock image that’s like a construct and there’s maybe a little star next to it,” Roman said. “Rose made one that had the star being the point of a tree, so it was a Christmas Constructor. It was creative!” 

Another favorite was in reference to a quirk in LabVIEW.

“There is this quirk in the Icon Editor itself where you can make stuff transparent, but it doesn’t have a transparency button. There is one specific shade of off white that it interprets as transparency. You can accidentally choose this shade of white, and you think it’s going to be a white background, and then it just ends up being transparent,” Milos said. “There is an icon that has the RGB color code for that shade of white. Someone took the time to take an X-acto knife and cut out each pixel that is that shade of white, so it is see-through only on the text. That one’s pretty good!” 

After an evening of fun and team bonding, it’s clear that this is an event that the team wants to turn into an annual tradition.

“I think we want to make it an annual thing,” Roman said. “It’d be very fun to do it again next year!” 

Learn more about DMC’s Test and Measurement services and our company culture!

The post DMC’s Test & Measurement Team Makes LabVIEW Holiday Ornaments appeared first on DMC, Inc..

Background

The system we tested on had/did the following:

• Two PICC Programmers from Custom Computer Services, Inc. (CCS), ICD-U80 and Prime8
• They programmed 1 and 8 devices respectively: for a total of 9 devices programmed
• Windows 10
• LabVIEW 2019 SP1 (the version should not actually matter)

Methods

There are two main methods you can use to communicate with the programmers: CCSLoad.exe and Windows command line.

CCSLoad.exe

CCSLoad is the driver interface that allows you to execute operations with the programmers. I highly recommend starting with this to verify that everything is in working order.

1. In the Diagnostics tab, check that software and hardware versions are fully up to date according to CCS’s website. You can also update firmware/software directly from the tab.
2. You should be able to perform read/write operations using the programmers at this stage.
   • One common issue we noticed with older firmware versions of the Prime 8 was the slow speed of programming all 8 slots. The solution was to update to the latest firmware version.
   • The ICDU80 did not give us any issues.
3. If you have any issues performing actions with the driver, check the following:
   • If you are not connecting to the device, check your USB connection.
   • If you are failing to write, check your target file. Make sure that the chip type is specified in the file and that it matches the target.
   • ‘Erase’ and ‘Read’ functions should work as long as the chip is functional, both may be useful for troubleshooting the target chip itself.
4. Once you can successfully read, write, or perform actions without any issues, you are ready to move on to the windows command line. With the CCLoad program, you can only operate one programmer at a time. It must disconnect from one before connecting to another. With the windows command line you will be able to operate them both in parallel. You should be able to perform read/write operations using the programmers at this stage.

Windows Command Line

Full documentation of Command Line Usage can be found here:

C:\Program Files (x86)\PICC\ccsload.chm (Windows User Interface –> Command Line Usage)

This page provides a comprehensive list of all commands and their associated actions. I will be covering all commands that we used — which were  a very small subset of all the available ones.

Because we are using LabVIEW, we will use System Exec.vi to call the windows command line and send commands this way; however, the process should be the exact same as long as you are using something to call the command line.

The only three input parameters relevant for us are “command line”,” wait until completion?”, and “run minimized?”.

• “Command line” is the input string that determines the operation you want to perform.
• “Wait until completion” delays the transfer of information downstream until this VI has finished executing.
• “Run minimized” determines whether you want the command line window to pop up on execution or stay hidden in the background.

Here is an example of an erase command we are sending using LabVIEW.

Some things worth noting:

1. The first line is the path to the ccsloader.exe command line.
   • We are using the windows command line to call this new command line — which is then responsible for communication to the programmers.   
2. We specify the Port/Device because we will eventually be programming with two. If you are only using one Port/Device, this is not necessary as it should auto detect.
   • The nickname/alias for each device can be set manually here: “C:\Users\[your windows username]\AppData\Roaming\PICC\pcw.ini”
3. We always specify the device. I’ve found when you don’t specify, it can fail.
4. +ERASE is the actual operation we want — which erases the chip. The first 3 lines are all setup, and the following line(s) is the operation. 

When starting out, I highly recommend disabling ‘run minimized’ and enabling ‘wait until completion.’  This opens the command line on execution, and it also shows you exactly what it’s doing: like connecting, erase/read/write operations, and any errors it encounters. When it does error, it only briefly shows the error before it closes the window, so I recommend taking a video or recording it somehow to go back and replay what error it showed. Any other combination of these settings will not give you live feedback.

Here’s another example, except, this time, we are using the Prime 8 and performing a write action:

Notice that everything is the same except for the difference of PORT, DEVICE, and an additional line that defines the SLOT. For the Prime 8, since it is a multi-device programmer, you have to specify which slots you’d like to perform actions on. You can also see the format used for writing a target hex file.

The last example will be a read operation. Reading back from the device is important because we need to know if our operation was successful. It’s nice when the command window tells us, but it’s also good to verify the code itself. So, I recommend reading from the device both after erasing and writing. After erasing, the hex file should be full of 00 or FF, and you should be able to observe the difference post-write.

Here is an example of a command reading from all 8 slots of the Prime 8. Notice how we have to specify a different file for each slot since we need to verify all 8 slots are working.

Using these three commands, you should now be able to erase, write, and read using the windows command line: just like the CCSLoad driver interface. Once you get that, it’s time to move onto the last two steps: +STAYOPEN and parallel programming. 

+STAYOPEN

At this point, while performing operations, you may have noticed that the compiler must always connect to the device before starting its operation, and it closes automatically after it finishes. This is quite time-consuming as the time taken to connect to the device(s) often takes longer than the operation itself. The solution for this is to incorporate the command +STAYOPEN. This establishes a connection to the device and leaves it open — allowing you to send future commands without needing to connect over and over again. You essentially front-load the connection time once at the beginning and never have to worry about it again. The downside is you lose the ability to see the compiler updates from your commands — which is why it was important to establish everything was working before we got here.

It’s also important to know that if you use +STAYOPEN, you must also use +CLOSE to close the connection after, since it will not auto-close anymore. These commands look like this:

I recommend performing the following series of operations with each programmer to verify that everything is working properly before moving onto parallel programming.

1. Open connection
2. Erase chip (verify that it is erased)
3. Read from chip
4. Write hex file to chip
5. Read from chip (verify that it is no longer erased)
6. Close connection

Parallel Programming

Using multiple programmers in parallel is not an explored space according to CCS, but they have worked with me to get it working. That means, for the following steps, your mileage may vary. CCS support may be a useful tool in case you find your system reacts differently. We did perform parallel testing successfully with multiple computers, so there is some level of consistency present.

There are two categories of parallel programming: with and without the use of +STAYOPEN. I will first cover parallel programming without using +STAYOPEN.

The first thing you will have to do is make a copy of the ccsloader.exe application. You can simply CTRL+C CTRL+V it, and rename it something like this:

We will now need two instances of it, one for each programmer.

The ‘trick’ I’ve found is to duplicate the LabVIEW calls at this step: one for each programmer. Make sure to change the target compiler and the PORT. When you call them, do not call them at the same time. You should actually delay the calls about a half second apart. I found the secret recipe is:

1. Send a command to the ICDU80
2. Wait ~500ms
3. Send a command to the Prime 8

This looks something like this:

Notice how:

1. They are not wired in series. Remember, we want ‘wait until completion’ to be true.
2. We are calling both instances of ccsloader/ccsloader1 and specifying different port values. 

You should observe both compiler windows opening (slightly staggered), then both connecting successfully and performing the operation.

If this fails, you can try the following troubleshooting steps below:

1. If one fails to connect, open in driver interface to try to ‘reset’ the connection.
2. Swap the order of the programmer calls.
3. Fiddle with timing between device calls.

You should now be able to erase, write, and read using BOTH devices at the same time! The final issue to address is to incorporate +STAYOPEN, since we are still losing a lot of time connecting to the programmers.

Parallel Programming with +STAYOPEN

In a perfect world, we would be able to copy the same line of logic as when we used +STAYOPEN using a single programmer, but, unfortunately, it is not that easy. Initially, according to CCS support, the ccsloader program does not support two ‘STAYOPEN’ sessions on the same machine.  

When +STAYOPEN is used, the process creates a Windows server that can communicate with a client. That server has a fixed ID number built into the program. So, when we try to send two instances of the same ID, it doesn’t work; however, CCS were able to get back to me and send over another version of the ccsloader application that, instead, uses the full path and filename as part of the ID. This means that, with our ccsloader and ccsloader1, they should generate two unique IDs.

If you are at this point, you will need to ask support@ccsinfo.com for this version as I am unable to provide it here.

The following steps assume you do have this new version (simply replace the ccsloader and ccsloader1 with copies of the newer version).

1. You can now replicate the calls we did in ‘Parallel Programming without STAYOPEN’.
   • Delay the calls by 500ms.
2. Any future commands do not need to be delayed; they can be sent purely in parallel or in series with ‘wait until completion’ set to false.
   • There is no need to set ‘wait until completion’ to true anymore, since you will not get live compiler updates either way. Only the original +STAYOPEN command can give updates, but it will not give updates on future commands
3. Test and verify that the command order still works (Open, Erase, Read, Write, Read), and you’re done!

You have now successfully performed parallel programming using two programmers AND included the usage of STAYOPEN —  which has made the overall process more time efficient. 

Learn more about DMC’s LabVIEW Programming, and contact us today for your next project.

The post Parallel Programming with Two CCS Programmers appeared first on DMC, Inc..

1. Why Should We Configure Custom Device Messaging?
2. How to Send Messages between a Custom Device and LabVIEW
   1. Step 1: Pass Engine Event Ref into Custom Device Engine
   2. Step 2: Create Event Structures in Asynchronous Loop to Receive Messages
   3. Step 3: Create LabVIEW Code Module to Send Message

Why Should We Configure Custom Device Messaging?

Back to Table of Contents

Creating Custom Devices in VeriStand is a powerful tool that allows developers to package and deploy code for a device simply by adding the Custom Device to a system definition file.

There are two primary methods for transferring data to and from a custom device: channels and messages. Channels are typically used to read or write data in a control loop, and they can be interacted with by a user through a VeriStand screen once deployed. On the other hand, Messages generate events to configure and command custom device actions or properties.

Messages to Custom Devices are sent through LabVIEW code modules. There are many advantages to communicating with a Custom Device using messages from LabVIEW:

• Messaging data allows for more flexibility in the types of data sent to a Custom Device engine
  • VeriStand channels only support DBL numeric data, while messaging supports other data types
  • The number of channels is fixed by the system definition file, so data structures, like arrays, need to have a fixed size
• Because most Custom Devices are deployed through VeriStand onto RT systems, the ability to send messages between the Custom Device and LabVIEW allows for communication with a PC-based LabVIEW application
• LabVIEW code modules for Custom Device messaging can be used in TestStand steps to develop large sequencing and test applications with a Custom Device
   

How to Send Messages between a Custom Device and LabVIEW

Back to Table of Contents

Step 1: Pass Engine Event Ref into Custom Device Engine

Back to Table of Contents

When messages are sent between LabVIEW and a VeriStand Custom Device, the Custom Device engine treats the message as a user event. Before handling this user event in the async loop(s) of the Custom Device, all asynchronous loops should be passed the reference to the Custom Device engine events. This reference contains the events associated with Custom Device messaging in the engine and can be obtained with NI VeriStand – Register Custom Device Events.vi. Below is an example implementation of RT Driver.vi with the engine event reference being passed as an initialization parameter into the code that starts the asynchronous Custom Device process.

Step 2: Create Event Structures in Asynchronous Loop to Receive Messages

Back to Table of Contents

Now that the Custom Device engine events reference is accessible from the asynchronous loops, event structures may be created to handle message events. There are two messaging events within the engine event reference: Message (String) and Message (Byte Array). Both events contain a Command, Data, and a Response Event. The difference between the two user events is the format of Data.

• Command: the name or type of message being sent
• Data: the data associated with the command
• Response Event: an event reference to send back data to LabVIEW; consider using this to send back data processed by the Custom Device or a confirmation that the message was received

As shown below in the example code, a case structure may be implemented to handle each type of incoming message to the Custom Device. Each case contains logic to handle the message Data as well as generate a response and error message (if applicable). The response and error are bundled as a message response and sent back to LabVIEW through the Response Event.

One limitation of messaging between VeriStand Custom Devices and LabVIEW is that messages can only be formatted as strings or byte arrays; however, messages of any type may be flattened to a text string and converted into a byte array. Below is an example of how message Data could be handled within a case to receive data of a type associated with the message Command and send any type of response data back to LabVIEW as a byte array. In LabVIEW, message Data and responses can be converted to or from a byte array in a similar manner.

Step 3: Create LabVIEW Code Module to Send Message

Back to Table of Contents

After setting up event structures to handle messages sent to the Custom Device, the final step is to send messages and receive responses in LabVIEW. This is made simple by the Custom Device Communication Palette.

• First, use NI VeriStand – Open Custom Device Reference to open a reference to the Custom Device specified by Custom Device Path (also known as Node Path) and Gateway IP Address that can be used to send messages
• Next, call NI VeriStand – Send Custom Device Message to send the formatted message’s Command and Data, ensuring that the Data sent is of the type expected by the engine
• When a response from the Custom Device is received, call NI VeriStand – Close Custom Device Reference to close the messaging reference.

.

Scripting VIs based on a VeriStand system definition file can programmatically obtain references to Custom Devices and return properties such as the Node Path which is used in the VeriStand messaging VIs to open a messaging reference to a Custom Device. Stay tuned for more VeriStand tutorials and blog posts — including how to create a system definition scripting library!

Learn more about our LabVIEW Programming, and contact us today for your next project!

The post How to Communicate with a VeriStand Custom Device Using LabVIEW appeared first on DMC, Inc..

Table of Contents

• Customer Benefits
• Flex Blocks and Flex Coordinators
• Ethos Behind the Flex Framework
• Standout Flex Blocks and Code Features
• DMC Module
• DMC Device
• Typical Application Module/Device Lifecycle

Customer Benefits

Open Solution: DMC can provide clients with license-free source code, allowing clients to extend or explore the code.

Extensible: DMC’s Flex Framework is based on a proven, scalable, LabVIEW Object-Oriented architecture.  This allows for DMC engineers or clients to add pieces/functionality to an application while keeping the overarching application architecture managed and maintained, enabling faster development.

Re-Usable CodeBase: Solutions start from a vetted architecture and drivers proven out over multiple projects, instead of re-creating integration logic.  Projects also get the benefit of improved supportability as DMC continues to advance and improve the Framework, which can benefit any project that uses the architecture. 

Modular Design: The Flex Framework consists of a collection of stand-alone software packages, which have the potential to be utilized outside of the Flex Framework or extended within the Framework. 

Flex Blocks and Flex Coordinators

DMC’s Flex Framework consists of two key elements:

• Flex Blocks
  • Component pieces that perform an action in an application. Some examples are:
    • Digital Multimeters
    • Power Supplies
    • Graphing Displays
    • DAQmx cards
    • XNET/CAN cards
    • HMIs
• Flex Coordinators
  • Constructs which integrate, manage, and build the Flex Blocks into a focused solution

Flex Coordinators, such as the Test Stand class, pull from the library of Flex Blocks to create a tailored solution for each client.  Flex Coordinators are the ‘brains’ behind the application and serve as the string that ties the Flex Blocks into a functioning software package.

Flex Blocks modularize one task, device, or feature set, and are designed to be agnostic of other Flex Blocks wherever possible.

Ethos Behind the Flex Framework

The Flex Framework provides a tested and proven starting point for projects eliminating the development time it would take to build up these capabilities from scratch. Furthermore, it establishes a modular design pattern which enables developers to adapt and expand the Flex Framework to client requirements.

Common Code

Common code, such as device drivers, do not need to be re-written for each new solution or project. Instead, DMC has developed this code once to be shared and improved in a single location so many of our clients and projects can benefit from future changes or feature additions.

Hardware Abstraction Layer

It’s common to have many different brands and types of COTS devices in a test system, but many of them do nearly the same thing. For this reason, interaction with individual devices (i.e. Digital Multimeters (DMMs), Power Supplies (PS)) has been abstracted in more general classes. Children of these LabVIEW abstract classes implement specific methods to add device-specific functionality and meaning to the parent’s method. For example, an abstract parent “_Power Supply” class provides a common interface for all Power Supplies, but the children of this class (Agilent HVPS, Lambda ZUP power supply, RMX power supply, etc.) implement the hardware-specific drivers and communication protocols through which the interface acts.

Multi-project interface coherence

Each test system may have unique characteristics, but it’s usually desirable to retain commonality in the underlying code modules, LabVIEW user interfaces/user experience (LabVIEW UI/UX), and system design. This enables users to have a consistent experience when moving from one test station to another (i.e. EOL Test Station, R&D Test Station). There are also programming benefits since ramp-up on a new project that leverages the Flex Framework is quicker and lowers overall development cost.

Code Modularity

The Flex Framework has code modules that are as independent as possible, allowing them to be re-used without dragging unwanted dependencies into a project. DMC Flex Blocks are agnostics of the existence of other Flex Blocks. Only the Flex Coordinator knows about each Flex Block included in the application. This software encapsulation and modularity keeps code more maintainable over time, which provides greater value to end-users of the Flex Framework.

Standout Flex Blocks and Code Features

DMC’s Flex Framework has many Flex Blocks and features which we have explained in separate case studies:

• Alarm Handling
  • Provides traceability for system faults and notifications
  • Allow for system recovery from faults or errors
  • Standalone toolkit
• User Access Levels
  • Easy to integrate toolset which keeps track of user permission levels
  • Simple to extend and tailor to customer’s user role definitions
• Data Logging/Reporting Capabilities
  • Flexible logging utility
  • Live feedback of user-configured, graded, testing parameters in LabVIEW
  • Standalone toolkit
• DMC Grid Viewer
  • Dynamic test interface configuration
  • Subpanels any LabVIEW VI and allows for drag-and-drop interface configuration
  • Standalone toolkit
• Tailored User Workflows
  • Application-specific interfaces and implementations to tailor the Flex Framework to exact customer needs
• Manual/Automatic Control Modes
  • LabVIEW Testing automation abstractions
  • Automated running of pre-configured testing routines
  • Manual testing support, for in-depth engineering diagnostics
• Configuration Management with Workspaces and DUT construct
  • Configuration Management
  • Single click switching of Device Under Test (DUT)-specific configurations
• Test Execution with the DMCquencer
  • LabVIEW Test Execution Engine
  • Test automation
• Built-In Diagnostics
  • I/O Checkout Routines
  • System self-diagnostic check
  • Diagnostic Logging
• Hardware Abstraction Layer
  • Test stand hardware hot-swap support
  • LabVIEW design pattern

DMC Module

DMC Flex Framework’s LabVIEW Object-Oriented architecture is based on a lightweight class named the DMC Module.  Most of the classes in the Flex Blocks group are grandchildren of the DMC Module class.  Modules are independent pieces of code responsible for a particular function.

DMC Modules introduce the concept of a ‘Module Command.’  These commands are used to capture a given Module’s API usage, keep track of the data modified by those API calls, and provide a level of traceability to an application.

Additionally, the Module class allows for the definition of daemons and/or interfaces which the Module may use to meter out tasks, maintain heartbeat communication with a device, or provide a user interface for an operator.

DMC Modules are typically software constructs which don’t have physical manifestations (i.e. database loggers, file writers, and data processing tools)

DMC Device

The DMC Device class inherits from the DMC Module class and is its most commonly used child.  DMC Devices add one additional piece of functionality: variable publishers.  Most classes in the Flex Blocks group are children of the DMC Device class.  Like Modules, Devices are meant to be independent pieces of code (i.e. they do not interact with or know about the existence of other DMC Devices).

Variable publishers are used in the Device Command architecture (which draws from the DMC Module Command architecture).  If a device API is called with the Device Command constructs, then the class is able to post ‘modified’ variables to a registered variable publisher.

Keeping track of modified variables allows for a single place in an application to monitor variables (an example of this could be a Current Value Table).  DMC uses this collection of device variable values to monitor the health of a test system, abort automated testing if a variable violates a safe operating range, and centralize reporting of system variables through the application’s lifecycle.

DMC Devices are usually classes which interact with physical hardware (i.e. digital multimeters, power supplies, relay modules, DAQmx hardware). 

Typical Application Module/Device Lifecycle

Many of the projects which utilize the DMC Flex Framework follow a common pattern:

1. Application is launched
2. User configures settings
3. The user chooses to run an automatic test or manually interact with the system (Manual Mode or Automatic Mode)
4. The testing Mode (Manual or Automatic) is active until the test finishes or the user clicks ‘Abort’
5. The system goes to an idle state
6. Repeat Steps 2-5 as needed
7. Application is closed

To accommodate this application lifecycle, a corresponding Module/Device lifecycle is managed by the Flex Coordinators by breaking the Modules/Devices into two groups:

• Eternal Modules/Devices
  • Active through the entire application lifecycle
  • Examples include interlock monitoring devices, database connection modules, etc.
• Session Modules/Devices
  • Active during the testing mode only. Constructed/initialized when the test begins and terminated/disposed of when the test mode completes
  • These are typically constructed on application start and parameters pulled from a System Parameters file, but then are disposed of and re-constructed when a test begins
    • This is done to capture any settings (and subsequent System Parameter file) modifications prior to starting a test

An example lifecycle of both Eternal and Session Modules/Devices are shown below.

National Instruments / LabVIEW Experience

DMC has been a National Instruments (NI) Alliance member for over 10 years with one of the largest teams of Certified LabVIEW developers in the country, including several National Instruments’ Certified LabVIEW Architects (highest level of certification available), and multiple NI Certified LabVIEW Developers.

DMC is proud to be recognized as a National Instruments Alliance Partner. Learn more about DMC’s National Instruments partnership and contact us today to find the Flex Framework solution that’s right for you.

The post DMC Flex Framework: A Flexible LabVIEW Toolset appeared first on DMC, Inc..

This meeting began with Pizza and networking between DMCers and LabVIEW users from the Chicagoland area.

We kicked off the user group meeting by highlighting some of the most exciting features that were released at NI week this year.

NI Week 2019 Overview

DMC Presentations on LabVIEW Programming

Systems Engineer Ryan Yu presented an overview of NI Package Manager, with content initially developed by National Instruments and presented by Allen Hsu.  Yu showed LabVIEW users the workflow for installing, upgrading, and managing NI software.  He then highlighted the workflow of both NI Package Manager and SystemLink, when used in conjunction with LabVIEW. Users exchanged ideas with Yu and asked questions on use cases, versioning, and SystemLink feeds.

NI Package Manager

Systems Engineer Kyle Mitchell demonstrated JKI’s VI Package Manager, a reasonably popular tool among the user group. Mitchell gave a walkthrough on how to build and deploy packages within LabVIEW, and users shared their experiences and tips about VIPM.

VI package manager

Sharing LabVIEW Stories

This section of the meeting is devoted to short topics (max of 10 minutes) talking about a neat project, cool tool, or challenging problem users need help solving. 

Users shared stories about creating a custom VI to update UI elements through property nodes more effectively, warned about big arrays affecting the search feature, and one user shared a story about how to do LabVIEW translations effectively.

There was also a shoutout to the LabVIEW wiki that the community is currently constructing.

Thanks to our friends in the LabVIEW user group who made it to the event!

Learn more about DMC's partnership with National Instruments.

The post Chicago LabVIEW User Group Meeting at DMC appeared first on DMC, Inc..