LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using LabVIEW DVR Classes in Packed Project Libraries

Hi All,

 

I have a project where a LVOOP class is accessed by reference (using a DVR). This method was chosen because the object data will be modified internally by private methods, multiple clients need access and we are likely to need more than one of them, making LVOOP and DVRs a natural fit. This means that the object is only accessed by a DVR of the object class (with New, and Delete methods to create and delete the DVR). Built and tested in LV 2012 SP1 patch f3.

 

The object is intended to be reusable, so it was built into a Packed Project Library (eg. "PPL.lvlibp"). Using this PPL in another project works comfortably.

 

It is often useful for us to rename the original PPL filename. Validation is not an issue here since we can progromatically access the Oriignal Filename and Version fo the PPL for verification. However if I attempt to access the class inside the renamed PPL, LabVIEW informs me I have a "class conflict". This conflict appears to go away if I open the offending PPL class method call front panel and then close it without modification; however if I attempt to run the VI making the calls to the DVR class LabVIEW will frequently crash (often without the NI Error Reporting Service detecting the shutdown).

 

Does anyone have any experience with this? If I don't rename the PPL, then things seem to work as expected. It seems interesting that renaming the PPL has this effect. Is there any information on the stability of using LVOOP DVR classes within PPLs? Or the structure of PPLs that renaming the filename would effect? NI recommends using a renaming scheme in their white-papers regarding PPLS, but this strategy appears to cause more problems than it solves in this scenario.

0 Kudos
Message 1 of 5
(3,244 Views)

Several questions:

  • How do you rename the PPL? Using the Windows File Explorer or within an existing LV project in the files view?
  • If you are using the Windows File Explorer: Is this PPL already part of a project? If so, are there already VIs calling into the PPL?
  • The PPL works "standalone" or are there external dependencies?
  • Do you use functions like "Current VI Path" or "Application Directory" to browse within the PPL? In case: Do you "leave" the PPL for support files?

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 5
(3,222 Views)

Hi Norbert,

 

In answer to your questions:

  • The PPL is renamed within Windows Explorer. It is not possible to rename the PPL in the Project Explorer in LabVIEW (I've tried but it's not an option). If it is a dependency to a PPL build spec, and I select the prefix option in the PPL build spec, it does not change the PPL's filename either.
  • The PPL is not already part of a project when it is re-named. A new LV Project with top-level VIs refer to VIs within the re-named PPL (and thus it is a dependency). Adding the PPL to the project explicitly does not influence the effect I see.
  • The PPL is stand-alone.
  • The only PPL heriachy VI that is called are the PPL API functions (Packed Library Path.vi) in order to ascertain the PPL Version and Original Filename properties.  This is called in one stand-alone VI within the PPL (eg. a "Version.vi" built solely to identify programatically the PPL's identity). This Version.vi works just fine and returns the expected file information

I have attached a simple example (PPL Renaming.zip). It contains three projects:

  • PPL Project A is a project that contains a ByRef class, built into a PPL
  • PPL Project B is a project that contains a ByVal class, built into a PPL
  • PPL Test Project is a project that contains the built PPLs and renamed (in Windows Explorer) PPL versions (4 PPLs). There is a VI for each of the four PPLs that attempts to call methods. This example also shows me that a ByRef and ByVal class shows the same mis-match behaviour.

This example hasn't crashed LabVIEW (yet, the night is young) but it does illustrate the wire mis-match. I have another example that demonstrates a similar PPL re-name situation that appears to take LabVIEW down reliably. I can attached this too if you are interested. Just don't want to flood with information.

0 Kudos
Message 3 of 5
(3,209 Views)

Hi,

Can you please upload the example which crashes LabVIEW?

 

Thanks,

0 Kudos
Message 4 of 5
(3,134 Views)

@Australia_ wrote:

Hi,

Can you please upload the example which crashes LabVIEW?

 

Thanks,


Hi there. I believe I have already emailed your ni.com email address with a link to the code. I am not permitted to upload the code here directly. Thanks!

0 Kudos
Message 5 of 5
(3,128 Views)