LabVIEW class compatiability with TestStand

[davidpcl]

Just a general question about using LabVIEW classes with TestStand aimed mainly at the NI guys on here.

I've just finished a set of fully object orientated instrument drivers using LabVIEW 8.2.1 and having used LVOOP for this I have to say that I like it so much that I am going to find it difficult to do LabVIEW tasks in the future in any other way. The only slight moan I have is with the inheritance functionality which I don't think it quite there yet, or at least it was not appropriately usable for what I am doing.

Anyway - we've now started calling these vi's from TestStand and have found that they lose their .lvclass prefix. We thought this could have caused a problem with different classes having the same method names, but it appears that TestStand is able to get around this by using an absolute path, and when you build a deployment it simply renames the duplicate vi's - it's maybe a bit in-elegant, and far from ideal but works.

Just really wondering if it is likely that TestStand will recognise LabVIEW classes in the future, or if there is any sort of update that will allow it to do so now.

Nothing major, just something I'm quite interested in knowing.

Many thanks in advance for any responses,

[Scott_Richardson]

David -
TestStand does not support directly calling LVOOP VIs, but it is something that we will look at in the future. As you may already know, TestStand can call non-LVOOP VIs that use LVOOP VIs. What we recommend is that if you need to pass the LVOOP object to TestStand back from a VI to pass it back to another VI that TestStand calls, you must flatten the object to get it into a TestStand variable and unflatten the string back into the object in the VI that you call.

[davidpcl]

Hi Scott,

Thanks for your reply - it's a shame that there's no plans on the horizon to let TestStand recognise LabVIEW classes - I guess it just means being careful with the naming of vi's within classes if you're going to use them with TestStand i.e so that you don't get any kind of name duplication, but that's not a huge issue.

Thanks again for you response,

[dofr]

Hi,

When flattening / unflattening an class instance like proposed above, do we loose any informaton that can prevent dynamic dispatching functions?

For example, a factory VI creates a CDerivedClass instance and flatten it to string such that TestStand can store it.  TestStand then call an other VI (say a test algorithm) with this string as input parameter.  The test algo VI "unflatten" the string to a CBaseClass instance.  The algo VI calls a dynamic dispatch VI.  Which dynamic VI gets called ?  The one in the CBaseClass or the one in CDerivedClass.

Thanks,

dofr

[Rick_Francis]

dofr,

>When flattening / unflattening an class instance like proposed above, do we loose any informaton that can prevent dynamic >dispatching functions?

No, flattening does not lose information as LabVIEW classes are a by value data type.  

>For example, a factory VI creates a CDerivedClass instance and flatten it to string such that TestStand can store it.  TestStand then >call an other VI (say a test algorithm) with this string as input parameter.  The test algo VI "unflatten" the string to a CBaseClass >instance.  The algo VI calls a dynamic dispatch VI.  Which dynamic VI gets called ?  The one in the CBaseClass or the one in >CDerivedClass.

I coded up this example and the derived class's dynamic VI still gets called.  There are some possibile ways you could get into trouble:  If there are no instances of the derived class in memory LabVIEW may unload the VIs for the derived class.   If you are storing refnums in your class there is the potential that the refnum could be closed while the class is flattened.  If this happens the class will still unflattened w/o an error but the refnum wouldn't be valid.  These problems occur with dynamic loading/unloading,  if you load at the start of the execution and unload when the execution is finished you generally shouldn't see these problems.

-Rick Francis

[dofr]

Thank you, especially for the warning on the dynamic loading / unloading issue !

dofr

[ATE_Dude_22]

I am having a similar issue with LabVIEW 2011 SP1 and TestSTand 2010 SP1. This ATE uses vi's that are member's of class libraries, and the behavior I am seeing is sometimes when you open the vi's from within TestStand sequence editor, sometimes the vi will open up broken, and cite a myriad of issues with DAQmx drivers, canned LabVIEW function vi's, and of course membership issues for vi's claiming to be part of classes but the class reports that it isn't. Now these are working vi's that have no problems anywhere in their heirarchy, but yet open up broken. However, if you close the vi, and then refresh the VI prototype, this same vi will now up just fine with no errors.

Earlier in this discussion I read that TestStand is not compatible with LVOOP vi's, but I believe the problem goes deeper, can anyone better explain what may be occurring in this situation?

[buton]

i have teststand 2014 and labview 2014 and they run pretty good with classes calling directly from teststand

[ATE_Dude_22]

It would not suprise me if the issue i am seeing was solved with later versions. Unfortunately, I am stuck at this version because of a driver incompatability with NI-FGEN.

I'm just trying to gain a better understanding of what may be causing the behavior, then maybe I can come up with a work around that won't force me to have recode the entire ATE.

Thanks.