From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

BreakPoint

cancel
Showing results for 
Search instead for 
Did you mean: 

Rube Goldberg Code

A common task is to generate a path to a file (e.g. ini) that is located right next to the VI or exe.

 

Here are two possibilities, the top one was seen here.

 

 

altenbach_0-1711497055080.png

 

Top:

  • Hard to debug and reconstruct from memory in the future.
  • Breaks after building exe
  • Breaks on any other OS.

Bottom:

  • just works!

 

 

Message 2561 of 2,571
(421 Views)

@altenbach wrote:

A common task is to generate a path to a file (e.g. ini) that is located right next to the VI or exe.

 

Here are two possibilities, the top one was seen here.

 

 

altenbach_0-1711497055080.png

 

Top:

  • Hard to debug and reconstruct from memory in the future.
  • Breaks after building exe
  • Breaks on any other OS.

Bottom:

  • just works!

 

 


These two methods are "the same" as long as VI opened stand alone, or located in the same directory as project. When opened within project and locations of the project and VI are different, they are not the same any longer. Its because if you call this VI from the development environment and the VI is loaded in a LabVIEW project file, then Application Directory VI returns the path to the folder containing the project file, not the VI:

 

Screenshot 2024-03-27 07.15.03.png

In additional, for many users, who coming to LabVIEW from text-based languages is still more easy to use RegExps or Formula Nodes in graphical environment. Especially in this case could be easily modified to get it running within exe as well. Nothing principal wrong with this, although NI recommend other method how to Access a VI's Current Directory.

Message 2562 of 2,571
(404 Views)

@Andrey_Dmitriev wrote:

@altenbach wrote:

A common task is to generate a path to a file (e.g. ini) that is located right next to the VI or exe.

 

Here are two possibilities, the top one was seen here.

 

 

altenbach_0-1711497055080.png

 

Top:

  • Hard to debug and reconstruct from memory in the future.
  • Breaks after building exe
  • Breaks on any other OS.

Bottom:

  • just works!

 

 


These two methods are "the same" as long as VI opened stand alone, or located in the same directory as project. When opened within project and locations of the project and VI are different, they are not the same any longer. Its because if you call this VI from the development environment and the VI is loaded in a LabVIEW project file, then Application Directory VI returns the path to the folder containing the project file, not the VI:

 

Screenshot 2024-03-27 07.15.03.png

In additional, for many users, who coming to LabVIEW from text-based languages is still more easy to use RegExps or Formula Nodes in graphical environment. Especially in this case could be easily modified to get it running within exe as well. Nothing principal wrong with this, although NI recommend other method how to Access a VI's Current Directory.

While that is mostly true, if you use projects you really should not tie configuration files into a subfolder of your project tree. If you intend to have your ini file located along the exe file (since Windows 7 only valid if it is not written from the app) then it would be the most logic place to store it in fhe project directory.

You don’t determine the path of your C or C# file to use as base of your configuration files either!!!

And if you need to also write to the file it should be stored in the Public or User Preferences.

Also, string manipulations on paths are a bad practice even in a C, C# or Python app, so no need to not suggest correcting them in a LabVIEW code!

Rolf Kalbermatter
My Blog
Message 2563 of 2,571
(396 Views)

I contend this is the true equivalent de-rube'd version.

 

paulmw_1-1711538916767.png

 

 

 

Message 2564 of 2,571
(370 Views)

@paulmw wrote:

I contend this is the true equivalent de-rube'd version.

 

paulmw_1-1711538916767.png

 

 

 


As a direct replacement, that is correct.  But, as at least alluded to (I only quickly skimmed the previous few posts), configuration files really need to be relative to the executable/project.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2565 of 2,571
(358 Views)

If autoindexing never existed, we probably would need to do somethings as follows (top of image, seen here ).

 

(It is puzzling that the OP has partial knowledge about more advanced concepts, such as the feedback node, but missed the class about autoindexing)

 

altenbach_0-1711983558189.png

 

0 Kudos
Message 2566 of 2,571
(230 Views)

@altenbach wrote:

(It is puzzling that the OP has partial knowledge about more advanced concepts, such as the feedback node, but missed the class about autoindexing)


I think LabVIEW defaults to insert a feedback node on circular wiring.  So I doubt the OP actually knows about feedback nodes, but rather stumbled upon it.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2567 of 2,571
(221 Views)

@crossrulz wrote:

@altenbach wrote:

(It is puzzling that the OP has partial knowledge about more advanced concepts, such as the feedback node, but missed the class about autoindexing)


I think LabVIEW defaults to insert a feedback node on circular wiring.  So I doubt the OP actually knows about feedback nodes, but rather stumbled upon it.


You are probably right. 😄

 

cycleresponse.png

 

Actually, upon further research, it seems they've been (ab)using feedback nodes for over three months already.. 😄

 

 

0 Kudos
Message 2568 of 2,571
(212 Views)

The amount of times a feedback node was created when i wanted it is pretty low.

The amount of times a feedback node was created when i absolutely didn't want one is too damn high.

Message 2569 of 2,571
(164 Views)

@altenbach  a écrit :

If autoindexing never existed, we probably would need to do somethings as follows (top of image, seen here ).

 

(It is puzzling that the OP has partial knowledge about more advanced concepts, such as the feedback node, but missed the class about autoindexing)

 

altenbach_0-1711983558189.png

 


Yet the OP should know about autoindexing, since a FOR loop automatically creates one when you input an array... So that means that they've disabled it on purpose 🤔

0 Kudos
Message 2570 of 2,571
(154 Views)