• Send a message to the IoT hub (device to cloud messaging)
• Receive messages from the IoT hub (cloud to device messaging)

The customer was seeking to improve their operations by connecting their field assets to the cloud. In the field, NI CompactRIO (cRIO) controllers were running a custom LabVIEW real-time app to control hardware and log data on the field equipment. The data was all there, but the data was distributed and only accessible from HMIs out in the field. They needed a simple solution to make their data actionable and viewable centrally.

The web app’s APIs were available to the LabVIEW app via LabVIEW’s HTTP Client toolkit. When the LabVIEW app collected data, it simply made an HTTP request to the web app to send the message to the IoT hub. This limited changes and impact on the LabVIEW real-time app.

Our customer’s equipment is often in remote locations, so internet connectivity is not consistent. DMC built in a local caching implementation using SQLite. This allowed offline field devices to preserve messages without internet connection. With caching, the web app could also build larger messages, limiting the number of messages sent to the IoT hub. Azure IoT hub charges per message, so this is a cost-saving feature.

The connection to Azure provided our customer with valuable insights into their field equipment. They can better schedule with live data, analyze failures, and perform preventative maintenance. The Azure IoT Hub provides a secure and scalable platform for aggregating and storing data and the web app. The Azure IoT Hub also enables many data analysis and visualization tools such as CosmosDB and PowerBI dashboards.

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

The post NI-cRIO Connection to Azure IoT Hub appeared first on DMC, Inc..

By using subpanels, we can then create user interfaces and workflows that are tailored to each project. For example, one project may require a comprehensive view of all device activity as soon as the application starts up (shown on the left), while another project may require starting on a login screen to maximize security (shown on the right).

Additionally, the framework has two independent HMI templates. The user can choose to simultaneously utilize both HMI templates for a dual monitor experience, which is an excellent option for projects that need to view a large amount of data at once during a test.

The Flex Framework also integrates our user login toolkit to control the exposed functionality based on the current user’s credentials. The access level can control aspects such as button or screen visibility. For example, most applications need to hide the settings page unless the proper user is logged in.

From screen layout and design to operator flow, everything about this HMI can be changed to suit a project’s specific needs. In other words, adopting the Flex Framework doesn’t require settling for a cookie-cutter user interface. Individuals have full control over the system’s user experience and operating workflows.

These features are part of a powerful suite of tools called the DMC Flex Framework. Find out more about all of these tools here.

Learn more about DMC’s LabVIEW Programming Expertise.

The post Customizable UI in DMC’s Flex Framework appeared first on DMC, Inc..

The goal of the Results Manager is to enable easy creation and logging of test information in a variety of formats.

The Results Manager organizes data into a simple, hierarchical data schema consisting of three levels: Session, Section, and Measurement. This hierarchy is depicted below:

1. Session
   1. Section A
   2. Section B
      1. Measurement 1
      2. Measurement 2
      3. Measurement n

Breaking down these three parts:

• Session
  • A complete set of test data
• Section
  • A specific procedure or test section within that set of data
  • There can be MANY sections within ONE session
• Measurement
  • Any analog, digital, or text value (i.e. DMM voltage reading, CAN DTC payload, Serial/VISA string response)
  • There can be MANY measurements within ONE section

Figure 1: Example of results displayed in a user interface

Results Manager Measurements

Each measurement is designed to contain the following information:

• Name
• Value
• Outcome (Pass/Fail/Unknown/Not Tested)
• Timestamp
• Grading Conditions
  • Analog – A user-configured range of acceptable values
  • Digital – The desired state of the Boolean value
  • Text – A Regular Expression used to match the input text

Numeric, text and Boolean measurements are natively supported; however, the Results Manager is flexibly designed to support additional data types easily.

To add new data grading type, a user can follow a plugin approach (leveraging LabVIEW Object-Oriented techniques by overriding the _Standard Measurement class) to create the type of grading logic needed for their application.

When configuring a measurement, a set of Grading Conditions can be specified to be applied to the reported value. When the Results Manager receives the measurements during testing, it will compare the value to the Grading Conditions and determine if the value ‘Passes’ or ‘Fails.’

Results Destinations

Results Destinations are constructs set up to export the data generated by the Results Manager. A Results Destination is a consumer which receives data from the producer, the Results Manager. Results Destinations handle formatting and delivery of the data to a desired location. Examples of past Results Destinations include:

• Web database via RESTful API
• Text, CSV, and TDMS files
• Live user interface display

The Results Manager can write to multiple Results Destinations at once, allowing for parallel logging of any individual Measurement (i.e., logging a measurement to a text file and a database concurrently). In the background, the Results Manager handles distributing data to each configured Results Destination to keep the user’s code clean and the Results Manager API simple.

Creating new Results Destinations is simple and follows the same LabVIEW Object-Oriented approach as a measurement: the user overrides the _Results Destination class and implements the data formatting and exporting to fit their application needs.

These features are part of a powerful suite of tools called the DMC Flex Framework. Find out more about all of these tools here.

Learn more about DMC’s LabVIEW Programming Expertise.

The post Flexible Logging with the LabVIEW Results Manager appeared first on DMC, Inc..

Up to eight ECUs can be simultaneously flashed with this test stand, drastically increasing automotive efficiency. All eight channels can be activated simultaneously or controlled individually. Each channel relies on its own “clone” of the core software required to control the flashing process properly. This ensures that all channels have equivalent and identical behavior, but remain independent from each other for flexibility.

Additionally, a DMC Relay Board controls the connectivity between the ECU and the various test stand devices, routing power and communication lines for proper ECU interfacing. This gives the system automated control over which channels are active. The image below demonstrates how each channel can be in different stages of the flashing process. 

Vector vFlashStation API

Vector provides a set of C/C# API methods that allow an external application to control their vFlash software. In this case, we created a C-based wrapper of these API commands so that we could access them through our LabVIEW application. For more details on how we accomplished this, check out the “Simultaneously Flash 8 ECUs with LabVIEW and Vector” blog.

Flexibility

The test stand was originally designed with four different ECU models in mind, but a modular and configurable architecture allows the end users to add/edit/delete ECU models to cover evolving product/test requirements. The application creates LabVIEW readable files for each ECU model that store the chosen flashing parameters. The program then creates, modifies, or deletes these files as necessary. This gives the customer the flexibility to modify the functionality without any additional software development.

UDS Request and Response Verification

Vector vFlash allows users to implement a pre-action and post-action script, so any function called within these scripts will execute at the appropriate time. This test stand utilizes these scripts to send UDS requests before and after software flashing to verify proper installation. Some of the requests sent include requests for ECU parameters such as software version, battery voltages, timestamp, etc. The software also sends shutdown commands through Vector tools to ensure that the configured parameters are saved to memory. The vFlash API then uses the ID byte to read and store the response from the ECU. The test stand then writes this information to a report text file (described below).

Manual Mode Operation

The software includes a system state diagram that provides manual control of individual relays and device configuration. From this view, the operator can perform any operation that the test stand hardware is capable of through a user-intuitive front panel. The relay controls can be toggled through mouse clicks, and the color indicates the current state of the relay, making it a powerful tool for ad-hoc measurements and investigations outside of the standard test procedure. This mode is only available to users with the proper access level.

Operator Error Reduction

Flashing an ECU with the wrong software could lock up the ECU due to an incorrect SeedKey. A locked-out ECU now needs to follow special protocol to be rebooted, which can cost time and money. This test stand mitigates the problem by verifying the serial number of the scanned ECU against the ECU software selected. If the serial number matches serial numbers of the desired ECU type, flashing will continue as normal. Otherwise, the flashing process is canceled, and the operator is alerted to verify the ECU scanned or ECU type selected.

Security Checks

Once an ECU flash procedure failed, it’s critical to understand why and repair the ECU if necessary. To ensure that a trained technician is aware of any potential issues, the test stand will lock out any channels that have experienced an error and remain in the error state until the proper user has logged in. This prevents operators from ignoring issues or shipping ECUs with potential errors.

If the operator enters improper credentials to reset the failure, a pop-up will notify the operator and remain in the error state.

Report Generation

A folder for each ECU is created with the ECU type and serial number in the folder name. Each folder contains files that log the UDS request and response verification portion of the flashing process. The data logged includes the Vector request byte, the recorded ECU response, as well as the configured limits for an acceptable response. The program also compares the recorded response to the configured limits to generate an overall pass/fail value for the flashing process.

Additionally, the error state triggers another text file that tracks the error that occurred, the user who reset the error, the channel affected, and a timestamp.

The hardware design and software architecture make this test stand an extremely flexible and powerful piece of test equipment. Not only does it increase throughput, but it also simplifies the overall flashing process for the operator.

Learn more about DMC’s Test and Measurement Automation Services. 

Learn more about DMC’s LabVIEW Programming Expertise.

The post 8-UP ECU Flashing Station appeared first on DMC, Inc..

1. CAN 2.0A (11-bit Identifiers) or 2.0B (29-bit Identifiers)
2. User-defined CAN Databases in *.dbc, FIBEX, or *.ncd formats
3. SAE J1939
4. Unified Diagnostic Services (UDS)
5. XCP (Universal Measurement and Calibration Protocol)

The software is predominately built around NI’s XNET API for LabVIEW, which allows reading raw frames and parsing frames against a provided DBC or FIBEX database to extract meaningful signals in engineering units.

During operation, the MPCL reads all data from the bus, filters to show signals of interest, displays the live data on the screen, and logs to the efficient and compact TDMS file format.

Sessions and Automatic Tagging

The Multi-Protocol CAN Logger supports organizing data into logical sessions.  For example, some DMC clients connect an ECU at the beginning of a session, run series of tests, then disconnect the ECU to conclude the session. Each session then contains logged CAN data alongside other important pieces of information, such as the ECU’s firmware version, serial number, test ID, etc. 

The MPCL is designed to sit idle until the designated CAN bus detects traffic. When traffic is detected, the MPCL optionally performs a startup sequence that can wake up, configure, and/or identify the ECU (see Figure 1, “ECU Identification / Wake up”). 

In one example deployment of the MPCL, a client used the ECU Identification portion to request a number of parameters from ECUs under test (using DMC’s J1939 toolkit), including firmware version, serial number, and other key pieces of information that could be used to provide context to the data files for that session. In this system, the serial number or firmware version of the ECU is used by the software to dynamically decide which database files to utilize, with no user interaction required.  This gives the MPCL pre-configured flexibility to communicate with many ECU models properly.  

TDMS Logging

When a new session starts, a TDMS file is created and populated with tags.  The MPCL initializes relevant CAN communication sessions for whatever protocols the user has enabled (frames, databases, XCP, UDS, J1939, etc.).  The software starts reading, displaying, parsing, and logging all data sent via CAN. If the MPCL detects inactivity, the tool closes the sessions and concludes reading and logging.

Figure 1: A diagram representing the typical states and transitions of the system.

XCP

The CAN bus for some ECU’s may support XCP, a higher-level “application layer” protocol that builds structure and functionality on top of the CAN data-link layer.  XCP works differently than “broadcast” CAN in that XCP messages don’t get transmitted without a request-response process.  The MPCL manages the initialization and servicing of XCP DAQ sessions to gather desired XCP data.  These MPCL functions are built upon NI’s ECU Measurement and Calibration toolkit which enables full implementation of the XCP master node specification.  The software uses A2L database files to carry out XCP communications.

Unified Diagnostic Services (UDS) Protocol

The Multi-Protocol CAN Logger supports the most powerful features of the UDS Protocol, including:

1. Service ID 0x10: Diagnostic Session Control
2. Service ID 0x27: Security Access (seed key authentication)
3. Service ID 0x3E: Tester Present
4. Service ID 0x22: Read Data by Identifier
5. Service ID 0x2E: Write Data by Identifier
6. Service ID 0x19: Read DTC Information
7. Service ID 0x31: Routine Control (Start, Read, Stop)

SAE J1939 Protocol

The MPCL supports the most powerful and common features of the J1939 protocol, including:

1. Read Parameter Group Number (PGN)
2. Retrieve Active Diagnostic Trouble Codes (DM1 and DM2)
3. Clear Active/Inactive DTCs (DM3, DM11)
4. Memory Access Request (DM14)
5. Memory Access Response (DM15)
6. Binary Data Transfer (DM16)
7. Seed Key security (DM18)
8. Multi-packet Transport Protocol

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

Contact us today to get started on your project.

The post The DMC Multi-Protocol CAN Logger appeared first on DMC, Inc..

The program not only displays the relevant CAN information for immediate operator feedback, but also has a live video stream integrated into the user interface using a VLC Media player plugin. The user interface allows operators to enter information which is tied directly to the CAN data, including project name, specific operation, and pipe number. The software continuously records all CAN data to TDMS files for later review and report generation. DMC provided a language framework to view these reports and the user interface in both English and Russian.

In order to preserve all drilling data, DMC implemented a data logging solution which starts automatically if the operators fail to indicate that data acquisition should begin. The software continuously analyzes the CAN bus, even when drilling data is not set to be recorded. If the program determines that drilling is being conducted, then it will automatically open a new project file and begin logging data to a TDMS file.

Learn more about DMC’s LabVIEW Programming Services.

The post LabVIEW CAN Monitoring and TDMS File Logging appeared first on DMC, Inc..

During the build phase, DMC worked with a trusted industry partner to complete design, electrical and mechanical drawings, construction, and testing. Together, we built and tested each test-stand completely so that the client was free from the technical responsibilities  of wiring, plumbing, power, and safety issues. The result was a set of fully completed turnkey test-stands that could be shipped directly to the client’s new laboratory.

The goal during software design was to present the user with a simple user interface that could initiate common tests very quickly, but also permitted completely flexible and customizable data-acquisition when desired.  For example, the user can start the software and initiate a commonly-run power-consumption test within seconds. Or, the user can choose individual data-acquisition devices and run a fully custom test without requiring any other technical details about the transducers being used.

While most appliances are only active for brief periods, refrigerators demand much more rigorous testing. The refrigerator test-stand therefore employed a rugged data-acquisition solution that could reliably acquire data, in the presence of the accompanying PC or not, for over a week. This was achieved with a real-time computer, NI’s CompactRIO 9114, which collected data and sent it to the test-stand PC. To promote usability and familiarity, the PC software exposed the same user interface for refrigerators as for other appliances. If the PC crashed or became disconnected, the cRIO would cache data locally until the PC became available. This recovery procedure prevents an expensive loss of time due to an unexpected PC issue during a very long test.

The entire project was built with extensibility in mind. Adding more tests only requires software changes if a specific calculation is required for a test. In general, new tests can be added by simply specifying the desired transducers and user input data. The test-stands initially supported several transducer types to make many different measurements: voltage, current, power, humidity, temperature, water flow & pressure, gas flow & pressure, and more. More transducer types can be added easily using NI’s Measurement and Automation Explorer.

After each test, all data is saved to an on-site Windows server. The test data is summarized and logged to the server’s SQL database. A secondary application written by DMC allows users to search the database for tests matching certain criteria. It can then load the data for display and analysis. Separate software packages for data acquisition and data analysis, combined with a central server, permits the user to conduct analyses outside the lab or even outside the facility.

Learn more about DMC’s test and measurement automation services.

The post Consumer Product Turnkey Appliance Test System with Power Measurements using LabVIEW appeared first on DMC, Inc..

DMC seamlessly integrated existing code into a stable and robust PID temperature controller for gas cartridge heaters and created a separate, resettable DAQ engine to handle all digital and analog I/O. After introducing client staff to a queue-based State Machine, DMC modified and tested TCP/IP project libraries into a message handler to act as a liaison between PXI and PC. High-speed CAN communications are handled and parsed separately, ensuring synchronization and data integrity. Test Logic components are launched anew during the start of each test and run linear sequences, setting control valves and gas flow rates. Gas composition and CAN data collected during the test are pushed to the PC application for display and logging. Once integration and full debug were complete, stand-alone executables were delivered.

DMC left the client development staff with both a professional application and the knowledge to maintain and reuse source code internally for future projects.

Learn more about DMC’s test and measurement automation services.

The post Automotive Smart Sensor Testing in LabVIEW appeared first on DMC, Inc..

On the software side, DMC developed the UI with usability in mind. The program supports a manual mode, for users to isolate and probe different part valves for easier leak detection. The Automatic Test sequence steps through the different test components, checking first for each valve’s functionality before quickly monitoring leak-rate on the manifold. If a leak is detected, users have the ability to pause the test to investigate, depressurize and tighten components before continuing. The main test allows pressure to stabilize, then monitors pressure drop over a given timeframe. Start and limits are clearly marked on the screen for user observation. Estop or abort at any time will vent the entire system and place it in a safe state.

After the test is complete, the operator has the option to log data and results to a central database. The relational database tables link sub-assembly pieces up with final shipped parts. Editable test parameters, such as maximum allowable pressure drop, can be setup through password protected configuration screen.

Designed and built with a flexible software and hardware architecture, DMC was able to ensure that new functionality, modifications, and upgrades could easily be added. 

Learn more about DMC’s test and measurement services.

The post Turnkey Solution for Food and Beverage Product Testing appeared first on DMC, Inc..

DMC met with the client software team, gathering system information and requirements. After reviewing all pieces and defining an architecture that fit their application, development tasks were divided among all programmers. DMC tackled more advanced topics, such as developing a custom TCP message handler between PC and PXI, while the client moved forward, modifying subVIs to work with a queue-based state machine. On other pieces, DMC worked alongside client staff, forming libraries and cleaning up previously written LabVIEW code. DMC and client developers met nearly every week to check on status, merge code, and test on the PXI station. DMC provided design, best-practice guidance, and inside NI know-how throughout the entire project. DMC also introduced good software project management skills, such as scheduling demos, setting release timelines and issue tracking as well as ramping up team on source code control.

Once integration and full debug were complete, DMC rolled both applications into stand-alone executables. DMC taught the client development staff best practices for maintaining and reusing source code internally for future projects. The client retained all libraries and source code to continue development as they see fit.

The post LabVIEW Consulting and Training for Internal Development Team appeared first on DMC, Inc..