Symphonic Stand

Table of Contents

• Requirements
• Testing
• Components
• Conventions
• Physical Structure
• Bookmarks

Requirements

• Developed in LabVIEW 2025 Q1

• Most of the libraries can be installed by using VIPM to install .\cfg\environment.vipc. See that file for details

• The font used for VI Icons is Small Font Regular which should be a deafult Windows font. If it isn't, in Explorer, simply right click > Install Font on the .\cfg\smalle.fon provided here. You may also want to add to the LabVIEW.ini IconEditor.TextTab.TextFont="Small Fonts".

• DAQmx drivers are required for DAQ and will need to be installed separately.

Testing

The test code is contained in .\test\ and relies on the Caraya framework. With the requirements installed, you can run all of the tests contained in the project by selecting from the project file Tools > Caraya > Run all tools in project.... You can run single test simply by running that test function.

This can be automated such that the tests are run on every commit or, more conventionally, for every PR targeting the master branch. Ideally, to do this, you'd have a Docker container with LabVIEW to aid in this.

Components

Non-Module Libraries

MessageLogger

MessageLogger writes to disk and console messages of various types. This is useful not only for debugging but to capture "As run" test data if, for instance, all commands are logged.

The core of the MessageLogger is BenjaminR's Error Log library (BSD licensed, https://www.vipm.io/package/benjaminr_error_log/). This provides common log levels as well as console screens for monitoring log messages.

From BenjaminR's documentation, the log levels prodided are:

• DEBUG : Detailed information, typically of interest only when diagnosing problems.
• INFO : Confirmation that things are working as expected.
• WARNING : An indication that something unexpected happened. The application is still working as expected.
• ERROR : Due to a more serious problem, the application has not been able to perform some tasks.
• CRITICAL : A serious error, indicating that the application itself may be unable to continue running.

As implemented, MessageLogger will create two separate log files and two separate consoles. One set (file/ console combination) is the DEBUG log which will contain all messages; the other set is the "ERROR" or "INFO" log which will omit DEBUG level messages.

Note there are some peculiarities with BenjaminR's Error Log library that have been accounted for here:

1. The By Reference implementations provided do not allow for modifying the output format--the API suggests it does but there's a bug in that library that prevents the feature from working. As a work around, I've implemented a global solution, a "wireless" handler that simply wraps the By Value implementation.
2. JSON formatting is not true JSON in the output text file. Rather, the library stores non-coherent JSON blobs--each message is it's own JSON item. To work around this, I've implemented MessageLogger.lvclass:Fix JSON Formatting.vi which is called on MessageLogger termination; this function jams all of the JSON blobs into a JSON array, making the file easier for machine processing.

TDMS

The core object for TDMS interaction. This is quite thin and provides no read capabilities. Write Data.vi is the core item and it can be converted to a malleable .vim to make for extension of handled types.

ModuleHandler

Module Handler is the communications hub between Modules. It exists to decouple Modules such that they don't need to host any other Module's dependencies. Because of this, there is a significant amount of boiler-plate to simply wrap each Module's APIs in order to accomplish this decoupling.

The heart of the ModuleHandler is ModuleHandler:Router.vi which is responsible for injesting outputs from each Module and marshalling them to wherever else the need to go. For instance, ModuleHandler:_route_DAQ.vi consumes data events and forwards those to the DataLogger and writes them to a data structure that makes the values available for GUI monitoring.

MWL

The Master Wiring List (MWL) object houses MWL interactions. The parsing of the .xlsx MWL requires a Python module that can be found in src/Py-MWLParser.MWLParser.py

Py-MWLParser

It's a good bit easier to work with Excel files using Python as compared to LabVIEW which is why this module exists. To call the parser, ensure you have the python virtual environment installed and active and then use the following:

python -m <path_to_MWLParser.py> <xlsx_file_to_parse> (<output_json_path>)

for example:

python -m c:\test-stand\src\Py-MWLParser\Py-MWLParser "c:\test-stand\cfg\MasterWiringList.xlsx" "c:\test-stand\cfg\MasterWiringList.json"

Modules

DAQ

DataLogger

DataLogger implements a simple TDMS saving library. No TDMS read capability is implemented at this time. This is a fairly straightforward library that uses TDMS.lvclass to wrap the TDMS logging capabilities.

Files will be named based on some configuration information: <File Target>\<Prefix>_<Current UTC Time>.tdms; eg C:\Data\BatteryTest_2023-03-07_10-17-96,tdms. The configuration data as well as the host name on which the tdms file was generated will be added to the file's metadata automatically at DataLogger initialization.

Data is logged by group and a timestampped channel is added to each group based on source timestamp data. That timestampped channel's name is defined in .\src\lib\TIMESTAMP NAME.vi

Safing

Conventions

• Private functions are prefixed with an underscore "_"; eg _thisIsAPrivateFunction.vi
• There is some use of constants for specific paths or specific names. These are contained in functions named in ALL CAPS; eg THIS_IS_A_CONSTANT.vi

Physical Structure

• .\cfg

  Configuration Files

• .\src

  Source Files

  • .\GUI

    Front End source

  • .\lib

    Common use files for everything in src. This includes classes that are not Modules such as the MessageLogger and TDMS

  • .\Modules

    These encapsulate high level features and inherit from the parent Module

    • .\lib

      These are files and typedefs intended to be shared only with Modules while not being logically defined as behaviors of the Module base class

• .\test

  Test cases. Generally, the subdirectories here are associated with the class or library that is tested. See the Testing section for more details on how to use these functions.

  • .\lib

    General use files for all tests that don't logically make sense as TestFramework behaviors

  • .\TestFramework

    Functions and types that facilitate testing such as Standup.vi and Teardown.vi

Bookmarks

There are some bookmarks in the code to draw attention to specific items. As much as possible, these have additionally been tracked as GitHub Issues. To view all bookmarks in the LabVIEW project, select View>View Bookmark Manager

• #TODO: These are feature additions that may be interesting in the future
• #ISSUE: These are bugs or corner cases that were left as it didn't seem to be an issue in the application in its current state but may become an issue later (eg increased scale or different use cases)

License

This project is licensed under the MIT License - see the LICENSE file for details.