Leaderboard

The .rtexe is actually not an executable file. Rather, it is a "bundle" that contains your compiled VIs. The real executable is /usr/local/natinst/labview/lvrt -- This executable loads your .rtexe bundle and runs the top-level VI(s) from the bundle. The lvrt program checks a config file -- /etc/natinst/share/lvrt.conf -- to find out which .rtexe it should load. So, in theory, you could edit this file and then shut down the VIs that are currently running. This causes lvrt to re-launch, and it will read your updated config file and load your new .rtexe. Notes: Only 1 rtexe can be active at a time. If you simply kill lvrt (as opposed to triggering a proper shutdown from within your .rtexe), LabVIEW thinks that it crashed. By default, LabVIEW will enter Safe Mode after 2 crashes: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kFQ6SAM

I learned about the Project-level "Mark Existing Items" button reading that blog post...

1. What type of source control software you are using? Git on GitLab with Git Fork or Git Tower 2. You love it, or hate it? LOVE it!! 3. Are you forced to use this source control because it's the method used in your company, but you would rather use something else We get to choose, and git is the scc system of our choice. 4. Pro's and Con's of the source control you are using? Pro: Decentralised, very popular (i.e. many teams use it), very flexible, very fast, feature branches, tagging, ... Con: Complicated to set up if using SSH, Exotic use cases/situations can be very hard to solve and sometimes need turning to the command line 5. Just how often does your source control software screw up and cause you major pain? Never. It's always me (or another user) doing something wrong. For our internal team of 5, it never happens. For our customers, the occasional problem occurs. As mentioned above, we use Git Fork and/or Git Tower as our graphical UIs to git. IMHO, using a graphical client is soo superior to working with git on the command line (but I'm posting to a LabVIEW forum, so who am I telling this?). In order to avoid having to merge VIs (we actually do not allow that in our internal way of working), we use the gitflow workflow. It helps us with planning who's working on which parts of an application (repo). I honestly can count the number of unexpected merge conflicts in the last few years with one hand. On top of git, many management systems like GitHub, GitLab, Bitbucket etc. offer lots of functionality like merge requests, integration with issue tracking, and other project-management-type features.

I wrote a blog post about separating compiled code a while ago, it might be interesting for you: https://www.hampel-soft.com/blog/separate-compiled-code-from-source/

Yes there is such a VI. That VI is provided by NI. It's located at '\vi.lib\Utility\libraryn.llb\Is Name Multiplatform.vi' in LabVIEW 8.6 and up. For older version look in 'project\llbedit.llb\Is Name Multiplatform.vi' Ton