Opening LabView VI's from a LLB

Hello,
I am currently trying to connect my newton Andor Shamrock camera and access the VI's so that I can use them in my LabVIEW program.
The readme software directed me to the LLB directory, in which I found all the applicable VI's for the camera. However, when I try to open them, a dialogue box appears directing me to find various files in the "Shared Library". Canceling this dialoge box allows the VI to still open, however the block diagram show ? and blanks where the icons of the camera's VIs should be.
Is there a way for me to access the VIs in the LLB Manager list or do I need to secure them from a separate source?
Thanks,
Justin
Solved!
Go to Solution.

Just a few names would be sufficient to give us a better idea. You can do a ctrl+h and hover over one of the missing subVI with the mouse and the missing filename will show in the context help.
LabVIEW Champion . Do more with less code and in less time .

Similar Messages

  • How can I enable Windows Explorer (Windows 7 64 bit) to open LabView 8.2.1 LLB files?

    How can I enable Windows Explorer to open LabView LLB files? I am running LabView 8.2.1 on Windows 7 64 bit. The option “Enable Windows Explorer for LLB Files” in Tools/Options/Environment is unchecked and grayed out.

    LabVIEW until 7.1 came with a shell extension that could display the content of an LLB in an explorer window.
    That was removed in LabVIEW 8.x for  a number of reasons.
    - Shell extensions are pretty badly documented, tricky to implement right, and of very limited use since only Windows Explorer and a few explorer replacements can use them. It doesn't add any functionality for most other programs in Windows, since the shell extension are a Windows Explorer thing, and not a Windows core technology.
    - With 8.x NI decided that LLBs were pretty old fashioned and their main feature of supporting file names longer than the DOS 8.3 naming was pretty much obsoleted by then, while they didn't allow for more than one level of directory hierarchy. So they decided to depreciate LLBs and declared them a legacy technology that should not be used for new development anymore.
    - For the uupcoming 64 bit version of Windows a new shell extension would have been required to allow Explorer to use it.
    For all these reasons the LLB shell extension was removed from the LabVIEW installation to further discourage the use of LLBs.
    If you have a LabVIEW 7.0 or 7.1 installation on your computer and run 32 Bit Windows you can enable the shell extension in the LabVIEW Options dialog.
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Open file in excel from labview

    I need a way to open an existing Excel file, that may or may not be open already.  I am using the attached "Open Specific WorkBook.vi" from the examples.  My LabVIEW program must be able to either open a specifc Excel workbook and worksheet even if it is already open.  Is this even possible, or would it be better to close it (if open), the open it again?
    Attachments:
    Open Specific WorkBook.vi ‏37 KB

    As you probably know, nothing "bad" happens when you open Excel if it's already open, it just doesn't come to the front of your LabVIIEW ap. To get it to the front, Minimize the Excel window then immediately Maximize it (or Normalize it) programmatically with a PN.  I have tried many of the other methods (but not all of them) to no avail, this works for me. There may be a more elegant solution.
    There are other known methods to bring an ap to the front, with callbacks etc, but they can be clunky, or require Userlib32, etc. Since this property node already exists in your ap, it's comes at little expense.
    Of course, you may want to check that the ap was open before you do this, but even that is optional, at the expense of a little flashing on the screen.
    Richard
    Attachments:
    windowState.gif ‏4 KB

  • Labview 8.2 close or crashes when opening up Test Exec. from labview 5.1

    Why  would Labview 8.2 close or crashes when opening up Test Exec. from 5.1? Labview 8.2 begins to load the Test Executive VI, then, stops and closes labview altogether.  I remember getting it to load before but do not know what could be causing this?  I am tasked with updating the old code from Labview 5.1 to Labview 8.2.1; actually Labview 8.5, since it is the latest.
    Thanks, Mike

    Dennis,
    Thanks for the response.  The odd thing is that I am able to open some of the subvi's.  And I've opened the test executive before.   Now, during the initial loading of the Test Executive, there are some drivers that are not executable by Labview 8.2.1 (i.e.  ni-daq cards.... for MIO and DIO boards).  Could that be it?  I would expect the program to load but not run.  I have gotten the program to load before, so I am confused by it not loading now.  Thanks for the tip on Labview 8.5 as I was ultimately going to that version, too! 
    My ideal situation would be to load all drivers ( including Traditional Ni-daq and Ni-VXI 3.3.1, etc) and run this program using Labview 8.5 or 8.2.1 on an XP platform.  This original program was created in Labview 5.1 and Windows NT.  Any help and suggestions would be appreciated.
    Thanks for your help,
    Michael

  • 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

  • How to open labview program with Quit Labview function inside?

    Hi Any idea how to open labview program with  Quit Labview function inside?
    I forgot to add and set the condition of the type for this program.
    If the program is an application, it would close straight away.
    If it is still labview work, it will go straight to editing program without closing.
    So I need to recover, open it and make some changes.
    Clement
    Solved!
    Go to Solution.

    Put the VI in a project and open it from there, then it shouldn't autorun. You can use App.kind property of application to decide whether to close or not.
    /Y
    LabVIEW 8.2 - 2014
    "Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
    G# - Free award winning reference based OOP for LV

  • Tdms-files: Is it possible to prevent LabVIEW and DIAdem from creating .tdms_index files?

    Hello,
    is it possible to prevent LabVIEW and DIAdem from creating .tdms_index files when opening/creating/editing a .tdms file?
    I think I have no benefit from the .tdms_index files because our applications create a lot of little .tdms-files (repeat measurements). With the additional .tdms_index files we have unnecessary memory consumption and it takes longer for Windows to open the containing folder. Also it´s confusing when searching for a certain file.
    Best Regards
    Daniel
    Solved!
    Go to Solution.

    Hi Baui,
    I'm afraid there's a direct way to disable creating .tdms_index file now from LabVIEW and DIAdem. You can use TDMS Advacend API in LabVIEW, which doesn't create any index file, or you can just make some simple programming and delete the .tdms_index file after closing the TDMS file. 
    This is a request for a long time, we'll consider to add this feature for TDMS in future releases.
    Yongqing Ye
    NI R&D

  • Some errors when calling LabVIEW VIs Interactively from DIAdem

    Hi! I'm having some trouble using the "Calling LabVIEW VIs Interactively from DIAdem" found on:
    http://zone.ni.com/devzone/conceptd.nsf/webmain/1A98AB48E35D913086256E23004E6A22
    Following the troubleshooting section didn't resolve the issue. I
    recompiled and built the exe (DIAdemLabVIEW.exe) for version 7.1.1,
    which I am developing on. But still I got the same error message, after
    a waiting for about a minute, on a diadem popup window:
    Error in <MenuAdd...ctDo.vbs (row:1, column: 1)
    Error in <addmenuentry.vbs (row:14, column: 3)
    ActiveX component can't create object.: 'DIAdemLabWIEV.Application'
    Using the llb's and exe's that was included with the installer worked
    flawless, with the exception that LV 7.1.1 vi's didn't appear on the
    popup window(DIAdemLabWiev.vi). So I tried to recompile and build for
    the 7.1.1, with this result.
    I'd be very grateful for fixes or solutions for this problem!
    Regards
    Roger Isaksson

    Brad, thanks for the reply! Below is my (correct?) modification of your script. Have I got it right?
    Dim lvapp, vi, viPath, paramName(1), paramVal(1)
    Set lvapp = CreateObject("LabVIEW.Application")
    viPath = "C:\TEMP\Test.exe"
    Set vi = lvapp.GetVIReference(viPath)
    vi.FPWinOpen = True
    paramName(0) = "In Name"
    paramVal(0)  = "In Value"
    paramName(1) = "Ut Name"
    Call vi.Call(paramName, paramVal)
    Call lvapp.Quit()
    MsgBox "Parameter1 Value = " & paramVal(1)
    I am not sure about the format of the <paramName(0) = "In Name">.
    The control name is "In" and is a I32, the name for the indicator is
    "Ut" and has the same storage type as the control.
    Running the script gives an error in line 4, that is the <Set vi =
    lvapp.GetVIReference(viPath)>. I'll attach the exe and the error
    message.
    I have another question regarding the relatively large amount of RAM
    that diadem uses for export from my labview application to diadem. More
    than 10 times the size of the data is required for exporting to diadem.
    Since our application use relatively large files, actually up to
    several GB's, this soon becomes problematic. See the attached picture
    of the memory usage after exporting a 10MB segment (contains 42
    channels of measurement data). Your help in these matters would be
    appreciated!
    Regards
    Roger Isaksson, Damill AB
    Message Edited by Roger Isaksson on 09-09-2005 10:22 AM
    Message Edited by Roger Isaksson on 09-09-2005 10:22 AM
    Attachments:
    VBError.JPG ‏181 KB
    Test1.vi ‏9 KB

  • Running Datasocket in labview 2013 open labview runtime engine 7.0

    Hello All,
    I am trying to communicate with a COGNEX camera using Labview 2013. I am using Datasocket to read tags from cognex OPC server.
    but when I open labview and run the code for the first time. An installer will automatically pop up trying to install labview runtime engine 7.0.
    When i cancel the installation datasocket throws an error. Again if i run second time, datasocket works fine and communicate with cognex camera using OPC.
    This problem comes everytime I open labview and run the datasocket. I cancel the installer. second time onwards when i run the code everything works fine.
    This is actually annoying and i doubt how things will work when i make an executable. 
    Need help. 
    Is this due to datasocket version installed... how to resolve this.
     

    Hi phil,
    That is interesting that you were unable to find the offending key that the installation is having trouble with.  Do you have Administrator privileges on your computer? You may even want to try to log in as the actual Administrator itself to make sure that you have access to all of the proper registry keys.  Also, I was going to say that I do think you're right with Windows XP not having the Scanreg/fix function, but there are several free programs that you can download as registry checkers.  You may want to try one of those to see if you can find the key and give it the proper permission.
    As far as the other part of your question, the Run-Time Engines are very important for LabVIEW to be able to run, but the 7.1.1 Run-Time Engine should not be affecting a LabVIEW 8.2 installation as it will use the 8.2 Run-Time Engine.  One thing that you can do is go into your Control Panel under Add or Remove Programs>>National Instruments Software and you can try and repair/modify your Run-Time Engine there.  If you already have the 7.1.1 Run-Time Engine on your computer, this is where it will show up so you can make any changes you want.  Also, if you go to www.ni.com and click on "Drivers and Updates" on the right, you will be able to find the Run-Time Engine there that you will need, but I would definitely try using a downloadable registry checker first before attempting to change any of the software that is currently on your computer.  As stated in the Knowledgebase article, this is actually an error from Windows saying that the registry key does not have the proper permission settings, so I am reluctant to say that downloading the new Run-Time Engine from our website will help much.  Please try some of these suggestions out and let me know how they work out for you. Thanks!
    Regards
    Noah R
    Applications Engineering
    National Instruments

  • Cannot open Labview 7 without "not enough memory" error

    I get the "not enough mempry to complete this operation" as Labview is opening. I have tried uninstalling everything and reinstalling. No good. There is 512 Mb in this system should be plenty to open Labview. Any ideas? Labview will also not open a vi. It says it cannot find it (the one I selected for it to open). It tries to load it and all subvi's but cannot get past the first vi.

    I figure there are two possiblities. LabVIEW is poorly installed on your system causing the error or your VIs are corrupted. You can test the former by installing LabVIEW on another computer. If you can open the VIs there, consider contacting NI for ways to more throughly remove NI products from your machine. To test the latter, see if you can create new VIs in 7, save, close, and reopen them. You can also see if other VIs on your machine open. If your VIs are corrupted, then try to open them in your older LV, copy the Block Diagram over to a new VI, save, and open in LV 7.0. At the very least, you can get a screen shot of the diagram.
    Good luck!!

  • Open a secondary Vi from a principal Vi and run all together

    Hello!
    I have to different applications,two different Vi. One of this, the principal Vi have to run all time. I want to open the secondary VI from the principal, use it and close it.......but the principal don't have to stop any time.....
    Is possible to do this? I've tried to use the secondary Vi as a suv VI but the principal VI stops until secondary finish. How i havw to do this? Which is the best way?
    Thank you very much
    Merry Christmas to all you!!!!
    Larson

    Either place it in its own loop, where it won't stop the rest of the VI, or call it dynamically.
    To do this, you need to place on the diagram an Open VI Reference, followed by an Invoke Node (both from the Application Control palette) and wire the VI reference into the invoke node. Then, select the Run VI method in the invoke node and wire F into Wait Until Done. This will make the node run the VI and return immediately. You may need to place another node to open the FP of that VI. Note that if you want to build this into an application, you need to explicitly include this VI in your build. Search for information and tutorial regarding "VI server" to learn more about calling VIs dynamically.
    To learn more about LabVIEW, I suggest you try searching this site and google for LabVIEW tutorials. Here and here are a couple you can start with. You can also contact your local NI office and join one of their courses.
    In addition, I suggest you read the LabVIEW style guide and the LabVIEW user manual (Help>>Search the LabVIEW Bookshelf).
    Try to take over the world!

  • Can LabVIEW download files from the Internet? I know the URLs of the files.

    Can LabVIEW download files from the Internet? I know the URLs of the files.

    Hi bmihura,
    I'm not sure what you what to do - download or open URLs - but I've put together the attached VI.
    I hope it is of some use.
    Charlie Rodway
    Test Design Engineer
    Rolls-Royce Controls and Data Services Ltd
    Attachments:
    WebBrowser.vi ‏21 KB

  • Opening LabVIEW source code

    Hi,
    This year LabVIEW celebrates its 20th birthday. A development environment that started from a virtual instrument development tool has grown into an outstanding general purpose visual programming language. Troughout LabVIEW history it has beeen debated if LabVIEW is a general purpose programming language or not. It defenitely is a general purpose programming language but maybe not as general as it could be. Every LabVIEW power user knows that even though LabVIEW has very many outstanding features, it also have very many shortcomings not present in the main stream programming languages and development environments.
    Requirements for LabVIEW functionality keep raising as the number of LabVIEW users constantly grows. During the history of programming we have seen that it indeed is quite challenging to develop an excellent programming language. All the most popular languages are developed as a joint effort of the computer science community. This ensures that the design decissions made are in agreement with the state-of-the-art techniques of the present time and that all the possible shortcomings are considered when these design decissions are made.
    LabVIEW as a proprietary programming language doesn't have the power of the computer science community. It may be extremely hard to recruit the best minds of the community to work exclusively for National Instruments already for purely geographical reasons. As a result NI presumably cannot keep up with the pace required to keep LabVIEW a high quality general purpose programming language. Until now NI has had central pantets protecting graphical design of LabVIEW. The most central ones of these patents have expired or are soon to expire leaving the field of graphical programming languages open for competition.
    From this perspective it would be very wise move from National Instruments to open the source code for LabVIEW programming language and releasing the patents protecting the language for the use of the community helping to develop LabVIEW. National Instruments should see this more as an opportunity than a threat.
    Opening the source for LabVIEW would gather new free-of-cost developers for developing LabVIEW. LabVIEW would improve and gain more reputation as a general purpose programming language. Students and computer scientists arount the world would get acquainted with LabVIEW as the barrier of expensive licenses wouldn't be there. LabVIEW has many features that are expected to be in a future general purpose programming language as natural support for multithreading. However it lacks many features that are required from a future general purpose programming language. As an open source language, LabVIEW could develop towards a generally accepted programming language of the next decade.
    As the LabVIEW user community grows, also NI could take advantage of its expertise in LabVIEW integration. The growth of LabVIEW user community means that the number of pontential customers for National Instruments measurement and automation products grows and NI can take full business benfit from it. NI can still sell proprietary Measurement and Automation software and hardware for integrating the NI hardware with LabVIEW, managing measurement data and managing other measurement and automation related tasks. Only LabVIEW as a general purpose programming language would no longer be a source of income. Still NI could go on selling development environment for LabVIEW.
    Open LabVIEW would also open new opportunities to NI. It could benefit from its expertise of software and hardware integration in the field of embedded computing. The embedded computing is growing fast as every device around us gains a microprocessor. If LabVIEW would be used as a general and most popular programming language for embedded computing, it would allow NI to sell number of new products and solutions to this embedded computing industry.
    Open soruce LabVIEW is an opportunity for the LabVIEW community, for the computer science community in general and last but not least for National Instruments. LabVIEW community get improved general purpose programming language with all the state of the art techniques and functionality. Computer science community gets the opportunity to start developing programming techniques and paradigms for visual programming and this way solving the shortcomings of text-based programming languages bringing the programming for everyone. National Instruments would gain major advantages from LabVIEW becoming generally accepted programming language. The increasing user base would get NI a number of new potential customers and opportunity to start selling new kinds of products and solutions. On the other hand, if NI will not open LabVIEW source and tries to keep its monopoly, I predict that it may be hard to keep up with the recent developments in programming language technology. General purpose programming languages will evetually offer all the benefits of LabVIEW and much more. NI will lose it's position not only in LabVIEW but also as a provider of measurement and automation hardware.
    I'd like to hear what you, the community, think of this issue.
    Regards,
    Tomi
    Tomi Maila

    I must say that I disagree with this idea.  One of the very fundamental -- and important -- aspects of LabVIEW is its internal consistency as well as its wide applicability.  Having been an "old lline" Unix hack, I know the message and promise around open source; however, I also know the incredible shortcomings that have come out of many of those initiatives.  We run our deployed product in Windows, as a develped LV app precisely so that I have a consisten, intuitive programming environment.  All of my development headaches throughout the life cycle of this product have come not from LV code but from the limitations of text-based code developed outside of the LV environment -- entities that have to be included via DLL calls and such.  That all works well enough but, when there are profound changes to those outside development environments, it greatly hampers the ability to maintain and expand the legacy code.  I have spent many days and weeks having to rewrite VB and VC++ code so as to make for easier integration and upgrading capability.  In particular the shift -- on Microsoft's part -- from WMP6x to later incarnations, forced a complete rewrite of some important multimedia components.  Similarly, changes to the <vector> class with the move to Visual Studio Net forced similar problems.
    Open source still holds great promise but also great peril.  Too many cooks really can spoil the broth at times.

  • Is there a way to open a new window from the "Go" menu in Mavericks?

    Before Mavericks, I was able to go from the Finder to the top menu "Go" -> "Utilities", or Applications or Home… and a new window would open.
    Now I have to manually open a new window to avoid loosing my existing window.
    Is there a way to open a new window from the "Go" menu?

    Before Mavericks, I was able to go from the Finder to the top menu "Go" -> "Utilities", or Applications or Home… and a new window would open.
    Now I have to manually open a new window to avoid loosing my existing window.
    Is there a way to open a new window from the "Go" menu?
    First, as others have already stated.....make sure the checkbox is deselected for "open folders in tabs instead of windows" in Finder Preferences.
    If you're like me and don't like tabs very much, there is a way to make folders always open in windows with a simple click (I'm using Mavericks 10.9.5).  Go to a root folder (for example, the Documents Folder), open it, and select View > Hide Toolbar, then all folders within that root folder will open in a new window.
    As an alternative method, any folder can be opened in a new window by holding down either Command Key while clicking the folder. But sooner or later you will forget to hold down that key, and then clicking on a folder will open in a tab (which will automatically resize the window and cause much aggravation).
    The Hide Toolbar trick will also work with any folder present on the Desktop. It will make all folders inside that folder open in new windows.
    To make the Applications Folder open in a new window when opening it from the menu bar at the top of the screen, you will have to open the main hard drive folder and use the Hide Toolbar trick. This will cause all folders inside it to open in new windows.
    Hope this helps.

  • When I open a pdf document from my dropbox to view it, the document shows up blank, even though it is filled out. This also happened with pdf documents that have been e-mailed to me.

    When I open a pdf document from my dropbox to view it, the document appears blank, even though I know the information is actually there. This also has happened with pdf documents that have been e-mailed to me, then opened to view and they are blank?? Why are they showing up blank?

    When I open emails with PDFs I click on the attachment (doing this all on my iPad) it gives me the option to "open in iBooks", I accept then after that the document is sucked into my iPad but I can't do anything with the PDF after that.  Where is the actual file on my iPad? Why can't I email or send these PDFs to my cloud (Dropbox)?
    It's like once they go into iBooks they're stuck forever.

Maybe you are looking for