Packed project Library Labview Class Issues

I packed my whole Labview project as a packed proj library during teststand Deployment
I am using classes in my labview project
unfortunalely by one of sub seq calls got the following error !
"Type mismatch. The LabVIEW Class does not match the class expected by the VI.
Cannot pass a base LabVIEW Class to call a method initially defined in a derived LabVIEW Class."

The error message is quite clear:
You are using inheritance where you do have methods which are not part of the parent class (as dynamic dispatch).
During the call, you pass an object of the parent class and try to call the (unknown) method of the child.
Why this is happening can only explain your code....
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Similar Messages

Packed Project Library (lvlibp) slows LabVIEW Project

Hello,
My LabVIEW project (2010SP1) perfoms well except when I add a critical library provided by my customer in the form of a LabVIEW Packed Project Library. Activities like loading the project, opening VIs, running VIs, editing VIs respond VERY SLOW (about 20X). In contrast, if I open VIs in the LVLIBP without loading the project, everything responds at a normal rate.
Any suggestions?
Jorge

Hi Jorge,
May I know what does that Packed Library contain? I have read about a similar issue but in that case they were running some TestStand benchmarks that loaded a packed library.
Jorge
Applications Engineer
National Instruments
Certified LabVIEW Associate Developer (CLAD)

Packed project library 1003 error when building it

Hi,
I am trying to build packed project library, but I get 1003 error. I have tried all things suggested in other threads regarding the 1003 error, but nothing helps.
My two project HardwareSpecificFunctionalities and ModuleTemplate are attached. HardwareSpecificFunctionalities PPL is used in the ModuleTemplate's VIs. When I am trying to build ModuleTemplate PPL I get 1003 error saying that one VI is broken, but actually it is not. If I remove the ReadOffset.vi from the AcquisitionInitialization_Main.vi, the ModuleTemplate PPL is build successfully.
Have anybody an idea what is wrong?
Attachments:
PPL problem.zip ‏1230 KB

Hello Andrej.
I just noticed that in document LabVIEW 2011 and 2011 SP1 Known Issues (http://www.ni.com/white-paper/13164/en#323425_by_Category) it is stated that this bug will be fixed in LV 2012 (32 bit).
This version of LV will be available in August 2012.
All workarounds that are known, are the one that are described in this link.
Kind regards,
Sofija

Packed Project Library error: contains compiled code

I was trying to figure out how the packed library works for LVOOP, but face a wall with an error and don't know how to solve it.
i) I made a class 'Class 1', which I then put in a library called 'library'.
ii) I create a Packed Library and set the top-level library in the source files
iii) Once compiled and saved, I create a new project and add the newly create Packed Project Library to it. Second I add a newly create class, named 'Class 2'.
iv) I set the inheritance of the Class 2 as a child of Class 1.
v) select new VI for Override
vi) get Error 1035
What am I doing wrong or how to solve this?
Solved!
Go to Solution.

The default setting for packing VIs into lvlibp's will remove the block diagram.
You must not remove the block diagram for dynamic dispatch VIs you are going to override.
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Packed Project Library Shared With OI?

I have an application which needs to share some resources/instruments with TestStand steps. The requirements require the application to communicate with these resources/instruments with or without the TestStand Engine running.
I understand that the suggested approach is to ONLY place instrumentation code in a test sequence. However, what is the best approach if the application requirements dictate the resource/instrument must be shared?
Can a packed project library be shared with the operator interface?
Is a source distribution the only option?
CLA, CTA
Solved!
Go to Solution.

> What Language are you using?
LabVIEW
> Is it possible to get a more detailed explanation of what you are trying to do?
Read and write from instruments in both my Code Modules and my Operator Interface
Implement Diagnostic Panels without requiring the TestStand Engine
When the TestStand engine is not running, I would like to read and write from the instruments in debug panels on the operator interface.
Implement Status Panels without requiring the TestStand Engine
During a TestStand Sequence, I only wish to read from the instruments in the operator interface (IO status panels).
Implement a few high-speed timed loop state machines within LabVIEW. These loops must start running as soon as the application is launched and for the lifetime of the application. I would like to share the state/data of these loops with TestStand and allow a command/response interface.
> It is possible in TestStand to run the test Sequence in a independent execution as long as it has the references to the source files.
What if I want to start a VI that talks with an instrument. Why can't I open a serial port in the OI and pass the session to the TestStand API?
Why is is "better" to call a Code Module VI in a new execution vs just calling the VI from the Operator Interface? For example, if I want to display the "status panel" of a digital input card...
> You mentioned that you need the program to sometimes run even if TestStand is not running, will these programs ever be running at the same time?
There will only be a single application that launches the TestStand Engine.
The idea is that the program utilizes the TestStand engine to run automated tests. I would like to allow the OI to read the current values (status panels) while TestStand both reads and writes.
Additional Questions
I would like to understand how TestStand executes LabVIEW VIs differently with the Development and Run-Time adapters.
If I run a TestStand sequence with the LabVIEW Development System Adapter, from my Operator Interface (OI) I can call code modules and vice versa. This will work for VIs within the context "Main Application Instance" (no project).
When I deploy this system using the LabVIEW Run-Time Engine with a built "Operator Interface" EXE, it seems they may run in different "Contexts".
Why is the separation between User/Operator Interface and Code Modules required?
The TestStand Reference Manual states "Do not use instrumentation code in user interfaces". Why?
If I change the Preferred Execution System in the LabVIEW VI (that is running in the OI) settings to "standard" is this ok?
I hope this detailed response explains my goals adequately. Thanks for your assistance.
CLA, CTA

Private inlined VIs and packed project libraries

So, I'm trying to build a packed project library and it has a few *private* VIs that are crying out to be inlined (simple VIs used in a for loop etc). However, this seems to be causing a few issues:
1. When I attempt to build the lvlibp I get an error stating "You cannot include inlined VIs inthis build if you remove the block diagram from the VI or if callers adapt to VIs in the packed library.". Whilst this makes sense to me for public packed library VIs, why does this matter for private ones - surely the VI will already get flattend out into the calling VI during the build process?
2. If I try and set the Source File Settings for the inline VI to not remove the block diagram (as suggested by the error), the error still does not go away (I would really like to keep the ability for callers to adapt to VIs in the packed library).
Here's a stripped out project (with instructions) showing the issue.
It seems like a bug to me, but any ideas?
Thanks,
Shaun
Attachments:
Inline VIs and Packed Libraries.zip ‏19 KB

I was just going through the instructions to reproduce the error. Because the error says "You cannot include inlined VIs in this build if you remove the block diagram from the VI OR if callers adapt to VIs in the packed library," it seems like as long as you maintain your settings for the caller to be able to adapt the VI, then I would expect this error to continue to occur.

"The LabVIEW project library does not sharre a common path to disk with the files the project library owns" msg

I thought this was a file the project library owns. So what's up?

2and4 wrote:
What if I have no application? In other words I'm trying to build an installer ONLY to distribute an XControl? I get this error and I don't know how to correct it. Thanks in advance!
Answered here
Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas
LabVIEW, programming like it should be!

Using LabView class in multiple projects

Hello,
I have created a LabView class that I'd like to use in multiple projects while using source control (we use Serena for this) with the source files of the class in a centralized location (not seperately for each project as I don't want the code of the class to diverge in the different projects). Now I'm wondering what is the best way to accomplish this. I see a couple of different possibilities:
- Have the class VIs at a certain location in the repository and link to all the files from the other projects in the repository. This will mean I will have all the files in all the project folders on disk but only one archive in the repository for them as they all link to the same location. Problem: Serena cannot create links to folders, so every VI has to be linked and if the structure of the class changes or VIs, the links have to be updated in each project -> not very nice
- Have the class VIs at a certain location in the repository that will be checked out to a certain path on the local hard drive and add the class VIs to the projects from this fixed path. Problem: it's not guaranteed that the path will be the same on all computers. Some team members might check out to a different location -> bad solution
- Use a .llb file that is also in the repository and create links to it from the different projects, i.e. the source files will only exist at one location on the hard drive but in every project folder there will be an .llb-file that will come from a single archive in the repository -> actually my favourite solution. Problem: I use the VI Server to call VIs by relative path inside the class and this works differently inside the .llb, since there seems to be no folder structure anymore. If there was a good workaround for this, this might be the best solution
Does anybody have experiences on how to do something like this? Are there other possibilities to do it?
Thanks,
Tobias

Hi,
thanks for your reply.
I think I have to make my question a little clearer. Say I have a class ClassA that uses some VIs that are in the same folder (or subfolders) as the class file. Now I put all of this in an SCC repository at the path /SCC/ClassA/. Now I have two projects that use this class and are located in the SCC repository at /SCC/Project1/ and /SCC/Project2/. Now some people might check out /SCC/ to c:/Projects, other people might check it out to d:/SCC so the absolute paths of the resulting files on the disks could be different. This makes it hard to add ClassA to both projects because on one computer the path to it would be c:/Projects/ClassA/<ClassName> on the other it would be d:/SCC/ClassA/<ClassName>. A common solution for this that we use for C++ projects is to create links inside the SCC, link the source files or a DLL inside the SCC to the /SCC/Project1/ and /SCC/Project2/ folders. This will create multiple copies of the DLL on the harddisk, one in the Project1 folder and one in the Project2 folder.
Another solution might be the one you proposed, to have the sharde files inside the <LabVIEW> folder. However there are a couple of downsides to this, as far as I can see:
- It won't work for people who don't have local admin rights (and actually having to change the files inside the "Program files" folder for development is not a good idea, imho)
- It makes it quite hard to guarantee that both the projects and the shared files are always the same version (for example if I want to build an older version of Project1 I might need an older version of the ClassA, too. If I have it all inside one project in SCC, I can just get an older label to some folder and build it. If I have the shared files in the <LabVIEW> directory, I will have to replace this. There is no way to have multiple versions (older and newer) parallely on the disk in different folders.
Tobias

Variable in class path of project library

Hi,
When you create a project library in JDeveloper 10.1.3.4. then you must specify the full path to the corresponding jar file, for example c:\subversion\ebab\trunk\web\lib\...\library.jar. Is it possible to define some kind of variable %TRUNK_DIR% so you can define the path as %TRUNK_DIR%\web\lib\...\library.jar?
The libraries we depend on in our project are checked in in subversion but on the PC's of the different developers the local folder where the module has been checked out differs.
Best regards,
Vincent Botteman

I am not sure about the possibility of this but actually JDeveloper doesn't use absolute path to locate the library , it uses relative paths which is according to the location of the project so if you keep relativity same it should work fine at all machines.

Open VI Reference for a Project Library VI

Hi,
my code calls some subVIs by reference by using "Open VI Reference" and "Call by Reference" VIs. Now, "Open VI Reference" expects a path to the VI:
When the SubVIs sit in the same folder as the calling VI, it is easy to simply supply the name of the SubVI. However, I would like to call a SubVI that is part of a project library sitting somewhere else on the disk. I could give the relative path, but this make the code pretty inflexible and if the relative path changes all the paths would need to be ammended. Ideally, I want to utilize the fact that I am using a project library. The help for Open VI Reference states that
vi path accepts a string containing the name of the VI that you want to reference or a path to the VI that you want to reference. If you wire a name string, the string must match the full delimited name of a VI in memory on that target. If you wire a path, LabVIEW searches for a VI in memory that you previously loaded from that path on the same target.
I thought that the underlined path was my ticket and tried something like this:
but this did not work and I got
"Error 1004 occurred at Open VI Reference in MainVI.vi:
Possible reason(s):
LabVIEW: The VI is not in memory.
To load a VI into memory with the Open VI Reference function, a path must be wired for the VI Path input."
Wiring a path is not desirable as per reasoning above. Is there a way around the issue?
Thanks in advance!
Solved!
Go to Solution.

tst wrote:
That should work, but you have to pay attention to something that's stated both in the help and in the error - if you use a string, the only way for LV to know what to access is if that something is already "in memory" (sometimes also referred to as "being loaded"). In the case of standard libraries, that means the VI itself or one of its callers has to be loaded. In the case of classes and XControls, loading the library (as in having it in an open project) should be enough to also load all of its members.
Hm, thanks, I am not advanced enough to know about classes and XControls, but I will check it out. My VIs are part of a library but obviously don't get loaded because, as you said, all their calls are dynamic.
tst wrote:
What I usually do is use a static reference to a VI to get its name, because that ensures that it will be statically linked, included in executables, etc. That might not work for you if you want dynamic loading and then you will need to use some other means.
Hm, this actually gives me an idea! I could add an enable input to all these dynamically called VIs so that the logic runs only when enable is ON; otherwise the VI is called but does nothing. Then I call the VI first statically with enable=OFF just to load it in memory and then proceed with my dynamic call. A little ad-hoc, but should work and serve my purposes, I think.
Thanks!!

LabVIEW classes and mass compile

Just wondering if anyone out there has found any problems mass compiling LabVIEW classes, as I am having what appears to be totally un-resolvable issues - I get a list of VIs that either say BadsubVI or BadVI all of which I have verified are error free.
The only thing I can round it down to is the use of the lvclasses, and in particular the fact that I'm making extensive use of the inheritance functionality, and also a few override vi's.
It wouldn't be such an issue except that I'm calling some of these vi's from TestStand, and am unable to get a deployment to work without a successful mass compile.
Appreciate any responses,
David Clark
CLA | CTA
CLA Design Ltd
Hampshire, England

I'm not sure if it's the same problem but I had a vi that would compile into an unrunable exe. I found the problem by mass compiling the project, which came up with a bad vi and bad subvi's that used that vi. Turns out my problem was that I had two classes with the same name (even though they were in separate lvlibs). And renaming one corrected my problem. LabVIEW 8.5 gives a warning and renames the compiled vi's (so if you could try 8.5, that might help you find the problem quicker assuming it's related). It seems to me that the name spaces provided by lvlibs go away when compiled into an exe or by the mass compiler (It may just affect lvlclasses).
Matt

LabVIEW Class crash - ntdll.dll access violation

Hi,
When I close my LV11SP1f2 I always get a warning.
It didn't bother me until a vi I wrote that uses a class with nothing out of the ordinary started crashing my LV.
The crash says that: "DAbort 0x37C03D in MemoryManager.cpp"
I sent the log files to the local support and they saw that the common issue between my logs is an access violation in ntdll.dll.
Any operation that uses the property nodes of that crazy class fails, sometimes with a crash and sometimes with a error that sends me to a bundle by name in the autocreated property node.
I rewrote the project with the class and there is no error.
Sending the crashing project to another computer gave no error.
Before I go on and investigate windbg to search for a conflicting app and finally formatting my entire computer could some1 help? Please...
I attached several logs for example.
Thanks in advance,
GoofyWires.
Attachments:
92c82e7b-fa2a-43af-b2be-a6650c031681.zip ‏2485 KB
daa462b5-9395-4e3f-8894-05a3bdb3d159.zip ‏65 KB
ea2c40ef-056d-41ed-a4c5-9cf4bc6666fc.zip ‏494 KB

I did a clean format and reinstalled LabVIEW 11.0.1f2 without adding many of the add-ons from VIPM and without installing the rest of my shortwave, yet, the crash is still here!
I was able to reproduce it on my pc:
1. I have a class that contains two children of another class which each contain another class with a class inside it.
2. I accessed the classed through property nodes.
3. I then went on and deleted a private data from the first class control, deleted its property nodes and added a new private data to that class control and added the property nodes for it.
4. I updated the vi that used the classes to stop using the deprecated property node and start working with the new one.
5. I did a "save all" and run the vi. All OK!
6. I closed LabVIEW and reopened the project and run the vi which is not broken! LabVIEW crashes!!!
I guess the complexity of the class is not the issue and it can be reproduced in a much simpler way.
Yet, since I bet the scenario caused you to raise an eye brow I'll give an example as an analogy:
File Handler class contains ASCII Read class and ASCII Write class which inherit from class ASCII.
Class ASCII parent contains class Headers while class Header contains class Data.
Thus, class ASCII Handler will use class ASCII Read/Write to give a high level simple interface while during the read/write the inner ASCII Read, for example, will add to the Header class in it the read data which will in turn be added to the array in the private data of class Data.
I'll try and reproduce it on a different pc and send the local NI support the code and way to reproduce.
I see two possibilities:
1. Something is wrong with my new Dell PC.
2. LabVIEW doesn't handle and propagate correctly changes in a class to all the vis that use it. Maybe changing the array size in a class overrides some memory since the class can't change its size.
Please let me know if this rings a bell.
Update: I coundn't reproduce the crash on my pc with a simpler case. There is something missing...
I'll try to replroduce with the complex class on a different pc and if it crashes I'll simply send my original code.

Labview class data read node problems

I've been noticing some odd things when i use read\write nodes on labview class objects.
It seems like at some point the link between the read node and what it's supposed to be doing gets broken - so that it reads out the 'default' value of the data than the actually written value. I have worked out how to fix it when it happens - by deselecting the correct node, and then reseleecting it - seems to refresh whatever is happening underneath - although it is a pretty annoying bug.
It seems to have started happening in the last few months when i updated to LV2011 SP1 in code that had been unchanged for at least a year. (so LV2010).
I can't quite pin down the exact circumstances because it seems a bit transitory. It seems to mostly happen after labview crashes - which seems to happen quite often in LV2011. I have a feeling it might be especially when you do class inheritance.
Anybody else noticed this behaviour? Have been wondering if I should avoid using these node read\writes, and go for the actual VIs.
JP

Hi JP,
Many thanks for your post. I have been using LabVIEW 2011 for a recent OOP project and not experience this behaviour so believe it could be an issue introduced in SP.1.
I have checked and this is not a known issue with LabVIEW 2011 SP.1. I have had a go at recreating the issue in SP.1 but have been unable. In order for me to report this as a known issue and ensure it gets rectified I need to be able to recreate the behaviour. If you are able to explain some steps to recreate the issue then this would be great. Alternatively, could you send me in a VI/project which has the issue?
If it seems to occur after a crash then I suspect the two are related and the key will be identifying what is causing LabVIEW to crash.
Best Regards.
Aaron. E
Applications Engineer Team Lead
National Instruments
ni.com/support

Pleassss i want to know bi 7 supporting project point or production issue

Hi expert,
i am pradeep .a job seeker could pleassss help me. i want to know bi 7 supporting project point or production issue and in bi 7 what are role in production project .shore to assign point my id is [email protected]
thanks&regards
pradeep.k

Hi,
It may vary in different projects.
I can just give you a couple of general roles in Support project
Data Load Monitoring:
1.Carried out data load on a daily, weekly and monthly basis using Process chains from both SAP Source systems as well as Non-SAP Source systems such as Informatica.
2.Resolving Data load error such as Invalid characters, Time period conversion, Currency conversion, Duplicate records, etc
3.Ensuring the availability of the updated data in the datatarget on time.
4.Spooling out data through Infospoke from SAP BW to systems like Trillium, Ariba (Reporting Tool)
Ticket Resolution:
1.Process chain modification: Working on Optimizing Process chain by creating new process chain considering the load dependencies.
2.Reloading of R/3 data from different clusters Reconciliation issues
3.Enhancements as per Business requirement.
Additional responsibilities:
Preparing design documents from the Business Requirement docs and identified the relevant data targets for satisfying the customer requirements.
Creation of Operational manual: BW Run & Maintain Support.
Process Chain Detail Documentation (Sequencing & Dependency within Local Chains).
Monitoring checklist Document (From Process Chain Perspective)
BW Doc checklist preparation
Table space activity with basis team.
Data load analysis taking into account the CPU utilization.
Applying Support packs and performing ORT.
Refer
Roles & Responsibilities for Junior & Senior consultants(Technical)
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/08f1b622-0c01-0010-618c-cb41e12c72be
Production and Implementation
/message/4755150#4755150 [original link is broken]?
hope this helps,
Thanks,

Web Service Import Error - Can't Create Project Library

Hello,
I'm haiving an issue importing a particular .NET web service using the import wizard. I'm running .NET 2.0 framework and LV8.2. I have followed this tutorial and successfully got a few simple services working. I can successfully import an use simple web services like this one with no issues, but when I attempt to import a local web service I keep experienceing the same error at the end of the import, the error is:
The following errors/warnings occurred when generating the local proxy dll and VI wrappers for this web service.
Can't Create Project Library.
Project Library Generation Failed.
Possible Reasons:
1) The imported project library has a conflicting name with a project library already in memory.
2) The imported VIs have conflicting names with VIs already in memory.
Close the project library and VIs and reimport the Web Service.
ionService.lvlib
I seriously doubt that the error is actually caused by 1 or 2, I think this is just the default message for some other error. I have cleaned all previous failed projects from the userlibs and opened and closed the program, restarted etc... I have also tried this and got the same error with another machine running .NET 1.1 and LV8.2, same error.
The service's WSDL page seems to be working correctly, LV sees the availble functions and lists them correctly for import, it just always fails when creating the DLL wrappers.
I have included the WDSL XML file for reference.
Anyone have any ideas for fixing this?
Thanks,
Adam
Message Edited by ajckson on 05-20-2008 04:27 PM
Attachments:
WSDL - XML.zip ‏2 KB

Hi Adam,
Some of the functions in your project library may have the same names as some of the inbuilt functions in LabVIEW or any loaded functions in the memory.
Try closing down all other programs and see if it works.
What are the names of the functions you are using?
You may have to rename them to remove the naming conflict, but you did mention that you don’t think that it’s because of one of those reflected conflicts!!
SubVIs being generated may have the same name as some LabVIEW inbuilt functions which may be causing the problem.
Could you please provide the header file to see the names of the functions?
Hopefully this helps!!
Aashish M
Applications Engineer
National Instruments
http://www.ni.com/support/

Packed project Library Labview Class Issues

Similar Messages

Maybe you are looking for