NI Home > Community > NI Discussion Forums

LabVIEW

Showing results for 
Search instead for 
Do you mean 
Reply
Knight of NI
Knight of NI
Ben
Posts: 16,154
Accepted Solution

Community Nugget 1/29/2007

Dynamic Instantiation of Occurrence Based Architecture
Or
Creating an array of Occurrences

Introduction:
Occurrences are an elegant way of implementing a Boolean event based architecture. Building an array of Occurrence references is not straightforward.

Solution:
Dynamically instantiate re-entrant sub-VI’s that create the Occurrence references.

Discussion:
An example of Occurrence Based Architecture (OBA) that recently came to mind after I viewed a copy of one of the Animusic videos . In this video a set of synchronized machines work together to produce music. My buddies turned to me and said, “We could build one of those… Couldn’t we?”



OBA.jpg

Latter my mind wondered to the question of how would I architect such an application. An OBA came to mind were I could use a single control VI to distribute Occurrences to a set of VI’s that would control the associated instrument and note. The control VI would read the “sheet music” and distribute “triggers” or Occurrences to the VI’s that implement each instruments note.

Occurence_Source.jpg

Occurrence Source.jpg illustrates the arbitrary distribution of triggers from a single control loop. After a fixed size array of Occurrences is built, a set of “Instrument-Note-Controllers”(Occurrence_Sink.vit) are created to by the For Loop. In order to keep this example simple, the note “intensity” is illustrated by Boolean color intensity. The while loop fires the Occurrences based on random indexing of the Occurrence Reference.


Running.jmp

When attempting to implement this type of architecture we run into a bit of a complication when you attempt to realize it in such a way as it can be of arbitrary size. The arbitrary size enters into my LVAnimusic exercise when I want to implement a different number of instruments and notes for different songs. The complication with OBA of arbitrary size becomes apparent when we look at the value returned by the Generate Occurrence node (GO).

Occurence_Source_mod1.jpg

The GO will generate AN occurrence. It will not generate a new Occurrence each time it executes. If you drop a GO in a For Loop and index of the output tunnel you will get an array of identical Occurrences.

Occurence_Source_mod1_FP.jpg

Since all of the “Instruments” (Occurence_Sink.vit) will be looking at the same Occurrence we will only be capable of very dissonant music. :smileymad:

As shown in “Occurence_Source.jpg” it is possible to create an array of unique Occurrence using a unique GO for each, but how to get an arbitrary number?

By using LabVIEW’s VI server and opening multiple copies of a non-re-entrant sub-VI, we can generate an array of unique Occurrences. This is illustrated in “Occurence_Source_mod4.jpg’.

Occurence_Source_mod4.jpg

This approach works because LabVIEW will load a unique “copy” of a VI when the VI is marked as non-re-entrant. Each time the sub-VI loaded, a new copy of the GO is loaded into memory. When we open a new reference to the non-re-entrant sub-VI we are loading a new GO at the same time we create the reference to the VI. When we pass unique VI references to the “Call by Reference Node” we are executing DIFFERENT copies of the GO each time.

There is one last point that I would be negligent if I did not mention. It is the “good little assistant” nature of LV can get carried away if we do not take into consideration the lifetime of the resources of a VI. The resources that affect the illustrated OBA are the Occurrence itself. The Occurrence is valid only as long as the VI that holds the GO is active. If we closed the reference to the sub-VI’s used to create the Occurrence references in the For Loop where they are created, the Occurrences would go invalid before they were ever used. To prevent the Occurrences from going invalid, all of the VI references are closed only when the application no longer needs the Occurrences.

Summary:
OBA – can be used to distribute an arbitrary number events
GO – will only return a single Occurrence reference regardless of how many times it executes
VI Server-Non-Re-Entrant VI – Open will load a new copy of the VI’s code and resources.
VI Server Close – will remove all resources allocated when the VI was opened.

Closing:
A copy of all of the code used in this Nugget can be found in the attached zip as LV 7.1
I thank you for reading, invite your comments and hope that you and LabVIEW will be beautiful music together.
If you have a Nugget you would like to present please post here to reserve your week!
A list of all Nuggets can be found here .

Ben

Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction
Knight of NI
Knight of NI
tst
Posts: 10,906

Re: Community Nugget 1/29/2007

Very nice, Ben.

Here's my version of this (backsaved to 7.0).

It can be quite hypnotic and could probably be used as a screen saver.

Hey, get it to do colors and you've got yourself a disco. :smileyvery-happy:

 

Warning, this VI can open a lot of subVIs. I suggest you close other stuff you have open before running it.


___________________
Try to take over the world!
Active Participant
Matthew_Williams
Posts: 407

Re: Community Nugget 1/29/2007

Good job Ben!  Interesting problem, elegant solution, lucid explanation.  Thank you!

Matt
Active Participant
Jarrod_S.
Posts: 1,420

Re: Community Nugget 1/29/2007

Great post! I love the tie-in to generating musical notes. My initial thought on all this is that there is a bit of overhead for creating a new VI instance for each occurrence. One way to account for this would be to have your reentrant Generate Occurrence VI be able to generate up to N unique occurrences. One way to implement this would be a functional global with 10 duplicate cases in a case structure, each with its own Generate Occurrence node. The functional global could then increment its count each time it gets called. Each time up to N times that you call it, it will generate a unique occurrence. On the N+1th time, you load another reference to this VI.

It seems to me at some point it would be worth your while to implement this design. The more occurrences each VI holds (the larger the N), the lower percentage of VI overhead you have per occurrence. This is probably only worth it if you plan on using a very large number of occurrences.

Any thoughts?




Jarrod S.
National Instruments
Active Participant
Tomi_Maila
Posts: 419

Re: Community Nugget 1/29/2007

Nice nugget, Ben!

I was wondering this specific issue a few months back. Occurrances are the best performing synchronization nodes but one looses the performance when the creation using call by reference node is slow. If one wants to make the code better performing, one can places a matrix of occurences in the VI and instead of returning a single occurence, return an array of them.

Tomi
--
Tomi Maila
Active Participant
Tomi_Maila
Posts: 419

Re: Community Nugget 1/29/2007

Hi,

I wrote a SubVI that creates any number of distinct occurrences using the method proposed by Ben. The occurrences are distinct under any circumstances unlike the occurrences directly created with Generate Occurrence node. The Create Multiple Occurrences node is distributed under BSD license i.e. you are free to use it in any of your project with no charge and no obligations. The file is for LabVIEW 8.0 or later. I don't have earlier versions of LabVIEW installed on this computer.

--
Tomi Maila
Knight of NI
Knight of NI
Ben
Posts: 16,154
0 Kudos

Re: Community Nugget 1/29/2007

[ Edited ]

Thank you for reading and replying!

Tomi and Jarrod,

We have to keep the reference to the dynamic sub-VI's alive to keep the Occurrence references valid. If I specify more than 32 Occurrences, only the first 32 are good!

See attached.

Ben

Message Edited by Ben on 01-29-2007 07:32 AM

Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction
Member
K1200LT_rider
Posts: 97

Re: Community Nugget 1/29/2007

This gives me the idea that Occurences may be the way to syncronize one or more instances of a VI that controls, tracks, and/or simulates a thermal chamber while the UUT testing loop and UI update loops wait for and send occurrences to the chamber loop(s).  Hmmm...  I've been contemplating the best approach for creating an universal thermal chamber VI we could just drop in to any project that uses one.  Thermal chambers are so common that I would imagine someone has done this already.  Anyone willing to share how you did it and how well it works?
 
- Brad
Active Participant
Steve.Briggs
Posts: 339

Re: Community Nugget 1/29/2007

I remember being first introduced to LabVIEW last year in my engineering design class.  The professor played this exact video in the lecture and everyone in the entire lecture hall sitting amazed and speechless.  Funny thing is, we all thought we could jump right in to LabVIEW and create something like that on our own :smileyvery-happy:
 
Great post Ben!
Member
eaolson
Posts: 108

Re: Community Nugget 1/29/2007



Ben wrote:

Occurrences are an elegant way of implementing a Boolean event based architecture. Building an array of Occurrence references is not straightforward.



Perhaps I'm just being a bit thick (hey, it's Monday), but what's the advantage of this over an array of boolean notifiers? There's a slight performance advantage of occurrences, I understand, but don't you use that up by the dynamic VI Server calls? In this example, you could even use a U32 notifier, and combine the synchronization of the notifier with sending the data to the other VI.