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?

Working with XML is fairly common and an addition to the palette to replace a specific node value would be helpful. Besides, there's lots of space there yet.

This link saved time. Thank you to juliodia

for posting this.

https://forums.ni.com/t5/LabVIEW/XML-Update-Element-Text/td-p/1239026?profile.language=en&lang=en

VI snippets are useful but often hard to deal with. Sometimes you can drag one directly from a website into LabVIEW and have it just work. Other times you have to download it, open File Explorer to it and drag the file into LabVIEW.

Many times dragging directly from a website doesn't work and results in a comment with a link to the VI snippet. Instead LabVIEW should try to go to the link, download it and insert it as a VI snippet. There are some cases when this will not work (for example the user needs to sign into the website) but LabVIEW should at least try the link. It is possible a link will be provided to LabVIEW that is not a VI snippet in which case LabVIEW should recognize that and just treat it as a normal link.

I'm not sure but there may be cases when a PNG image is dragged or pasted onto the block diagram. Is there a possibility for LabVIEW to check if it is a VI snippet and treat it as such?

Allow array controls and indicators to line-wrap 1D data into a 2D display.

I have, say, a 1x1000 array of square images, and I'm browsing through them, and it'd be really lovely to be able to pop them into a grid as a single display element instead of having to make several array indicators with carefully synchronized display indices, or reshaping the array.

That is, if I have a 1D array consisting of the alphabet, and I pull the array indicator into 3x3, then it could look like:

abc

def

ghi

or if I entered index 1 in the index box, it would show

bcd

efg

hij

etc.

An option to allow vertical-first would seem reasonable:

adg

beh

cfi

If we can have instrument simulator VIs, we can test our codes prior to the actual hardware acquisition

The idea proposes device driver packages from IDNet to include a vendor instrument simulator VI that can be run prior to code testing. The VI can be configurable (VISA based on virtual ports created during runtime, file paths to read from to simulate measurements and responses to messages, etc) and started asynchronously (call & forget) at the start of the program and terminates when the caller terminates.

or as a template from the "New > Simulated Instrument" where user can modify according to the instrument that they are going to use.

...and that it covers NI and 3rd party instruments