TestStand should realize Labview TypeDef / Strict TypeDefs

[BrianKincaid]

So, I really like Labview's new product idea page.  In the same vein I want to request this feature for TestStand:

I would like a TestStand feature for auto-update container based on LabView TypeDef and Strict TypeDef controls. 

I have spent a lot of time using TestStand while developing test suites and the 'fix' is as follows:

Load Sequence

*Broken since the TypeDef changed*

Create new container for the changed TypeDef

Change TestStand variable linked to old container(old TypeDef) to the new container

Delete old container

Rename new container to the 'old container name'

I think I understand the bug-checking reasoning behind this process, but I would like a check-box for 'auto-update from LabView typedef' in the container properties.

Best regards,

Brian (Daniel) Kincaid

[BrianKincaid]

Really nobody wants/needs this?

-Brian

[DRock]

Hey Brian,

Actually, I think it's a fantastic suggestion.  I'm not sure why you never received a response to your original post and I do apologize for this (we try to make sure every post receives a response).  Typically, developers using typedefs in LabVIEW use them exactly for their strength that any changes to the typedef are propagated to any connected instances of the typedef itself (implying that the typedef is likely to be changed or tweaked numerous times).  I can see that this would become a headache for our NI TestStand developers because it will break sequences every single time a change is made. 

I'm going to file a Product Suggestion on your behalf so that our R&D team will take a look at this and see if there's any variation of this idea that could be included in a future release of NI TestStand.  Would you consider doing the same?  I think this could cause a bigger "splash."  

If you're interested, you can find our Product Suggestion Center by visiting www.ni.com/contact and then navigating to Product Feedback.

[glennjammin]

This has been on my wishlist also.  It would definitely be an awesome feature.

[Mark_Ireton]

Is this feature is on the TestStand development roadmap, or has anyone has developed an easier way to deal with updates to Strict TypeDefs?

[BrianKincaid]

I haven't heard anything new.  Currently we pass through teststand using variants.  Can't update anything easily from within teststand but we couldn't afford to keep updating containers.

-Brian

[RayFarmer]

Hi Brian,

Currently TestStand is still the same.

Have you submitted your idea on the new NI Teststand Ideas page.

[RayFarmer]

Hi,

Attached is a document I produced in response to question given at a Cambridge LabVIEW User Group meeting a while back. It highlighting the problem with LabVIEW TypeDefs  and TestStand.

[CoastalLabVIEWER]

I google searched this issue and this thread was the first link.  We've been bitten a couple times now because of this and I'd love to hear the explanation on why this doesn't work better for best in class software/development platforms such as LV and TestStand.

We very often do concurrent LabVIEW vi development along with the interfaces in TestStand so it isn't unusual for us to not plan perfectly and decide we want one extra data type represented in the TypeDef and have to go through the delete/create/relink/rename process.

[snowpunter]

I agree that this is a painful issue, however I think sometimes we make it harder on ourselves than it needs to be, especially for minor changes to a LV tyepdef. Updating a TestStand typedef from a minor change in a LabVIEW typedef does NOT require a delete/recreate. You can simply add/delete whatever changes were made in the LV typedef to the TS typedef and then update the label in the Cluster Passing tab of the Type properties. I agree that having an auto-update would be awesome but propogating a minor change isn't all that difficult.