Static reference of VI VI reentrant

Is it possible to use a static reference of VI to dynamically launch a VI on the way home?

I found this old post, http://forums.ni.com/ni/board/message?board.id=170&message.id=120367, the user can find a work around, but it of ugly, isn't it

The last snapshot in your link shows the best way to invoke an instance of a reentrant VI dynamically. The only thing I would change from that is to use the Name of VI property instead of the Path of VI property to wire open VI return. You can simply use the name of VI if the VI is in memory, which is more effective. Since you have a static reference of VI, the VI will certainly be in memory.

I agree that it's a bit ugly. Personally, I created a Subvi to hide the ugliness and make him feel more simple!

Tags: NI Software

Similar Questions

  • VI static references in an application using

    Hello to you all, useful forum fans!

    I use 4 different static references of VI hung directly to "Run a VI" invoke nodes, with the waiting "until" and settings "Auto have Ref" both false, run the four screws dynamically, which each does nothing except call my serial port returning from input/output VI with a different index of COM port number.  Overall it works pretty well.  However, I have a few questions concerning the improvement of my installation.

    (1) is it possible to somehow set an input parameter to the serial port environment VI and thus be able to invoke it directly four times in a loop for, each with a different input value?  I don't know how I would do that, except that I heard that you can set the value of a control on a VI by using a reference to it.  I also fear that the use of the same reference VI static to invoke the VI 4 times somehow re - start the same instance of dynamic VI 4 times, instead of spawning 4 copies of it.  However, this solution would allow me to remove the 4 screws that do nothing except call the reentrant VI, and my code would be simpler and more extensible (e.g. making it easy to interact with 8 ports in the future series just by increasing the number of for the iterations of the loop).

    (2) it seems to be necessary for me to add the 4 screws that I dynamically invoke in my lvproj file and add to the section "Still included" my generation of application properties in so that they can be included in the executable file of my application.  It was what I had to do in previous versions of my code when I've referenced via a path on the screw name, but now I've changed using static references of VI, I thought they would be included automatically.  LabVIEW already knows to automatically load them into memory (for example, when I do a search it finds them even when they are not open), and they are included in the list of dependencies in the LabVIEW project, so why they would be built to my executable?  I would prefer not to have to add explicitly, as it is one thing to forget if I change it in the future.  Is there a setting or something somewhere that I can change so that they will be included in the executable file automatically?

    I thank very you much for your time and your help as always!

    -Joe

    Hey Joe,

    Answer to Q1: Yes.  Wire one '8' (type of data I32) entry 'options' function 'open VI Reference.  This indicates 'Reference open VI' that the VI is re-entrant.  It will look like this:

    Use the resulting table of references to follow your screws laid throughout the rest of your application.  Don't forget to close them when you are finished with them.

    For the 2nd quarter... I certainly built executables by using code similar to what I show above and did not have to explicitly include the screw called statically in the build.  You're right, they should be automatically included in the compilation - mine were always, including modules that reside in a different lvproject (called by a main control VI).  Sometimes I felt it necessary to develop modules in a lvproject and then call them from different main screws that reside in other projects.  If I used a static reference, they are always included.  What LV version do you use?

  • static reference with the global variable

    Hi, I used a static reference to a Subvi where I change a global variable before (3-4 years ago) and do not remember how I did it.

    It was something like these attachments, but now I'm using LabView 2013 instead of LV 8.6.

    The change in the overall operating system sees only not in the main vi (looks like the invoke node run vi does not work with globals).

    In addition the vi close with the invoke node close vi but not if I put the custom in the Subvi properties to automatically close.

    dkfire wrote:

    Why not call the sub vi as usual, just with the setting to display the front panel, when it is called?

    Use the connector pane to transfer the value of the sub vi Ok button when done.

    That's what I recommend.  If this is not possible for some reason, then you will need to use a flat Structure of the sequence to force the reading of the global variable after the Subvi is complete.

  • How to use a static reference to maintain a VI in memory, but then call it in parallel?

    Hi all

    I have a MainVI and I want to call him a Subvi in parallel so that I can have both windows open and sensitive at the same time.  The Subvi can be closed and then reopened any number of times, but only one in existence at the same time.  I know how to do it using the reference VI opened, offering a path relative to my Subvi, check to see if its already running and if so bring window to front (using front panel: open with entries True/Standard method) and if not run it using the Invoke method: Run (and eventually open its façade by program).  This method worked very well.

    Now, I've added functional global variables in my Subvi, and I want to keep in memory inbetween opening Subvi window.  I can do this by placing a copy of the functional overall in my MainVI, even if I do not here for nothing.  It works very well.

    By chance, I came across a reference to a static reference of VI, which resembled a great improvement in my method, for the following reasons:

    1) Subvi keeps in memory all the time, eliminating the need to put the functional overall in MainVI when it is not used it.

    (2) tells the LabVIEW to include the Subvi when I build my executable, rather than me having to specifically mark as always include in the build specification.

    (3) eliminates the need to continue the path and the name of Subvi updated in a constant string in my code, in order to use the open VI reference.

    However, in trying to implement this solution, I ran into the problem that once you put a reference of VI in strictly typed static (strict typing is necessary to keep in memory) on the block diagram, that VI is reserved for execution.  This means that I can't run it using the Invoke method: Run.  I did not just put it on the diagram directly as a Subvi because I need it to run in parallel to the MainVI.  I searched through these forums extensively, and although there are several references to a static reference of VI, none of them say explicitly how to actually run this 'thing'!  : PEI

    I greatly appreciate any insight into my problem.  If I have to go back to the old way it works perfectly, but I really like the apparent elegance of this solution.  I hope that it will be technically possible, and I'm not bad understand something.

    Thank you for your help,

    -Joe


  • Get a static reference to decoration

    Is it possible to get a static reference to a decoration? I have some tips that is represented by colorful decorations that I want to change the colors of them based on the data that I get. I know, it is possible to obtain references to the decorations in a programmatic manner, but it is something huge maintainability because it is incredibly difficult to follow the course of the program. Thank you.

    I don't think you can get that directly. Check the exchange of ideas. I think that there has been a few proposals along this line.

    Perhaps another approach would be to put indicators of color behind the decorations box and change the color of those. The borders of your pipe decorations would be opaque, while the Interior would be transparent to allow the squares of color to show through. The color boxes appear as standard terminals on the block diagram. With appropriate labels, they fit perfectly in the paradigm of data flow.

    Lynn

  • a static reference to a URL object

    I want to create a final static reference to an instance of URL:
    public class SomeClass {
      static final URL rooturl = new URL(stringA); // fail. an exception is thrown but not caught.
      ...
    }
    If I do not end rooturl, then it works:
    public class SomeClass {
      static URL rooturl;
      static {
        try {
          rooturl = new URL(stringA);
        } catch(Exception e) {...}
      }
      ....
    }
    I'm ok with the help of the solution of the static initializer block.
    But I would like to know how to create a final static reference to an instance of a class whose every constructor throws an Exception.

    I won't read all of this code, because it is irrelevant to the question I think you, and stuff on the newspapers and magazines is also irrelevant.

    Your first post properly reflected your problem, I think.

    public class Foo {
      private static final URL url = new URL("a://b.c"); // Your question is: What do I do if new URL() can throw a checked exception?
    }
    

    Here's the thing. When you say static private final URL url, you tell the compiler that the url variable must be assigned a value when your class loading. Now, as you saw, you can throw a checked exception to a static initializer, but that's OK, you can just wrap in the Unchecked exception, ExceptionInInitializerError, like I showed you. That's what this course is aimed at the:

    public class Foo {
      try {
        private static final URl url = new URL("a://b.c");
      }
      catch (MalformedUrlExeption e) {
        throw new ExceptionInInitializerError("Could not create URL", e);
      }
    }
    

    It is a correct approach. You have already decided that this value must be initialized at class load - your class requires time in order to do its job, or if you have asserted. So if the URL cannot be created, this class can't do his job, then he expected to fail to load.

    If you makes it not final, then your catch block can log the error, instead of throwing. Do you understand why? This is because the final member variables must be initialized before that code can go further. Throw the uncontrolled exception means that code is not go any further, it's legal. And for a variable not final, it is not necessary to have a value, then you can simply log in and continue.

    HOWEVER, suppose make you no final, record a message and continue. Now what?

    Your code continues as if everything is fine, when in fact, he's not fine. Catch the exception did not have the problem go away, and to raise once again does not, your code has no idea that something was wrong. So when you get to the point where you try to use the URL, you will get a NullPointerException. Then what? You catch that, record and continue as if everything goes well?

    Some point to actually deal with the fact that an error has occurred. Does not simply continue on as if all goes well. If you have one) offer some State assistance or operation that takes the place of the problematic code (almost never a good approach), b) again, or c) propagate the error to the caller and let him face (usually approach correct).

  • Call for a stop of the method may not set via a static reference with type.flash.media.Sound

    This error appears when I tried to put this code "soundFx_1.stop ()"; inside a function implementation. What does that mean?

    you don't have to stop all sounds in your earpiece mouseover, only your listener reversal function function:

    var soundFx_2:Sound = new Sound (new URLRequest("Cabinet_Close.mp3"));

    var soundFx_3:Sound = new Sound (new URLRequest("Cabinet_Open.mp3"));

    var SC: SoundChannel;

    Cabinet1_00.addEventListener (MouseEvent.MOUSE_OVER, fl_MouseOverHandler);

    Cabinet1_00.addEventListener (MouseEvent.ROLL_OUT, fl_RollOutHandler);

    If (this ["showAcid3"] is nothing)

    {

    var showAcid3:Boolean = true;

    }

    showAcid3 = true;

    function fl_MouseOverHandler(event:MouseEvent):void

    {

    Cabinet1_00.gotoAndStop ('Open_0');

    SC. Stop();

    SC = soundFx_3.Play ();

    setChildIndex (Cabinet1_00, numChildren-1);

    If (showAcid3 is true)

    {

    Cabinet1_00.Acid_3.gotoAndStop ('Still');

    Cabinet1_00.Acid_3.addEventListener (MouseEvent.CLICK, removeSelf);

    }

    on the other

    {

    Cabinet1_00.Acid_3.visible = false;

    }

    }

    function removeSelf(e:MouseEvent):void

    {

    showAcid3 = false;

    soundFx_1.play ();

    DisplayObject (e.target) .removeEventListener (MouseEvent.CLICK, removeSelf);

    }

    function fl_RollOutHandler(event:MouseEvent):void

    {

    Cabinet1_00.gotoAndStop ('Still');

    SC. Stop();

    SC = soundFx_2.play ();

    }

  • Static VI reference will result in failure

    Nice day

    my application is composed of an exe (labVIEW 2014) and a "self-made" (labVIEW 2014) library, the two using many other lvlibs.

    Failure (own error set when detected that MODBUS initialization has not been done) is due (according to me) to not executing a static reference of vi.

    The failure occurs in the exe file before loading the library.

    Exe and library use the same lvlib MODBUS.

    I built with the lvlib MODBUS library in the files OR program branch.

    I have 2 PC to build & test. (If both computers have the lv2014 OR installed Dev Environment).

    The failure does not occur when I build the exe with the MODBUS lvlib incorporated in its own project, not in the direction of the program files OR and 1 specific PC.

    On the other PC, I can't fix so that the exe file is well-formed (build succeeds; although having conflicts (not solvable...; correctly construction means that the executable runs composed this failure)).

    Same conflict (not studied all the) on the PC with properly build exe, even more conflict... (I managed to get 1 single conflict on him does not correctly build pc...; the properly build the pc, he sees green conflicts).

    When it's a lvlib, I can open with lv and discovers the vi formed after generation, with an exe file, I can't.

    Can someone put me on the right track to tackle this problem, so that I can understand why it is still unable to build what on this PC?

    It is not the as with Windows dll hell, but hell lvlib. (I solved it once that similar cases with SEO in good lvlibs and not vi under program files...?)

    WARNING: pretty complicated, not for beginners. I'm sorry. I will not be able to provide sources...

    THX.


  • Asynchronous reentrant vi references table

    I have a fgv in which I'm trying to store references to the screws reentrant I can see the reference is stored in the table, but when I use the index table to get some reference, I get an error. Can anyone help with this?


  • Reference a static open VI

    Hello guys,.

    To open the screws dynamically, instead of Hardcoding the name VI in a constant string, I do as indicated below to keep addictive for my VI, so if someone ever delete the VI of the project, move, rename, it will create a wire broken somewhere so that we will be able to fix it more quickly.

    However, don't you think it's a little weird to have the reference to the VI already, but we need to open a new reference, is there a way to get rid of the node property to get the path of the VI? Is that the static VI reference must be closed after the opening of the other reference?

    Would it make sense to be able to right click the static reference and specify the option to open a call and forget the reference?

    Is there a best practice?

    See you soon,.

    Mike, I remember there was at least at one point some subtle differences on the use of name vs. way (I think that having need of the loop from the root), but I'm not sure about this. In any case, I don't think it makes a real difference.

    Regarding the point of origin, it is true that it would not be techincally a requirement (at least as long you don't need special options such as reentrancy). You can vote for this if you want that it changed - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-Asynchronous-Call-By-Reference-with-Strict-Stati...

  • Static VI reference

    I dynamically call a VI so I used the call by reference and dragged the inside VI, the question is if I use the reference open VI or not because I fell twice, handmade VI using the reference open VI the call by reference and the path of the VI of wiring and make reference to the second time I forgot the open VI and I just used the call by reference and this has worked exactly like the first time.

    The other question is what happens if I close the VI reference once I open the front panel and run the VI with a property node

    Good questions. The way you have it now, in the excerpts you provided, Admin is responsible at the same time that principal is responsible. Aren't you load dynamically. You call it dynamically in the sense that you use Server VI to do as opposed to a Subvi. In other words, Admin comes in memory once hand comes in memory. Admin does not start running when the hand starts to run if.

    The only difference between the way you did and with the help of a Subvi, it is that with a Subvi, Admin would be booked right hand began to run. The way you, Admin is not reserved or running until it is called, but it is loaded into memory.

    The reason open VI reference is not do anything for you right now, is that the reference is already open. The reason why you'd call the Open VI reference is to get a reference that doesn't already, based on a file path. But since you have a static reference of VI, you already have the open reference, so open VI reference is not give you what you have not already.

    If you want to use the reference node call, you must have a wired type at the entrance of laughing type specifier reference open VI. A type specifier is a special type of reference VI which is only concerned with connector part information, but not of particular witih VI. All VI with the same connector pane could be open in this way. For example, you can use Open VI refers to get a reference pointing to a particular VI, VI, given by the path of the file.

    If I want to use the call by reference that is useful thread reference strictly typed to open VI reference but it is not necessary, is it? because I wire the strictly-typed reference to the call by reference and it worked fine.

    There are two ways to call a VI dynamically. The first is how you did it-using the Run of VI. This does not require a strictly typed VI reference. The second main way is by using the call launched by the reference node. The appeal made by the reference node is different because it uses the information in the connector pane to pass arguments in and out of the VI. To do this, you must have a strictly typed VI reference. It should not be a static reference if - the output of the reference open VI is strictly typed If you pass a type as an input specifier.

    You might think a reference VI containing any or all of the following information: the VI, part of connector info. Therefore,.

    Weakly-Typed reference VI - path of the VI

    Type specifier - connector component Info

    Strictly typed reference VI - path and connector Info pane

    I hope this helps!

  • Are there different types of references to screw? This example needs to be so complicated?

    "Forced Nonlinear Curve Fit.vi" requires some other VI implements the shape of the model must be adapted and requires a reference to this VI as one of its inputs.

    It seems that there are several kinds of references to screw - why? What are they and how do I know which one to use?

    I have attached a vi that the curve fitting with the vi mentioned above, and it also sets up the reference for the other vi that contains the model, also attached. By the comments, I thought that some simple reference pointing to the model VI would be all he needs, but he seems to need a dynamic reference that has been altered by cast to another type of reference vi. At least, if I understand this right.

    Can anyone shine light on it or hit me somewhere useful? Note that I already saw a context-sensitive help to create references to the screws.
    That's where I got my instructions.

    cebailey,

    If you right-click your static VI reference and select strictly "Typ VI reference", then you can connect in the constraint Nonlinear Curve Fit VI.  The VI curve adjustment uses a call by the reference node, which does not accept that strictly type (specific to a given link pane) references.

    Here are some help of LabVIEW on static references to VI:

    http://zone.NI.com/reference/en-XX/help/371361E-01/Glang/static_vi_ref/

    Chris M

  • The image reference

    Hi Expert Vision,

    I just started tinkering with the module Vision and think it's very nice.

    A rookie question I had, with a picture (for example from a grab IMAQdx) reference, I have to connect through all functions, or is permitted to use only the first copy.

    What I really mean is that with normal references the reference itself is constant, and should not be religiously it wire even though all States, etc.

    Please refer to the image that I hope that my request a little more clear. Thank you!

    Yes you are right, it is just a normal static reference. Nevertheless, I prefer always connect via all nodes and use registers with shift on the nodes. Just for cleanliness of code.

    And second thing, beware when wire you the Dst vision Image entry live treatment in this case, the reference to output image is equal to Image Dst. If Image Dst is left unwired, the output image is equal to the Src of the Image.

  • set the configuration of appeal vi for node reference vi call

    As noted in the title someone knows how to set the configuration of appeal vi (load with the appellants, charging for each call, load and store on first convocation) for a vi dynamically loaded via call by reference node?

    Thank you.

    CBR is irrelevant in the present case, since he already receives a VI reference.

    If you use the primitive opening VI refers to open this reference, then the VI will be charged the first time you call the primitive.

    If the VI leaves no memory (and you do not configure it on the way home), subsequent calls to the prim OVR returns the reference to the first VI you have opened. This is equivalent to the load and keep it.

    If you close and reopen the VI reference, it is equivalent to recharge.

    If you use a static reference to the VI, it is equivalent to the load with the appellants.

    Personally, I have all my default subVIs charge with the appellants.

  • Reference queue on a DVR?

    Hi all

    I'm trying to track down a bug in my code without success (so far). I tried to check if my problem is caused by a 'feature' in LabVIEW, while I continue to tear (whats left of) my hair...

    Here's what I do:

    • I create my "lines of communication" in my toplevel vi. This is nameless. My toplevel vi is a queue-based state machine. I use OO by reference. The place where I kept my reference is object > DVR > Cluster > queue reference.
    • With the help of the toplevel.vi I run a user interface. I do this using static reference VI > SetVal passes the value of the object/DVR to the UI, then > Run (wait til done wrong) to start the user interface.
    • And here's the problem: when put an element in the queue of the toplevel state machine using the user interface, it is not received by the toplevel state machine.
    • Here's what I looked at in an attempt to find out what the problem
      • The element is placed in the queue without error
      • The references are valid
      • This I noticed is that when I probed the hexadecimal numbers of reference are different - my understanding created a new reference queue by name would give two different references to the same queue in memory (and so they must be closed). But in my case I just create a reference to the queue, put it in my DVR and remove necessary... so, what are the different values?
      • I already used this same architecture in this project, but in this case I did not have references to queue on the DVR - instead I opened new references by name whenever I shared between modules. It worked well... but I'd rather do not restrucutre my code if I can avoid it!

    If anyone can offer any suggestions that I can check or even if it is a 'feature' that has developed until I'd appreciate your feedback,

    Thank you

    Dave

    I have it... I produced a second reference to queue and too wrote the original - this update the DVR, but not the queue of State machine. Rookie mistake - doh!

Maybe you are looking for