TestStand locks up when selecting a class member call in complex projects

[Kyle97330]

At my company we use a fair amount of LVOOP classes as hardware abstraction tools and such.  We've got quite a library of hardware interfaces made using these LVOOP classes so when a project came up to use TestStand to create a new series of test stations to replace some old ones we decided that all of the new ones should use these class libraries called from TestStand.

Since were using Dynamic Dispatch VIs for a large portion of what we do, as per this article I used the "Class member call" option for "Call type", then selected the project, and it took a while to load.  When I selected the class, it just locked up the whole TestStand instance.  Repeated attempts sometimes lock it up while loading the project.  One time it did load the class but as soon as I selected one of the VIs in the class it locked up before it displayed the connection pane or the parameter list.

I tried it on another project file with a different, smaller class hierarchy in it (the main project had ~25 classes in it, this one had 7).  Still locked up.  I asked a co-worker to try it on his PC to rule out a problem with my installation.  Also locked up.  

Finally I tried it on a small demo project I had made as a proof-of-concept test.  10 classes, but there was no class data and only one VI per class.  That one loaded just fine and I could call the Dynamic dispatch class with whichever class I wished to and it would behave appropriately.

Therefore it seems to me that there's some sort of issue with TestStand and either Classes or Projects with a lot of VIs in them, or there's one or more element present in the large projects that wasn't present in the small demo project.

Setup:

W7 64 bit

VIs made in LV2015 32 Bit

TestStand 2016 and 2014 32-bit (problem occurs in both).

Any ideas would be appreciated.

[WireWeaver]

Kyle,

This is something we've seen before and are currently doing research internally to find the best solution. Here are some things that can help:

1. Mass compile all VIs in the same version of LV
2. Ensure all libraries use the default sort order in the project
3. Leave the class open in LabVIEW while doing development.

If you have the LabVIEW adapter set to development mode and the class is already in memory - TestStand won't have to load it every time you click on a step.

Hope this helps!

Trent

[buton]

I had the same issue working with clases at teststand. it will take a bunch of time to load my framework..

how did i fix it?

Well  my mistake  was that on the step i was loading Labview project file and picking the class i was going to use. Doing this will load everything that the LabView project has. 

To fix it just call the class directly without the project. it will be much faster...

[Kyle97330]

By switching to the LabVIEW development adapter and having the project open in LabVIEW at the time, I was in fact able to get the VIs selected and put in as steps, and they worked when I ran them.  After that, I was able to change to the Run-time engine and close LabVIEW, and they still worked.

I did notice that it was taking a ridiculous amount of time to analyze the sequence before it ran.  I had 4 class calls (3 from 1, 1 from another) and it took 41 seconds to do an analysis.  When I added 2 more VIs (one from the class that had 3 already, 1 from a new one) the analysis time jumped up to a minute and 15 seconds.  While I'm fully aware that I can turn off sequence analysis, I'm not wild about the amount of overhead these seem to have.  Turning off analysis lets it run in with a minimal 1-2 second delay between the run button and the first step executing.

Can you elaborate on what "Ensure all libraries use the default sort order in the project" means?  Are you talking about directory search order?  What libraries?

[buton]

On the LabView step settings call the class directly and leave the project file empty. that is what i was trying to say.

[WireWeaver]

Kyle,

I'm referring to this help topic.

If you have this property set to 'Custom' it will alter the layout on disk. Switching this to 'Name' can help with load times.

-Trent

[Kyle97330]

Ah, thanks.  I was looking for an option to change the sort inside of TestStand (and failing) so I wasn't thinking you were referring to the sort order of items inside of the LabVIEW project.