Read/write LVOOP object using TestStand API

[jsiegel]

Is it possible to read/write a LVOOP object from/to a TestStand variable from within LabVIEW using the TestStand API?

SetPropertyObject() takes a green reference wire, which is incompatible with a LVOOP object.  SetValVariant(), SetValIDispatch(), and SetValInterface() seems to just write a null variant value.  I don't know if I am using the wrong API function or if it is just not possible.

[SerJames]

Hi jsiegel,

Do you think you could provide more context on what you are trying to accomplish as currently there is a little confusion on that matter.

To use a LabVIEW object in TestStand you have to pass it to TestStand first through the connector pane, otherwise TestStand would not know what to think of it as there is no inherent LabVIEW "object" type.

Regards,

[jsiegel]

I'm trying to avoid using a wire to pass an object into/out of a VI from TestStand.  From your message, it sounds like this is not possible?

Instead of passing my object data around in TestStand up and down the sequence hierarchy, I am considering creating an object repository (which may be implemented in one of many ways).  I was trying to have a general prestep VI that retrieves the object from the repository, which may or may not be a TestStand variable.  The prestep VI just has a sequence context input, so that I can change where the VI gets its object from without having the change the TestStand sequence that calls it.  If I choose to have the object stored in some TestStand variable, I would change my VI to programmatically get (or set) the object value with the TestStand API.

[SerJames · Accepted solution]

Hi jsiegel,

That is correct, it is not quite possible to what I believe is your intent. As mentioned, TestStand cannot create the LabVIEW object. To be able to pass and use LabVIEW references with TestStand, you will need to have LabVIEW output that reference, which TestStand can then store as an Object Reference. For VI's that need the LabVIEW obeject as an input, the saved object reference can be passed back in. To make calls to LabVIEW classes you use the Class Member Call with a VI Action Step instead of the VI call for the Type.

Of course, you need both LabVIEW and TestStand 2012 or newer to be able to use these features.

Regards,

[jsiegel]

Thanks for your response, James.  I know that LV Objects are a somewhat different beast from other TS objects, but not being able to use them with the TS API makes the API behavior somewhat inconsistent.  Is this an oversight that may be fixed in a future version of TS, or is this behavior (or lack thereof) intentional?

Jeff

[SerJames]

Hi Jeff,

I would say the best way to look at it is that it is intentional. A big part of it is that since this is a LabVIEW class, there is little need for the API to support operations operating on it. TestStand is not a development framework so operating on a LabVIEW class within TestStand, or providing API functionality to do so,  is not quite intended. That is actually what the Class Member Call command is for, so that LabVIEW can operate on the LabVIEW class objects.

Regards,

[jsiegel]

I understand what you are saying about TestStand not being a development framework and that TestStand would therefore never operate directly on the object like it could with other data types.  But just because TestStand wouldn't directly operate on a LabVIEW object doesn't mean that you shouldn't be able to read/write its value like you can with other TestStand properties.  I don't need an API to manipulate a LabVIEW object, just get or set its value.

Sometimes there are good reasons(?) for reading/writing a TestStand property (such as a number) within a code module without passing it through the connector pane; I would say that the reasons for reading/writing a TestStand property (such as a number) within a code module without passing it through the connector pane would be the same (and, in fact, they are for me).  But I guess you could make the argument that a LabVIEW code module should always read/write TestStand properies through the connector pane, but you can get away with directly reading/writing other (non-LabVIEW object) TestStand properties because the API has to be there to support TestStand's need to do so directly.

Jeff

[SerJames]

I checked with the PSE over TestStand he added that this is also due to the newness of LabVIEW OOP. Full support will take time to get implemented and released. What I would recommend would be to add a topic on the idea exchange that way the developers can see there is demand and can add it accordingly to their development schedule.

Regards,