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

Similar Messages

Please Convert Vis from Labview 2013 to Labview 2011

Please convert the attached Vis from Labview 2013 to Labview 2011
Solved!
Go to Solution.
Attachments:
Convert from2013 to 2011.zip ‏255 KB

Here you go.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Attachments:
Converted to 2011.zip ‏176 KB

Labview trying to find runtime engine when opening up VB6

This is bizarre. I'm not even trying to open a labview program, and I get this error.
when I go to open up VB6 from Visual Studio (Visual Studio 6, Enterprise Edition), I get a pop-up saying that the Labview runtime engine 7.1.1 is going to be configured. A new window then pops up, because it can't find the lvruntimeeng.msi file.
Problem is, I'm using Labview 8.2.
Worse, now my VB6 programs are hanging if I close out of all the installer boxes (it does this multiple times).
UPDATE-4:42PM EST-
I noticed when I went into Add/Remove Programs in the control panel, when I clicked on Change for National Instruments, it says that only the 7.1.1 Runtime Engine is installed. However, I can not uninstall it because another product relied on it. I also downloaded the 7.1.1 runtime engine, but it doesn't install because it says a higher version is already installed. (?)Message Edited by Dauntless on 12-26-2006 03:46 PM

There are some NI programs which were written in LabVIEW and so need the LV RTE in order to run.
Theoretically, the RTE should be properly installed when these programs are installed, but for some reason maybe it wasn't. Maybe one of the NI services running on your machine tries to do something when you're opening VB or maybe your code calls some NI component?
I used to have something similar where for some reason going into certain websites prompted me to insert the LV 7.1 CD so that I can configure the RTE. I think it stopped after doing it one time.
You can try downloading the 7.1 RTE and installing it to see if it will stop. If not, you can try pointing the dialog at the MSI once to see if that will stop it.
Try to take over the world!

When replacing Labview 2013 with Labview 2014, do I firstly need to uninstall Labview 2013?

I have just recieved my latest version Labview 2014 CD.
When installing this new version, do I firstly need to uninstall previous Labview versions?
Solved!
Go to Solution.

Bob_Schor wrote:
The reverse, however, is not true. Once you install one version of LabVIEW, you cannot install an older version without uninstalling everything and "starting over". Be warned ...
Not exactly true. You can install just an older version of LabVIEW. I have had LabVIEW 2012, 2013, and 2014 installed on a computer and then installed 8.2.1. It is all of the support drivers and what not that do not install side-by-side. So the real lesson here is that if you install an older version of LabVIEW, pray that your current drivers support that version of LabVIEW. You will need to reinstall the drivers to install the support for the older version of LabVIEW though. Installing just the support takes hardly any time.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Several question s about runtime Engine, application builder and labview player

I am a little confused by all the options to distribute a program.
Please help bij answering (one of) the following questions:
1. Does an application built with the application builder always need the LV runtime engine? The LV runtime engine is 33 Mb to download!
2. Is there anyway to make a 'normal' executable that runs on a windows machine, without any supporting installed software?
3. What is the advantage of the labview player above the runtime Engine?
All questions refer to the latest software versions of NI software
Thanks in advance,
Regards,
Ferry

ferry1979 wrote:
1. Does an application built with the application builder always need the LV runtime engine? The LV runtime engine is 33 Mb to download!
Yes, the runtime engine contains all the stuff that is common to all LabVIEW applications. This is not any different than e.g. the Visual basic runtime (VBrun...) or dforrt.dll for Fortran.
If you built the application, you can strip it a little bit by including the runtime with the installer and leaving out unneeded modules (see image from the 7.1 builder).
The advantage of a seperate runtime engine is that applications are very small. The runtime needs to be installed only once. On any broadband connection, 33MB is peanuts. I distribute everything without runtine, but tell people to download and install the runtime directly from NI.
(In LabVIEW 4, no runtime was needed, with the disadvantage that even the simplest program was multiple megabytes. Not an efficient solution).
(Maybe in a few years LabVIEW will be so prevalent that the LabVIEW runtime will be part of a standard OS install ;
2. Is there anyway to make a 'normal' executable that runs on a windows machine, without any supporting installed software?
No. See above.
3. What is the advantage of the labview player above the runtime Engine?
The two are quite different. The labview player is more a simple educational tool, because it lets users inspect the diagram. It is not designed for any serious application deployment.
Message Edited by altenbach on 08-21-2005 10:05 AM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
runtime.png ‏24 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.

Mise a niveau Labview 2013 vers 2014

Bonjour,
Je dispose d'un programme de labview dernierement compilé avec labview 2013, et apres installation de labview 2014, j'ai essayer d'ouvrir mon programme dernierement compilé avec labview 2013,avec labview 2014, mais cela souvre mais je n'arrive pas a le compilé et il m'affiche des erreurs sur une des mes sous VI,
Etant donné que je suis novice avec labview, puissez vous m'aider svp en m'éclairant sur cette question.
Je vous remercie d'avance de votre réponse;
Cordialement,

Kathiaswe wrote:
Hi,
My error is: your Vi can't executed, can you corect your error. ça donne ça car j'utilise la version en français.
Mercii
Il n'y a définitivement pas assez d'information pour être d'une quelconque aide. Ouvrir le sous-vi en erreur et cliquer sur la flèche blanche (run) et une fenêtre d'erreur ouvrira. Poster l'information détaillée de cette fenêtre d'erreur, à partir de cet information nous seront plus en mesure de vous aider.
Ben64

Labview 2013 daq assistant missing

I can't see the DAQ assistant in Labview 2013!
Labview 2013 + real-time + fpga
Max 5.5.1
Visa 5.4.0
Device driver august 2013
Why?
Thanks
Solved!
Go to Solution.

Did you install DAQmx AFTER installing LabVIEW? Can you see any of the DAQmx palette?
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

NI Developer Suite 8.2 / LV Runtime Engine 8.2 vs 7.1.1

I have NI Developer Suite 8.2 and have installed LabVIEW v8.2 from it onto my development computer. I have converted a LabVIEW 6.1 application to 8.2 and am now setting up an installer build for the application.
When setting up installer build properties, I find NI LabVIEW 7.1.1 Runtime Engine, NI LabVIEW Run-Time Engine 8.0.1, and NI LabVIEW Run-Time Engine 8.2 listed as additional installers that can be included in the build.
Wanting to use the latest and greatest for my application, I have selected Run-Time Engine 8.2 for inclusion in the installer.
Upon testing the installer, I find Runtime Engine 7.1.1 installed, not 8.2.
I checked the development computer (Control Panel->Add/Remove Programs->National Instruments Software) and found only Runtime Engine 7.1.1 installed. I then uninstalled LabVIEW 8.2 and reinstalled it, hoping to be able to specify which runtime engine to install, but there is no option in the installation process for runtime engines.
My question is: what happened to runtime engine 8.2? Why can't I get it installed on my development computer? If it doesn't exist, why is it listed in the installer build properties as an installer that can be included? Is it vaporware?

Hi Igk,
On your development machine, the LabVIEW RTE 8.x will not appear in Add/Remove Programs because it is an invisible MSI Installer. The installer is invisible because other applications (LabVIEW Development environment, for example) are dependent on the RTE. Uninstalling the RTE would cause problems for all the other programs with dependencies, so the option to remove it is not there. If you uninstall all the programs that depend on the RTE, the RTE will be uninstalled with the last program. You can see in the attached image that I don't have LV RTE 8.0, or 8.0.1, or 8.2 in Add/Remove Programs, but it is listed in MAX Software.
If you run this LV installer on a clean PC(without the LV development environment), I havn't tested for sure, but because the application installed depends on the RTE, the RTE still probably won't show up in Add/Remove Programs (but your application will). You can verify the RTE's existance by checking the <Program Files\National Instruments\Shared\LabVIEW Run-Time\8.2> directory and verifying the lvrt.dll version is 8.20.x.xxxx. Also, when the application runs, you will know the RTE exists. Also as TonP mentioned, you can use MAX to verify its installation.
As a side note, I would generally avoid running LV built installers on a development machine that already has LV. Installing the RTE (or any other NI installer) from a LV custom installer will change its installation source stored in the registry from the LV CD where it was originally installed from to the installer that you built. Future repairs of the RTE will then look for this custom installer rather than the original source. If that installer disappears or changes, repairs or uninstalls become more difficult. I usually set up a test machine to test my LV built installers.
Cheers,
Spex
National Instruments
To the pessimist, the glass is half empty; to the optimist, the glass is half full; to the engineer, the glass is twice as big as it needs to be...
Attachments:
820RTE-Installed.jpg ‏127 KB

DSC runtime engine problems

Hi,
I recently started a project which involves DSC runtime engine. This being my first contact with runtime engines, i obviously ran into some problems. Hope someone can shed some light. Here goes: I developed a project on my work laptop on which I have LV / DSC 8.6 installed. The project is then built into an EXE application and then run on a desktop computer with DSC runtime engine.The desktop computer receives data from a PLC through an OPC server (which is not NI OPC server). At first, I imported a csv file containing the list of variables in my project with the correct path of the OPC server from the desktop. When I ran the EXE application on the desktop, I got an error (PSP Led was red) saying that the variables could not be read / written. This was because the variables were not declared in the Distributed System Manager. And so my first question is this: is there a way to import my list of variables from a csv file or something similar, and if so, how can i achieve this? Because so far, all I was able to do was to manually enter only one variable at a time in the Distributed System Manager, and after about 50 of them I decided I would really hate to enter almost 800...
My next question regards the Citadel Database. As I told you before, I entered a few variables in the system manager and played with them for a brief amount of time. I set them T / F, I got the correct readings from OPC server, my PLC leds light up, the works. Now I wanted to see my actions in the Citadel DB, but when i ran MAX, there was no Citadel DB, only Default DB, and I could not find any of those variables which I entered and chaged states. Is there a problem with the Citadel DB not showing up? Am I not declaring correctly the variables in the System Manager? (i followed the help directions to the letter). Anyone has an idea as to why I cannot see the varaibles in my DB?
And now for a final problem.. In the LV front panel, i have some boolean buttons which are set to switch when pressed Mechanical Action. When I have the PLC connected sometimes when I press a button, it remains stuck on the TRUE state, thus screwing up my logic scheme (e.g. for a feed mill conveyor motor I have two buttons - start, stop. If i sometimes press the start button and it gets stuck, i can no longer SHUT DOWN that conveyor, which is really a big problem. I found a so-called 'fix' - right click on the stuck button and select Reinitialize to default value, but I was looking for an answer to understand this problem, not a silly little fix).
Hope I have been clear enough and you have not got tired of reading so much,
Cheers,
Sabin

Hi Andrew and thanks for the reply!
I don't think I deployed the library file, because I didn't know exactly how to do it. In the Source Files Property Page on Build Specifications I only selected VIs. I never selected lvlib files, so this may be the case. On the Source File Settings I saw that .lvlib files had the property Include if referenced and I thought that was the property which deployed the library. I will change the build specifications at once and keep you updated, but it could take 1 or 2 more days, because the computer with DSC runtime is in another city, and I have to get there first maybe tomorrow.
I have several buttons set on Mechanical Action Switch Until Released. They are all Shared Variables which are connected through OPC server to memory locations in the PLC CPU. In my LV Block Diagram, they are NOT connected to anything. They are just located in a While Loop, to get their state. The preffered action is that when I press a button on my Front Panel, I get to change a memory location in my PLC and then something happens in Ladder Logic. So, the boolean values are just there, in my Block Diagram, alone and not connected to anything. Do you have an idea as to why I get that kind of behaviour (I mean the buttons get stuck on True state)?
And finally, someone told me that the Citadel 5 might be missing because of incorrect option checking at install. However, I remeber that on the desktop, I installed the DSC runtime engine FULL INSTALL, I mean I checked each and every tick box, everything, examples and the like. One thing I was told was to insert the install CD once again and perform a re-install. I will of course try this, but let's not consider this for a second. Do you have another idea as to why the Citadel DB wouldn't show up?
And no, in the EXE Build Specifications, I did not check the option Enable Enhanced DSC Run-Time support. What does it do? Could you please elaborate?
Looking forward to your answer,
Sabin

Compiled vi always runs when opened, Labview 2013 bug?

I'm presuming it's not a bug, but right now it looks like that:
I compile a vi to an exe using the application builder, but no matter how I adjust the settings, the vi will always run when opened.
I'm running LabVIEW 2013.
Lars Melander
Uppsala Database Laboratory, Uppsala University

The start up vi will run. This is expected behavior.
If you want the running vi to wait for user input before executing a process you need to code a proper arcetecture to do that. Look into the Producer Consumer (Events) design pattern. It is a good way to start an application like you describe.
Spoiler (Highlight to read)
See, asking a question (or at least explaining what behavior you want) gets more specific answers.
See, asking a question (or at least explaining what behavior you want) gets more specific answers.
Jeff

How can I build a LabView application that uses the 2012 runtime, on a development system with LabView 2013 or 2014 installed?

I need to build a LabView application .exe to run with the 2012 Runtime, for legacy support. I currently have LabView 2013 installed on my development system, and have 2014 available. How can I build an application that uses the 2012 runtime on this development system? Do I have to downgrade to 2012? Thank you.

We have existing customers that have installed our application that was originally built with 2012 (provided by a contractor that is no longer available). Due to IT regulations, it is far easier to update these customers by simply replacing the .exe file, than creating an install that their IT department must run.
If I have to downgrade to LabView 2012, where can I get the installation for this?

I can not open Excel (97, 2000, or 2003) spreadsheet in Win98 OS PC using LabVIEW 7.0 Runtime Engine

Hi,
I have a problem opening an Excel spreadsheet by a LabVIEW application that is using Runtime Engine 7.0 in a Windows 98 OS environment .
I tried LabVIEW 7.1, it will not install on Win98. Meanwhile, I installed Excel 97 and 2000 (Excel 2003 does not install on Win98) and tried to open the spreadsheet, no luck with any combination.
Same code can open the spreadsheet in a WinXP OS, RTE 7.0, Excel 2000/2003 environment.
What can I do? Any advise?
Regards,
LVLV

Hi,
I did some experiment, I found out that Run-Time Engine 7.0 running executable generated at LabVIEW 7.0 environment (code written in LabVIEW 7.1 but save as 7.0) cannot open Excel 2000 files. If I replace Excel 2000 with Excel 2003 application on my pc, the executable code will open the Excel file (Run-Time Engine 7.0 works with Excel 2003).
Is the Excel 2003 and higher versions will only work with Run-Time Engine 7.0 and higher code?
How can I make executables using Run-Time Engine 7.0 work with Excel 2000 (Windows 98 operating system)??? (I cannot change Excel and Run-Time Engine and OS versions due to limitations, how can I work with what I have?).
Thanks for your help.
Regards,
LVLV

Since upgrading to LabVIEW 2013, every VI compiles every time I open it (including quick-drop).

Hi all. Since upgrading to LabVIEW 2013, every VI compiles every time I open it (including quick-drop). This really slows things down! Perhaps related, my system tells me I don't have permission/access to modify my LabVIEW ini. Has anyone seen similar, and/or any hints towards a solution?

Jeff-P wrote:
As a side note, LabVIEW.ini is a file that gets generated by LabVIEW when it is launched if the file does not exist. So if you are missing the 32-bit ini file, launch 32-bit LabVIEW and that file should be created.
I thought that the message: "Perhaps related, my system tells me I don't have permission/access to modify my LabVIEW ini" might indicate that the labview.ini file cannot even be created... strange...
LabVIEW Champion . Do more with less code and in less time .

How do I determine if a VI is running in the runtime engine or LabView Development Environment?

Is there a function or VI that I can call that will tell me if the program is running in the LabVIEW Runtime Engine or if it is running in the LabVIEW developement Environment? I am using LabView 8.5.
I have a menu item, File/Exit, and I would like to call the Exit LabVIEW vi if running in the runtime engine when that item is selected. However, in development, I don't want to shut down LabVIEW when I select that menu item.
Maybe there is a more appropriate way to exit the program. However, I am looking for something elegant. I'm sure I could find some other way to accomplish the same thing, but I'm looking for a clean way to do it.
Thanks

Here is a small VI with this exact function.
Attachments:
Is EXE.vi ‏9 KB

Running Datasocket in labview 2013 open labview runtime engine 7.0

Similar Messages

Maybe you are looking for