LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Will LabVIEW ever support text-based development?

Solved!
Go to solution

While LabVIEW is primarily focused on supporting measurement and test of hardware, it has a lot of advantages going for it as a general-purpose programming language:

  • Effortless parallelism
  • Low barrier-to-entry for non-software engineers
  • Simple front-end development
  • Cross-platform between Windows and Linux desktop environments

As a software engineer, I chose LabVIEW for many of my desktop applications because of these advantages. However, there are several key drawbacks to LabVIEW as a general-purpose language which have made my development experience difficult:

  1. Mandatory graphical programming:
    • LabVIEW's graphical programming makes it a great choice for collaborating with fellow engineers whose background is in hardware rather than software, and it makes parallelism very simple to set up and understand.
    • However, it does make developing and maintaining complex applications very difficult. Simple additions to a program take much longer than they would in a text-based programming language because it forces you to spend hours pointing and clicking tiny nodes.
    • Connecting two nodes that don't fit in the window at the same time is a nightmare in LabVIEW. I have spent hours dragging wires across my block diagram just to add simple passthroughs in large case structures or shift registers in large loops. In a text-based programming language, this signal would just have a name I could type in both places in seconds.
  2. Compiled source code:
    • .vi files are saved compiled with no option to save them in the text-based DFIR or the LLVM-IR. This makes version control with GIT a nightmare. No two developers can edit the same .vi at the same time to add or update functionality.
    • In a text-based programming language, or even a graphical programming language which saved to a text-based intermediate representation, multiple changes would be on different lines of the file, and GIT would be able to merge changes with little issue. This is impossible in LabVIEW because it saves to bytecode.
    • By default, compiled code is not separated from sources. There is an option to change this, but it doesn't seem to always work. Modifying a VI that calls another VI results in both VIs being recompiled on disk. The result is that you can overwrite changes another developer has made to a VI in your repo simply by opening a higher-level VI that calls it.

I would love it if LabVIEW had an option to save VIs in the DFIR or LLVM-IR. This way it would be possible to write text-based code in concert with the default graphical code, to maintain source file independence, and to enable precise version control. I believe LabVIEW has the potential to be a simultaneously high-performance and approachable general-purpose programming language, but withholding the option of text-based sources is holding it back from reaching its full potential.

0 Kudos
Message 1 of 12
(1,977 Views)

Hi carrastro,

 


@jwestra-carrastro wrote:

However, there are several key drawbacks to LabVIEW as a general-purpose language …

  1. Mandatory graphical programming:
    • LabVIEW's graphical programming makes it a great choice for collaborating with fellow engineers whose background is in hardware rather than software, and it makes parallelism very simple to set up and understand.
    • However, it does make developing and maintaining complex applications very difficult. Simple additions to a program take much longer than they would in a text-based programming language because it forces you to spend hours pointing and clicking tiny nodes.
    • Connecting two nodes that don't fit in the window at the same time is a nightmare in LabVIEW. I have spent hours dragging wires across my block diagram just to add simple passthroughs in large case structures or shift registers in large loops. In a text-based programming language, this signal would just have a name I could type in both places in seconds.

For me the graphical nature is not a drawback, but a main advantage!

  • Simple additions take the same time, regardless of the size of the exisiting code! Why do you need to click nodes for hours?
  • When your nodes are not within the visible part of your block diagram then your block diagram is way too large. Simple rule/guideline: block diagrams should fit on a screen!

@jwestra-carrastro wrote:
  1. Compiled source code:
    • .vi files are saved compiled with no option to save them in the text-based DFIR or the LLVM-IR. This makes version control with GIT a nightmare. No two developers can edit the same .vi at the same time to add or update functionality.
    • In a text-based programming language, or even a graphical programming language which saved to a text-based intermediate representation, multiple changes would be on different lines of the file, and GIT would be able to merge changes with little issue. This is impossible in LabVIEW because it saves to bytecode.
    • By default, compiled code is not separated from sources. There is an option to change this, but it doesn't seem to always work. Modifying a VI that calls another VI results in both VIs being recompiled on disk. The result is that you can overwrite changes another developer has made to a VI in your repo simply by opening a higher-level VI that calls it.

  • To ease any kind of SCC you should always turn on "separate compiled code".
  • Why do you need to merge multiple changes to a file? A VI should follow the rule "one file per function"/"one function per file"…
  • You cannot overwrite changes in one VI by opening another VI. Why do you think so?
  • When working in teams developers should not work on the very same function, no matter if its text based or LabVIEW. They can always check out code from a repo and prohibit other developers from modifying the very same part of code (regardless of programming language). In a team there should be clear tasks and responsibilites for each developer/team member!
Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 12
(1,962 Views)

I totally agree with GerdW.

 

A lot of complaints you've are because you're not structuring your project appropriately to follow the best practices. There are several LabVIEW developers who have mastered a lot of shortcuts using the quick drop plugins to make their life easier. Using a proper architecture, framework and tools, adding features will become easier.

 

Only one thing that can be improved is the LV compare and merge but if you avoid ending up in that scenario by carefully structuring the VIs then you're good.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 3 of 12
(1,942 Views)
Solution
Accepted by jwestra-carrastro

@jwestra-carrastro wrote:

I would love it if LabVIEW had an option to save VIs in the DFIR or LLVM-IR. This way it would be possible to write text-based code in concert with the default graphical code, to maintain source file independence, and to enable precise version control. I believe LabVIEW has the potential to be a simultaneously high-performance and approachable general-purpose programming language, but withholding the option of text-based sources is holding it back from reaching its full potential.


I share your view on these issues and would like to add one more perspective to it:

 

The IDE and compiler are products. Opening the source code file format would allow third parties to create their own tools for editing and compiling. It is thus primarily a question of business strategy.

 

The last time I checked VI scripting, the functions that would allow you the create your own editor were restricted to use within the IDE only. NXG had an open format and was cancelled.

Message 4 of 12
(1,889 Views)

Because no one has mentioned it yet: there is still LabWindows/CVI, where you can program text-based in C.

Message 5 of 12
(1,804 Views)

@ThomasHenkel wrote:

Because no one has mentioned it yet: there is still LabWindows/CVI, where you can program text-based in C.


I guess that's because it is not LabVIEW.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 6 of 12
(1,756 Views)

Even for very large apps, I find LabVIEW easier to use than text-based languages.

In fact, for me, the large the app, the greater the advantage of using LabVIEW.

Message 7 of 12
(1,745 Views)

@paul_a_cardinale wrote:

Even for very large apps, I find LabVIEW easier to use than text-based languages.

In fact, for me, the large the app, the greater the advantage of using LabVIEW.


Although you can query the ID of an instrument in LabVIEW faster than you can type "printf".  Well, faster than I could type it, anyway.  😄

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 8 of 12
(1,735 Views)
@billko wrote:

@ThomasHenkel wrote:

Because no one has mentioned it yet: there is still LabWindows/CVI, where you can program text-based in C.


I guess that's because it is not LabVIEW.


It is some kind of a text-based version of LabVIEW, which is what the OP asked. You can access DAQmx, VISA and Co in the same way as in LabVIEW. If he wants to program in a text-based language, LabWindows/CVI is definitely worth a look.

0 Kudos
Message 9 of 12
(1,664 Views)

@ThomasHenkel wrote:
@billko wrote:

@ThomasHenkel wrote:

Because no one has mentioned it yet: there is still LabWindows/CVI, where you can program text-based in C.


I guess that's because it is not LabVIEW.


It is some kind of a text-based version of LabVIEW, which is what the OP asked. You can access DAQmx, VISA and Co in the same way as in LabVIEW. If he wants to program in a text-based language, LabWindows/CVI is definitely worth a look.


No, this is not even closely related to LabVIEW.  It might have a superficial resemblance to LabVIEW, but that's where the similarities end.  And the question was specifically if LabVIEW would ever support text-based development.

 

Also, it would seem that the OP was thinking along the lines of a LabVIEW hybrid.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 10 of 12
(1,657 Views)