LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 
rcpacini

Consolidate LabVIEW File Types

Status: New

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)

 

Should we consolidate?

3 Comments
felipe.foz
Member

I don't know if NI will take any of your suggestions. But it was a good research on file types and their content and compatibility, well done.

 

IMHO, I believe NI will only accept drastic changes in NXG, the traditional LabVIEW probably will die (or not) slowly with minor updates and bugfixes only.

 

Regards,

Felipe Pinheiro Silva


Follow my blog for LV content!

TheQ
Active Participant

There are less in NXG.

 

https://labviewwiki.org/wiki/LabVIEW_File_Extensions 

 

But for the reason they didn’t create a new extension for Interfaces, I doubt they’ll do away with any.  They are too many tools that would break. 

 

Quentin "Q" Alldredge

Owner, Q Software Innovations, LLC (QSI) | Director, GCentral | Admin, LabVIEW Wiki
Tech Lead, Hill AFB LabVIEW Center of Excellence | Creator, The QControl Toolkit
Certified LabVIEW Architect | LabVIEW Champion | NI Alliance Partner


I'm Speaking at the GLA Summit!

AristosQueue
Proven Zealot

I can tell you this idea is dead on arrival. There's just no way we could migrate user code across such a change -- dynamic load code, plug-in find code, and scripting code would all break under such a change, making it impossible to even seriously entertain this argument.

 

For NXG, NI did a deep analysis of our file extensions, where they provide benefit and where they do not, and you can see the result. We did consider a single ".gsource" file extension for all files and determined that there was too much benefit in being able to recognize which file is which in a directory even outside of the LV IDE. The fact that you need LabVIEW to look inside the files doesn't mean that LV is the only tool manipulating those files.

 

So, for backward compatibility, I do not see this as an option for LabVIEW.

For customer usability, I do not see this as an option for NXG.