NI TestStand Idea Exchange

About NI TestStand Idea Exchange

Do you have a feature idea for how to improve NI TestStand? Submit and vote on ideas now!

  1. Browse by label or search in the TestStand Idea Exchange to see if your idea has previously been submitted. If your idea exists sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea. Be sure to submit a separate post for each idea. Note: the TestStand Idea Exchange is not the appropriate forum to submit technical support questions.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see implemented!

The TestStand R&D team is committed to reviewing every idea submitted via the TestStand Idea Exchange. However, we cannot guarantee the implementation of any TestStand Idea Exchange submission until further documented.

Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
NickNZ

Deployment utility must warn and or ignore LabVIEW's separate compiled code flag.

Status: Declined

The separate compiled code flag is great when using VIs and source code control.

 

However TestStand (2016 SP1) deployment utility builder does not warn if the separate complied code flag is set - This means the VI will not run with the TestStand Deployment Licence without a LabVIEW development system installed. 

 

I do think the the Deployment utility should have a checkbox to force include the compiled code in all VIs and Controls so it can be run easily with the TestStand Deployment licence and LabVIEW runtime engine. 

 

Suggested because I have pulling my hair out wondering why a VI on a deployment machine won't run. 

Turns out a type def control had separate compile code flag set!  I even wrote code to clear this flag on VIs and all subVIs - it never occurred to me to check controls!

 

Also please update the error message in TestStand:

----------------------------------------
Details:

Parameter 'UUTServiceType': -This was a bit of a clue... but the TestStand type matched when I recreated it.
Unable to load VI 'Dialog - Prompt to connect UUT.vi' with the LabVIEW Run-Time Engine version 17.0.
The version of a subVI might not match the version of the run-time engine and the Version Independent Runtime feature is disabled or a VI dependency might be missing.
Try the following steps to troubleshoot the issue:

1. Open the VI in the LabVIEW development system. If the VI is broken, fix any errors in the VI.
2. Force compile the VI by clicking the run arrow while holding the 'Ctrl' key.
3. In LabVIEW, select File >> Save All to ensure that all subVIs are saved in the same LabVIEW version.

4. Check that the separate compiled code flag is not set on the VI or its dependent subVIs and controls (typedefs) when using the LabVIEW Runtime engine. 
----------------------------------------
Error Code:

-17600; Failed to load a required step's associated module.
----------------------------------------
Location:

Step 'Prompt User to Connect UUT' of sequence 'MainSequence' in 'My testsystem.seq'
----------------------------------------

 

{edit1} I also have just realised that running the code with the LabVIEW runtime in adaptor settings worked fine on my development PC as the control's code was in my local object cache. So I was also wondering why it worked fine on my development machine and not on the deployment machine when using the LabVIEW runtime.

Therefore the Runtime adapter should have a setting  to either Disable the Runtime using the local object cache

or an option ot clear the local object cache before running the sequence. This means this issue would have been reproducable on my development machine with the LabVIEW runtime adapter. 

 

I feel this idea is almost is close to being a bug.... 

 

 

 

Download All
2 Comments
WireWeaver
Active Participant

Deployment Utility does check for this flag, so if you can provide a case where it doesn't include the compiled code in the deployment image, it would indeed be a bug and not a feature request.

 

Trent

National Instruments

https://www.linkedin.com/in/trentweaver
WireWeaver
Active Participant
Status changed to: Declined
 
https://www.linkedin.com/in/trentweaver