Opening/Closing Queue Reference By Name

I'm curious if opening and closing a queue reference to put information onto the queue, using the queue name -> obtain queue -> enqueue -> release queue(Non Force) is problematic.  I thought i saw a thread a long time ago that opening/closing a reference to a queue over and over could lead to a memory leak, even if the original queue never was released.  Obviously, i'm ignoring the general pass the wire(by value) correct labview way. 
Instead of opening/closing using the queue name i could also wrap the queue reference in a FG after originally creating it and work on the reference that way. Ignoring the "right way to do it" are there still downsides, other than programing correctly, to open/closing queue reference's in this fashion such as memory leaks.

PaulG. wrote:
I have never heard of any unwanted consequences of repeatedly opening and closing any reference. The trick is to make sure a reference gets closed when no longer needed. I don't see any reason not to implement queues the ways you describe. I've done all three and haven't had any issues that I know of. If opening and closing a queue reference repeatedly caused a memory leak that would be considered a bug.
I have to disagree here. A couple of years ago I was using a DAQmx Write with "autostart" option set to TRUE in a loop (ca. 100ms timing) to constantly make sure, that in application standby my Digital Outputs kept the values they ought to have. This reproducibly caused a blue screen on Windows after 6 hours of the program running in standby. As it turned out, LabVIEW was using a new reference to the task for every call of the Write, because with autostart set to TRUE it had to create the task beforehand and close it afterwards. After the mentioned peroiod of time, LabVIEW ran out of reference numbers, as the support explained to me.
Of course, even LabVIEW Help says to avoid using autostart=TRUE with DAQmx VIs in a loop, but only because of the overhead the repeated Create and Clear is consuming. Naturally, I have learned that the hard way now.
So - Create the reference once, use that same reference all the time (FG is fine, I think - I use this method for obtaining my logfile reference all over the place!) and close it only, when you don't really need it anymore.

Similar Messages

  • Queue Reference on a DVR?

    Hi All,
    I am trying to track down a bug in my code to no avail (so far). I wanted to check if my problem is caused by a 'feature' in LabVIEW while I continue to tear (whats left of) my hair out.....
    Here is what I'm doing:
    I create my 'communication queues' in my toplevel vi. These are unnamed. My toplevel vi is a queue-based state machine. I'm using OO by reference. Therefore the place where I've stored my reference is Object>DVR>Cluster>queue reference.
    Using the toplevel.vi I kick off a user interface. I do this by using Static VI reference>SetVal to pass the object/DVR value to the UI and then >Run (wait til done false) to start the UI.
    And here's the problem: when put an element on the toplevel state-machine queue using the UI its not received by the toplevel state machine. 
    Here's what I've looked at to try and find out what the problem is
    The element is placed in the queue with no errors
    The references are valid
    One this I did notice is that when I probed the reference hex numbers they are different - my understanding was creating a new queue reference by name would give two different references to the same queue in memory (and so they have to be closed). But in my case I only create one reference to the queue, put it in my DVR and remove it as needed.......so what are the values different?
    I've used this same architecture already in this project but in this case I didn't put the queue references on the DVR - instead I opened new references by name whenever I communicated between modules. This worked fine......but I'd prefer not to restrucutre my code if I can avoid it!
    If anyone can offer suggestions that I can check or indeed if this is a 'feature' which has come up before I'd appreciate any comments,
    Thanks,
    Dave
    Solved!
    Go to Solution.

    Hi All,
    Please disregard the comments about the reference hex numbers being different - I built a very simple test program to make sure performance was correct and found that it was. In my test code both reference numbers are identical as should be expected! Its a common/garden bug causing my problem not a LabVIEW 'feature'......just gotta find the bugspray now!
    Dave

  • Customer & vender opening & closing balences

    pls  send the customer & vendor opening & closing balenses
    teble & field names
      i am not able to find out that
      pls send any

    [1] Customers - KNC1. Vendors - LFC1
    These table stores total debits/credits for the month.

  • Opening/closing References in TS-engine does not work as expected, so creating memory hooks. Any solutions?

    Hi!
    As my project had grown beyond the point where I could keep a global overview, I tried creating atool that dynamically creates a kind of hirarchy for my TS libraries. It runs quite well for a small test setup, but crashes due to missing memory for the whole project. Any ideas?
    A short description: I do all coding in LV7.1.
    * Firts I open an automation refnum to TS.Iengine and invoke the method 'GetSequenceFileEx' with the path to my main seqfile, Flags = 0 and conflicthandler_Error.
    * Than I use that sequencefile object to invoke the method 'Getsequence' with an index of 0 (assuming this beeing the 'MainSequence').
    * For the returned sequence object I invoke the method 'GetNumSTep', which is fed into a For-Loop. Inside that loop, the very same object reference is used to:
    - invoke 'GetStep' with the loop index
    - with the step object i get some proiperties like Name, some expression and bolean values. If the step 'can_Specify_module', I invoke 'GetDescriptionEx', before the step object is closed (cvlose reference vi)
    - I also invoke 'Parameters' on the step object. The parameter reference is used to access the property 'getLocation', which than is used as lookupString to access the property 'GetNumSubProperties', which I take as number of parameters of that step. Finally the parameters reference is closed
    * The reference to the sequence object is closed after the for loop.
    I fianlly get an array of description for all steps in the sequence file, in the order they are called from mainsequence there.
    This array is used to recursively add a similar subarray for any subsequence call in it, until all calls are resolved (using a while loop that runs until the loop counter reaches the number of steps in the step description array).
    The array is than scanned for 'typical' errors of mine like wrong parameter number at subsequence calls, missing/misspelled subsequences andf so on.
    The LabVIEW execution accumulates more than 1 GB of RAM. LabVIEW itself reports just some 100kB of used RAM. So I assume the difference is RAM used by TS as a child process in LV. What can be done?
    A vi with this code is provided (AS IS!).
    Attachments:
    SeqFileAnalyser.zip ‏192 KB

    Hello Lul,
    I tried out you tool and took a quick look at it and it ran fine. I did notice that LV memory grows during execution but only a few kb with a standard demo from TS (the increase is about the same size as the file being saved at the end). This is expected bahavior since results are being stored in memory during execution. When it is done, my mem goes back to about what it used to be before running. 1 GB of Mem seems to be very very very high! Did you expect it to be like this? How big is your txt file being created? Is the VI you posted exactly what you are using or do you have additinal loops that make the VI run continuosly and save to txt after multiple runs? I did not see any critical issues with your VI but I also did not go into your code in debth.
    As long as you close all your TS references in LV, you should not havbe any mem leaks.
    If you expect big fiole to be created, your PC will use up all RAm then use Virtual mem, the size for Virtual mem can be set in the Control Panel in Windows, usually tough, the system can set it dinamically, this might help you avoid crashe.
    Hope this helps
    Nick

  • Are both "OpenMQ" and "Open Message Queue" correct names for it?

    Hello,
    should I use "OpenMQ" in the product name for a client library for OpenMQ (like 'MyLibraryName OpenMQ Client'), or is it recommended to use the name "Open Message Queue" for some reasons (so it would be 'MyLibraryName Open Message Queue Client"? I am not sure if OpenMQ is an "official" name for it, which I should use to refer to.
    It is a Delphi library, the first public release will be ready real soon.
    Best Regards,
    Michael Justin

    Many thanks for your answer! The library is targeted at Delphi developers, so maybe I will give it a short name and a long name, "MyLibraryName OpenMQ Client" and "MyLibraryName OpenMQ Client for Open Message Queue" for announcements and other places where it should be clear what MQ stands for.
    Best Regards
    Michael Justin

  • When do VI and queue references become invalid?

    Hi all,
    I have a fairly complicated problem, so please bear with me.
    1)  I have a reentrant SubVI (let's call it VI "Assign") that has an input cluster of (VI ref, queue ref) (let's call the cluster type "Refs").  If the VI ref is invalid (first execution), the VI ref and queue ref are assigned values and are passed on as an output cluster of same type.  (The VI does other things too, but for simplicity only this is important.)
    2)  The VI that calls VI "Assign" (let's call it VI "Store") is not reentrant and has a local variable of type "Refs" that is wired to the input and output of VI "Assign".  This VI effectively stores the references.  The references returned by VI "Assign" are always valid right after the call, but after the problem condition described below, they are invalid at the start of all calls before they are passed to VI "Assign".
    3)  VI "Store" is called by multiple non-reentrant VIs, so the local variables of VI "Assign" retain their values (Has been tested and verified to retain their values).  The VI causing the problem in this case is a template VI of which multiple copies are launched (let's call it VI "Template").
    The problem is that the moment an instance of VI "Template" is closed, the queue reference becomes invalid, although the actual variant value of the reference remains the same.  The VI ref can become invalid or not, depending on small changes, but is always reproducible.  I assume there must be some similarity between VI and queue refs.  After spending some time researching, the Labview help states for the Open VI Ref component "If you do not close this reference, it closes automatically after the top-level VI associated with this function executes."  In this case I assumed it means that the moment the reentrant VI "Assign" finishes, the references will get cleared ??  So I made a non-reentrant VI (let's call it VI "NR Assign") that only assigns values to the references and VI "Assign" now calls this VI (It effectively does what I described VI "Assign" does).  I keep this VI alive by using it in a VI which never terminates and since it never terminates, the references should never become invalid.  Anyone still following?  This didn't solve the problem though.  If I reproduce the same scenario using only one instance of the template VI, it works just fine.  Furthermore, the VI and queue references are never closed, to aid analysis of the problem.  Can anyone shine some light on what happens when a template VI terminates?  Could this be the problem?
    Unfortunately I cannot include the code.
    Thank you whoever is able to make sense of this.
    Christie

    Christie wrote:
    Hi all,
    I have a fairly complicated problem, so please bear with me.
    1)  I have a reentrant SubVI (let's call it VI "Assign") that has an input cluster of (VI ref, queue ref) (let's call the cluster type "Refs").  If the VI ref is invalid (first execution), the VI ref and queue ref are assigned values and are passed on as an output cluster of same type.  (The VI does other things too, but for simplicity only this is important.)
    2)  The VI that calls VI "Assign" (let's call it VI "Store") is not reentrant and has a local variable of type "Refs" that is wired to the input and output of VI "Assign".  This VI effectively stores the references.  The references returned by VI "Assign" are always valid right after the call, but after the problem condition described below, they are invalid at the start of all calls before they are passed to VI "Assign".
    3)  VI "Store" is called by multiple non-reentrant VIs, so the local variables of VI "Assign" retain their values (Has been tested and verified to retain their values).  The VI causing the problem in this case is a template VI of which multiple copies are launched (let's call it VI "Template").
    The problem is that the moment an instance of VI "Template" is closed, the queue reference becomes invalid, although the actual variant value of the reference remains the same.  The VI ref can become invalid or not, depending on small changes, but is always reproducible.  I assume there must be some similarity between VI and queue refs.  After spending some time researching, the Labview help states for the Open VI Ref component "If you do not close this reference, it closes automatically after the top-level VI associated with this function executes."  In this case I assumed it means that the moment the reentrant VI "Assign" finishes, the references will get cleared ??  So I made a non-reentrant VI (let's call it VI "NR Assign") that only assigns values to the references and VI "Assign" now calls this VI (It effectively does what I described VI "Assign" does).  I keep this VI alive by using it in a VI which never terminates and since it never terminates, the references should never become invalid.  Anyone still following?  This didn't solve the problem though.  If I reproduce the same scenario using only one instance of the template VI, it works just fine.  Furthermore, the VI and queue references are never closed, to aid analysis of the problem.  Can anyone shine some light on what happens when a template VI terminates?  Could this be the problem?
    Unfortunately I cannot include the code.
    Thank you whoever is able to make sense of this.
    Christie
    All LabVIEW refnums do get deallocated automatically when the top-level VI in whose hierarchy the refnum was created goes idle (stops executing). You will have to make sure that the creation of a refnum is done inside a VI hierarchy that stays running for the entire time you want to use that refnum.
    Rolf Kalbermatter
    Message Edited by rolfk on 06-27-2007 11:52 AM
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Query regarding Opened/Closed GL periods

    Hello Gurus,
    ive got an issue, when using 0FIGL_C01 Cube.
    The query ive created balances on cumulative balance (as key figure) and GL account names (as hierarchy).
    Now i want to show the data of cumulative balance regarding closed periods.
    I.e. if we have current April month the balance should be 0, but all other in the past January, February, March should be displayed.
    How it is possible to do this?
    Ive tryed to create a calculated key figure, whith code something like:
    IF debit and credit == 0 then Cummulative balance=0 else Cumulative balance.
    It works fine but it shows also the postings of current period, which isnt realy closed.
    Tried to search the indicators of FI open/closed periods, but the only thing i found is S_ALR_87003642 - Open and Close Posting Periods transaction showing Company code, GL account ranges and from to period data.
    What could be the sollution for this? Should i create new DS for the mensioned TC and then to create a multicube or perhaps is a better and faster way in doing it?
    Thanks a lot in advice
    Laurynas Prikockis

    Hi Shrikant,
    >
    Shrikant Varma wrote:
    > Yes, I could consider using belnr selection to reduce the size of the selection. This will again be a selection more
    > based on knowledge of application(of course with fine tuning of packet size).
    >  But then this approach will not be as efficient and as easy as letting database take control of the iteration of this
    > huge dataset - as is intended by the use of cursors with the help of packet size.
    >
    I'm not sure what you mean here: "let the database contorl the iteration of this huge dataset - with cursors".
    Generally speaking you have 2 options when it comes to parallel processing:
    Parallelize processes in the ABAP stack. These processes access different, non-overlaping, parts of your restult set
    in parallel. Using the BELNR could be an approach to build different, non-overlapping paackages.
    Database side parallelization. This is possible for every action that uses multiblock I/O (full table scans and index fast full scans) and for partitioned segments. For non-partitioned segments and single block I/O database side parallelization is not possible.
    So, generally speaking, you have 3 options:
    1.) parallelize in ABAP and build idependent packages
    2.) force the DB to do multiblock I/O (full table scan, index fast full scan) in parallel
    3.) partition your table and indexes.
    I think (it's just my opinion) for an ERP (not BW / BI) system
    - option 3 is not a good option for OLTP systems (several reasons). I see it very, very, very rarely or close to never in OLTP systems
    - option 2 may read (much) more data then you would need to read, although a very efficient I/O method would be used (multibock I/O)
    - option 1 requires programming in ABAP but will read exactly the data you need to read and can be controlled very well in the ABAP stack (parallel single block I/O will be used)
    In alamost all cases (that are similar to your case) i have see option 1 was used.
    Kind regards,
    Hermann

  • Closing ActiveX references correctly in Simple UI

    Hi,
    I am currently trying to modify the Simple UI provided with Teststand 2013 in order to access global station variables through LabVIEW.  As a simple test, I am trying to access the LastUserName value.  When I run the VI for the first time after opening LabVIEW, I get no error messages and the program runs as required.  Stopping the VI execution returns no errors, but when I try to run the VI and run the Teststand sequence again, the execution stalls and I get a waiting status.  I must then close the VI execution by killing all Teststand threads  I believe the PropertyObjects are not released properly and I find the event structure quite puzzling to deal with.
    My attempt at closing the references within the while loop looks like this : 
    The rest of the program is exactly as provided with Teststand 2013.
    Any input on how to properly close the ActiveX references and retrieving station globals within LabVIEW would be much apreciated.
    Thank you for your help,
    Christian
    Solved!
    Go to Solution.

    First of all, I would like to thank you for your answer.
    I understand that repeatedly opening a reference inside the while loop does not represent a viable solution.  This morning I found a very handy reference that explains how to pass data from the Teststand API through custom UI user messages.  This allows a more elegant and robust way of handling data that is retrieved from Teststand.  I'll use a custom event call back that will trigger on any custom message.
    Here are the references ( which are IMO clear enough for someone with very little LabVIEW experience) : 
    http://www.ni.com/white-paper/4532/en/
    https://decibel.ni.com/content/docs/DOC-21047
    So far, I have been able to create a dummy Teststand sequence that sends a custom UI message containing the string ''Hello, world!''. The UI can accordingly retrieve the string and display it in a dialog box.
    I still have to find a way to pass the data from the subVI to my UI.  I am investigating the use of global variables, but there may be a better solution that I am not aware of.  Any input on how to pass information between two active VIs would be much appreciated!
    Christian

  • Limit Values in Open/closed Activities of BP Page

    Hi,
    On the BP overview page we have views displayed for 'Open Activities' and 'Closed Activiities'. By default they would display all open/closed activities. After a while this can become a lot (and slow, and not very useful).
    So, there is a view (CRMV_ACC_1O_CUST) where we can customise the time frame of activities that we wish to see. Our problem is that none of the time frames there are useful to us.
    We can choose, 'This Year', which is useless in January or we can choose, "Last Year', which is useless in general. What we can't choose is, 'From last year until today'. That would, of course, be entirely useful.
    The entries in the customising table take the form Y-1, Y A, Y1 etc and these formulae are translated at run time to an actual date range. This is hard coded in a CASE statement in FORM build_the_query of Include LCRM_BSP_OIC_1O_SEARCHF01 so changes can only be done as a repair.
    The way the standard works is that Y+-1, if run on date 20120126, will return the date range 20110101 - 20111231. This means that we won't see any open activities from January. Y A, which means current year will return the from date as 20120101, which means that we won't see open activities from December.
    I read about the BAdI CRM_BP_UIU_BT, which would allow us to inject our own selection parameters; but I can't seem to work out which parameter names should be used for activity start/end dates. Pushing 'STARTDATE', 'FROM' etc result in an empty activities table being displayed.
    What I would like, of course, is that Y+-1 would return 20110101 - 20120126 when executed on 20120126. Or to create a new entry such as Y*1 which would mean one year either side of the given date. I can make a repair to the standard code, but I'd rather not have to perform a repair to write my own logic for dates range.
    Any other ideas? I assume we're not the only people using the 'Open Activities' view; how did the rest of you handle January?
    Thanks for your time,
    P.

    Hi,
    We got an answer from OSS;
    For your business requirement, in order to set up a time frame option
    like 'last 12 months', you need to extend the customizing table:
    "CRMT_ACC_1O_CUST". You can define your own time frame as below.
    I will provide a sample for it:
    ***********************Creating Time Frames***************************
    1. Go to Tx: SE16.
    2. Enter the table TSCTFGROUP.
    3. Create new records here with the following details:
    (Please ensure that you enter a sort order that doesn't already exist)
    APPL NAME TIMEENTITY LENGTH DEF FLAG SORT ORDER
    CRM_1O_LOC M+ - 12 <blank> 14
    4. Go to Tx:SE16.
    5. Enter the table TSCTFGRT.
    6. Create new records here with the following details:
    (This table is to create the text. Please ensure that you create here
    as many records as you have created in the above step 3)
    LANGU APPL_NAME TIMEENTITY LENGTH TF_TEXT
    EN CRM_1O_LOC M+ -12 last 12 months
    7. If needed, enter the same records in other required languages also.
    After this, time frame 'last 12 months' will be visible in the selection list. Now You can select this time frame in the SPRO customizing for certain business transactions. But above changes are not standard changes If you upgrade CRM landscape to higher versions/packages, you will have to transport these changes manually.
    That was the answer, we've done as was suggested and things are fine now.
    You can have a programmer look at
    Include: LSSC_RULESF03
    Form:  compute_dates_f
    To see how the formulae are translated at runtime.
    For instance, you'll see that you can create an entry such as D365, which means 365 days before until 365 days after today. However, in the code there is no way for M or Y* to be translated; a programmer can explain that to you if required.
    I hope that this helps someone at some point,
    Patrick.

  • Use of "Open FPGA VI Reference" function --- Build Specification vs VI vs Bitfile

    When using the "Open FPGA VI Reference" function in a LV2012 cRIO application, there are 3 options: Build Specification, VI, or Bitfile. What would be the reasons for selecting one over the others? Does it affect the resulting startup.rtexe when the cRIO application is built? I searched through the help and in these forums, but I don't see criteria for selecting one over the others; maybe I missed it.

    Hello Chris,
    Apologies in advance for a long reply.  
    The reference method won't change the functionality of your rtexe.exe.  They all end up dropping a bitstream, based on a bitfile, onto the cRIO's FPGA.
    To a degree, the method used to reference the FPGA code is a matter of taste, but there are situations where one method is better suited than the others.
    Reference by VI:
    Setting the configuration options to open reference by VI is helpful during development when you are making changes to an FPGA VI often and building/testing using the same spec.  When this option is used, a bitfile is selected based on the default build specification for the project.  A project may have only one default build specification.  You can make any build the default by checking the option under the Source Files category in the build properties.  The default build is indicated in the project explorer by the green box around the builds icon.  
    Reference by Bitfile:
    This option references a bitfile directly.  Through the configuration window, you can select one specific bitfile to open a reference to (this is not dynamic and does not change unless you physically go make a change to that path).  If you're using this method, it helps to give your bitfiles more meaningful names than the ones that are automatically generated by LabVIEW.  When you run subsequent compilations off of the same build specification and do not change the bitfile nname or path in the build configuration, the old bitfile is overwritten and replaced with the new one.  When you are using this option, it is critical that you keep up with which bitfile is the one you want to be using.  There is an option now that will help alleviate any problems referencing by bitfile through the Open FPGA VI Reference function.  There is a new VI called Open Dynamic Bitfile Reference.  It is typically used when you want to chose a specific bitfile to load depending on something in your host code (a configuration option etc) - but it allows you to dynamically reference a bitfile on the block diagram by path.
    Referency by Build Specification:
    This option is good for when you want to always use a bitfile that is associated with/compiled with the same build configuration.  Say you have two options for top level FPGA VIs in your project (each with its own build spec).  Both of these VIs have the same interface (read/write controls, DMA) but they run different algorithms or something.  This is nice because you can easily switch your host application between them by picking the build spec associated with the FPGA VI you want to use.  In this type of sutation, referencing by VI is no good because you can only have on default build spec.
    cheers.
    Matthew H.
    Applications Engineer
    National Instruments

  • Error opening file/URL reference by alias and Administrative limit exceeded

    Hello All,
    Problem:
    SMTP Error: 4.5.0 error opening file/URL reference by alias
    and
    Search failed with: netscape.ldap.LDAPException: error result (11); Administrative limit exceeded
    Here is my configuration:
    Windows 2000 server (without Active Directory)
    SP4
    Iplanet Messaging Server 5.2
    Netscape Directory Server 4.16
    IPlanet Messaging Server 5.2 Hotfix 1.09 (built Jan 7 2003)
    We have a group which we use to flash messages to all the users of the mail server. Till last week it was working fine but now I am not able to send messages to this group <group-name>.
    There are around 800 (Eight Hundred) E-mail id the messaging server and the flashed message is supposed to go to all 800 + users.
    Note: I have another group of 300 users and I am able to send an E-mail to this group of 300 users.
    I am using Dynamic Group for Members list.
    The error message I get while trying to send message to this group is
    SMTP Error: 4.5.0 error opening file/URL reference by alias.
    The corresponding error in mail.log file is
    30-Jan-2004 10:55:21.40 41c.7e4.1098 tcp_intranet J 0 <group-name>@domain rfc822; <group-name>@domain domain (localhost [127.0.0.1]) 452 4.5.0 error opening file/URL referenced by alias: <group-name>@domain
    Now when I construct and Test the LDAP URL from Console, the error I get is:
    Search failed with: netscape.ldap.LDAPException: error result (11); Administrative limit exceeded
    I have increased the various limits but I still get the same error when I send mail to that group or do a LDAP Test:
    The deafult and new limits are:
    Sizelimit: Default 2000 New 10000
    Timelimit Default 3600 New 3600
    Lookthroughlimit Default 5000 New 6000
    The corresponding error entry in access log of slapd is:
    30/Jan/2004:12:19:26 +051800] conn=34 op=213 RESULT err=11 tag=101 nentries=0 etime=2 notes=U
    My search for Administrative limit problem and error opening file/URL error in Sun forum and other groups did get some hits but that did not solve my problem.
    I will appreciate any suggestion/comments.
    Thanks and Regards,
    Maneesh Bisht

    Thanks Jay.
    My problem has been fixed.
    Your suggestion was to increase the lookthrough limit. As you would have noticed in my posting that I had increased this limit to 6000 but that did not solve my problem. Today I increased this limit to 10000. And after that I did not get "administrative limit exceeded" error. Also I do not get "error opening file/URL reference by alias" error while sending E-mail to a particular group of 800+ ids.
    Regards,
    Maneesh Bisht

  • Opening a VI Reference from an Application

    I have a VI that calls "Open VI Reference".
    When I'm developing, its not a problem to generate the path, I just point at the path where the VI is located.
    When I build an application, what the heck is the path to the VI?

    LabVIEW can't figure magicallly which VIs you'll call dynamically to include them in the application. That is why you have to add them yourself as "Dynamic VI" in the application builder. It is a one time procedure and may be tedious at most but not painful...
    When you add a VI as Dynamic VI in the AB, the VI and its subVIs are included in the application internal LLB so you do not have to specify the subVIs in the list.
    Labviewguru suggested to include the dynamic VIs on the diagram of a loader VI (set as Dynamic VI in the AB). It is true that all subVIs will be automatically included but you will find the procedure as tedious as selecting them in the AB.
    About the Dynamic VI path in a built application, the good news is that you don't have to care
    at all. When opening a VI reference from a VI path, the server first looks in the application internal LLB (where are stored dynamic VIs) to search for a VI having the same name. If one is found, the actual path is ignored and the internal VI is opened. Thus you can leave the same path you used in LabVIEW development to build an application calling Dynamic VIs.
    Including a LLB as support file won't have any effect on the application. The LLB will simply be copied as is in the destination directory so unless you build dynamic VI paths to this exact location, the VIs won't be found.
    Error 7 means that the VI specified in the path was not found neither in memory, in the internal LLB nor at the actual path. Unless I'm mistaken it also occurs when you attempt to open the front panel of a VI which FP hasn't been saved. By default the AB do not save the FP of dynamic VIs, you have to change this setting manually when required.
    LabVIEW, C'est LabVIEW

  • The buttons in main the vi get locked after opening a vi reference in a subpanel and using buttons within the subpanel.

    I am trying to open a reference to a vi in the subpanel of the main vi. However after the vi opens in the subpanel and after pressing a few buttons in the subpanel the buttons in the main vi get locked, i.e. I can't even close the main vi or control anything else. Is there any way how I can avoid this happening?

    > The buttons in main the vi get locked after opening a vi reference in
    > a subpanel and using buttons within the subpanel.
    >
    > I am trying to open a reference to a vi in the subpanel of the main
    > vi. However after the vi opens in the subpanel and after pressing a
    > few buttons in the subpanel the buttons in the main vi get locked,
    > i.e. I can't even close the main vi or control anything else. Is there
    > any way how I can avoid this happening?
    This is most likely happening because in either the top or sub panel,
    there is an event structure that is queuing events, and is set to lock
    the panel until the events are handled, and because of the logic in the
    diagram, the events aren't being pulled from the queue.
    So, you have a deadlock. You are waiting
    on the panel. The panel is
    waiting on the diagram. And the diagram is waiting on something else.
    So, if there are indeed event structures involved, determine where in
    the diagram things are delaying. Also, if you do not need the panel to
    lock until the event is handled, you can change the setting in the
    events dialog on the structure. But the events will still be queued
    until the diagram starts executing.
    Greg McKaskle

  • Mini-Nugge​t Creating Typedef'd queue references

    Transfering typedef'd data using queues used to be tedious if the typedef changed and the transfering queue reference is passed between VI's using controls. The tedious part was updating all of the controls for the queue ref since they would not be linked to the typedef of the data the queues transfers. This Nugget exaplains how to create a queue ref that is tied to a type definition.
    1) Drop an obtain Queue
    2) Create, drop, and wire a typedef of the data that will be transfered by the queue.
    3) pop-up on obtain Que output and select "Create Control"
    4) Find created control and pop-up to select Advanced >>> Customize
    5) In control editor use the control palette >>> "Select a Control ..." and browse to the typedef from step #2
    Note:
    A) The typed must be dropped on the pink boxes
    B) The marching ants around the queue ref control confirms you are dropping in the correct location.
    6) Save the queue ref control as a type def.
    If you look at your hiearchy you will see that the typedef'd queue ref is using the type def from step #2.
    I hope this helps!
    Ben
    * This works in LV 8.6 but not in LV 7.1. I am not sure in which version the feature was introduced.
    Message Edited by Ben on 11-11-2008 02:21 PM
    Ben Rayner
    I am currently active on.. MainStream Preppers
    Rayner's Ridge is under construction
    Solved!
    Go to Solution.
    Attachments:
    Drop_Obtain_Que.JPG ‏19 KB
    Drop_n_Wire_Typedef.JPG ‏21 KB
    Drop_TypeDef_in_Control.JPG ‏41 KB

    That sounds about right.  I started doing this about LabVIEW 7.0 when I started using single-element queues for reference objects.  I always used the "create control, customize, save" method for creating the strict typedef reference, since it did not update correctly by itself in 7.0.  There were a lot of changes made in 8.0, some of which resulted in some fairly nasty crashes and hangs on type propagation (always modify your cluster with nothing else open in 8.0).  These were fixed in 8.2.  At this point, type propagation seemed to work OK.  However, I have been through a lot of versions of LabVIEW and have learned never to trust my memory on things like this.  Try it.  If it works, you are good .
    This account is no longer active. Contact ShadesOfGray for current posts and information.

  • CC14, all files open with asterisk in file name.

    CC14, all files open with asterisk in file name, need to save or cancel to close file. Is there a way to change that?

    No. It happens to any InDesign file. I created a new file in CC14, saved, closed, opened and it had the asterisk.
    If it is a time synchronization, how do I correct that?

Maybe you are looking for