LVClass Architectures

[ATE_Dude_22]

Does anyone know if there is a way to configure LabVIEW to not load all vi's that belong to LVClass into active memory. I have an ATE running on older PXI-8106 controllers, and what I am seeing at times are vi's appearing to broken because not all memebers of the class library have been loaded into memory, and my fear is that at run-time i could see similar issues that could cause inconsistent performance of the ATE.

[tyk007]

---

@ATE_Dude_22 wrote:

Does anyone know if there is a way to configure LabVIEW to not load all vi's that belong to LVClass into active memory. I have an ATE running on older PXI-8106 controllers, and what I am seeing at times are vi's appearing to broken because not all memebers of the class library have been loaded into memory, and my fear is that at run-time i could see similar issues that could cause inconsistent performance of the ATE.

---

As far as I am aware this behaviour cannot be changed for statically linked classes. Thus I don't think that this is the reason for the problem you are experiencing, unless the application is attempting to dynamically load classes into memory.

Typically when there is an issue with a class as a whole (lvclass file and member VIs) the whole class is blocked - this is the same functionality you have with most project library types that are intended to either "all work or not at all".

[ATE_Dude_22]

Well, as an example, this project uses Class objects for different types of functionality (i.e. Signal Generation, Switching, Model Information, etc...), and the test execution is handled by TestStand. The behavior I am seeing more and more as the ATE grows in size is that when I open vi's from the TestStand sequence editor, after awhile normally working vi's will all of a sudden break citing things like the vi is claiming memebership in a class, but is not a memeber (which is wrong), so I shut down LabVIEW and restart, and the vi opens just fine.

Would like any suggestions you might have to help investigate what may be causing these issues.

Thanks for your response.

[tyk007]

---

@ATE_Dude_22 wrote:

Well, as an example, this project uses Class objects for different types of functionality (i.e. Signal Generation, Switching, Model Information, etc...), and the test execution is handled by TestStand. The behavior I am seeing more and more as the ATE grows in size is that when I open vi's from the TestStand sequence editor, after awhile normally working vi's will all of a sudden break citing things like the vi is claiming memebership in a class, but is not a memeber (which is wrong), so I shut down LabVIEW and restart, and the vi opens just fine.

Would like any suggestions you might have to help investigate what may be causing these issues.

Thanks for your response.

---

I'm going to go out on a limb here and tell you something that I have absolutely no proof for - I never work simulataneously with LabVIEW code and TestStand sequences at the same time (ie. updating a VI while that VI is loaded in the Development adaptor in TestStand). I have had all sorts of strange issues with connector pane updates invalid or the ActiveX adaptor just plain crashing. This often happened when using the "Class Member Call" option - using the standard VI Call type semed to work better.

The "Unload all modules" function only worked for me around 50% of the time - occasionally some modules would not be properly unloaded and I'd have to re-start TestStand anyway.

How we do our work now is by pre-building our modules into PPLS, and then referencing those PPLs in the TestStand code modules. The main down-side is that the LabVIEW version is locked in and upgrades to the ATE will need to re-compile the PPLs.

Just some un-provable "in the trenches" observations I have had.

[ATE_Dude_22]

Agree that the "Unload all modules" option becomes irrelevnt when using LVClass objects. I always use the standard VI call type, so i'm not sure what effect using class call type would have.

My gut had always told me that TestStand was why this issue was occurring, but I have ~4 years with TestStand, and 20+ with LabVIEW, so I'm still finding new things in TestStand on a daily basis.

Thanks again for your ideas.