Jump to content

bpreis

NI
  • Posts

    17
  • Joined

  • Last visited

    Never

Posts posted by bpreis

  1. QUOTE (Omar Mussa @ May 16 2008, 03:18 PM)

    The 'Additional Installers' feature would work much better if you could force it to point to a specific NI Installer file -- otherwise you can get stuck with it asking for 'Device Drivers May 2006' and you are pretty much SOL if you don't have that exact version (you can't just point it to May 2007, etc.

    We're considering* an improvement to the Locate Distributions feature. The improvement we're considering might* work something like this: In the example of DCD May '06 vs. DCD May '07, if the system detects that the original distribution by which the part was installed is May '06, we will ask for that, but now the user will have an opportunity to tell us they don't have the original distribution, at which point we'll ask for an alternative distribution that 1) had been installed on the system at some point and 2) is known to contain the exact same missing part (which could be DCD May '07 in this example). You might* be able to try this feature if you're a beta member, possibly*.

    *Use of safe language intentional so as to avoid volcanoes, earthquakes, and otherwise violent reactions from the gods.

  2. The Additional Installers list is built from files found in C:\Program Files\National Instruments\Shared\MDF\Manifests. The xml files there represent the additional installers and their dependencies.

    The fact that your Additional Installers page is missing some installers, like the LabVIEW 8.5 RTE, would suggest that the files representing those installers are not present. But since you found those installers in the ProductCache folder, I'd expect there to be a file in the \Manifest folder as well.

    I recommend going to Add\Remove Programs> National Instruments Software, then select all and press Repair.

    -Bob

    QUOTE (PalamarTM @ May 15 2008, 05:27 PM)

    When I try and create an installer it claims that three of the required run time installers do not exist on my system. It is requesting the 8.5 Run-Time, DAQ-mx 8.6 and Sound Vibration Run-Time. Additionally I know I also need the TDMS installer as well. But my list of "Additional Installers" does not seem to be filling out properly. It only contains the LabVIEW 8.0.1 Run-Time Engine, LabVIEW 8.2.1 Run-Time Engine and LabWindows CVI 8.1 Run-Time Engine. I know I should have more and a quick look in the ProductCache folder shows the following directory listing with MSIs in all of the important ones that I checked.

    Directory of E:\Program Files\National Instruments\Shared\ProductCache

    CVIRTE [8.1.1]

    lv80rte

    mkl700

    NI Certificates Deployment Support [1.01.49153]

    NI LabVIEW RealTime NB-FIFO [8.2.1]

    NI LabVIEW RealTime NB-FIFO [8.5.0]

    NI LabVIEW Rutime Engine [8.2.1]

    NI LabVIEW Rutime Engine [8.5]

    NI License Manager [3.2.1027]

    NI Logos XT [4.9.0]

    NI Logos [4.9.0]

    NI MDF Support [2.51.87]

    NI Service Locator [8.5]

    NI Sound and Vibration [6.0]

    NI TDMS [1.1.0]

    NI Uninstaller [2.51.87]

    NI USI UFF58 Plugin [2.2]

    Even a look at the "Software" section of MAX shows that I have the LabVIEW Run-Time 8.5.0 installed. Any thoughts on how Installer gets its list of installed components? I'm not real interested in doing another full install of LabVIEW DAQ-mx, SV Tools, and DIAdem just to get my installer to recognize them.

  3. QUOTE (Cat @ Apr 9 2008, 09:50 AM)

    Bad Form! Replying to my own post...

    I finally figured out I can add my whole executable directory to the project and then the individual files are available to add to the installation. Hopefully this works...

    Cat

    While that does work, you might run into trouble later wrangling new support files into the installer build spec. New support files could be produced by rebuilding your exe if it links to additional dependencies in the future. Something you might want to try is assigning a unique folder name to the Support Directory in each exe build spec. You can do this on the destinations page, clicking Support Directory and changing the default folder name from "data" to something else.

    Alternatively, you could try putting each build spec into its own unique parent folder so that the data folder contents from your exe builds won't have a chance to collide when adding them in the Installer Builder.

  4. QUOTE (Aristos Queue @ Apr 25 2008, 01:13 AM)

    All structure nodes provide an opportunity for threads to yield. That bit of yield is all that is necessary to give the Open VI a chance to finish registering the new VI.

    I believe the wait functions (Wait Until Next ms Multiple and Wait ms) wired to zero are another, slightly more intuitive way, to do this. It had a few practical uses in LV RT.

  5. QUOTE (orko @ Apr 7 2008, 12:05 AM)

    As far as the whole "template/tookit chooser" that I'm trying to accomplish, I was also wondering if someone at NI would have had some insight on the mechanisms used internally to create new target projects (like the RT/PDA target projects that are created on the fly after their wizards finish). Are those just using VI Server calls to the Project API to create new projects in memory based on the user's choices in the wizard? That was my plan of attack for this custom project creator that this is turning out to be. :)

    It's just VI Server calls to the Project API to add files, however, it's a little more complicated when adding targets. You might find resource\Framework\Providers\lvdesktop.llb\PC_New.vi useful. Pass it your project reference and the project's "Root" reference (to the "Item" input). The "BehaviorGUIDs" input allows you to restrict the displayed results. The RT and PDA project wizards for example would use known BehaviorGUIDs so that the dialog only presents supported target types. I'm not sure how liberal we are about giving out GUIDs and such and I unfortunately don't have a list of all the possible BehaviorGUIDs anyway, but some other LV person (or PSE) who trolls here might be able to help you more with that particular input. ;) After invoking that VI, you should be able to continue operating on the project refnum by adding files to your new target with VI Server. If you're dealing with shared variables, be aware that much of their VI Server interface is private, but there is a primitive VI-based API in vi.lib\variable\* that might help.

    Good luck!

  6. QUOTE(venkatesh @ Dec 30 2007, 11:24 PM)

    I am getting this error(see the attachment) displayed, when I try to use the functions in Measurement I/O.

    I am using Labview 8.01 professional Development Suite.

    Help in resolving this issue.

    Regards,

    J.Venkatesh

    Hi J. Venkatesh,

    I viewed your attached error message: "Error loading 'nilvaiu.dll'. A dynamic link library (DLL) initialization routine failed." Unless this is related to the Application Builder or Installer Builder features of LabVIEW, you might have better luck posting this topic to a more relevant LAVA category.

    Did you build an executable or installer with a VI that requires this DLL? From your description, it sounds like this error dialog occurs when you simply drop a Measurement I/O VI on the block diagram.

    -Bob

  7. I'd start by changing the batch file to

       echo on		 pause		 register.vbs		 pause

    to verify that your vbs actually runs and see what the call to register.vbs is returning

    QUOTE

    Maybe you need to browse inside the batch/cmd environment to the installed location. or include the directory in the Path.

    I think Ton is on to something here. It's possible register.vbs is not being called at all if the current working directory is different from the install directory. In that case you should try:

       echo on		 pause		 cd "%1"		 register.vbs		 pause

    and modify the Installer Build spec to pass "[iNSTALLDIR]" (with quotes) as a command line argument. %1, %2, etc is the syntax used to access command line arguments passed to a batch file.

    -Bob

  8. You can try the /u parameter, but I didn't see any support for it when looking at some internal references. Also if you don't have access to the setup.exe file for some reason after installing, this wouldn't work.

    Another thing you could try is installing a shortcut file configured to launch Add/Remove programs. It's not ideal but it saves you some mouse clicks.

    QUOTE

    • Right-click on your desktop
    • Choose "New" then choose "Shortcut"
    • In the command line that appears type (or paste) control.exe appwiz.cpl
    • Give it a name (whatever you like)

    • Click "Finish" and you're done

  9. Hi Staffan,

    The behavior you're seeing is expected and is documented in the 8.5 readme (readme_AppBldr.html). Basically lvlibs are not treated like containers in app builder, starting with 8.5. As to why that decision was made, I'm not sure, but I do know it's intentional.

    QUOTE

    In LabVIEW 8.5, LabVIEW application builder no longer treats libraries as folders. If you load a LabVIEW 8.0 or 8.2 build specification in LabVIEW 8.5, and it includes a library in which you did not explicitly include all members of the library, only referenced members of the library might be included in the build.

    Workaround—Set the inclusion individually on all members of the library you want to include in the build. Alternatively, uncheck Remove unused members of project libraries on the Additional Exclusions page.

    I don't think this is related to the problem Justin was seeing, but if you happen to encounter more installer builder problems after applying the workaround mentioned above, feel free to post a followup to this thread. Thanks.

  10. Justin,

    Sorry for the delay - got a lot on my plate atm ;) . I downloaded your sample project and saw exactly the symptom you described. However, I noticed that when I delete the exe build spec from the Destination View of the Source Files page of the installer build spec, then re-add it, the tree information is re-populated correctly.

    post-153-1189474729.png?width=400

    It's only after I click OK (closing the build spec editor) and re-open the build spec when I see the bug appear. It's messed up in the same way on all subsequent loads.

    post-153-1189475549.png?width=400

    Another weird thing I noticed was that even though only one of the files appears to be incorrect in the UI, the XML seems to tell a different story - seems that both Write Numeric.vi files have the wrong FileTag

    post-153-1189478668.png?width=400

    I'm still investigating, but wanted to let you know I'm on the same page ;)

    -B

  11. So if I understand everything,

    • You started with an exe build spec, which builds correctly.
    • Your first pass through the installer builder lets you add files on the source files page, but the icons are all wrong in the project view, while the files all look correct on the destination view.
    • After closing and reopening the build spec, the source file page has deteriorated further - icons are still messed up in the project view and the destination view now has completely wrong file information
    • After all this, the installer builds fine and installs fine, but there are files the exe cannot find that happen to belong to classes (and an lvlib?)

    I'd agree those xml tags look wrong, like we somehow switched up the files when gathering information from the UI.

    Do you have a set of steps or files I could use to recreate the exe and installer build specs to reproduce the problem? Ideally, I'd like to make an exe, which hoses my installer builder source files page like what you've shown in the screenshots. I suspect it'll cascade into similar problems from that point on. Sounds like one key to this puzzle is to use classes and possibly an lvlib in the exe build spec. Let me know if you have more specifics on how to get into this state. Thanks.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.