Wine & Labview Executable​s?

Is it possible to run LabView executables under wine? Has anyone ever attempted to do this? Thanks for any information.
Regards,
Ken

Kenneth.Miller wrote:
Is it possible to run LabView executables under wine? Has anyone ever attempted to do this? Thanks for any information.
Regards,
Ken
I've tried it several years ago with
LabVIEW 5.1.1 and 6.1 and didn't really have any significant issues
except that everything was sort of sluggish and certain screen updates
left artefacts on the screen. Now Wine has come a long way since but so
has LabVIEW and I doubt somewhat that LabVIEW 8.0.1 would be as
complient with Wine as older versions have been.
All the .Net, Active X and what else more is quite involved and LabVIEW
8.0.1 does not for nothing require Win2000 or XP to run. Wine has on
that area quite some deficiencies related to specific functionality
such as ActiveX/DCOM and does not attempt to provide .Net functionality
at all. Of course you could get Mono into the picture here but last
thing I heard they were trying to sort of modify Wine to get their
system to load properly.
I believe that .Net is optional in that LabVIEW will only weak link to
.Net functionality and did so before with ActiveX/DCOM but since
Win2000 comes with ActiveX support out of the box, this weak linking
might not have been tested properly anymore and might actually fail.
All in all not exactly a good constellation and since LabVIEW for Linux
is available since a long time I haven't bothered about LabVIEW on Wine
for quite some time.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Similar Messages

  • Improving load times in Linux LabVIEW executable

    I'm looking for (simple) ways to improve the loading times in a Linux LabVIEW executable. We're using a low performance, low cost CPU board, and loading times are terrible. The CPU is capable of doing everything after the application is loaded, but takes forever to get there.
    One of the problems is the size of the executable, that grows everytime you just look at it. Are there ways to create smaller executables? It runs from a Compact Flash card, which is ofcourse much slower than hard disk.
    Another problem is a dynamic vi, that is started for every TCP connection that connects to the application. It takes a long time to load, and connecting too fast can even effectively hang up the system. Starting a handler task takes about half a second, up to a few seconds for the first task.
    We're using the LabVIEW 7.1 runtime, system is a 300 MHz cyrix SBC, running from a Compact Flash.

    Dennisvr wrote:
    I'm looking for
    (simple) ways to improve the loading times in a Linux LabVIEW
    executable. We're using a low performance, low cost CPU board, and
    loading times are terrible. The CPU is capable of doing everything
    after the application is loaded, but takes forever to get there.   One
    of the problems is the size of the executable, that grows everytime you
    just look at it. Are there ways to create smaller executables? It runs
    from a Compact Flash card, which is ofcourse much slower than hard disk.   Another
    problem is a dynamic vi, that is started for every TCP connection that
    connects to the application. It takes a long time to load, and
    connecting too fast can even effectively hang up the system. Starting a
    handler task takes about half a second, up to a few seconds for the
    first task.   We're using the LabVIEW 7.1 runtime, system is a 300 MHz cyrix SBC, running from a Compact Flash.
    I'm
    not sure about the first part of your question. LabVIEW is highly
    binary and does a lot of memory allocations before even one VI is ready
    to be started. So maybe the memory manager is a problem. Another issue
    is that the Macintosh like resource file format that is used by LabVIEW to store its VIs etc. results in
    lots and lots of individual disk accesses with a rther random like
    character inside a single file. So if you can configure the read
    caching of your disk to use more memory this may significantly increase
    the speed of loading LabVIEW VIs or applications.
    And finally spawning VIs through VI server is a rather costly operation
    especially on low resoruce systems. A VI is more like an executable in
    many ways as far as resource consumption is concerned rather than a
    thread. A much better way would be to avoid spawning subVIs altogether
    and implement a queued TCP/IP server similar to the Date Time Server
    example. It is a little extra work to work with this shift register
    architecture but it will not have the issues of long load times for
    every new TCP/IP connection coming in.
    Rolf Kalbermatter
    Message Edited by rolfk on 03-07-2006 06:33 PM
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Open VI Reference to a LabVIEW executable.

    Hello,
    I haven't done this for a while and it's not working like expected.  I'm trying to "Open VI Reference" from executable A.exe to B.exe.  I'm trying to get a control value from B.exe in A.exe.  Can someone send me an example?
    Right now I'm at this stage: I have A.exe running as a LabVIEW executable.  I'm trying to "Open VI Reference" to A.exe from LabVIEW development without success.  Not sure what I'm doing wrong.
    Don't hesitate to ask more info if you need some.
    LabVIEW 2012, Windows 8.1.
    Thanks,
    Michel
    Solved!
    Go to Solution.

    Bob_Schor wrote:
    Once you have an Executable, does it matter that the underlying Development system is LabVIEW, rather than (say) Visual Studio, or Matlab?  I suppose you could write an application that "knows" to, for example, listen to a TCP/IP port and interpret/execute commands, but that doesn't sound like the question being asked.
    BS
    LabVIEW-built executables still run as VI's in the RTE, though.  Their identities have not been abstracted away into one single object or anything, and they still have name-based VI server access.
    You can configure a build specification to include almost nothing, and require the VI files to be present in expected locations (i.e build specification's data or support directories).  By default, all items in an executable application build specification are set to be put in the same location as their caller, which results in most things going into the .exe file, internally referenced in a directory-esque form like crossrulz mentioned, "MyExecutable.exe\MySubVI.vi".

  • Is it possible to call a VI that is inside a LabVIEW executable from a TestStand sequence?

    I have created a custom TestStand operator interface and have modified the default sequential process model to display a UUT information dialog that prompts for more information than just the UUT serial number.  This UUT information dialog is a LabVIEW VI.  To distribute the operator interface, I build it into an executable.  As part of the build process, I make a copy of the UUT information dialog VI (which is part of my operator interface project) and place it in the same folder as the executable.  I have then configured the sequential process model to call the dialog VI from this location.  It would be really nice if I could embed the UUT information dialog VI inside the operator interface executable so that I could distribute just an executable instead of an executable and separate VIs.  Is this possible?  In other words, is it possible to call a VI that is inside a LabVIEW executable from a TestStand sequence just like a standard LabVIEW VI call?

    Ryan,
    The dialog that you've created isn't being directly called by the OI at all and shouldn't need to be included in the same directory as the OI for distribution. Since you are modifying the PreUUT of the default process model, you will give the path to the VI in that step, create a deployment and then manually copy the VI to the directory referenced in the step. The VI is considered a support file for the process model and is not related to the OI at all.
    Test Engineer - CTA

  • How can I run a labview executable file inside a VI

    How can i add and run a labview executable file inside the vi and grab the output of the executable file to be used in the vi?
    mytestautomation.com
    ...unleashed the power, explore and share ideas on power supply testing
    nissanskyline.org
    ...your alternative nissan skyline information site

    Hi cmdrb,
    to run an executable you use SystemExec function.
    To get the output of your (LabVIEW-made) executable you need to program some data transfer means: you may use network functions or file functions. In both cases your "LabVIEW executable" needs to provide that options…
    Best regards,
    GerdW
    CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
    Kudos are welcome

  • How can I call a LabVIEW executable from within another LabVIEW executable?

    I have a customer requirement for two LabVIEW executables. Based on their current setup, they need to run executable "A" or "B", both of which are under independent revision control. I have created a third "selection" executable that allows the operator to choose between one of the two, but I am receiving errors when I attempt to call a LabVIEW executable from within a LabVIEW executable using either the "System exec" VI or the "Run Application" VI. If I call a non-LabVIEW executable (such as Windows Explorer) everything works fine.

    > I have a customer requirement for two LabVIEW executables. Based on
    > their current setup, they need to run executable "A" or "B", both of
    > which are under independent revision control. I have created a third
    > "selection" executable that allows the operator to choose between one
    > of the two, but I am receiving errors when I attempt to call a LabVIEW
    > executable from within a LabVIEW executable using either the "System
    > exec" VI or the "Run Application" VI. If I call a non-LabVIEW
    > executable (such as Windows Explorer) everything works fine.
    As with the other poster, I suspect a path problem. You might try the
    path out in a shell window, and if it works, copy the complete absolute
    path to LV to see if that works. LV is basically passing the comma
    nd to
    the OS and doesn't even know what is in it, so you should be able to get
    it to work.
    The other poster commented on subpanels, which is a good suggestion, but
    without going to LV7, an EXE can have open more than one VI. You can
    use the VI Server and the Run method to fire up another top-level VI.
    The decision is whether you want both to be in unique processes.
    Greg McKaskle

  • Control where a LabVIEW executable write it's Settings Configuration file

    Is there any way to control which directory a LabVIEW executable writes it's configuration settings file to? I am using version 7.1.

    I believe the INI file must be in the same directory as the executable. You can use the keys found in the LabVIEW.ini file and they will apply to your executable without any special programming on your part. That being said, you can always create a custom settings file or files anywhere you like to store configuration information specific to your application.
    If we could specify some other path for the executable settings file, it would probably hurt more than help in the long run. The same directory as the executable is the only one whose existance you can be sure of..... or of whose existance you can be sure.
    Dan Press
    PrimeTest Corp.
    www.primetest.com

  • Problems with a waking up a labview executable after computer hibernation?

    I am just wondering if anyone has had any problems with waking up a labview executable after hibernating a computer.  The executable was running before the computer was hibernated and it seems to have frozen not crashed after the computer was woken up.  I am using Windows 7 and Labview 2009.
    Thanks for your time.

    What is the application doing?  (if that even matters)
    If it were performing a data-acquisition hardward process then that might matter..
    I haven't experienced this problem.

  • Labview executable does not open excel...

    i just compiled labview code into an executable and when i run the executable, it does not open an excel document like it is supposed to.  it opens the excel program, but not the specific file stipulated in the code. the problem only exists on one of my computers.  the "problem computer" is being set up for the first time to run labview executables.
    thanks in advance for the help.
    Erik

    That is probably the reason.  Microsoft is notorious for the way they change their activeX components between office versions.
    At the minimum, you need to install the LabVIEW runtime engine on the other PC.  It needs to be the same version as the version of LabVIEW you developed in.  You can either search the NI website and download and install the run-time engine, or you can create an installer for your application from the development PC that will include the run-time engine.
    You may need some other run-time engines such as VISA or DAQmx if your application is using any of those functions.

  • How to start a LabVIEW executable programmatically.

    I created a LabVIEW executable and want to start it programatically from another PC.
    I know how to start LabVIEW remotely but not how to handle an application.

    If you have NT/Win2k machine, then you can launch labview built exe using DCOM. Here is example that tells you how to do that.
    http://zone.ni.com/devzone/devzoneweb.nsf/opendoc?openagent&9208517E41C2B1B18625683A000CB86E&cat=9C6DF90777E5A78206256874000FA14E
    Another one
    http://zone.ni.com/devzone/devzoneweb.nsf/opendoc?openagent&20346814BACE06BF8625683A000C3C98&cat=46E7994B7483D781862567C300662667
    A Rafiq

  • Best way to create a Windows service from a LabVIEW executable​?

    What would be the best way to run a LabVIEW executable as a service? I needed this recently and I think I have set up such a service using srvany.exe from the Windows 2003 Resource Kit, but that seems like a bit of a hack. The Kit is not offically supported in Server 2008, but seems to work. I don't know about Server 2012 or beyond.
    So what would be the "proper" way of going about creating a Windows service from a headless LabVIEW application?

    The proper way is to interface to the according Windows service control API. That is however not a trivial task to do. We used to sell a LabVIEW toolkit which supported a full interface to this, but it's not currently actively marketed.
    srvany.exe is sort of a hack but works reasonably well for most use cases, as long as you do not need any further interaction with the service manager interface in Windows than to start and stop your service.
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Queue data sharing between multiple LabVIEW Executables

    I have 2 LabVIEW Executables(Exe) where one Exe produces data and other one consumes the same. Is there anyway I can use a single queue reference for the same ? First Exe obtains the queue reference number and stores the reference number in V.I.G where as the second Exe read this reference number from this V.I.G. The error from the second VI dequeue was invalid queue reference.
    Is there anyway I can share the same data between different exes with the functionality of a queue ?.
    Solved!
    Go to Solution.

    Ben wrote:
    Each exe is mapped into its own memory space so refs to resource in one context will not work in another but...
    If you exposed an Action Engine in one instance to be used via VI server Invoke Node from the other, the AE (Note: it will be running in the server context) could queue the data in behalf of the client.
    Plese note:
    If the server porcess goes idle all of its resource will be invalidated (including the queue) but a ref to the AE will still be valid. In this case the enqueue op will fail so you have to code to account for this situation. (been there done that )
    This smae approach will work in any network architecture where VI serve can be used. I used this approach about 10 years ago (minus the queue) to allow control of a factory floor from a laptop with a internet connection.
    Ben
    Do you think the same must work with following scenario:
    1. LabVIEW Exe calling a data acquisitio thread dynamically(VI Server) and enqueue the data into a Queue with reference in VIG.
    2. Same Exe calling a TestStand Engine and one sequence inside that calling the same queue to dequeue the data.
    3. Remember that the LabVIEW adapter I use with TestStand is LabVIEW Run-Time Engine(Not development system)

  • Is it possible to run a Labview executable on a Windows 8 Phone?

    If I create an executable from Labview,will it be possible to run it on a Windows 8 phone?
    Solved!
    Go to Solution.

    No, as Mike already said.
    The reason being that a LabVIEW executable contains binary code that is compiled for the x86 CPU architecture and accesses the Win32 API. Windows Phone typically runs on ARM or RISC CPUs and did only provide a very limited Win32 subset in the past. With the new Windows RT technology it actually moved even further away from Win32 compatibility as it's entire architecture is based on the .Net technology.
    So even if you happen to get an Intel Atom based Windows Phone device which would be x86 compatible it couldn't work, since a LabVIEW executable is a Win32 portable executable format not a .Net bytecode image.
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • LabView executable on Windows Embedded Standard 7

    I will like to know if LabView executable with IMAQdx Vision code can be  run on Windows Embedded Standard 7. Thanks.

    Greetings,
    Most certainly, you should be able to use LabVIEW Executables on Windows Embedded Standard 7 that contain Vision VIs. The cRIO 9082 is a great example, for it uses WES7 and brings in GigE Camera support.
    Cordially;
    Simon P.
    National Instruments
    Applications Engineer

  • Calling labview executable from teststand

    I have a labview VI that I build into an exe, and I'd like to call it from my teststand sequence in the setup - other test steps need to use its capabilities in the remainder of the sequence (main).  If it were just a VI, then no problem, the inputs would be visible to me, and I could pass them in.  Since it's an executable, though, my step is of type "Call Executable", but I don't see anywhere that it allows me to pass in the inputs it needs.  Thoughts?
    Solved!
    Go to Solution.

    What version of TestStand are you using?  With TestStand 4.0 for the 'Call Executable' step there is a line called
    Argument Expression:
    Enter your parameters to pass into your LabVIEW executable.  You will have to know which ones to pass in and in what order. I believe you can seperate the arguments by spaces.  In my attachment, I pass in one parameter to a LabVIEW executable.
    Remember, though you have to set the Build properties in LabVIEW to allow it to Pass command parameters to the application.
    Thanks,
    PH
    Attachments:
    Call Executable.JPG ‏48 KB

Maybe you are looking for