MODAQ Reference Design Manual
Since each project tends to be unique and measurement objectives can vary considerably, there is no typical configuration that will satisfy all situations. Instead, most MODAQ:Field builds start from a common base configuration that encompasses features commonly used in MRE DAQ projects. While that still might not be suitable for all applications, it provides a good starting point and model for discussion. This reference design (MODAQ:RD) represents the core MODAQ:Field configuration as a starting point for most builds. If an end user were to buy the same hardware, configure it the same way, and use the linked MODAQ:RD code, the user should be able to set up a functional MODAQ:Field system.
Some topics discussed below are covered in greater detail in the Technical Reference section of this document.
MODAQ Hardware Reference Design
This repository contains a version of the MODAQ:RD based on the DAQmx API, though an FPGA based version can be made available upon request. Users with older cRIO chassis will need to use the FPGA version, while users with newer cRIOs (cRIO-904x and cRIO-905x series), can use either version, but are encouraged to use the DAQmx version. Tech Note:The FPGA version will require a license to the LabVIEW FPGA module in order to build the FPGA bitfile or make changes to the FPGA source code. In addition, if precision time keeping is important, the FPGA version will require the NI-9467 module.
Tech Note: National Instruments introduced DAQmx and Time Sensitive Networking (TSN) support to cRIOs beginning with the 904x and 905x series. To meet more demanding requirements, particularly for large designs with lots of I/O, MODAQ:Field now uses DAQmx in the core design. These larger designs require TSN to assure precision timing and synchronization between multiple chassis.
This reference design has been built and tested on the cRIO-9049 embedded controller, however this code will likely run on most recent cRIO variants with Intel processors and the Linux real time kernel with little to no modification. The core MODAQ:RD configuration, before consideration of device-specific measurement objectives, includes code for a GPS/Inertial Navigation System (GNSS) module for position, heading, and attitude. This device can connect to the built-in RS-232 port on the cRIO, however since it's common to have separate GPS and IMU devices, and thus requiring more than one RS-232 port, we include the NI-9870 4-port RS-232 module in this design. If only one RS-232 port is needed (such as the case with a GNSS or if there is no need for either the GPS or IMU), then the NI-9870 can be omitted and the single built-in RS-232 port can be used instead. See this in the Technical Reference section for more information on configuring the serial ports. Tech Note: One of MODAQ:Field's basic design requirements includes precision timestamping of measurement samples and events. To achieve this, earlier builds of MODAQ:Field designed on older cRIO hardware used an Ni-9467 GPS time synchronization Module and the Timekeeper API implemented in FPGA. This was great at the time and continues to be a viable and effective solution for accurate timestamping. However, as mentioned in the previous Tech Note, newer cRIOs support standards-based TSN or PTP (Precision Time Protocol)- which has distinct advantages over the former method with the NI-9467 module. Please see the Technical Reference for more details. The FPGA version of MODAQ:RD uses the NI-9467 method, while the DAQmx version uses PTP. Not to over-complicate this matter, but PTP can absolutely be used instead of the NI-9467 with the FPGA version, but only if the cRIO supports PTP (cRIO-904x and cRIO-905x series).
As a basic system, the MODAQ:RD is designed to acquire 3-phase voltage and current from a generator or PTO (power take off) at sample rates up to 50 kHz at 24 bit resolution for power performance and quality assessment. Essentially, this is a core configuration with added voltage input cards. Here is a list of the required National Instruments hardware: Tech Note: This design assumes the use of PTs and CTs (potential and current transducers) that output a voltage proportional to the signal under measure in the range of ±10 VDC (example Verivolt IsoBlock V). MODAQ:Field can also be configured to measure PT/CTs that have outputs up to 300 Vrms (PT) and 5 Arms (CT), but for safety considerations NREL recommends using PT/CTs with low voltage outputs where possible. The higher voltage and amperage output option is implemented in FPGA for high speed acquisition and this code is not provided by default with the reference software. Please contact NREL for more information.
The following GPS/INS/IMU devices currently have MODAQ:Field support but only the XSens INS noted below has been enabled in the MODAQ:RD code. SubVIs for the Spatial Dual and V104 are included in the code, but disabled by default. It should be noted at this point that NREL typically incorporates higher-end true INS devices (both GPS and IMU in one device) in its system specification. Most of the units listed here sell for several thousands of dollars. Depending on measurement objectives and quality expectations, cheaper instruments may be used, however MODAQ:Field drivers or decoder/parsers for devices not appearing on this list will need to be written. Also, the V104 (which as been succeeded by the V123 or V200) is a dual GPS self-contained in the antenna unit. It provides heading and heave in addition to position. Again, a project may elect to substitute a cheaper, less capable device. Since MODAQ:RD can parse standard NMEA-0183 GPS sentences, MODAQ:RD code modifications should be minor. A detailed hook up guide will not be provided here, however MODAQ:RD will expect the I/O modules to be in the slots as indicated in Figure 1 above and the sensors/instruments attached to the I/O modules in the following order: WARNING: Only connect PT/CTs with ±10 VDC outputs to MODAQ:RD's NI-9239 modules. Do not connect MODAQ:RD directly to a generator's 3 phase AC lines. If unsure, please consult with the appropriate electrical expertise prior to attaching MODAQ to an energized system. Always have electrical work completed by trained professionals with the necessary certifications to conduct such work. NREL provides the MODAQ:RD LabVIEW source code in this repository and users are free to use and modify this code under the Revised BSD License applicable open source licensing terms. To view, modify, and/or deploy MODAQ:RD from the source code, the following LabVIEW development environment is required: MODAQ:RD has not been tested on versions of LabVIEW newer than 2019SP1. Chances are that later versions of LabVIEW will run MODAQ:RD fine, but LabVIEW will recompile (upgrade) the MODAQ code to the later version- which will not be backward compatible. Keep this in mind if you intend to contribute back to this project or post issues to the repository. National Instruments now only offers LabVIEW as a software subscription and the current cost for the required packages is $3,159.00 to $5,762.00 per annum as of 2023 (there is no discount for buying multiyear). NI offers a "Debug and Deployment" version of LabVIEW as a perpetual license that is intended to be used for modifying existing code and deploying it on targets. It is recommended to review the license terms for the Debug and Deployment edition to understand what uses are allowed and whether it's a suitable alternative to the pricier development editions. Either way, LabVIEW is a very sophisticated and capable programming language that can take years to master. A programmer skilled in other languages, such as C/C++ or Python, may be able to gain sufficient LabVIEW competence in short time to modify/customize and deploy the MODAQ:RD code. NI offers both free and paid tutorials and courses for learning LabVIEW and a tiered Certification Program. Aside from going the route of getting a LabVIEW license and in-house LabVIEW expertise, there are a couple of additional options. A stand-alone configurator utility is provided to customize various settings within MODAQ:RD. This was developed to avoid 'hard-coding' values within the software and allow more flexibility without having to edit the source code and recompile the executable. Since this MODAQ:RD is a relatively simple implementation of MODAQ:Field, the included Configurator is similarly simple. Settings made in the Configurator are saved to an XML file that is loaded by MODAQ:Field on startup. Therefore, any changes made in the Configurator while MODAQ:Field is running will be ignored until the system is restarted. In a pinch, it is possible to manually edit the XML file in a text editor, however this is not recommended since it could render the file unreadable to MODAQ:Field. The Configurator runs on the user's local computer and the resulting XML file must be moved to the cRIO manually. MODAQ:RD will expect to find the file (MODAQ RD Configuration File.xml) in the root folder of the storage drive located at /media/sdb1/. Ironically, the location and name of the configuration file are hard-coded in MODAQ and cannot be changed in the Configurator. When MODAQ starts up, it auto-archives a copy of the loaded configuration to the /media/sdb1/Logs/ folder. This provides a reference of what configurations were applied for any given run. The NI-9049 cRIO controller has 16GB of onboard storage and also contains an SD card slot. Paths to the preferred data storage location can be set in the Configurator. Since the onboard storage is relatively small and shared with the Real-Time Linux operating system it's not recommended to use this storage for measurement data. An SD card is a viable option, but these can be slow and have reliability issues. National Instruments specifies industrial UHS-I SD cards for the cRIO controller with capacities up to 32 GB. The preferred option is to use an SSD drive connected to one of the USB 3.1 Type-C ports (the USB-A port is limited to USB 2.0 specification) on the controller. This way, speed and capacity are no longer an issue. All high-resolution measurement data generated in MODAQ:Field is saved to the binary TDMS format. As mentioned in the Software Architecture section, TDMS can be read in Excel (with this plug in), MATLAB, and python, or TDMS data can be viewed, manipulated, and exported with 3rd party tools such as Scout. See the technical reference section for more detail on how TDMS is used in MODAQ:field. In addition to the binary TDMS files, most MODAQ:Field modules also create a comma separated value (CSV) text file called a summery file. These are "summary" files in the sense that in most cases they contain sub-sampled, resampled, statistical, or summarized versions of the raw measurement data that are easier to upload over low bandwidth connections. Summary file upload interval can be set in the Configurator. MODAQ:Field uses AWS S3 for programmatic data transfers. Users can independently enable S3 uploads of the TDMS and summary files in the Configurator. They can also set their AWS access and secret keys, as well as the desired S3 bucket. Since TDMS files can become large, users should evaluate available network bandwidth and data transfer costs before enabling the TDMS upload option. Slow TDMS file transfers could impact measurement determinism and in some cases, data may be generated at a rate faster than the available transfer speed. Various events within MODAQ:Field can be set to issue an email alert to a distribution list. This is useful for monitoring for exception conditions and users are encouraged to set email alerts judiciously in order to avoid email fatigue. Settings for the email server address, account credentials, and distribution list email addresses are done in the Configurator. An email service provider is required to use this feature, such as gmail, web email hosting service, or a properly enabled enterprise email server. MODAQ:RD includes a watch circle feature. Since most field deployments are quasi-stationary, like in the case of a surface buoy, the watch circle can alert users by email if the device moves beyond a preset distance from its mooring location. Watch circle preferences and alert radii are set in the Configurator. The Spatial Dual also includes a dual GPS receiver, which can not only give highly precise positioning data but also determine heading. It also covers both the positioning and attitude tasks and has internal sensor fusion to control IMU drift. ↩ The SubVI included in the reference design for the XSens INS will likely work with other XSens MTi-series devices assuming they use, or are configured to use, the MTData2 binary format. We have only tested the code with the model indicated. ↩ 32 bit LabVIEW is required, since the 64 bit does not support the Real-Time Module. ↩
Setup
MODAQ Software Reference Design
LabVIEW
Configurator
Local Storage
TDMS
Summary Files
AWS S3
Email
Watch Circle