Problem when building an executable with labview 6.1

I use LabView 6.1 and I want to build up an executable. I use the labview application builder to do this. I have already built up executables and I had no problems but this time I just obtain a labview vi library which is called "internal.llb" each time I try to compile my vi's. Do you have an idea to solve my problem please ?

Make sure that you have "Single target file containing all VIs" selected
under Build Option in the Target Tab of the App builder. Sounds like you
have "Small target file with external file for subVIs" selected with the
target being a llb.
-Tom
"gege" wrote in message
news:[email protected]..
> I use LabView 6.1 and I want to build up an executable. I use the
> labview application builder to do this. I have already built up
> executables and I had no problems but this time I just obtain a
> labview vi library which is called "internal.llb" each time I try to
> compile my vi's. Do you have an idea to solve my problem please ?

Similar Messages

When building an executable I get the error message var.lsb not found.

When building that executable with LV 5.0 it will work, but it will not work on a korean version of WinNT 4.0.

When exactly does the error message come up? When you're doing the build or when you attempt to run the executable?
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Is it possible to build a project with Labview 2010 on a Windows XP system, that is useful for a system with windows 7 on it?

Hi there,
I am planning to use Labview 2010 in a short time.
But before I'm going to use it I have some questions.
I know it is possible to run Labview 2010 in an XP environment. But is it also possible to, when running Labview 2010 on a XP system, to build a project to a version that is useful in a Windows 7 environment?
Or do I have to run Labview 2010, when I want to build a project that is useful on a Windows 7 system, on a system with Windows 7?
Please give me some information.
I hope to hear from one of you soon.
Regards,
Kenny
Solved!
Go to Solution.

Is it possible to build a project with Labview 2009 on a Windows XP system, that is useful for a system with windows 7 on it?
Thanks.
Philippe B.
Certified Associate Developer / Dépt Moyens d'essais
www.ingenia-system.com

ORA-00600 problem when create XMLType table with registerd schema

Hi,
I am using Oracle9i Enterprise Edition Release 9.2.0.4.0 on RedHat Linux 7.2
I found a problem when I create table with registered schema with follow content:
     <xs:element name="body">
          <xs:complexType>
               <xs:sequence>
               </xs:sequence>
               <xs:attribute name="id" type="xs:ID"/>
               <xs:attribute name="class" type="xs:NMTOKENS"/>
               <xs:attribute name="style" type="xs:string"/>
          </xs:complexType>
     </xs:element>
     <xs:element name="body.content">
          <xs:complexType>
               <xs:choice minOccurs="0" maxOccurs="unbounded">
                    <xs:element ref="p"/>
                    <xs:element ref="hl2"/>
                    <xs:element ref="nitf-table"/>
                    <xs:element ref="ol"/>
               </xs:choice>
               <xs:attribute name="id" type="xs:ID"/>
          </xs:complexType>
     </xs:element>
Does Oracle not support element reference to other element with dot?
For instance, body -> body.content
Thanks for your attention.

Sorry, amendment on the schema
     <xs:element name="body">
          <xs:complexType>
               <xs:sequence>
                    <xs:element ref="body.head" minOccurs="0"/>
                    <xs:element ref="body.content" minOccurs="0" maxOccurs="unbounded"/>
                    <xs:element ref="body.end" minOccurs="0"/>
               </xs:sequence>
               <xs:attribute name="id" type="xs:ID"/>
               <xs:attribute name="class" type="xs:NMTOKENS"/>
               <xs:attribute name="style" type="xs:string"/>
          </xs:complexType>
     </xs:element>

IS APPLICATION BUILDER 6 COMBATIBILE WITH LABVIEW 7 ?

IS APPLICATION BUILDER 6 COMBATIBILE WITH LABVIEW 7 ?

No it's not but it is a free upgrade last time I checked. Go here and click on the Upgrade Advisor link. You will need the serial number of your current app builder.
p.s. LabVIEW 7.1 was released today so you might want to skip 7 and go straight to the latest.

Language Problem when building executable

I'm having a weird issue when building executables. Labview seems to forget the english language. I have tried selecting English exclusively as the run time language but when i do that i get a "No supported languages installed!" error. Everthing works fine in the development environment. It only seems to apply to application menus and not custom user menus. Thanks for any insight.
Solved!
Go to Solution.
Attachments:
Language.png ‏3 KB

Hello Jed394,
I took a look into the issue, just to be sure the error thrown was “No support Language Installed,” correct? Check to see if the language of your operating system and the language LabVIEW is using is English. If these are both English, then it looks like this is an error due to installation issues in the run-time engine. Try to perform a repair by going through the install menu of LabVIEW. The following link will help you with the repair: http://digital.ni.com/public.nsf/allkb/FE6B641E86E55AF2862576DE00038001?OpenDocument
If you have any further issues, please let me know. Thanks!
Matt S.
Industrial Communications Product Support Engineer
National Instruments

Building a dll with labview for CVI

Hi,
I am making some abstract hardware layers for some instruments and i use to work with Labwindows CVI. But i have found ONE instrument, the Instek pst3201 alimentation which is ONLY created with Labview.
So i downloaded the 8.6 LV demo and builded the llb projet in order to obtain some .dll, .h and .lib files and included it to a CVI project in order to construct an intermediate Dll level.
Everything builds fine, like usually when i use an IVI driver but my problem is that when i try to call this intermediate Dll level with my abstact hardware layer using LoadLibrary, nothing is returned like if the DLL doesn't exist.
So my question is : Do you think that this is a problem from CVI (and i repeat that i have made a lot of others abstract hardware layers using IVi drivers except that this time i haven't got any .fp or .c but a .h and i include the .lib to the project), or a problem from Labview and i should use the LV Application builder if it's different ?

Hi,
It's seems that you have no exported function. What function do you have in your header file? did you tryed to create a really simple dll (doing an addition for example ) in LabVIEW only to verify that you are correctly creating the dll?
Manuel R
AE dans une autre vie

Ora-00922 when building a model with Oracle Data Miner

Hi,
i'm using Oracle Data Miner 10.1.0.2 with Database 10.1.0.3.0 under Linux x86.
The specific patch 10.1.0.3.1 for Data Mining was applied because i didn't manage to execute the models in the tutorial.
So all were fine, and i succeded creating my own models and i executed them.
But few months later, i.e now, i'm trying to build som other models but when building i have again the ora - 00922 : missing or invalid option
I tried applying once again the patch but no effect !
Is anyone ever faced this problem !?
Eric

Hi Xiafang,
the database were not upgraded but used to build some ETL mappings.
Here are the results of the SQL statements u gave me
SQL> connect / as sysdba
Connected.
SQL> select value from v$option where parameter like '%Data Minin%';
VALUE
TRUE
FALSE
SQL> select comp_id, version, status from dba_registry;
COMP_ID VERSION STATUS
WK 10.1.0.3.0 VALID
EM 10.1.0.3.0 VALID
XDB 10.1.0.3.0 VALID
AMD 10.1.0.3.0 VALID
CONTEXT 10.1.0.3.0 VALID
SDO 10.1.0.3.0 VALID
ORDIM 10.1.0.3.0 VALID
EXF 10.1.0.3.0 VALID
OWM 10.1.0.2.0 VALID
ODM 10.1.0.3.1 VALID
CATALOG 10.1.0.3.0 VALID
COMP_ID VERSION STATUS
CATPROC 10.1.0.3.0 VALID
JAVAVM 10.1.0.3.0 VALID
XML 10.1.0.3.0 VALID
CATJAVA 10.1.0.3.0 VALID
APS 10.1.0.3.0 VALID
XOQ 10.1.0.3.0 VALID
Is the DM option enabled, i think yes but the SQL answer TRUE and FALSE.
So, should i enable DM with the commands u gave me ?
Eric

How to build demo versions with Labview ?

Hello,
is it possible to design Labview applications in a kind,
that it is possible to generate "demo versions" of it ? Demo version in the means of feature-limited crippled versions of a full instrumentation software, where SOME hardware access is denied, but you can load and view and analyse data.
Of course it might be useful to compile this demo version with the Labview Application Builder,
What might be the business modell for demo versions:
A hardware manufacturer creates a Labview application which controls the manufacturer's components, and allows instrumentation and data recording. The application is not free but sold for extra money.
As pre-sales benifit, the manufacturer would like to send the (compiled) Labview application to future customers.
Now the problem is, that the customer has not (all) the external devices or PCI/USB devices,
on the other hand the hardware manufacturer does not want to give the "full application" as gilft to the customers.
Now with traditional software development with C++, Java, C#,
either a demo version is gained from the full version by replacing some module with hardware access by modules wth "empty" function body or with function body which return constant values instead of accessing the hardware.
In the world of process industry, usual process control systems may supply "alternative" values if the original device is not available.
What kind of software structure must I build with Labview, to do the same ?
Now the problem with Labview applications is
Labview applications depend on drivers. Drivers depend on hardware.
So if the FULL commercial version of the Labview program accesses a DAQmx driver, GPIB driver or any other hardware driver by a VI,
and often this means that a special manufacturer VI is used in the Labview program which does the actual hardware access,
how to modify the software to make a demo version
a) so that IF the customer buys the hardware and gets the hardware driver, he still does not have the full version
b) so if the customer neither has the hardware nor the driver, he still can run the Labview software and load an view data, push buttons, can execute menu items even can manipulate data ect, can use the manufacturer's VI
Unfortunately, it is no solution just to delete "some" of the VIs with hardware access from the distribution of the demo version, as this just causes error messages during the loading of the (compiled) Labview demo application.
Message Edited by hemmerling on 01-11-2007 12:35 AM
Message Edited by hemmerling on 01-11-2007 12:37 AM

Thanks alot.
Conditional Disable and Diagram Disable Structures
http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/cond_diagram_disable/
are indeed at least a part of what I wanted.
Anyhow, as such "suspended" VIs are often the *source* of signals,
so there must be an addtional method how to provide "alternative" signals for the demo version,
which does not make the administration / further development the full version too complicated...
For example: The VI for an external signal generator device is disabled, but alternatively it would be nice if the users of the demo version can get a fixed sinus signal instead...
How to do that with Labview and the "Conditional Disable and Diagram Disable Struktures",
and can I test this all even without Labview Application Builder, in the full development system ( so that I don´t need the compiler for frequent checking ) ?
Btw, with what version was this "Conditional Disable and Diagramm Disable" feature introduced ? Is ist already available with Labview 7.0, /.1 ?
Sincerely
Rolf

Error 1 when building my application in Labview 2010 Version 10.0f2

I am getting the following error trying to build my application in Labview 2010 Version 10.0f2 and I get the following error:
Error 1 occurred at Invoke Node in AB_Build.lvclass:Copy_Files.vi->AB_Application.lvclass:Copy_Files.vi->AB_EXE.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_Application.lvclass:Build.vi->AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488: Command requires GPIB Controller to be Controller-In-Charge.
Method Name: Linker:Write Info To File
I have searched and can find no real sollutions to this problem. I did the updates and still nothing. Now I can't even build an app with Laview 8.6. I reference several .NET items and refuse to rebuild each and every one of them. My only option at this point is to uninstall all Labview and then reinstall 8.6 so I can do something.
Help if you can.

Hello RBrown
I am really sorry for this inconvenience! This is a known issue.
Can you please attempt the following for me:
When you are building an application, under Advanced please check the last box "Use LabVIEW 8.x file layout"
If that doesn't work, you may need to rebuild the LLB in a separate directory with new names, and use it as the build inclusion.
Here are some forum posts strictly for your information:
I have found users that have had similar issues. I am trying to make this workaround work for you.
http://forums.ni.com/t5/LabVIEW/error-1052/m-p/912192
This is a known issue that some customers have already commented on:
http://forums.ni.com/t5/LabVIEW/NI-Please-don-t-put-illegal-vi-names-in-your-toolkits-thanks/m-p/745...
I have filed a corrective action for this issue and I will add you to the list of individuals who need this issue resolved.
Sincerely,
Greg S.

How to remove the "int len" of my return string on the DLLS header when building a DLL on LabVIEW 8.5

Hi all.
I'm building a DLL on LabVIEW and I choose a string as an output on the terminals connectors.
But LabVIEW creates another output, the lenght of the return string.
This is a problem because I have other DLLs and I need them to be compatible.
How do I remove this length from the header? What is the difference between Pascal String and C string and String Handle Pointer?
String Handle Pointer removes the length from the header but I don't know the difference between this data types.
Thanks in advance for the help.
Daniel Coelho
Portugal
Daniel Coelho
VISToolkit - http://www.vistoolkit.com - Your Real Virtual Instrument Solution
Controlar - Electronica Industrial e Sistemas, Lda

Daniel Coelho wrote:
Hi all.
I'm building a DLL on LabVIEW and I choose a string as an output on the terminals connectors.
But LabVIEW creates another output, the lenght of the return string.
This is a problem because I have other DLLs and I need them to be compatible.
How do I remove this length from the header? What is the difference between Pascal String and C string and String Handle Pointer?
String Handle Pointer removes the length from the header but I don't know the difference between this data types.
Thanks in advance for the help.
Daniel Coelho
Portugal
C string pointer is a pointer to a memory location whose string information is terminated by a 0 byte. Pascal String Pointer is a pointer to a memory location where the first byte specifies the number of bytes to follow. This obviously allows only for strings up to 255 character length.
LabVIEW String Handle is a pointer to a pointer to a memory location where the first 4 bytes are an int32 value indicating the number of characters to follow. You can read such a String handle in a function without many problems, but you can only create, resize and delete such a handle by using LabVIEW memory manager functions. So this makes only sense if the caller of such a DLL is LabVIEW too as another caller would have to go through several hoops and tricks in order to gain access to the correct LabVIEW kernel that could provide the memory manager functions to deal with such handles.
Last but not least output strings whose allocated length is not passed to the funciton as additional parameter are a huge secerity risk (talk about buffer overrun errors). LabVIEW DLL Builder does not support the creation of DLLs with output string (or array parameters) without the explicit passing of an additional parameter telling the DLL function how large the allocated size is (so that the DLL function can make sure to never write over the end of the buffer).
The additional length parameter only disappears for String Handles because LabVIEW will simply resize them to whatever length is necessary and that is also the reason why those handles need to be allocated by the same memory manager instance that is also going to execute the DLL function.
Resizing of memory pointers is non-standardized and in normal circumstances not suited for passed function parameters at all.
Rolf Kalbermatter
Message Edited by rolfk on 06-13-2008 12:28 PM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Error when building an executable in BridgeVIEW

Hi,
Every time I try to build an executable in BridgeVIEW I get an error that I have to close all VIs before building an EXE, but I only have the top level VI open. I tried shutting down the PC and restarting but nothing works. I have seen this in LabVIEW, but LV closes them for you.
Any ideas?
Thanks.

Lupita wrote:
HI,
You are probably right. So here is what Ive tried:
1) Restarting my PC. Opening a blank new VI and trying to build an application by adding my "main.vi" as a top level VI. This way I make sure there are NO VIs opened.
The list that appears on the Build Application menu contains ALL VIs called by my main.vi.
Thanks again.
I can't really say that I remember a behaviour like this but considering that the latest BridgeVIEW version corresponds to LabVIEW 4.1 (which was never released) or so, I would say that this is so long ago that my memory might be flaky here.
And the application builder back then was also not the same as it is now. I'm afraid unless you are going to use a more recent version of LabVIEW together with the DSC Toolkit (which is basically what BridgeVIEW evolved into) there is little cahnge that anybody can help you with this here.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Why might a VI break when building an executable on one machine versus another?

I have a large test application that is designed to work on several machines. In the process of testing I go to each machine and open the project on the machine I am testing. When I am satisfied the project is behaving as expected I build the executable and test that it is working as expected. This is where my problem occurs.
More Background: This software was originally meant to run one test at a time and was upgraded to run multiple tests at the same time(sharing resources and the like). To accomplish this, another VI was written that opened instances of the original VI (clone). I don't know if this is common, however this has been in use for a while and is known to work even after the migration to the network(probably not the problem).
My issue is that I can build the software on one machine and it will work on another machine, yet when I try to build the same exact project from the other machine it will no longer open the instance of the original VI. I probed the error wire and it indicates that the VI must be broken. So I open the VI and it has no errors.
I have no idea how to diagnose this any further. Anyone have any ideas?
-Nate
Solved!
Go to Solution.

Try mass compiling the entire project hierarchy prior to making a build. Also, if you are dynamically launching VI's, you must put them in the "Always Include" section of a Build Spec.
Do either of these things help?
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}

Interfacing Siemens Desigo PXC Building Automation controller with LabVIEW

Hello everyone,
I am currently trying to interface Siemens building Automation controller Desigo PXC100-E.D http://www.buildingtechnologies.siemens.com/bt/global/en/buildingautomation-hvac/building-automation...
with LabVIEW using OPC servers. I had once interfaced the S7-300 PLC of Siemens with simatic step-7 software with LabVIEW but in this case I don't which driver should I select and don't know is it possible or not. If any one of you have similar sort of expierence please I need advice..
Thanks
Naqqash.
Naqqash

Hi,
As you have described I've done the whole configuration. I am using MatrikonOPC for BACnet and as I've checked my device and the software are working properly. Now what I am trying to is that I am connecting the BACnet OPC server with LabVIEW so that the MatrikonOPC act as a connection layer between my device and LabVIEW. So that I will be able to change values directly from my LV vi. Now when I connect that Bacnet OPC with LabVIEW using the same procedure for PLC it gets connected because it is showing all the tags from the device. But after doing the whole procedure which is the same according to the tutorial 'connecting LV to any PLC using OPC' when I deploy the variables I am getting some error. I am attaching the screenshot of the error. Please let me know if I am doing any thing wrong.
PS: I am using a virtual machine and I've tried the whole thing with the NI OPC servers as well according to the tutorial but still when i deploy variables I am getting this error.
Naqqash
Attachments:
OPC_error.JPG ‏22 KB

Problems installing FP v4.1 with LabVIEW v6.1 application

We have a LabVIEW v6.1 application that interfaces to a FieldPoint FP-1000 Network Module for its I/O. We have been distributing it to customers for about 18 months with the FieldPoint v4.0.1 driver - no problems other than some difficulty getting the Watchdog Timer setup properly via MAX.
The latest purchase of FieldPoint hardware came with FieldPoint v4.1 driver. There are three issues that have arisen with the advent of FP v4.1.
1.) There occurs several (identical) warning messages during the FP v4.1 installation on Windows XP SP2 (the exact number depends on the selection of features to install). The message is "Error 1931" and it says that Windows stopped the installer from updating the stdole2.tlb file. It suggests that we update the OS, which has been done, but the messages continue.
Question: is it critical that the stdole2.tlb in the FP v4.1 distribution be installed, or is this an error with no consequences?
2.) When installing FP v4.1, we select LabVIEW v6.1 support, but disable the Real-Time v6.1 Support and the Examples. We also disable the LabVIEW v7.0 and v7.1 Support and the LabWindows/CVI Support. We keep the Documentation and MAX features. We have gone through the install/uninstall cycle several times and each time when uninstalling the list of features includes LabVIEW v7.0 Support - not v6.1.
Question: does this indicate that the installer is erroneously installing v7.0 support and omitting the selected v6.1 Support? Or is this just an error in what is displayed by the uninstaller?
3.) After FP v4.1 is installed (with LabVIEW v6.1 Support selected) our LabVIEW v6.1 application runs but fails to communicate with the FP-1000 Network Module. Upon quiting the application, there is an error message stating that the FP.Open.vi failed to run because the FieldPoint Server .dll was not found (no filename for the server- just ".dll").
Question: Is this an issue of the installer not putting the proper FP Server .dll file on the computer (see question 2) or is this a matter of compatibility (do I need to install FP v4.1 on the development computer and remake my application)? Something is wrong here, FP v4.1 doesn't support a LabVIEW v6.1 application that runs fine under FP v4.0.1. Do I need to install the LabVIEW v7.x Support in addition to the v6.1 Support?

Hi lkj,
There has been few reported problem with installing FP4.1 in LabView 6.1, but none of them are similar to what you are experiencing. According to the 4.1 driver documentation certain vis from this driver version cannot be installed and used in LabView 6.1. What I would suggest is to uninstall the current driver and revert back to the ver. 4.0.1 since we know for sure it works in the LabView 6.1 environment. If you you'd like to use the 4.1 driver, then if would suggest upgrading to LabView 7.0 or 7.1.
Regards,
Natasa

Problem when building an executable with labview 6.1

Similar Messages

Maybe you are looking for