NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Prototype reload request even with no changes

I have a problem with Teststand thinking that I need to constantly reload prototypes on vi's that have not been touched. I can close a sequence that is perfectly operational (all prototypes loaded and working) and then reopen it. TS frequently (not always) determines that the prototype needs to be reloaded and it can happen on many, many steps.

 

The next issue is that if one of the inputs to the vi is a cluster and one of the items is an enumeration. When I do the reloads, it randomly changes the values of the enum which is dangerous for obvious reasons.

 

I'm running LV 2010 and TS 4.2.1 exclusively and as far as I know all patches for known isssues have been loaded in both LV and TS.

 

Has anybody seen this and found  a fix?

 

Thanks,

Dave

0 Kudos
Message 1 of 7
(4,212 Views)

Dave,

 

My guess is that your search directories contain 2 or more paths which lead to your VIs.  What happens is that TestStand will find the VI at one path and then find it at the other thinking it is a different VI with the same name.  I explain it better here: http://forums.ni.com/t5/NI-TestStand/TestStand-Deployment-5-7-hours/m-p/1577138#M33085

 

Regarding the enum situation:  Enums don't work in TestStand so I'm not surprised.

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
0 Kudos
Message 2 of 7
(4,203 Views)

What do you mean enums "don't work"?  Enums are supported as parameters from VIs.

0 Kudos
Message 3 of 7
(4,200 Views)

Yeah but TestStand doesn't have enums.  So I guess if you are passing them as parameters to LV then you just pass a numeric value?

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
0 Kudos
Message 4 of 7
(4,198 Views)

Hi everybody!

 

I had a situation where a 'enum' was contained in a cluster as one of the input to a VI that did a DMM measurement.  The enumeration was the Measurement Functions of the DMM : DC Volts, AC Volts, 2-Wire Resistance Etc. Called 'niDMM Function.ctl' saved as a typedef.   This being defined by National Instruments within their niDMM library.

 

Well everything worked fine until one day we updated the drivers to more recent Product Distribution.   Then EVERY single step that used this VI containing the ENUM I just mentioned had to be relinked because the enumeration was changed by NI to add 'Temperature' as a supported DMM function. Summary. NI updated their DMM library.    It took some time to figure out what was going on because it was not apparent why it was being relinked ( NOTHING changed in the connector pane ).

 

So one case of possible relinking is that an enumeration input to the connector pane changed. 

 

It sounds like you are perhaps linking to different VIs, I have never seen it 'randomize' the order of the enumerations.  Perhaps you are calling two 'similar' VIs with the same name that have slightly different enumerations?

 

Is this just happening on your development PC? Or other PCs you are performing a build on?

 

Thanks,

PH

 

 

0 Kudos
Message 5 of 7
(4,192 Views)

You may be on to something there with the enum changes since that is something that I have altered frequenlty. It is unclear why this would trip it as you say. The enum doesn't change the connector interface. Or, apparently it does.....

 

Thanks for all the tips!

0 Kudos
Message 6 of 7
(4,141 Views)

The problem of re-loading a step prototype in TestStand occurs if:

 

             1. The connector pane pattern of LabVIEW VI has been changed.

             2. The datatype of control / indicator tied to connector pane has changed

           

I had faced similar problem in my project having more than 70 steps. Initially I used to pass data between LV & TS using connector pane. However, the problem of re-loading prototype used to bug me.

 

Advice: Use ThisContext of TS in LabVIEW to share data between LV & TS. Now, only two connections are required on connector pane. One for TestStand reference & other to select the state machine case (ENUM).

 

If you add more items to ENUM or modify it, then you may have to reload the step prototype in TS. However, there is a automatic way by selecting "Tools\Update VI Calls". In the "Types Of Calls To Update" select the ring control and select "Reload prototype if modified". Thus there is no need to update LV calls in all steps manually.

 

If you don't want the State ENUM to be passed from TS, then define the state value in TS string variable and read it from LV. On connector pane in LV just link it to SequenceContext control. Thus there would no problem of reloading prototype in TS

 

Sorry for the long message 🙂

0 Kudos
Message 7 of 7
(4,085 Views)