NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Deployment Utility fails when block diagrams are excluded

If I run the deployment utility with the setting “Remove Block Diagrams” unchecked, the build works OK.

If I check “Remove Block Diagrams”, the build fails because the file "C:\Program Files (x86)\National Instruments\LabVIEW 2013\vi.lib\addons\TestStand\_TSUtility.llb\TestStand -64 Bit GetPropertyI64Value.vi" is broken.  I'm not actually using that file anywhere in my project, but the deployment utility insists on including it.  It is able to include broken VIs in the deployment as long as they have their block diagrams, but it can't include a broken VI without its block diagram.

 

Does anybody know how to get the deployment utility to not vomit on itself?

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 1 of 4
(4,206 Views)

Hi Paul,

 

I'm sorry to hear you are having issues with the Deployment Utility.  I am unable to reproduce this behavior on my end using a deployment which includes the get 64-bit integer pallete VI, but I am seeing that the TestStand -64 Bit GetPropertyI64Value.vi in question is broken.  This VI is expected to be broken in LabVIEW 32-bit, since it is only intended to be called when using LabVIEW 64-bit. We would like a bit more information on your current configuration to better characterize this issue:

 

  1. in the LabVIEW options, do you have the Check for Broken VIs option selected?  Does changing this option have any effect on the error?
  2. Do you have the Output VIs to a Packed Project Library option selected?
  3. What version of LabVIEW are you using to deploy.  Is it a 32-bit or 64-bit version?  note that the deployment utility does not fully support LabVIEW 64-bit at this time (see KB 50O9851O: TestStand Compatibility With 64-Bit LabVIEW Versions)
  4. If possible, please send the tsd file and the failing deployment log.  Feel free to private message me these files.

 

If you are using 32-bit LabVIEW, you should be able to prevent this behavior using the following modification:

 

  1. open the following VIs in <LabVIEW>\vi.lib\addons\TestStand\_TSUtility.llb 
    • TestStand - Set Property Value (Number {Signed 64-bit Integer}).vi
    • TestStand - Set Property Value (Number {Unsigned 64-bit Integer}).vi
    • TestStand - Get Property Value (Number {Signed 64-bit Integer}).vi
    • TestStand - Get Property Value (Number {Unsigned 64-bit Integer}).vi
  2. in each VI, select the default case in the conditional disable structure, then right click and select Remove Conditional Disable Structure
  3. Save and close the VIs
  4. Repeat these steps for the VIs in <TestStand>\API\LabVIEW\_TSUtility.llb to prevent the behavior from returning after using the TestStand version selector (the version selector replaces the VIs in vi.lib with the ones in this location)

 

Al B.
Staff Software Engineer - TestStand
CTA/CLD
0 Kudos
Message 2 of 4
(4,197 Views)

* Checking or unchecking Check for Broken VIs doesn't fix the problem.

* Ouputing VIs to a Packed Project Library allows the build to proceed without errors, but the application then doesn't work due to path issues.

* We are using the 32-bit version of LabVIEW.

* in _TSUtility.llb, there are actually 5 VIs that are broken.  None of them had Conditional Disable Structures, but I added them to disable the code; now the build works OK.

 

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 3 of 4
(4,164 Views)

I have a similar problem with TestStand 2010 SP1 & Labview 2014. I'm also running LV 32-bit. When I go look for broken 64-bit VIs in _TSUtility.llb, I don't find any. Should I do a similar thing as the other user an disable the entire code for all 64-bit VIs in the llb?

0 Kudos
Message 4 of 4
(2,402 Views)