07-15-2025 11:06 PM
Hello community, I am new to LabView, and my learning has been very limited to specific information. I am currently stuck with the topic of executables, installers, and applications. I will try to be as detailed as possible to explain my problem.
I have a LabView project with VIs at three levels: FPGA, RT, and MyComputer, which are structured as shown in the image "skeleton".
At the FPGA level, I only send or receive data to the RIO modules through FIFOs.
At the RT level is where the base programming resides. This program sends a sine wave signal with fixed parameters through a shared variable and receives two other analog signals, which it processes and sends as voltages. The shared variables are:
-1 boolean to activate and deactivate the signal
-3 doubles solely to read the amplitudes of the sine waves
-1 double waveform to read the output sine wave (this only helps me verify that the executable works).
Here in the RT.VI, I used the Bitfile for the "Open FPGA VI Reference," although I had previously used the VI (here is my first question: Is it better to use the VI or the Bitfile?). I "converted" this VI into an application, which I set as a StartUp on my cRIO.
At the MyComputer level is where the shared variables are hosted. Why are they here and not at the RT level? Because I had previously placed them at that level, and when I tried to open the executable on another computer that did not have the root file, I encountered the error shown in the image "error." When I moved the shared variables to the MyComputer level, the error disappeared when opening the application; however, it still was not functional. At the MyComputer level, I only have visual indicators; I do not process information or anything beyond that.
My purpose in creating this application and installer is to run the application on a computer that does not have the LabView environment or, more specifically, licenses. I have been trying to make the application work on a computer that does have licenses but not the root program, and it still does not work.
I saw a similar problem in the forum https://forums.ni.com/t5/LabVIEW/Stand-alone-RT-application/td-p/1556578 ; however, I did not fully understand the topic of the "aliases" file, which is part of the link: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019OsiSAE&l=en-US&OpenDocument, and I am not sure if that is the solution to my specific problem. It would help me a lot to know your point of view, and if additional information is needed, I would appreciate it if you could request it so I can respond as soon as possible.
Thanks for your help.
07-18-2025 03:28 PM
You are "new to LabVIEW", yet you are building a LabVIEW Real-Time Application that also involves FPGA code -- that's three LabVIEW routines (the Host, the cRIO Target, and the FPGA) that have to run "peacefully" together.
I've done a few of these (I'm fairly new (< 10 years) to FPGA), and can say that the trickiest part is the Host / Target relationship. Experience has taught me to avoid Shared Variables (maybe I can get away with what I'm about to say because the Host / Target relationship is on a tens-of-milliseconds level of "tightness", though I haven't actually measured it).
Both Host and Target run a variety of a Channel Message Handler, modeling a State Machine. I use Network Streams for all the Host-Target communications --
I did a lot of the initial development by myself (which I do not recommend!), but early on I developed the notion of small Host/Target routines that did nothing but exchange simple messages and get communication working. [Try to build simple VIs to configure and manage Network Streams -- you can find some discussions about setting them up on this Forum -- I remember writing one such)]. Even if you are the most advanced LabVIEW developer in your organization, find a colleague and ask them to listen to you explain your code -- try to write code that is easy to conceptualize and understand.
Although it is in need of a Second Edition, "The LabVIEW Style Book" by Peter Blume made me a much better LabVIEW developer.
Bob Schor
07-21-2025 09:59 AM
So... from your point of experience, the most suitable solution I can provide is to change the shared variables to another type of communication between levels? Will these types of communication allow me to create the executables I need and make them work optimally on other computers, whether or not they have LabView? I apologize for the questions, but it has been difficult for me to find answers to this issue of creating executables for computers without LabView. I had already read a bit about shared variables not being the best option; however, since I had read that forum I mentioned at the beginning, I was somewhat hopeful about not having to switch to another type of communication.
07-21-2025 04:07 PM
Hello, Magma.
I may have missed the main point of your query, and gotten lost in the weeds of Shared Variables vs Network Streams (or other inter-"execution engine") communication path.
When you are working with a LabVIEW RT project, there are two places that your code needs to reside -- in a (PC) Host and on a LabVIEW-RT "Target" (which is probably running some version of NI Real-Time Linux). I'm going to confine my remarks to the Host code, since I (almost?) always have the Target physically connected to the Development PC and build it directly on the target destination directory, /home/lvuser/natinst/bin.
So now the question is do you build an Application (which is what I do 90% of the time) or an Installer? With an Application, the Build takes less time, but doesn't include LabVIEW "libraries" with Device Drivers and other support code present in the Run Time Library (which is, of course, LabVIEW Version-specific). So in addition to copying the Executable (and its associated folders, some of which you may have created to hold Configuration or other data in a "known place" relative to the .exe file), you'll need to download and run the appropriate Run-Time Library (but you only need to do this once, unless you change the LabVIEW version of the Host code).
On the other hand, building an Installer lets LabVIEW do both creating the .EXE and installing the Run-Time Library (or Libraries). Most of my experience is with "unique" routines (which run on a single User's machine, plus my own Development system), so I'm not that familiar with Installers, but my colleagues seem to like them. There are a few more "bells and whistles" to contend with when using Installers ...
Bob Schor