Giga_labview.llb

I'm trying to download the giga_labview.llb file from http://zone.ni.com/devzone/cda/tut/p/id/3625#toc1 but I get a connection time out error. Is there any other safe place to download from?
I want to learn how to handle large files and how to display large data sets...
Thanks,
mrsound

The NI site was undergoing maintenance yet again this weekend (frankly, it seems like a monthly occurrence). So, that's probably why you were having problems downloading it. I had no problems downloading it this morning, so just try again - it should work.

Similar Messages

  • What is the eaisest way to convert an LLB to new labview version?

    I have an insturment driver LLB that is a total mess now.
    It started out as a LV 5.11 LLB
    I am working in LV 8.5 now and LV 8.5 will not open code written in LV 5.11 (Too old)
    I have tried to mass compile it in LV 8.2 but I still am running in to VI's in the LLB that are too old for LV 8.5 to open.
    That means they are still in LV 5.11.
    Do I really have to open each and save every single VI in the LLB in LV 8.2 to be able to use it in LV 8.5? 

    Dennis Knutson wrote:
    I was able to mass compile it. I did notice that you did not include the hp34970u.llb. Did you point to this during the mass compile. Also, this llb is long obsolete. There is a nice, modern 8.5 project style driver available as well as a plug and play driver. Why do you even need to convert this?
    I have mass compiled it with out errors too, but it seems like it was not really compiled as I still keep running into vi's in it that were still in 5.11.
    I have a decade (or more) of 5.11 code that I am maintaining and upgrading when I have a chance.
    Production test is still coding and deploying LV 5.11  
    I have tried the newer version of the 34970A driver but it is missing some of the vi's that many of our 5.11 codebase uses so is is not a drop in replacement for upgrading code.
    Here is the "u" llb too, I forgot to attach last time
    Message Edited by RTSLVU on 03-10-2009 01:12 PM
    Attachments:
    hp34970u.llb ‏21 KB

  • Problem with NIReport.llb\Print HTML Report using IE.vi on different machines

    We have 5 machines here in our workgroup which have the same state regarding security patches and other system updates. We recently found out that there is a problem with the NIReport.llb\Print HTML Report using IE.vi on the different machines.
    If I would open the VI on MachineA the control could be loaded. If I would open the VI on MachineB the control could be loaded. If I would copy the VI from MachineB to MachineA and open the VI the control could not be loaded. If I would copy the VI from MachineA to MachineB and open the VI on MachineB the control could be loaded. MachineB could load the version from MachineA and MachineB but on MachineA only the own version will load. I have seen that both versions have the same GUID for the Microsoft Webbrowser but are different in some other aereas.
    Since printing HTML Reports is part of the application which will be distributed as application I want to know if someone else have seen such a behaviour or has got problems distributing an application.
    Also I want to know which additional information is stored in an Active-X container about the control beside the GUID.
    We have Win XP Prof SP2 with MS IE 6.0.2900.2180 on all machines in the workgroup.
    Waldemar
    Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
    Don't forget to give Kudos to good answers and/or questions

    Hi Tom,
    this is the VI <vi.lib>\Utillitiy\NIReport.llb\Print HTML Report using IE.vi copied from a machine that can load and run the VI and it will print. On this machine the control in the VI is white.
    This VI will give the "Control could not be loaded" message on my machine.
    The file shdocvw.dll is 2006-10-23 16:18 size 1.460 KB and I verifyed that both machines have the same version of this file.
    Waldemar
    Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
    Don't forget to give Kudos to good answers and/or questions
    Attachments:
    Print HTML Report using IE.png ‏11 KB

  • Quirk, Open VI Reference and LLB

    I found a strange quirk opening a VI Reference (on a PXI).  The "normal" method of doing this is to Open Application Reference (to find the remote site) then to Open VI Reference with the path to the desired VI.  Darren Nattinger pointed out (in 2006) that you can use just the name of the VI, provided the VI is on the same folder or LLB as the current VI.
    Caveat -- this behavior is present in LabVIEW 7.0 (I'm maintaining some "legacy code").  I suspect it will be present in later versions, but haven't (yet) tested it.
    Quirk 1 -- if the VI in question has been downloaded (or deployed) to the remote site, and hence is in memory, then the "path" information isn't used, only the VI name.  Thus if you have a path "C:\ni-rt\startup\MyVI.vi" specified in the Open VI Reference, but have absolutely nothing in the startup folder on your PXI, but have "deployed" your Project, this call will work, even though the "path" part of the argument is not valid.  Useful when testing.
    Quirk 2 (and the "real" reason for this post) -- if the VI is embedded in an LLB, it depends on whether or not it is a "Top-level" VI or not.  Suppose the path is C:\ni-rt\startup\MyLib.llb\MyVI.vi.  Consider two VIs in this LLB -- TopLevel.vi and SubVI.vi (where TopLevel is at the top level of the LLB, whereas SubVI is not).
    Case A -- the LLB has actually been downloaded to the remote site.  Doing an Open VI Reference, with either the full path or just the VI name, works, whether or not you are calling TopLevel or SubVI.  Nothing surprising here.
    Case B -- you are taking advantage of Quirk 1, and have not actually put the file on the Remote site (i.e. there is nothing at the path specified).  You have, however, downloaded the LLB to the Remote.  Doing an Open VI Reference with SubVI, whether with full path or just VI name, works fine.  However, trying to open TopLevel fails, with Error 7 (File Not Found), whether using full path or VI name.
    Summary -- Quirk 2 is that Quirk 1 has a quirk if the VI being referenced is a top level VI in an LLB.
    [My apologies if this is common knowledge -- I failed to find this behavior documented, but may have overlooked something].

    Bob Schor wrote:
    I found a strange quirk opening a VI Reference (on a PXI).  The "normal" method of doing this is to Open Application Reference (to find the remote site) then to Open VI Reference with the path to the desired VI.  Darren Nattinger pointed out (in 2006) that you can use just the name of the VI, provided the VI is on the same folder or LLB as the current VI.
    Caveat -- this behavior is present in LabVIEW 7.0 (I'm maintaining some "legacy code").  I suspect it will be present in later versions, but haven't (yet) tested it.
    Quirk 1 -- if the VI in question has been downloaded (or deployed) to the remote site, and hence is in memory, then the "path" information isn't used, only the VI name.  Thus if you have a path "C:\ni-rt\startup\MyVI.vi" specified in the Open VI Reference, but have absolutely nothing in the startup folder on your PXI, but have "deployed" your Project, this call will work, even though the "path" part of the argument is not valid.  Useful when testing.
    Quirk 2 (and the "real" reason for this post) -- if the VI is embedded in an LLB, it depends on whether or not it is a "Top-level" VI or not.  Suppose the path is C:\ni-rt\startup\MyLib.llb\MyVI.vi.  Consider two VIs in this LLB -- TopLevel.vi and SubVI.vi (where TopLevel is at the top level of the LLB, whereas SubVI is not).
    Case A -- the LLB has actually been downloaded to the remote site.  Doing an Open VI Reference, with either the full path or just the VI name, works, whether or not you are calling TopLevel or SubVI.  Nothing surprising here.
    Case B -- you are taking advantage of Quirk 1, and have not actually put the file on the Remote site (i.e. there is nothing at the path specified).  You have, however, downloaded the LLB to the Remote.  Doing an Open VI Reference with SubVI, whether with full path or just VI name, works fine.  However, trying to open TopLevel fails, with Error 7 (File Not Found), whether using full path or VI name.
    Summary -- Quirk 2 is that Quirk 1 has a quirk if the VI being referenced is a top level VI in an LLB.
    [My apologies if this is common knowledge -- I failed to find this behavior documented, but may have overlooked something].
    This will likely not apply at all to >= 8.0. LabVIEWs Open VI Reference will now distinguish cleanly between absolute path and just the VI name itself. If you use just the VI name the VI needs to be in memory or for a built application included in the app. The quirk about VIs in the same LLB as the currently active VI sounds very strange to me but it may still work.
    However if you specify an absolute path, Open VI Reference will bark with an error if the VI can not be found at that location or if the VI already loaded in memory with that name has not the same absolute path. This is supposedly to make it very hard to create cross linking even when using VI server.
    Rolf Kalbermatter
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • VI Reference in a LLB

    Hello,
    Just a quick question from someone who is fairly new at using LabVIEW...
    I am trying to create a VI reference, and I am using the "Open VI
    reference" VI (built in). How do I reference a specific VI that is inside
    a .LLB file? I am opening the reference from a VI that is NOT in the same
    LLB. Thanks in advance.
    -Matt

    > Just a quick question from someone who is fairly new at using LabVIEW...
    >
    > I am trying to create a VI reference, and I am using the "Open VI
    > reference" VI (built in). How do I reference a specific VI that is inside
    > a .LLB file? I am opening the reference from a VI that is NOT in the same
    > LLB. Thanks in advance.
    >
    You need to have a path to the VI. LLBs are valid elements of paths, just
    like directories. If you need to construct a path, you can use one of the
    constants in the File palette, Strip Path to remove elements of a path,
    and Build Path to add elements to the path.
    Greg McKaskle

  • Error 10 when building app with Report Generation _wordsub.llb in the project.

    Error 10 occurred at ABAPI Dist Copy Non-VI Files.vi -> ABAPI Dist Build LLB Image.vi -> ABAPI Copy Files and Apply Settings.vi -> SDBEP_Invoke_Build_Engine.vi -> SDBUIP_Build_Invoke.vi -> SDBUIP_Build_Rule_Editor.vi -> SDBUIP_Item_OnDoProperties.vi -> SDBUIP_Item_OnDoProperties.vi.ProxyCaller
     This is the error I get when a set up _wordsub.llb to use of report generation in a build project.

    Dave,
    thanks for providing me with this information. I didn't hear about this error in the past, but I found a KB, that possibly can help you debugging the application: http://digital.ni.com/public.nsf/websearch/AF12BB5FAC27FE2186256F9400619C84?OpenDocument
    Let me know, if it helped you out
    Stefan
    Impossible is nothing - nothing is impossible

  • Error 1003 occurred at Open VI Reference in Dist Copy Non-VI Files.vi- Dist Build LLB Image.vi- Dist Build App Image.vi- Build Application.vi

    When trying to build  an application using labview 7.1 and windows XP,  I get the error
    Error 1003 occurred at Open VI Reference in Dist Copy Non-VI Files.vi->Dist Build LLB Image.vi->Dist Build App Image.vi->Build Application.vi
    I've tried the crtl-shift-run as well as  a mass compile and I still get the error.
    Any ideas?
    Thanks,
    Mike

    Hopefully this thread, or this KB article might help.
    It seems like this could come from a lot of things, but there's suggestions in those which might lead you in the right direction
    Message Edited by Day on 09-22-2006 02:07 PM

  • Porblems with built application, using wordsub.llb

    I am trying to compile a Vi that uses the New Report.vi to create a test datasheet. When I run the Vi in development mode, it works ok. When I run it after using the "build application" fucntion, the vi gives an error (Code 7). The description for the error says something about the "open vi reference". I believe the error has something to do with the "word" related vi's that are contained in the wordsub.llb.
    Does anyone know what I am doing wrong?
    Is it something with the build process?

    Are you using LabVIEW 8.0 or later?  If so, the instructions for building an executable are incorrect...they state that you must add _wordsub.llb as a Support File, but you should actually add _wordsub.llb\Word Dynamic VIs.vi as a Dynamic VI when building the executable.  Also, if you are calling any Excel-specific VIs, you would need to add _excelsub.llb\Excel Dynamic VIs.vi as a Dynamic VI as well.
    Try this out and see if it works...we are planning on changing the documentation for the toolkit for the next release to indicate the different steps you need to take for building an executable with Report Generation Toolkit VIs in LabVIEW 8.0 versus previous versions.
    -D
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

  • Can I programmatically copy vi within llb AND build an application?

    I previously posted the question how to programmatically work (copy, delete) on files within llbs and got two answers to use the librarian vis in vi.lib > utility > libraryn.llb
    That works really good but only till I try to build an application. The application builder seems to use the librarian vis also and complains that it cannot build an application with vis that are currently in use...
    Any idea how to solve that?
    Cheers, Daniel Troendle

    Make a copy of all the VIs used by the librarian and save them under a
    different name (making sure to link the sub-VIs to the new name of course.
    Awkward, but it should work.
    Shane
    D. Troendle schrieb in Nachricht
    <[email protected]>...
    >I previously posted the question how to programmatically work (copy,
    >delete) on files within llbs and got two answers to use the librarian
    >vis in vi.lib > utility > libraryn.llb
    >
    >That works really good but only till I try to build an application.
    >The application builder seems to use the librarian vis also and
    >complains that it cannot build an application with vis that are
    >currently in use...
    >
    >Any idea how to solve that?
    >Cheers, Daniel Troendle
    Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)

  • How can I provide information in which llb a vi is located?

    Hi,
    I have several llb's with many vi's supporting my application. On my development computer, LabVIEW "knows" which vi is located in which llb and finds them automatically. When I copy all these llb's to another computer and open a vi which needs vi's from other llb's, LabVIEW asks for the location of these vi's. Saving the vi's afterwards will store the location information, but for somebody who doesn't know the contents of all the llb's it's a frustrating task to search for the right location first. Is there a way to take over information in which llb each vi is located? I don't want to use one large llb only.
    Thanks in advance,
    best regards,
    Gabs

    If you are still in the development stage you can either put your libraries in 'user.lib' or go to Tools>Options>Paths>VI Search Path> and add your directory of libraries with a \* at the end (NB. You need to unselect 'Use default' first).
    I think this should work - let me know if not please.
    Kim
    NB. The above is based on LV 6.0

  • How to add a LLB as a file to a project?

    Hello,
    I will add a LLB as a file to a project.
    If I add the LLB into the project explorer the LLB will be include as a folder and not as a file.
    I found the following description on the NI homepage:
    You also can add an LLB to a project as a file. If you add an LLB as a file, the VIs in the LLB do not appear in the Project Explorer window.
    Right-click the target or a folder under the target, select Add File from the shortcut menu, and use the file dialog box to navigate to the LLB you want to add.
    Select the open folder icon labeled VI with a single period to the right and click the Select button.
    But when I navigate to the LLB, I don't have an icon labeled VI.
    Have anybody an idea or can check this please?
    greetings
    Sascha

    So Sacha, you should probably add a vi inside the llb and then manually edit the .lvproj file..... (or wait until the not too distant future, is the not too distant past)
    Ton
    Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
    Nederlandse LabVIEW user groep www.lvug.nl
    My LabVIEW Ideas
    LabVIEW, programming like it should be!

  • Error 1003: Running a VI inside LLB from EXE

    HELP!
    I have a Labview Executable which is using some "plugin drivers" provided as LLB. The drivers are loaded dynamically with "Invoke Method: Run VI". My Exe does not contain any dependency to those driver LLB's. The LLB build projects are build with vi.lib. "Disconnect type def" and "Remove unused polymorphic ...." are both unchecked. Everything worked for a while without any problems. I had one driver which is using GMath:Interpolate 1D. Now I have a second driver which is using "Interpolate 2D". Those 2 driver VI's won't load at same time. It is really strange but if I disable one, the other will load. If both are active I get error 1003 indicating that some VI is not able to run mostly because of missing dependencies. I faced that message a lot in the past but this time I don't know what else to do. I tried several combinations of building the LLB's and the exe, even included those dynamic VI's into exe but all time same. I have less hope that someone here can help me but I give it a try.
    BTW, is there any chance to debug and see the exact reason why my VI won't load. When I breakpoint at "Invoke Method: Run VI" i will see that it returns 1003 but can I find out more?

    I have seen this happen as well in my application's plug-in architecture. It happened with a pair of different DAQmx Read VIs in our case. I filed CAR 285388 against it. It is currently under investigation. I will put the information about your issue in the existing bug report.
    Right now I don't know of any workaround.
    Jarrod S.
    National Instruments

  • LV crashes while loading my llb, but the built app. functions correctly???

    I�m hoping someone may understand the cause of the LabVIEW crash I�m experiencing.
    LabVIEW 6.1 crashes and Windows 2000 says, "LabVIEW.exe has generated errors and will be closed by Windows" when I try to load an llb by clicking on the top-level vi from within LabVIEW or when opening the llb from outside LabVIEW. It crashes while loading particular sub-vi�s of the llb. If I try to load the offending subvi�s directly, I also get the same crash. If I build the llb into an application, the build goes smoothly and the resulting application functions correctly. If I use a �splash screen� approach and do not load the offending sub-vi�s (by not opening vi references to them), they load-up fi
    ne when the top-level vi loads and then I am able to edit and re-save any vi of the llb including the offending sub-vi�s. I�ve tried re-saving the llb as a separate development distribution and still get the same crash behavior. I�ve also tried saving the offending sub-vi�s to separate files outside the mother llb (after getting them open with the splash screen approach) and I get the same crash when I open these files. If I save one of the offending sub-vi�s as a separate llb, I can�t get it open even with the splash screen approach. I�ve loaded the latest video driver for my Dell Inspiron 8100 laptop and I get the same behavior on a Dell Dimension 8200 desktop that is also running Windows 2000 (Version 5 SP4). There are 110 objects in my llb that includes *.vi�s, *.rtm�s, and *.ctl�s.. Any ideas as to why/how this is occurring and how I can fix it? Is this a known 6.1 bug that is fixed in 7? Any info would be greatly appreciated. I�ve included my splash screen like loader, f
    or what it�s worth. Thanks.
    Attachments:
    __loadVIs.vi ‏88 KB

    Thanks for responding. Your understanding is correct. Mass compiling was one of the first things I tried (although I failed to mention it). I also un-installed and re-installed LabVIEW. It crashes during mass compiling of the full llb, although the vi that it appears to be working on when it crashes is not an �offender�, i.e. I can open that vi fine. The crash during mass compiling is the same crash, i.e. Windows says it had to close LabVIEW because it generated errors.
    I�ve attached one of the offenders. It is missing many of it�s sub-vi�s so you�ll have to hit �ignore vi� a bunch when opening it. (The llb of it is ~2.6 MB. I thought that might be too big/rude to post.) This vi crashes LabVIEW upon mass compile or upon opening it (after hit
    ting �ignore subvi� a bunch).
    I was going to attach an llb of another smaller offender, but in the process of editing it to be a little prettier and better documented, the problem kind of vanished for that vi. The main routine still crashes when I mass compile the full llb, but now I can open some of the old offenders without incident. I still can�t open the main routine directly as it crashes LabVIEW. Thanks for your time.
    Attachments:
    aveParam.vi ‏769 KB

  • In saving a viWhat's the difference as a .vi verses .llb?

    Most of the .llb programs I pull up have .vi's attached or they are shelled within the .llb. I am trying to make a copy of a program I've written that includes multiple sub-vi's. I would like the copy of the program to include all sub-vi's without having to save a copy of each individual vi seperately. Any help will be greatly appreciated. Thanks in advance!

    Select With Options and choose Development Distribution to create an llb with all subVIs except vi.lib files. You can then use the Edit VI Library option under the Tools menu and make your main VI Top Level. If you plan on making this distribution the master, you should be aware that source code control programs don't really handle llb files.
    The llb was originally created as a means to get around the old limitation of DOS file name lengths.

  • What are the limits of an llb library file

    After much review and some experimentation of the different types of LV library files, I am planning on using multiple llb type libraries to contain groups of vi's for an extensive testing application (multiple deployments)
    Driving reasons are:
    1) based on info obtained in this forum, calling an item in an llb loads only that item while calling an item in an lvlibp packed library loads the entire package of files
    2) appears source control will be simpler with an llb
    3) vi's are compiled into a single container vs. just a list of files in a sub-folder like lvlib libraries so visibility (or lack thereof) and security are improved
    4) by using the llb files, I can make mods to the system and have a much smaller executable to deploy and if I make a change to an item in an llb file, I don't have to recompile the entire executable
    However, LV help doesn't explain very well what can and cannot go into an llb file.  In one instance, I was looking to contain all files associated with a particular pc of hardware since 1) it rarely changes, 2) it provides a single source for everything I need to interface with that hardware item wherever I need it.
    I attempted to add a dll file and it appears I cannot do it.  Can I just drag files into the llb file manager or do I have to implicitly add them when saving from the specific vi or ctl file.  If that is so, I guess that guides me as to what files can be added to the llb, just ones you can open and save in LV.
    Seems though, if you can include a dll in an executable, why not a library file.
    Thanks for any thoughts on this, confirming or countering what I am seeing.
    Doug
    Doug
    "My only wish is that I am capable of learning each and every day until my last breath."

    OK, so change compiled to packaged.  I understand that an llb is not a compiled file but rather a container that for my purposes, keeps the individual files from being end user accessible.
    Wasn't sure about the ability of adding a dll file because, as I states above, the LV help does little to explain what can and cannot be included in an llb.
    My reason for NOT wanting to use a packed library is that (and this IS in the help file) when you call on one item in the library file, everything contained in the packed library loads.
    My ultimate goal is to be able to utilize small pcs of my application as needed based on part number of the units being tested.  Each part number has a specific test sequence. There are dozens and soon to be hundreds of different part numbers and I don't want to have all that load when I only need one at any given time.
    For reference, if I build my entire application with all support and sub's today, I end up with an exe well over 20 meg and my IT doesn't give me rocket ship computers for production testing.
    The core application will be the exe and I will call the code required for the part number dynamically. Once that code loads, it will stay loaded until the next part number and normally run from several hours to several days.
    I had also considered OOP but that seems to be way overkill for what I am looking to do.  
    Hope this makes my desired path a bit clearer.
    Doug
    Doug
    "My only wish is that I am capable of learning each and every day until my last breath."

Maybe you are looking for