Labview version, OS version from within a VI?

How can you determine the version of Labview running and the OS version
running (on a Windows box) from within a VI? Do you need to invoke the WIN32
API? or is there a VI component that provides this?
Any help appreciated,
Marty Burns

Works Great! Thank you very much!
Marty
"Dave Langstaff" wrote in message
news:1042727744.276154@dyfi...
> Marty Burns wrote:
> > How can you determine the version of Labview running and the OS
> > version running (on a Windows box) from within a VI? Do you need to
> > invoke the WIN32 API? or is there a VI component that provides this?
> >
> > Any help appreciated,
> > Marty Burns
>
> The VI you want is the PropertyNode vi.
>
> Bring up your diagram and right click to get the vi palette.
> Go to the 'Applicaion Control' sub-palette.
> Drag a 'Property Node' vi onto your diagram.
> The properties you need are:
> OperatingSystem|Name "Windows Me"
> OperatingSystem|Version Number and "4.90"
> Appli
cation|Version Number "6.1"
>
> Hope this helps
>
> regards
>
> --
> Remove "spamkill." when replying to this message
>
>

Similar Messages

  • Help in converting to newest labview version (from v 5)

    Hi,
    i noticed that people do get their files converted to the latest version, so i was hoping to get some help
    the file is attached 
    thanks in adnvance 

    Mass compiled in 8.2.1, which you can open with anything newer.

  • Opening pdf Version of User Manual from Within Aperture 3

    In Aperture 2, I could open the pdf version of the User Manual from the Help Menu. I've downloaded the pdf version of the Aperture 3 Manual and would prefer to open it (instead of the html version) from within Aperture using Acrobat or Preview. Is there a way to set this up .... perhaps with an Applescript or a Service?
    Cheers,
    Peter O.

    Hi Peter
    Try this.... http://documentation.apple.com/en/aperture/usermanual/ (I realise you already have it)
    Click on the Aperture3 User manual Link, when it opens in Safari, go to > File > Print (don't worry) > you then get a drop down menu > click the PDF link (next to the help question mark) > then from the new drop down menu click > Save PDF to Aperture
    Peter, I haven't tried this myself so am not sure if it's what you want, let me know if it is what you require, I would be interested to know...
    Regards.... Gerry..
    Peter I tried it, it only downloaded the first page and let me save it in Aperture as a Project... Not what you needed i'm afraid... back to the drawing board
    Message was edited by: windhoveruk

  • How to convert llb from LabVIEW version 8 to 7.1

    Can someone tell how to convert the llb from LabVIEW version 8 to version 7.1?
    I hope to sent the program to the others, but the other side are using LabVIEW version 7.1 but not version 8.0.
    I know I can save to VI file as previous version, but it contains severals of VI in the library, it is quite time consuming.
    Can everyone sugguest any method or solution to solve my problem.
    Thanks.

    Hi anson,
    it will run also in LV7.1 - but you should check those warnings (probably things not/differently supported by LV7.1...) anyway!
    Best regards,
    GerdW
    CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
    Kudos are welcome

  • Hello, sombody knows how to start MS Excel from LabView (version 8.2)? Thanks

    Hello, sombody knows how to start MS Excel from LabView (version 8.2)? Thank you in advance.
    Regards Robert

    In the example finder  ">Help>Find Examples >>search for Excel", you'll find a sample program called "ActiveX Event Callback for Excel".
    It opens the Excel Application..  You can build on this to open/create new worksheet(s), etc.
    RayR
    Message Edited by JoeLabView on 06-20-2007 08:21 AM
    Attachments:
    OpenExcel.PNG ‏34 KB

  • I'm trying to read some XML data from temperature logger over my network. I'm using LabView version 2009 sp1. I'm using the URL Get Document Vi. It works fine when using Internet sites like google or foxnews etc...

    I'm trying to read some XML data from temperature logger over my network.  I'm using LabView version 2009 sp1.  I'm using the URL Get Document Vi.  It works fine when using Internet sites like google or foxnews etc...
    When I use it with my temperature logger most of the time I get an Error 66...but some times it does work and actually retrieves the document. 
    I can use the same address "http://172.22.21.68/XMLfeed.rb" (Internet Explorer or Google Chrome) in my browser and get a response every time.  When accessing from my browser the server in the temperature logger does take around 6 seconds to respond, but it does respond every time. 
    Is the URL Get Document Vi exceeding a timeout?  If so, where can I set it to wait longer?
    Attachments:
    Error 66.jpg ‏183 KB

    It looks like the TCP Buffered Read has a 2.5 sec timeout, I believe that is where I had trouble as well.  Try creating your own URL Get HTTP Doc vi in which you call URL Get Document in normal mode, with an appropriate number of characters to fetch (enough characters so that you capture all the important data in the XML file).
    Attachments:
    ex1.PNG ‏33 KB

  • Does LabView program behave differentl​y under Traditiona​l Chinese version from regular English version. The program reads in numbers and characters from input files.

    Does LabView program behave differently under Traditional Chinese version from regular English version. The program reads in numbers and characters from input files.

    Hope this helps,
    Ankita

  • What are developers​' opinions on how best to handle upgrading large code libraries with multiple apps to new a labview version?

    I have a large set of code that I've painstakingly migrated from one labview version to another over the years.  I have lots of deployed applications that I need to continue to support.  From experience and interaction with other developers, I don't think I can continue to migrate every application to a new labview version when I upgrade going forward.  Every application seems to break in one way or another, the builds don't work right and need to be re-done, and its too much time to get all my applications working and tested again.  That opinion is solidified by NI's policies that make it impossible to install old toolkit versions on new labview versions, for example.  Compatibility is often being sacrificed so NI can develop labview in the direction they choose.  So I have to take the position that whatever version I write an application in will probably need to be maintained in that labview version throughout it's life.
    In light of this, how are other developers managing older applicatiosn written in older versions of labview.  Right now I have a virtual PC on my system with 7.1, 8.0, 8.2, and 8.5 all running on different virtual PC's so I can keep each installation separate.  I strongly recommend this approach.  But keeping my large libraries of code separate is tough.  They are many GB, they all link to each other, and I always get worried even when I separate them in different directories that somehow labview will search in the wrong place and find the wrong version of a sub-vi.  Are other people also trying to maintain separate copies of all their code in different labview versions?  How are other people managing this problem?
    -Devin
    I got 99 problems but 8.6 ain't one.
    Solved!
    Go to Solution.

    Hi,
    The following directory hierarchy, coupled with a "hierarchical" VI naming strategy, have been effective (for me) at preventing "cross-linking" across projects and LV versions. The storage hierarchy was designed for use within an SCC environment, but works fine independently. Hierarchical-naming insures unique names for application-specific files. Use of Project Libraries (in LabVIEW 8.x) addresses the problem of having different VIs with the same name, still, it gives me warm-fuzzies to have app-specific files named uniquely, and I can't imagine not using Hierarchical-naming anymore - it's described at-length in section 2.1 of attached .doc..
    Note: It's been my experience that companies identify resources as supporting specific "Programs", where a Program is related to a product or "family" of products, so, under <Programs> (below) each "Program" subdirectory encapsulates product-specific (or product-family-specific) applications. Also, assuming no SCC tool is being employed the <Production> directory (below) exists as a repository for distributables.  All distributables required to reproduce a test-station should be located under <Production>.
    <Software_Root>
    <Development>
    | <Common>
    | | <LabVIEW_61>
    | | | <Drivers>
    | | | | <DMM>
    | | | | <OS>
    | | | | <PS>
    | | | <Utilities>
    | | |   <File>
    | | |   <Error>
    | | |   <String>
    | | <LabVIEW_711>
    | | <LabVIEW_82>
    | | <LabVIEW_851>
    <Programs>
    * Program-specific applications that (probably) have distributables
    | <Program_#1>
    | | <Application_#1>
    | |   <Docs>
    | |   <Source>
    *       Individual, application-specific, VIs go here
    | | <Application_#2>
    | | <Application_#3>
    | <Program_2>
    | | <Program_3>
    | <Tools>
    *   Tools are NOT "program"-specific, and, may have distributables
    |   <SomeTool>
    |   <SomeOtherTool>
    <Production>
    | <COTS&Freeware>
    | <Programs>
    | | <Program_1>
    | | | <Application_#1>
    | | | | <Application_#1_Rev#1>
    | | | |   Application_#1.bld>
    | | | |   <EXE>
    | | | |   <Installer>
    | | | |   <Source>
    | | | |     Application_#1.llb>
    *           Distributable is created from LLB "snapshot", not directly from development tree
    | | | <Application_#2>
    | | | | <Application_#2_Rev#1>
    | | | |    Application_#2.lvproj>
    | | | |   <EXE>
    | | | |   <Installer>
    | | | |   <Source>
    | | | |     Application_#2.llb>
    | <Tools>
    "Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
    Attachments:
    StyleGuide.doc ‏941 KB

  • Difference between labview version-6,7.1,8,8.2 and 8.6

    I m labview fresher---I wanted to know the difference in main features between each version and want to have the idea of whole evolution.

    Here are some of the advantages of 8.5 over 7.1
    1. Project explorer
        a. ability to deploy to multiple targets from one session of LV. Manage desktop, industrial, mobile and embedded targets.
        b. Organize files including external code, specifications, and data files
        c. Store and manage deployment settings
        d. Source Control
    2. Distributed Intelligence
    3. Shared Variable
        a. No longer requires two loops on target, RT FIFOs or Complicated TCP programming
    4. 3D Picture Control - to display graphics
    5. Memory control tools - To perform in place operations, avoiding costly duplication of data in the memory
    6. LabVIEW MathScript - ability to perform Mathscript operations from within LabVIEW.
    7. Multithreading and multicore - Controlling which core your code runs on.
    8. More inbuilt functions and added performance features.

  • Labview version 6.1 failure:"linker.cpp", line 2302

    I have the labview version 6.1 failure:"linker.cpp", line 2302 fault.
    Does any one can help me please ?
    Solved!
    Go to Solution.

    Actually HeapPeak existed as far back as LabVIEW 4 or maybe even 3. However it is not usually helpful for linker errors as that is something in the LabVIEW compiler itself. HeapPeak can be sort of useful for Insane errors to locate the element that the compiler considers insane (and consequently delete and/or rewire it).
    If this is a recent error on a VI that used to work before, it is most likely related to a corruption to the VI and the best course of action is to replace the VI from a backup (source code revision control would be a great advantage here). If it is something where no previous (working) state is known about, then it is going to be a tough cookie. This version is 14 years old and eventhough I still have some installation of that version somewhere it is several years ago that I started that up for more than some accidential reasons. I'm pretty sure NI would need to do some archeological work nowadays to come up with a system they could use to replicate such an error and the OP would need to be a pretty high profile customer that they would go through that sort of effort.
    Maybe it is related to this error. It is the closest available in the publically accessible list of errors. A complete recompile of the entire source code tree is definitely one of the first actions to try. It may fix the problem or run into even more errors that could maybe point into a more specific location. Upgrading to a more recent LabVIEW version is another possibility although hampererd by the fact that the currently shipping version isn't officially supporting XP anymore and that the Vision software is one piece of software that underwent serious changes in the course of time and an update from 6.1 to the most recent version is most likely not a seamless operation.
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Sypris Teslameter Driver_too early to convert to 8.5 labview version

    I am new to labview (8.5) programme and trying to use it to run my setup. I connected the Gaussmeter/Teslameter (FW Bell Sypris 6010) to the computer using serial port and RS-232 cable and used the driver (from the company) for this type of devices in order to allow labview to communicate with this device but there is always an error when I try to access the device through labview. This error says:
    "VI version is too early to convert the current LabView version"
    I would really appreciate any help in getting this solved.
    Many thanks
    Hadiq
    Islam means peace
    Solved!
    Go to Solution.
    Attachments:
    FWB6010.zip ‏412 KB

    Thanks for your suggestion. I did it and hope to get it sorted.
    Many thanks,
    hadiq
    Islam means peace

  • Determine Orchestrator version from code?

    Thanks to some legacy environments we're supporting, we have multiple versions of Orchestrator running in our environment. We run a common code base across all versions, so all of our workflows are the same on all the Orchestrator instances, but sometimes we need to run slightly different code on different versions of Orchestrator.
    The questions is, is there a way I can tell from within Orchestrator which version is running? Right now, we run a local 'hostname' command to get the name of the Orchestrator server and base our decisions around that, but I wanted to know if there was a more graceful / dynamic way to determine versions. Is there anything in the API or any scripting object I can use to get this information?
    Thanks!

    Do a GET request to the REST API:
    /vco/api/about
    Output sample from my appliance:
    json:
        "version": "6.0.2.2707387 (6.0.2.2700137)",
        "build-number": "2707387",
        "build-date": "20150428-1104",
        "api-version": "5.5.2"
    XML:
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <about-info
        xmlns="http://www.vmware.com/vco">
        <build-number>2707387</build-number>
        <build-date>20150428-1104</build-date>
        <version>6.0.2.2707387 (6.0.2.2700137)</version>
        <api-version>5.5.2</api-version>
    </about-info>

  • Lvwutil32 version too early to covert to current LabVIEW version?

    Hi all,
    I am looking to control the windows panel with some of the useful vis stored inside the lvwutil32 lib. However when I tried to open the vis inside the library, an error message saying that the vi version (4.0) is too early to be converted to my current LabVIEW version (8.5.1).
    Is there anyway to reconvert the vi that my current LabVIEW can use? It is a great shame as from the readme that comes with the lvwutil32, it seems that there are a lot of useful vis that I would find very useful for my projects.
    Hope someone could provide some help on this. Thanks!
    Solved!
    Go to Solution.

                           Hello,
                           I am having the same problem as YuanGe(the topic owner). I wanna open a file from the 5.1.1 LABview version on my LABview 8.6 and occurs the same error message.
                          I would be very grateful, if anybody could help me.
                          Thanks.
                          ps: The file is just down here.
    Attachments:
    ag8614x.zip ‏2795 KB

  • Old Labview versions

    Hello everybody!
    I want to use  some parallel port, labview programs with my old laptops using windows 95 and 98.
    Which Labview version can I use for that purpose?
    From where can I download such an old version for free or a trial version?
    Thank you!
    Solved!
    Go to Solution.

    Hey Nicku,
    Attached is the image that was missing from the above linked Knowledgebase. In regards to accessing older versions of LabVIEW, if you have a valid support contract, you can access some earlier versions of LabVIEW from the Service Resource Center . However, versions of LabVIEW available there do not go back as far as LabVIEW 6.1 which is what you would need for a Window 95 machine. Unfortunately, free or trial versions of LabVIEW would not be available for LabVIEW 6.1. It might be helpful to contact a local sales representative to discuss what options you have.
    Message Edited by BCho on 12-22-2009 10:22 AM
    Message Edited by BCho on 12-22-2009 10:24 AM
    Hope this helps.
    -Ben
    WaterlooLabs
    Attachments:
    lv versions.png ‏88 KB

  • SCC with different LabVIEW versions

    Hi. I have many different projects, and some of them are in older versions of LabVIEW. I was wondering if there is support and what kind of support there is for older versions in the SCC tools of LabVIEW 6.1

    We don't offer any cross versions tools for the source code control because VIs are generally saved in the LabVIEW version in which they were edited. If you want to use SCC with a project in an older version of LabVIEW, we recommend checking the files out of the master directory into the local, opening the VIs from the old local with LabVIEW 6.1, saving, and putting the VIs in a new project with the 6.1 SCC. This way you leave the old master directory intact for backup purposes.
    Jeremy Braden
    National Instruments

Maybe you are looking for