Several types of data are generated in the Waterpower Laboratory. Experimental and numerical data under a research project are significant in the laboratory. Key sources of the data are:

  1. Experimental work in the laboratory — velocity, pressure, flow, strain, etc. measurements.
  2. Numerical simulation — simulation files, drawing related formats, mesh formats, post processing formats, code
  3. Administrative — Microsoft office files, emails, text files, audio, video and images.



label Data archive and curation formats for the Waterpower Laboratory.

#

Category of data

Preferred format(s)

Alternative format(s), Note1

1.

Textual data: Reports, documents, word files, large text files with tables and figures.

ASCII *.txt, *.xml, *.rtf, *.pdf/a, *.odt

*.doc, *.docx, *.pdf, *.tex

2.

Tabular data: Large data from sensors and LabView software in table format separated by ‘space’, ‘tab’, ‘comma’, ‘semicolon’, etc.

Unix, UTF-8, *.txt, *.csv, *.ods

*.xls, *.xlsx, *.mat

3.

Image format data: Huge data from PIV measurements, images, photographs, figures in image format, etc.

*.tif, *.png, *.jpg2000, *.pdf/a

*.jpeg, *.jpg. *.tiff, *.gif, *.psd, *.bmp, *.pdf, *.svg, *.eps

4.

Programming and code

UTF-8 ASCII *.txt, *.xml, *.html

*.m, *.py, *.c, *.cpp, labview compatible, java, Note2

5.

Engineering drawings

*.dwg (autocad-2d), ASCII *.dxf, *.igs, *.iges, *.x_t, *.x_b, *.stl, OpenDWG, *.svg, *.stp, *.step, *.pdf, other legacy formats

*.vsdx, *.sw, *.model, catia v5-v6, *.prt, *.asm, *.sldprt, *.sldasm, *.par, *.asm, *.psm, *.x3d, Note3

6.

Data acquisition and calibration

ASCII *.txt, *.csv, *.ods, *.xml

All LabView supported files with compilers and add-in for DAQ hardware, Note4

7.

Recordings:

Video, audio, etc.



Note1: If you are concern of distortion of data while converting to the preferred format, you can use alternative format. If alternative format is not better option, you can submit in original format. However, please provide description of software and possible ways to convert into the preferred/alternative format.

Note2: https://gist.github.com/ppisarczyk/43962d06686722d26d176fad46879d41

Note3: If you have drawing format in other the listed formats in preferred and alternative categories, please convert them to compatible version of AutoCAD/Creo/SolidWorks.

Note4: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Consolidate-LabVIEW-File-Types/idi-p/4103443


Consolidate all LabVIEW G files into two file extensions:

  • Source LabVIEW File (*.xx) - Human readable source code files (e.g. *.vi)
  • Compiled LabVIEW File (*.xxc) - Compressed compiled binary files (e.g. *.vic) 

Justification:

LabVIEW is proprietary. I need LabVIEW to open LabVIEW files. There are +15 LabVIEW file extensions to create LabVIEW G code. Recognizable LabVIEW extensions are worthless because I still need LabVIEW to open and edit the files. Some LabVIEW files contain compiled code, whereas other LabVIEW files are glorified name-spacers; some are UI components, while others embed compiled LabVIEW code into other LabVIEW files.

 With every new LabVIEW version, capabilities are added that inherently cause inconsistencies between LabVIEW file types, environments and overall behavior. Let me explain. 

 Problem:

  1. Current LabVIEW file types don't adhere to consistent behavior:
    • Libraries (lvlib, lvclass, xnode, xctl) are xml files (human readable) but also contain encoded compressed data (non-human readable)
    • VIs (vi, vit, vim, ctl, ctt) are binary files that can contain compiled code (or not)
    • Libraries (lvclass) add dynamic capabilities like dynamically dispatched VIs and can embed class private data controls (or not for interfaces) using the same extension, rendering the extension useless
  2. Inconsistent code redistribution
    • Distribution libraries (llb, lvlibp) embed compiled code differently
    • Packed libraries (lvlibp) resolve system paths differently that source
    • Libraries (lvlib, lvclass) lack the capabilities to embed reusable libraries for redistribution - Similar to Python's PIP library
    • Some 3rd party applications (like VIPM) to manage distribution inconsistencies add more file types and compounds the redistribution problem
  3. Compatibility discrepancies
    • VI (Poly, Express), Class (Class, Interface) already introduces development idiosyncrasies that could be resolved with a one "file" fits all methodology.
    • More file extensions equals more variability, increased maintenance time, and puts ownership on developer community to find discrepancies

Proposed Solution:

  1. Consolidate current LabVIEW G source files (vi, vit, vim, ctl, ctt, lvclass, lvlib, xnode, xctl) into a single Source LabVIEW File (*.xx) that is human readable (i.e. xml) that contains no encoded, compiled or compressed data. - Similar to NXG's xml format
  2. Introduce Source LabVIEW File (*.xx) nesting/namespacing to remove the need for external Library files (lvclass, lvlib, xnode, xctl) - Similar to how C# or Python files allow for multiple methods within a single file.
  3. Add a build spec component to generate a Compiled LabVIEW File (*.xxc) that embeds the Source LabVIEW Files and Compiled Object Cache - Similar to Python wheels/pip package manager
  4. Allow developers to use the Source LabVIEW File (*.xx) or Compiled LabVIEW File (*.xxc) interchangeably in their development projects - Similar to how Python's *.py or *.pyc can be called

Features:

A single LabVIEW Source File (*.xx)...

  • can be human readable (i.e. xml) - Editor agnostic
  • can embed one or more LabVIEW Source Files - Single file libraries
  • replaces *.vi, *.vit, *.vim, *.ctl, *.ctt, *.lvlib, *.lvclass, *.xnode, *.xctl
  • adheres to common coding language extensions (C#=cs, Python=py, Java=java)

A single LabVIEW Compiled Files (*.xxc)...

  • is a specific build specification for packaging and distribution
  • contains the source files (optional) and compiled object cache
  • can embed run-time components - Package distribution
  • adheres to common coding practices (Python=.pyc, Java=.jar)
  • replaces *.lvlibp, *.llb, [*.exe]


LabVIEW currently has +15 extensions to develop G code:

(Not including, LV Projects, NXG, VeriStand, TestStand, LabWindows/CVI, etc.):

- Virtual Instrument (*.vi)

- Virtual Instrument Template (*.vit)

- Malleable Virtual Instrument (*.vim)

- Control (*.ctl)

- Control Template (*.ctt)

- Virtual Instrument Library (*.llb)

- Library (*.lvlib)

- Class (*.lvclass)

- XNode (*.xnode)

- XControl (*.xctl)

- Packed Library (*.lvlibp)

- Palette Menu (*.mnu)

- Run-Time Menu (*.rtm)

- Data (*.tdm, *.tdms, *.lvm, *.bin3, *.rc)

  • No labels