Macro in LabVIEW

[cyro]

I'm missing the feature of using macros in LabVIEW like in other languages. In text-based

languages a macro is a text replacement before compilation so in LabVIEW it should do the

same with g code.
I don't like the idea to put every single code into a sub VI just to clean up the code.

There are enough reasons to create sub VIs but the goal is to build logical / programmatical

units.

 

Consider a situation you are using long text in string constants enlarging the whole code

through this.

Consider a situation you are using many property-nodes within a while loop.

Use macros to avoid this.

 

So how to implement?

 

Macros are unique in every VI. Every VI should have named extra block-diagram layers to define these macros, one layer per macro. These layers are similar to a standard VI except they don't need / use a front panel to connect the controls. All controls are connected within the macro block diagram. The macro is used like a standard VI. It has a icon like a standard VI and is placed on the block diagram like a standard VI.

The macro code will be embedded virtual before compilation so the code will not be touched.

That's it - I think 🙂

[RavensFan]

What don't you like about subVI's?  Everything you described sounds just like what you get from a subVI.

[cyro]

I don't like it because it is an extra file. When I use a subVI I change the Code. When I use a macro I don't change the code. I think the compiled code should be exactly the same by using a macro.

Another example:

Assume I have a VI with 42 controls and I need an array of references to these controls, I get a big block of refs connected to a "build Array". The code is 100% OK but it doesn't look nice. There is no possibility to beautify this code by using a subVI. Using a macro within this VI takes this ugly code into the background without changing any functionality or structure.

[JackDunaway]

I think you're referring to an inline subVI, which is a block of code encapsulated within a subVI, but incurs no additional subVI overhead since it is "inlined" (collapsed onto the calling diagram) at build-time. So, if I understand you correctly, "macro"="inline subVI"? The benefit of inlining is that it provides code modularity without the performance hit.

My understanding (someone correct me if I'm wrong) is that certain VI's are more or less inlined with today's compiler. Change the execution mode to Reentrant/preallocate clone for each instance and bump the priority to Subroutine. Also, ensure input and output terminals can be operated on "in-place".

This post may be a duplicate of inLine subVIs in the background.

[JackDunaway]

---

cyro wrote:
I don't like it because it is an extra file

---

So you're asking for a subVI that is saved with the parent diagram? Then that's a duplicate of this idea: Ability to embed VI's and type definitions into other VI's and save them as a single file.

Message Edited by JackDunaway on 03-22-2010 09:44 AM

[tst]

Let's avoid the talk of what the compiled code looks like, as it's not really relevant, and focus on your second example: 

---

Assume I have a VI with 42 controls and I need an array of references to these controls, I get a big block of refs connected to a "build Array". The code is 100% OK but it doesn't look nice. There is no possibility to beautify this code by using a subVI. Using a macro within this VI takes this ugly code into the background without changing any functionality or structure.

---

If I understand correctly, what you basically want is the ability to take a block of code and collapse it into an icon, so that the unwieldy code is nicely hidden. Building an array or cluster of control references is actually a good example of this because it does take a lot of space if you want to do it properly and you can't move it to a subVI if you create a reference for each control (although if you want all the controls on the panel in an array you can actually use the Controls[] property of the panel or the pane, so you can hide this in a subVI, but I wouldn't do this).

With such a suggestion, the code will be represented as an icon, but it will still be part of the VI. I'm not a fan of hiding code, but this seems to be one case where such a feature might be useful. You can accomplish this today by placing the code in a flat sequence, disabling auto-grow on the sequence and then closing it around the code, but this hack doesn't accomplish all the goals and has too many problems to be usable.

Is this what you were thinking of? If yes, then it's an idea I might support, but the implementation would have to handle the various issues that come with hiding code.

[cyro]

I think that's it.

I don't want to embed complete VIs in a VI. And I don't think that this is really code hiding because it looks like a subVI except that it has no frontpanel. Maybe it should look a little different than a VI-Icon so you can see that this is a macro.

I think there are a view cases where this structure is very useful to keep your code clean. It isn't a must and it should be on the coders decision whether to use it or not. 

[JackDunaway]

Is this "macro" re-usable within a single VI? Can it be used on multiple VI's? Or is it just one piece of code, one place, like the Flat Sequence hack?

[cyro]

In my opinion it is reusable in the same VI. It is used like the #define in c. It is not usable in other VIs, it is a "look for the macro-icon in this VI and replace this icon with the specified code and then compile". But it is not reasonable at all times to use it more than once.

 Imagine you click "Edit"->"New macro...". A new window pops up like a new vi except there is no front panel. You put some macrocontrols and -indicators on it, edit the icon and connector-pattern and leave the macro editor. In your VI you rightclick and get the new defined macro from the macro section of the Functions-Palette and put it somewhere at your diagram.

Or you create macros like using the "Create SubVI" menu item.

[Mark_Yedinak]

While I agree this would be useful for the example provided as well as a few other cases I am hesitant to support this idea because I think this is a feature that would be abused too easily. I also believe that this would discourage people from thinking about code modularity and reuse. If this could somehow be restricted in how and when it is used it could be a useful feature. Without restrictions though I think it would cause more problems than it would solve.

Besides, if the code already has 42 controls than it is most likely a fairly complex piece of code to begin with. In this case it would most likely be a good candidate for using a state machine in which case you minimize screen use since the states help to "hide" code within the state machine.

Message Edited by Mark Yedinak on 03-23-2010 04:20 PM

[tst]

Can you provide examples of where this would be useful if it could be used in more than one place? I would think that in all those cases you could do with a VI, so at the moment I think this should at most be limited to collapsing code.

I agree with Mark that there are other ways of hiding code, which is another reason I'm not yet sold on this, but this suggestion does have a certain appeal.