VI macros?

[GregSands]

What?

 

Been there since pre-8.2?  Who's been laughing at us flailing around with locked-down multi-VI XNodes (or multi-multi-VI polymorphics) for years?  This seems to answer 99% of my (and everyone elses) requests for a simple type-adapting VI.  Looks like a very simple XNode without any type-checking (e.g. wire a Boolean to the Delay input and it generates the code but breaks the calling VI).  But if the programmer can be trusted, it looks incredibly useful.  I would presume it has the same caveats as using an XNode, but if it's now "released" (thanks jkodosky, who I imagine has some mandate to do so) it would be good to know anything to be aware of.

 

BTW, this is certainly not the same as the buggy, non-supported Generic VI that was dangled in front of us some time ago.

Edited August 13, 2015 by GregSands

[ShaunR]

What?

 

Been there since pre-8.2?  Who's been laughing at us flailing around with locked-down multi-VI XNodes for years?  This seems to answer 99% of my (and everyone elses) requests for a simple type-adapting VI.  Looks like a very simple XNode without any type-checking (e.g. wire a Boolean to the Delay input and it generates the code but breaks the calling VI).  But if the programmer can be trusted, it looks incredibly useful.  I would presume it has the same caveats as using an XNode, but if it's now "released" (thanks jkodosky, who I imagine has some mandate to do so) it would be good to know anything to be aware of.

 

BTW, this is certainly not the same as the buggy, non-supported Generic VI that was dangled in front of us some time ago.

 

Holy crap in a cabbage!......Have 500 likes (compressed into one)

 

To celebrate, you can all have data aware controls in the next release of the SQLite API for LabVIEW because I couldn't be bothered with xnodes.but this should work.

Edited August 13, 2015 by ShaunR

[hooovahh]

I have yet to look into the code yet. And jkodosky doesn't so much get asked to release things, he's more like the one telling people to release things...well probably sometimes with legal involved. I honestly don't know the inner workings of NI that much, but what I'm trying to say is, he has a lot of pull.

http://www.ni.com/company/our-vision/leadership/kodosky.htm

That being said when asked about VIMs in the past someone at NI mentioned that is is an old experiment (10+ years), following up the statement stating that the technology "sometimes works". That comment might be dated and who knows things might have changed. Or Jeff just felt like having some fun.

[ThomasGutzler]

To celebrate, you can all have data aware controls in the next release of the SQLite API for LabVIEW because I couldn't be bothered with xnodes.but this should work.

 

I have a feeling this might be a problem if the person using the vi doesn't have the ini file tweak *and* the vi needs to recompile for a different version.

I had to add "ExternalNodesEnabled=True" to my ini file to get it work with 2014 32bit. Once it was loaded and saved I was able to open it again with 2014 64bit without ini file change and it was adapting to type changes fine.

[Darin]

I have managed to do a few cool things with these, and I have also managed to crash LV twice. YMMV

[hooovahh]

Just twice? So your LabVIEW stability went up? Just kidding.

[Aristos Queue]

Honestly, folks, JeffK told me years ago it was an experiment he tried that eventually turned into inline VIs. I had no idea there was more to it or I probably would've tried to productize it years ago. 

One key caveat -- it does use an XNode to do its work. We'll all need to step lightly exploring this part of the LabVIEW attic. 

[eberaud]

OK are those really 2 different pictures? Or did they just photoshopped the shirt? 

 

[drjdpowell]

All this needs is the ability to specify terminal allowed types, including matching output types to inputs.   For example: “A must be a string", "B must be a numeric", “output C must be the same type as input Dâ€, etc.  Then it would be extremely useful (and would implement my long-declined idea).

[Sparkette]

I was wondering what that "GenericLabVIEW" XNode was for. Interestingly it seems like you're supposed to also be able to select a background texture for the node when "show icon" is turned off (i.e. "express VI"-like display mode.) But the image files are missing, so it doesn't work.

 

But I don't think .vim stands for VI Macro. I think it just means it's an improved VI. ^/s

 

Interestingly, the code for generic VI's is actually still in LabVIEW, even 2015. Even the hidden option that I assume Aristos used to create the example one he posted. (Add "GenericsAreGo=True" to the ini, right-click a control/indicator and there's a new "Generic" toggle in the menu--don't use it in anything you care if it breaks of course!)

Edited August 14, 2015 by flarn2006

[JackDunaway]

All this needs is the ability to specify terminal allowed types, including matching output types to inputs.   For example: “A must be a string", "B must be a numeric", “output C must be the same type as input Dâ€, etc.  Then it would be extremely useful (and would implement my long-declined idea).

 

Yep. This would help begin to bring parity with other languages' Generics (or Templates) abilities (the most concise read explaining this is Rust Generics annotated with Trait Bounds. If the word Trait muddies the waters here... just replace that with `Datatype, but totally super-awesomer`)

 

Additionally, I've built just enough XNodes (8-10 or so) to be of the opinion that VIM's are a little too underpowered to be considered over XNodes for the framework/middleware layers and below, but miiight be useful at the one-off application layer (extrapolating here, not based on battle scars and victories), where "saving development time" knob is tuned a bit higher, and "most elegant/usable syntax imaginable" is a bit lower.

 

To make a more familiar analogy on the LabVIEW Front Panel -- at the application layer, I would plop a subpanel and insert a VI long before considering creating an XControl, because making XControls takes marginally more time and introduces finitely more risk/liability. On the other hand, middleware/framework functionality to be reused many times warrants investment into more polish to provide that rich experience and in the words of Professor Steve Watts "Fewer WTF's".

 

That's all -- just jumping in to mention that the concepts of XNodes and VIM's "look a lot alike", but I don't feel are competing technologies, since their merits are tuned for different layers of the software stack.

 

And comparing XNodes and VIMs in LabVIEW to Generics of other languages -- VIMs fall short in capability, but XNodes can go far beyond the basic value proposition of a Generic function to enrich your DevX and IDE. (Let's save the conversations for how XNodes could be drastically improved for another day and another thread   )

[ShaunR]

All this needs is the ability to specify terminal allowed types, including matching output types to inputs.   For example: “A must be a string", "B must be a numeric", “output C must be the same type as input Dâ€, etc.  Then it would be extremely useful (and would implement my long-declined idea).

 

You sort of can.

 

If you wire a boolean to numeric primitive inside the VIM then try to wire a string, for example.

 

.

 

The VI will be broken with the error:

"You have connected a polymorphic terminal that cannot accept this data type"

 

 

So it not only adapts to type and does some intelligent type conversions, you can force terminal types with with a bit of verbosity in function use.

 

That's all -- just jumping in to mention that the concepts of XNodes and VIM's "look a lot alike", but I don't feel are competing technologies, since their merits are tuned for different layers of the software stack.

Sort of agree except about where they sit. Xnodes and VIMs aren't competing, but VIMs are closer to polymorphic VIs, IMO, without the code replication overhead of diagrams per instance that I always point out.. If you don't need to adapt to type for different companes, then these are the tool of choice to give adapt to type with a single diagram, single point of maintenance and no VI bloat or replication.

Edited August 15, 2015 by ShaunR

[mje]

I have nothing constructive to add other than... Wow.

[GregSands]

Additionally, I've built just enough XNodes (8-10 or so) to be of the opinion that VIM's are a little too underpowered to be considered over XNodes for the framework/middleware layers and below, but miiight be useful at the one-off application layer (extrapolating here, not based on battle scars and victories), where "saving development time" knob is tuned a bit higher, and "most elegant/usable syntax imaginable" is a bit lower.

 

I've created 30-40 XNodes, and while I haven't done so, I think almost all of them could be replaced by VIMs.  But most of mine are pretty simple, roughly equivalent to the OpenG Array XNodes, which I think could also probably all work well as VIMs.  Knowing that VIMs are just generic XNodes is kindof reassuring - while they have a few issues, they seem to me to be a lot more stable and usable than say XControls.  I've got pretty high hopes for VIMs, just no time to do anything with them at the moment.

 

 

Sort of agree except about where they sit. Xnodes and VIMs aren't competing, but VIMs are closer to polymorphic VIs, IMO, without the code replication overhead of diagrams per instance that I always point out.. If you don't need to adapt to type for different companes, then these are the tool of choice to give adapt to type with a single diagram, single point of maintenance and no VI bloat or replication.

 

Yes, this makes sense, as most of my existing XNodes are essentially polymorphic replacements, which is why they seem to be good candidates for VIMs.

 

However, what does blow my mind, even more than VIMs existing, is that AQ had no knowledge of them!  All my preconceptions are demolished!  Hopefully this is like feeding a mouse to a tiger - it only makes him hungrier...

[ShaunR]

One of my long standing annoyances was not having a completely generic re-use solution for encapsulating queues and events. As much as AQ thinks my vanishing wires is a no-no, it is a necessity to me to create reusable modular code that has the benefit of being clean and easy to read.

 

Taking the backbone of my message systems as an example, the Queue.vi, I was able to do this somewhat but had to make a decision to forgo data typing. Since my messaging is string based, I could encapsulate but had to wire a string to the input of the queue and fix the datatype - I had to wire something.

 

 

This meant for rare occasions when I did not want a string, waveforms, for example, I had to type cast or flatten.

(I actually wired it to the name wire, but at that time it was just so a wire didn't cross another. OCD? )

 

 

This was ugly, but acceptable for the 10% of use cases. It would have been possible to create a polymorphic VI which could work for simple types (bools, integers et. al.) but clusters, a more probable requirement, would be back to flattening. A poly would also have bloated the code base by a huge factor meaning that a simple, single VI of 16kB would have taken up an order of magnitude more space and compile time. I wasn't OK with that either. A Xnode would also have sufficed, but Xnodes where not around in those days,  are an unsupported feature even now and just too damned hard - if we ignore how flakey they can be. It's hard to justify any of the other complex technologies when all use cases are covered by a single small VI with some effort by the developer just for type casting.

 

The thing that was missing was VIM style of polymorphism that would transfer the datatype to the underlying queue primitive, transparently, without defining all permutations and combinations up front and without having a supporting entourage of VIs just to turn tricks. That would make it simpler to use. Simpler to understand and maintain modularity. It would be more elegant!

 

 

And now we know about VIMs. Woohoo! And I get all that (or should I say all that disappears) just by moving a wire and adding the letter m to the VI name , No code bloat. Still 16kB. Still a single VI. Whats not to like?

 

The one down side is that it can now produce a run-time conversion error. In the old days that would have been a problem as there were virtually no primitives that could generate run-time errors so that would have ruled out this usage. With LVPOOP, though, run-time errors have become acceptable so it is a small price to pay. This is why I'm so excited about the VIM. Finally my Queue VI doesn't need the flattening and unflattening verbosity and can relieve the user of that burden making the code even more compact and cleaner. My OCD has been satisfied

 

I was never able to find a generic solution to events, however. They were always application specific due to the registration refnum.. Now, though, I think VIMs will enable me to do to events, what I did with queues and that makes me even more excited.

Edited August 16, 2015 by ShaunR

[pawhan11]

In my applications I have vis with familiar functionalities for queues. I came to conclusion that all of us has created something like that.

For me there is no way to get rid of this variant conversion because in my state machines data is usually state dependent not queue dependent.

 

 

I was never able to find a generic solution to events, however. They were always application specific due to the registration refnum.. Now, though, I think VIMs will enable me to do to events, what I did with queues and that makes me even more excited.

 

Could You tell more about how are you planning to do that?    

When comes to UE i have vi that looks identical to addQ state but there is no response request.  I never figured a way to get response from all subscribers.

Edited August 16, 2015 by pawhan11

[mje]

At the risk of derailing, the specificity of the event registration refnum has never caused me issue directly since they can be combined via a cluster before hooking up to an event structure. What causes more problems passing those damned registration refnums through a connector pane. Make a change to an event encapsulated within that refnum and there can be a cascade of manual updates that need to be made, there's no way to properly typedef one of those magic refnums unlike say, a data value reference.

Anyways, back on topic, I have hopes these macros will help in dealing with advanced event based APIs as well.

[GregSands]

And now we know about VIMs. Woohoo! And I get all that (or should I say all that disappears) just by moving a wire and adding the letter m to the VI name , No code bloat. Still 16kB. Still a single VI. Whats not to like?

 

Can you attach a VIM version of your Queue VI?  I can't see how the Dequeue function works without wiring the output type into the VIM.  It would be different if you wired the Queue itself between VIs, but you expressly restrict that (for good reasons).

[ShaunR]

Can you attach a VIM version of your Queue VI?  I can't see how the Dequeue function works without wiring the output type into the VIM.  It would be different if you wired the Queue itself between VIs, but you expressly restrict that (for good reasons).

 

I might have wired the input then deleted the wire. The VIMs seem a bit too sticky and sometimes don't always adapt to type when specifying an output when asked to. You also need to delete and re-place them when changing the diagram. The VIM itself is really pretty much just as I described. The Queue.vi with the wire moved and the name change by aadding "m". *and changed the icon colour so I don't get confused)

 

At the risk of derailing, the specificity of the event registration refnum has never caused me issue directly since they can be combined via a cluster before hooking up to an event structure. What causes more problems passing those damned registration refnums through a connector pane. Make a change to an event encapsulated within that refnum and there can be a cascade of manual updates that need to be made, there's no way to properly typedef one of those magic refnums unlike say, a data value reference.

Anyways, back on topic, I have hopes these macros will help in dealing with advanced event based APIs as well.

 

Yes. The raw primitives can, but as you point out, as soon as you put it in a sub VI to modularise, they become fixed. Here is a typical use case for me.The "LOCAL" VI is a self initalising reference. Whenever you call it, you get a new Event refernce linked to the LOCAL event. If an event ref doesn't exist, it will be created on the first call (there is a caveat here, but will not muddy the water for now). We are on the same page, but using different dictionaries.

 

 

You can see that this will only work with this particular event. I can easily multiply up to create multiple listening processes for that event as shown below.

 

 

But what happens if I want to attach to a different event? Say, a Waveform instead of a string? I can merge another, already created,  event with the cluster, yes. But I can't reuse that VI like I can with the Queue. I have to make a new one!

 

I still need to remake the "LOCAL" VI that holds the reference (and name it REG). I end up with lots of specific event VIs that have very limited reuse. It is only reusable for that particular event and as that particular event is application specific-it is only reusable within that application.  With the Queue encapsulation I don't need to do that and it is reusable for different datatypes in any application. It is reusable across datatypes, VIs and projects without modification  and I don't have to create an identical VI with a different queue reference. I want the same for my events.

 

Could You tell more about how are you planning to do that?    

When comes to UE i have vi that looks identical to addQ state but there is no response request.  I never figured a way to get response from all subscribers.

Not sure at the moment. VIMs are re-entrant and don't honour the VI re-entrancy setting in the properties. My use case relies on self intialising globals and you need singletons for that. So I might have to use some queue trickery to create "Named Events" if that's even possible .

Edited August 17, 2015 by ShaunR

[hooovahh]

Additionally, I've built just enough XNodes (8-10 or so) to be of the opinion that VIM's are a little too underpowered to be considered over XNodes for the framework/middleware layers and below,

I agree and would like to take it a step further.

 

What can an polymorphic VI do that an XNode can't?  What can an Express VI do that an XNode can't?  What can a Generic VI, or VIM do that an XNode can't?

 

If XNodes were a released feature, I wouldn't mind seeing polymorphic VIs, Express VIs, Generics, and VIMs just go away.  XNodes aren't perfect, but if they were released I'd see little reason to invest in these other technologies.  I hear the complaint that XNodes are too difficult, and a VIM is easy.  Well sure but with scripting we could make XNodes.  So if you wanted to make a VI that accepts specific types in terminals, or has rules about the types of data it accepts, you could write a wizard that generates the XNode that does that.

 

As for Generics still being in 2015.  I believe NI actually used generics in a product of some kind once successfully, and probably doesn't want to break compatibility this quickly.  I mean if VIMs have been sitting in LabVIEW for 10 years and hasn't really been used (that I know of) it just shows NI is apprehensive with deprecating and removing functions.

[ShaunR]

If XNodes were a released feature, I wouldn't mind seeing polymorphic VIs, Express VIs, Generics, and VIMs just go away.  XNodes aren't perfect, but if they were released I'd see little reason to invest in these other technologies.

 

Polymorphic VIs are aggregators. They allow the same functional grouping as Action Engines but without the verbosity of all controls/indicators on one conpane. Or, from a different perspective, you could consider them like overrides in a class that you select by the drop down rather than wiring an object but you are not limited to the same conpane as a class is.

 

You achieve that just by adding existing VIs to a list. In the previous image; the polymorphic "REG" above also has the "Send"  in its drop down (amongst others) so all the messaging is in one VI, to all intents and purposes. These are all completely different VIs just grouped as an API. An xnode would be a poor and extremely complicated solution to realise IMO.

 

When you only have a hammer, everything looks like a nail.

Edited August 17, 2015 by ShaunR

[hooovahh]

When you only have a hammer, everything looks like a nail.

That's not true, it's more like you have a nail, and we both have hammers, but my hammer can hit more than just the one nail that your hammer is limited to.  Polymorphic VIs have a subset of feature that an XNode can.  Of course they could be seen as overly complicated method of doing the same thing.

 

Also can we agree that the polymorphic VI editor is a major pain to work with. Of course having a difficult feature of LabVIEW shouldn't mean to throw that feature away, it might be to suggest improvements, or make alternate editors.  I'm just trying to make a point that there are several features of LabVIEW that have subset features of this one unreleased technology.

 

I think the thing about XNodes that has me coming back, is that given enough effort they can meet so many needs.  Where things like XControls usually fall short of some edge case, unless the uses are very limited, at which point all that extra effort feel wasted.  If I wanted to make a competitor to a polymorphic VI using XNodes I could and it would probably work better than the native polymorphic VIs, supporting more features too.

[ShaunR]

Also can we agree that the polymorphic VI editor is a major pain to work with. Of course having a difficult feature of LabVIEW shouldn't mean to throw that feature away, it might be to suggest improvements, or make alternate editors.  I'm just trying to make a point that there are several features of LabVIEW that have subset features of this one unreleased technology.

I've never really given it much thought. UI in LabVIEW is generally atrocious - just look at the enum editor. I don't think its any worse than others, but that probably isn't saying much. I still get caught out by not being able to right click copy and paste into controls

 

I think the thing about XNodes that has me coming back, is that given enough effort they can meet so many needs.  Where things like XControls usually fall short of some edge case, unless the uses are very limited, at which point all that extra effort feel wasted.  If I wanted to make a competitor to a polymorphic VI using XNodes I could and it would probably work better than the native polymorphic VIs, supporting more features too.

That's a big claim there. Take your favourite action engine and make an xnode to replace it. Tell me how many days it took

 

Having looked at this a bit now, I think my Data Aware controls need to be Xcontrols (just as hard as Xnodes, but with an extra dollop of flakey) They really need the facade. I already have some (as Xcontrols) but I'm not going to release because I would have to replicate all the right click menu options manually in the code. That is just too much of an ask for something like a Treeview and pretty much rules them out for 90% of where I would want to use them.  I think anywhere that needs a custom UI that does not need to inherit an existing control or function is a good use case for  an Xcontrol or Xnode so we could probably agree that they could replace Express VIs. Does an express VI automagically make its diagram representation? That would be a nightmare creating the node look and operation from scratch. I haven't looked or even used them ,really, but I suspect they are the same technology too underneath.

 

It all seems to be just different cheeks of the same face The same underlying technology with specific, in built, interfaces to make certain desirable features easier fro muggles like me. I like that approach. That's how I try to design my APIs. They may be complicated under the hood, but should be intuitive and easy to use. Raw Xnodes aren't intuitive or easy

 

Xnodes are the potters wheel when all I want is a crappy ashtray to put my cigarette out. But VIMs and polys are super easy. They are the blue tack and scotch tape when I want to put my posters on the wall. They enhance my productivity which would plummet if they were to go or be replaced with Xnodes.  <shivers> Don;t say things like that.

[Dragis]

As mentioned previously, VI Macros are a (mostly untested) experimental feature. Is there a place we can aggregate known issues for this feature now that they are "in the wild" so to speak?

[hooovahh]

@ShaunR

I disagree.  But if my options are to make an awesome XNode, that is built on unreleased technology, or make a decent but not perfect polymorphic VI but is supported, I will go with the polymorphic VI most of the time.

 

Is there a place we can aggregate known issues for this feature now that they are "in the wild" so to speak?

Uh...aren't you NI?  Where would you like us to report known issues for this feature?

 

I think the real answer is, we do like we always have, and NI doesn't officially support unreleased features outside of NI.  I have lots of private functions that when they don't work I don't call up NI, because I know I won't get support.  But I know a few at R&D will troll these (and NI) forums and help us out, telling us a general feeling of "This is mostly stable and lacks documentation" or "This will crash LabVIEW, do not use it."

 

If you are one of those with inside information, we'd greatly appreciate any details you can give about stability, or instability of unofficial features.