VI macros?

[ShaunR]

Well. I think I've invented Named Events - my life is complete

 

They are flakey (seems to want highlight execution on when you first start for some weird reason) .

EDIT: Caused by a race condition. Hmmmm. Put thinking cap on.

 

 

I'll knock up a demo at the weekend so you can play.

Edited August 18, 2015 by ShaunR

[JackDunaway]

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?

 

Take less time/knowledge/effort to create and maintain by encapsulating complexity at the meta-language layer instead of dumping it into application repositories. What makes sense for you at what layer? They both have valid cases. 

[pawhan11]

Played for a few hours with vim and event generation.

I wanted to create universal vi for creating and adding UE. It seems that we can create one vi for registering and sending UE data, but registering more than one UE will require xnode

I added one flag to decide when to register and when to generate.

vim needs to be extracted because I couldn't attach it.

 

 

 

event testing.vi

event test.zip

[ShaunR]

Played for a few hours with vim and event generation.

I wanted to create universal vi for creating and adding UE. It seems that we can create one vi for registering and sending UE data, but registering more than one UE will require xnode

I added one flag to decide when to register and when to generate.

vim needs to be extracted because I couldn't attach it.

 

Yup. You've got it. I prefer to keep the generator separate because the register does some intelligent naming which could impact fast generation of events. It may be a personal preference, but I think I prefer less ambiguity between grabbing an event and generating one. I'd be shooting myself in the foot more often than not

 

One thing that we can't get is the name from a connecting control the same way the queues and events do.An xnode would probably be able to get it but I settled on an old method of using a VI as a control and having a "name" field - a poor mans type-def.. It requires unbundling so it's not as concise but acceptably verbose, I think. I did think about putting it inside the Macro but didn't want to start making "special use" rules. This  way its clear whats going on, IMO.

 

Below is a demo use case showing one of the sybsystems (ACQUIRE) and one of its listeners (in Main UI). My architecture has queues in and events out so the Get and Send is a queue. That probably won't get replaced by a macro as it needs to be able to send a single command or an array of commands. For that, you need different diagrams and a polymorphic VI is more appropriate.

 

 

So far. All the messaging, subsystems, user interfaces and project libraries are ~700 KB.

[ShaunR]

Oh yes. does anyone know the frequencies and durations to play the A-Team theme tune with the Beep VI?

[Phillip Brooks]

Oh yes. does anyone know the frequencies and durations to play the A-Team theme tune with the Beep VI?

 

I prefer Airwolf... ( http://users.elite.net/gurpal/tv/airwolf.mid )

 

Convert from MIDI format?

 

http://www.skytopia.com/project/articles/midi.html

 

http://subsynth.sourceforge.net/midinote2freq.html

[hooovahh]

You know what, I need to look at this differently, and Shaun is helping with that.  VIMs are getting people excited about an entry level way of doing type adaption, allowing for unrealized ways of making code.  This technology has its limitations, and as users use VIMs they might realize the powerful potential of XNodes and how they can bridge the gap between what they can do with VIMs and what they want to do with them.  It's a gateway drug VI.  

 

Or they may have a VIM that just does exactly what they want and don't need to change a thing...I wonder if I should try to make Variant Repositories with VIMs.  Not all of the features would be supported but type adaption is the big selling point.  Any function similar to Read/Write Anything could benefit from this for sure.

[bbean]

Played for a few hours with vim and event generation.

I wanted to create universal vi for creating and adding UE. It seems that we can create one vi for registering and sending UE data, but registering more than one UE will require xnode

I added one flag to decide when to register and when to generate.

vim needs to be extracted because I couldn't attach it.

Coffee hasn't kicked in yet and I feel a little slow this AM.  Can you explain:

• the use of the queue primitives and what they are for in the .vim? 
• why register flag doesn't get passed to the "created new" True case and wrap around the Reg Events Primitive?

And is the jist of the naming issue:

[ShaunR]

Coffee hasn't kicked in yet and I feel a little slow this AM.  Can you explain:

• the use of the queue primitives and what they are for in the .vim? 
• why register flag doesn't get passed to the "created new" True case and wrap around the Reg Events Primitive?

And is the jist of the naming issue:

naming issue.png

I'll answer #1, # 2 seems like a particular implementation issue.

 

To encapsulate events, you need a way to share the reference. Since wires will not be passed, we need a way of identifying a particular event refnum and storing it where all instances of the VIM can retrieve it. Normally you could just use a normal VI or DVR with a feedback node or shift register for memory, and a case statement to make it self intialising - VIs that are not set to re-entrant are singletons. This is how LV2Globals work.

 

VIMs are pre-allocated re-entrant, though. Even if you set the VI property to not be; it just gets ignored. So you can't use a feedback node (or shift register) as it will only exist for that instance. We want  grab a single event ref wherever we plonk the VIM in whatever VI we choose. So we use a single element queue to provide a named memory storage for the event renum. We can then retrieve the event refnum by peeking, that is, reading without destroying, the refnum. We use named queues to make named events that work in re-entrant VIs because we are retrieving by name, not by instance.

[ShaunR]

Attached is a demo using the VIM events. It works pretty well, when it works, but the VIM technology is far from production ready as we were warned..

 

If you don't see any broken arrows, don't go changing anything until you've run it . You will probably find there are no icons where the VIM should be but don't let that put you off.

 

If you have broken arrows then you will have to go around re-attaching the VIM to the events. Sometimes event names get detached, especially when you are changing the VIM. It gets very confused which instances are attached to what so you have to beat it into submission

 

There are two demos.

One is just a few of the events in while loops that exercise the event VIM - you have seen the diagram already in a previous post.

The other is a fun demo that may or may not work for you out-of-the-box (make sure the sound is on ).

VIM Msg Example.zip

Edited August 23, 2015 by ShaunR

[bbean]

Attached is a demo using the VIM events. It works pretty well, when it works, but the VIM technology is far from production ready as we were warned..

 

Thanks for the example of VIM events and the hard work that went into that example.  I noticed the VIM Event Test.vi ran a little choppy on the first run, hesitating every now and then.  After stopping and restarting it seemed to be fine.  Wonder what's happening here.

 

Attached are recompiled versions for 2012 / 2014 to save others the pain of manually re-linking the .vim file.  Do .vim files work more reliably if they are placed in the user.lib/macros/ ? 

 

Just a quick question....In your "subsytem" VIs (File and Sound) is there a reason for putting the srevent.vim file inside the while loop?  could it be outside the while loop to prevent unnecessary calls to the subvi to just return the reference? Or is it necessary to be in the while loop for some reason?

 

 

 

 

Edit - Updated 2014 zip file to have relinked Main.vi

VIM MSG Example 2012.zip

VIM MSG Example 2014 - Rev1.zip

Edited August 24, 2015 by bbean

[ShaunR]

Thanks for the example of VIM events and the hard work that went into that example.

You mean it worked?

 

Probably not as hard or as much work as may be thinking. There is really nothing complicated or hidden in there and its only 1.5MB excluding the wav files. The message library is only about 150K so all the code is for doing something and doing anything that  manipulates the UI in LabVIEW always makes it look complicated .

 

There is an empty place where the "Services" icons are in the Main.vi and if you look at previous images you will see a TCPIP icon that goes there. Since you got it up and running; do you want me to post the Telemetry service?

 

Maybe this should go in another thread or the uncertified CR because it is 99% application and 1% VIM

 

I noticed the VIM Event Test.vi ran a little choppy on the first run, hesitating every now and then. After stopping and restarting it seemed to be fine. Wonder what's happening here.

I notice this a lot with later LabVIEW versions regardless of application. It's like the compiler seems to decide that the VI really does need some more recompiling when you run it.I don't think it is specific to VIMs.

 

Attached are recompiled versions for 2012 / 2014 to save others the pain of manually re-linking the .vim file. Do .vim files work more reliably if they are placed in the user.lib/macros/ ?

Thanks. It will be interesting to see if it is the version that is the reason for the breakages and a lot of the "issues" or it is down to the object cache. If it is the latter, then the versions you supplied will also be broken. I can use the VIM on all versions on multiple machines but sometimes it breaks. If someone from NI decides to have a play maybe they can figure out a workaround

 

Just a quick question....In your "subsytem" VIs (File and Sound) is there a reason for putting the srevent.vim file inside the while loop? could it be outside the while loop to prevent unnecessary calls to the subvi to just return the reference? Or is it necessary to be in the while loop for some reason?

Two reasons. Neither are set in stone and mainly due to my programming style. Put them outside if you wish.

• I would normally put both in a sub VI (look inside the get VI) so that get refnum and Generate event is a single VI, drop in replacement, for the Generate primitive. As I said before, The "Name" is preventing me from doing that and I'm still umming and arring about it because I don't like that it is not a single VI. It annoys me enough that I keep the "Name" unbundle even though I could make it a separate terminal on the "type VI" to remove it, It keeps me thinking about how to get rid of it.as it is a blight in all VIs I have to work on
• The whole point of my implementations is that you can put them anywhere - pretty much care free - so you can reduce wires. So they are placed where they make the diagram look cleaner (to me). Optimization is one of the last processes to be preformed in a development and arguable whether needed at all for demos.

Edited August 24, 2015 by ShaunR

[bbean]

• I would normally put both in a sub VI (look inside the get VI) so that get refnum and Generate event is a single VI, drop in replacement, for the Generate primitive. As I said before, The "Name" is preventing me from doing that and I'm still umming and arring about it because I don't like that it is not a single VI. It annoys me enough that I keep the "Name" unbundle even though I could make it a separate terminal on the "type VI" to remove it, It keeps me thinking about how to get rid of it.as it is a blight in all VIs I have to work on

 

I have an idea regarding the "Name" issue.  Would an Xnode be a better solution instead of a .vim file?  I think you could use the AdaptToInputs and GetTerms3 functions to figure out the "Name" of the data input (at development time only of course) when it was wired to a variant data terminal. Then in GenerateCode wire up a static name to the SEQ input of your template VI.   Not sure if its possible, but you may also be able to dynamically (in dev env again) rename the "Data" input terminal in GetTerms3 to have the same name discovered during AdaptToInputs... potentially also fixing the generic "Data" Event in all event structures to something more meaningful.

[ShaunR]

I have an idea regarding the "Name" issue.  Would an Xnode be a better solution instead of a .vim file?  I think you could use the AdaptToInputs and GetTerms3 functions to figure out the "Name" of the data input (at development time only of course) when it was wired to a variant data terminal. Then in GenerateCode wire up a static name to the SEQ input of your template VI.   Not sure if its possible, but you may also be able to dynamically (in dev env again) rename the "Data" input terminal in GetTerms3 to have the same name discovered during AdaptToInputs... potentially also fixing the generic "Data" Event in all event structures to something more meaningful.

 

Yes. I say that in this post  but if VIMs ever get released, it would be nice if they did it so we didn't have to go through the Xnode madness or my old school way. I have demonstrated the use case with some pretty eye candy so hopefully it sticks in someones mind when/if they think about productionising VIMs After all. VIMs are Xnodes already (\resource\XMacro.xnode if you want to hack )

Edited August 24, 2015 by ShaunR

[bbean]

One other comment after looking at the VIs a bit more.  Why do use different conventions for identifying the recipient/sender for MSG Get (the caller VI's name or name override) and MSG Send (parsed out of the Msg input string)?  This is confusing.  Why not just do the Msg Send the same as Msg Get (using the caller VI name)?

[ShaunR]

One other comment after looking at the VIs a bit more.  Why do use different conventions for identifying the recipient/sender for MSG Get (the caller VI's name or name override) and MSG Send (parsed out of the Msg input string)?  This is confusing.  Why not just do the Msg Send the same as Msg Get (using the caller VI name)?

 

Send doesn't always sit in a Top level VI that has meaning at the system level. You can send a message from much further down or higher up the hierarchy whereas Get always sits in the top level VI of a service and there is only one of that service type (you can have sub services, i.e. turtles all the way down , but we'll leave that for now - it's a semantic segregation).

 

The VI name is always the Service Name (FILE.vi and SOUND.vi in this case) and anyone can send a message to a service even from another machine and even using non LabVIEW software (you just need some sort of TCP/UDP Service - I use a websocket one ) The sender is just a label that can be used for anything you like (filtering events and debugging usually) but by convention I use the Process Name or IP address. An important distinction is that the SENDER field does not dictate the return path!. You may notice that the SENDER for MAIN.vi is actually called "UI" rather confusingly. That is because it used to be the UI  - nobody is perfect The beauty is, though, I only have to do a text search and replace (apart from with arrays, it seems) and its all fixed with no recoding/relinking at all

 

Can a mod move this and the few previous ones to another thread, say, "VIM Demo-HAL"? so as not to pollute this thread too much? We are way off the OP now

Edited August 24, 2015 by ShaunR

[lordexod]

VI Macro technology update :

 

[bbean]

On 5/16/2016 at 2:58 AM, lordexod said:

VI Macro technology update :

 

Code looks the same as before.  Where is new technology?

[jeffk]

To further pique your interest in macros, there is a new one in LabVIEW 2016 / User Libraries / macros  called Norm.vim.

It is not meant to be rigorous from a mathematical perspective (it's just my best guess) but rather to illustrate a new (experimental) structure, a variant of the Diagram Disable Structure, called a Type Enabled Structure.  It has some interesting properties when used within a macro.

Here is how it works.  When an instance of the macro is inlined and types are propagated to the inputs, each subdiagram attempts to propagate types;  the first subdiagram (in subdiagram order) which successfully propagates types without any errors is enabled and all the others are disabled;  the enabled subdiagram is the one which is compiled for this instance of the macro.

The new structure is not in any palette yet, nor is there any documentation.  It isn't quite ready for prime-time, but you can copy it from Norm.vim and experiment with it and give us feedback.

[bbean]

43 minutes ago, jeffk said:

To further pique your interest in macros, there is a new one in LabVIEW 2016 / User Libraries / macros  called Norm.vim.

It is not meant to be rigorous from a mathematical perspective (it's just my best guess) but rather to illustrate a new (experimental) structure, a variant of the Diagram Disable Structure, called a Type Enabled Structure.  It has some interesting properties when used within a macro.

Here is how it works.  When an instance of the macro is inlined and types are propagated to the inputs, each subdiagram attempts to propagate types;  the first subdiagram (in subdiagram order) which successfully propagates types without any errors is enabled and all the others are disabled;  the enabled subdiagram is the one which is compiled for this instance of the macro.

The new structure is not in any palette yet, nor is there any documentation.  It isn't quite ready for prime-time, but you can copy it from Norm.vim and experiment with it and give us feedback.

Thanks for the heads up.  I guess I'll have to sign up for the beta testing to get a peak.

[hooovahh]

2 hours ago, jeffk said:

To further pique your interest in macros, there is a new one in LabVIEW 2016

So usually this is where I mention that discussing the beta material on the forums is against NI's NDA, and how you probably shouldn't talk about it.  But in this case I'll let it go for more than one reason.  Welcome to the forums.

Can't wait to play around with the expanded VIMs in 2016 that feature does sound useful.  If you are reading LAVA's discussions about VIMs I hope that you've realized one of the key features we'd like documented, is how to force a control to be a defined type, and not always adapt to type.  I see that code for this has been started in the VIM XNode but doesn't appear to be complete, and relies on arrays of strings on the front panel labeled something specific.

I'd suggest adopting what has been used on the right click frame work, assuming NI has gotten good feedback.  Here you can have a control defining the types that an input can become, or choose it to be the one type it is in the template, or choose it to adapt to any type.  The configuration of this matters much less to me, than the fact that it actually works.  I'm not a fan of having to jump through hoops to get things to work, but I am grateful when those hoops exist.

[ShaunR]

39 minutes ago, hooovahh said:

I'd suggest adopting what has been used on the right click frame work, assuming NI has gotten good feedback.  Here you can have a control defining the types that an input can become, or choose it to be the one type it is in the template, or choose it to adapt to any type.  The configuration of this matters much less to me, than the fact that it actually works.  I'm not a fan of having to jump through hoops to get things to work, but I am grateful when those hoops exist.

It sounds from the [brief] description that if no cases match then it could break the Vi, thus achieving what you desire by adapting to only those types you define in the structure (maybe an optional default case?). Except this is more powerful in that you could also do things like "nearly equal to zero" if it is a double type, for example.

[Aristos Queue]

2 hours ago, bbean said:

Thanks for the heads up.  I guess I'll have to sign up for the beta testing to get a peak.

Unfortunately, the beta is closed to new members now. The beta cycle is finishing up now.

To borrow from a popular TV show: "August is coming."

:-)

[hooovahh]

1 minute ago, ShaunR said:

It sounds from the [brief] description that if no cases match then it could break the Vi, 

Yeah I like that.  It could fix several things I've been thinking about, like what if you want to adapt an input to a 1D of any kind of data, but it must be a 1D array?  Then you could have a case where you wire your input into a Search 1D array, which would break if a 1D wasn't wired.  Not sure how this would work for performance performing a task with a primitive, whos output isn't used.  The compiler might optimize away code and do strange things.  Want to ensure only a cluster is wired?  Wire that input to an unbundle function.  Want a 2D of something?  Wire to a transpose.  Still there are times when I want more complicated checks, like the input is a cluster, and one of elements is a numeric, and has a label of XYZ, but I guess that's when XNodes could come in.

[ShaunR]

17 minutes ago, hooovahh said:

Yeah I like that.  It could fix several things I've been thinking about, like what if you want to adapt an input to a 1D of any kind of data, but it must be a 1D array?  Then you could have a case where you wire your input into a Search 1D array, which would break if a 1D wasn't wired.  Not sure how this would work for performance performing a task with a primitive, whos output isn't used.  The compiler might optimize away code and do strange things.  Want to ensure only a cluster is wired?  Wire that input to an unbundle function.  Want a 2D of something?  Wire to a transpose.  Still there are times when I want more complicated checks, like the input is a cluster, and one of elements is a numeric, and has a label of XYZ, but I guess that's when XNodes could come in.

Well. The fist thing I will do is fire up the VIM Hal Demo. If that works without having to replace all the VIMs and has meaningful event names; I will be a very happy bunny.

Edited June 6, 2016 by ShaunR