TestStand & Labview Classes?

[Daklu]

Silly non-Labview-specific question: How does one go about using Labview classes in TestStand?

I designed and implemented an entire class heirarchy with the idea of using TestStand to glue it all together. I plunked my first VI using a class and discovered TestStand doesn't know what a class is. Any idea how to pass an object from one VI to the next?

(I sure hope the last months of work hasn't been wasted.)

[Omar Mussa]

QUOTE (Daklu @ Aug 20 2008, 05:21 PM)

Silly non-Labview-specific question: How does one go about using Labview classes in TestStand?

Actually, this is not a silly question. I don't know if NI has even tried using LV Classes in TestStand. You may be sort of stuck in a sense ... TestStand can't even properly pass Variant data to LabVIEW... A workaround exists but it kindof sucks ... I think your best bet will be to flatten the class to string and basically write it to file and just have TestStand pass around a filepath to the Class data. I have a feeling that this is your best option. On the plus side, if TestStand has issues, you'll be able to inspect your LV Class data and have a really good idea of what happened during the test that crashed. On the negative side, you can't use TestStand to actively 'use' the data in your LV Class. I'm not sure exactly what you intended to do with the classes from within TestStand -- hopefully your only goal was to pass them from one step to another. If you had other ideas, please post and maybe a solution exists but I'd be surprised.

QUOTE (Daklu @ Aug 20 2008, 05:21 PM)

I designed and implemented an entire class heirarchy with the idea of using TestStand to glue it all together. I plunked my first VI using a class and discovered TestStand doesn't know what a class is. Any idea how to pass an object from one VI to the next?

(I sure hope the last months of work hasn't been wasted.)

Well, no offense but the lesson learned is PROTOTYPE before you dive in too far (a month is WAY too far). If you can't get a prototype to work, you need to find a solution or redesign -- tech support or forums are helpful for that too.

[Daklu]

QUOTE (Omar Mussa)

I think your best bet will be to flatten the class to string and basically write it to file and just have TestStand pass around a filepath to the Class data.

That's almost what I did. I flattened it to a string and just pass the string from step to step. (I am lucky in that I wasn't planning on having TestStand do anything with the classes.)

QUOTE (Omar Mussa)

TestStand can't even properly pass Variant data to LabVIEW... A workaround exists but it kindof sucks

I just ran into this problem today. Is the workaround flattening the variant to a string?

QUOTE (Omar Mussa)

Well, no offense but the lesson learned is PROTOTYPE before you dive in too far (a month is WAY too far). If you can't get a prototype to work, you need to find a solution or redesign -- tech support or forums are helpful for that too.

None taken. You've heard of biting off more than you can chew? With this project I can't even get a bite... I have to swallow the whole thing in a single gulp! There are a couple reasons why I didn't prototype the TestStand part of this project before developing code:

• TestStand came to the project late. It wasn't part of the original design and only surfaced within the last two weeks.
  
• The local rep indicated that he had never tried LVOOP with TestStand but he expected it would work.
  
• I've been a bit overwhelmed by the scale of the project and the amount of new information I've had to learn. 6 weeks ago I had done pretty much nothing with LVOOP, NI-Motion, or TestStand. "Drinking from a firehose" doesn't begin to describe it! I'm thinking sticking my head at the base of Niagra Falls is a more apt description. To avoid drowning I put off the TestStand part, expecting that it would work.
  

To be honest, wrapping my class methods in a flatten/unflatten vi isn't that big of a deal. I am wondering if I'm trying to use TestStand with Labview modules that are too small. (i.e. Don't do enough) Maybe I should bundle them into larger components.

[Rick Francis]

QUOTE (Daklu @ Aug 22 2008, 02:26 AM)

That's almost what I did. I flattened it to a string and just pass the string from step to step. (I am lucky in that I wasn't planning on having TestStand do anything with the classes.)

Flattening the class is the only way to pass a class between TestStand and LabVIEW because LabVIEW does not currently support passing classes in their activeX interface. But flattening is well supported because LabVIEW needs to be able to flatten classes in order to save them to disk.

QUOTE (Daklu @ Aug 22 2008, 02:26 AM)

To be honest, wrapping my class methods in a flatten/unflatten vi isn't that big of a deal. I am wondering if I'm trying to use TestStand with LabVIEW modules that are too small. (i.e. Don't do enough) Maybe I should bundle them into larger components.

That is generally a good idea- there is a lot more overhead making a call from TestStand to LabVIEW then LabVIEW calling a subVI. Try to avoid calling LV for code that takes less than 1ms. Also, try to make a TestStand Step for each items that you want to see in your report- you don't want to have TS call a single VI that returns a pass/fail Boolean and no info when things fail!

For example, let's say you want to take 100 points, average them, and perform a limit test. You should NOT loop in TS and take one point at a time in your LV. Instead use a single numeric limit test step to call a VI that takes the points averages them and returns the value to TestStand. Make your VIs very modular so that you can pass the number of points, the channel info etc. so this VI can be easily re-used by changing the parameters in TestStand.

-Rick Francis

[Aristos Queue]

For the record, Rick is an NI TestStand developer.

[Omar Mussa]

QUOTE (Daklu @ Aug 22 2008, 12:26 AM)

That's almost what I did. I flattened it to a string and just pass the string from step to step. (I am lucky in that I wasn't planning on having TestStand do anything with the classes.)

Actually, passing the string is probably better than writing it to file -- as you can keep everything in memory. Good one.

QUOTE (Daklu @ Aug 22 2008, 12:26 AM)

Is the workaround flattening the variant to a string?

That might work -- you should try some prototyping and see for yourself Make sure to reply to this thread on whether it worked for you or not!

In my project where we planned on using variants, the goal was to pass configuration data clusters of wildly varying types between LabVIEW/TestStand as variants. We ended up using a functional global in LabVIEW that stored the configuration data and having to basically create a custom TestStand type for each configuration (which sucks because it is harder to maintain as now our 'Types' are defined in 2 places -- a LabVIEW Type Definition and a TestStand Type Definition). Another thing that is bad is that TestStand doesn't have an equivalent to LabVIEW's 'Apply Changes' when it comes to changing the TestStand Type definition so you have to manually update every step that uses your custom type whenever the type changes.

[Daklu]

QUOTE (Omar Mussa)

That might work -- you should try some prototyping and see for yourself

Naw... I think I'll code for a month and then try it out after I'm done. It's much more exciting that way. :laugh:

Actually, since the TestStand Gods (one of which sounds remarkably like Rick Francis) indicated I should bundle up my VIs into larger elements, passing variants becomes a moot point in my case.

(Thanks to His prophet AQ for bringing His attention to my questions. What is the penance for my sin of too small TestStand elements?)

[jzoller]

QUOTE (Aristos Queue @ Aug 22 2008, 10:18 AM)

For the record, Rick is an NI TestStand developer.

He got a great member number

[Lars915]

A couple more observations to throw out. I also found that TestStand does not honor the LabVIEW project paradigm either. This could have some effect on handling classes. As for passing variants, I do that a lot. The only requirement I've found so far, at least for single values, is that variables must be cast as STR or VAL inside TestStand before TestStand can use them. I pass all my LV variants to TS containers.