1. Mastering Teststand Deployment Images J. Eagar, Control4 1-7-2016

2. Overview  What TestStand deployment images are and why you would want to use them  Licensing considerations for deployment images  How to use TestStand's Deployment Utility to create deployment images and installers  Common problems and pitfalls with the deployment utility  How to architect your test sequence to minimize problems with the deployment utility

3. What are Testststand Deployment Images?  Teststand Deployment Images are conceptually analogous to a built executable in LabVIEW.  Both Teststand Deployment Images and LabVIEW executables serve the same purpose—they both package all of the core code dependencies into a read-only form that can be installed onto test systems that just have runtime engines installed.  There are some significant gotchas when you work with deployment images so think of them conceptually like LabVIEW executables but do not treat them as executables and do not think of the deployment utility as the same as LabVIEW’s application builder.

4. Why would you want to use Teststand Deployment Images?  Scalability  Deployment Images solve some core problems with scaling up test sequences in production.  Cost  Consistency  Traceability  Protect intellectual property  Flaws in the deployment utility force better code practices  Enforces process flow

5. Why would you want to use Teststand Deployment Images? (Scalability)  Cost  A typical single seat of Teststand and LabVIEW is ~$10,000 vs $500 for a base Teststand Deployment license  Quickly adds up for a15+ test platform installation  $7,500 vs $150,000 in licensing costs  Consistency  No source code on production testers means no temptation to ‘Tweak’ in code under pressure  Traceability  Read-Only Deployment images are versioned. This allows you to have a high level of confidence that what the product was tested with was what is approved

6. Why would you want to use Teststand Deployment Images? (Scalability)  Protect Intellectual Property  Mostly for code going to off-shore partners or sub- contractors. Allows you to NOT ship the source code with the test sequence.

7. Why would you want to use Teststand Deployment Images? (Better coding through flawed tools)  Flaws in the deployment utility force better code practices  Deployment utility treats your code as if it  Follows best coding practices  Doesn’t contain any partially completed development remnants  Won’t have any complex linking issues post re-linking*  This includes third-party libraries and drivers…  If your code is not all of the above you will randomly hit brick walls until it does.  Very painful when under deadlines  You have been warned

8. Why would you want to use Teststand Deployment Images? (Enforces Process Flow)  Enforces Process Flow  Deployment Images give you a “release candidate” for a test sequence.  Discreet versioned package that can be signed off on.  Reduces pressure for “can you just make one little change please”

9. Licensing considerations for deployment images  Base Deployment ~$500  Debug Deployment ~$2,200  Can be included in Ni Enterprise Agreements

10. Licensing considerations for deployment images

11. How to use TestStand's Deployment Utility to create deployment images and installers

12. Starting The Deployment Utility

13. The Mode Tab  The Mode Tab is where you can change versioning for the deployment image ( it will auto increment )  For new deployments most of the options are grayed out  If you build a deployment and then save it you will get additional options if you want to use patches  Patches reduces the size of new deployment images by only including changed files in the deployment image  Good idea in concept. In practice I never touch anything on this tab.

14. System Sources Tab

15. The System Sources Tab  Used to select where the build utility gets the source files from and where to put the deployment image  Most common selections are  Check the “From Teststand Workspace File option”  Browse to your Teststand workspace (File->New in Teststand if you don’t have one)  Change the Location of the Deployment Images to a build directory  Warning:: Whatever directory you put for the location of the deployment image should be empty  I don’t recommend using the use directory option

16. Concerning Teststand Workspace Files  Extremely crude compared to LabVIEW project manager  No Auto-updating folders  Deployment utility won’t pickup unsaved changes

17. Distributed Files Tab

18. Distributed Files Tab Post Analysis

19. Distributed Files Tab  Always double check where your source files are coming from are where you think they are coming from  Note the “Include without Processing Item or Dependencies checkbox”  If all you use the workspace and project file for is the deployment you can safely uncheck them.  Some older versions of the deployment utility (2009) would randomly corrupt the deployment script if you unchecked some files. This was fixed in newer versions. If you see this error then start over and don’t uncheck anything

20. Installer Options Tab

21.  If you are creating an installer then this tab allows you to configure it  Pretty straightforward, only real tricky part is knowing which additional NI installers you need to include  VISA?  NI-DAQ?  Etc

22. Build Status Tab

23.  Most frustrating Tab NI has ever created  Outputs cryptic nonsensical error messages  Most of the time more useless than not

24. Building the Deployment and Installer Press Build If everything is working correctly than it will spit out some status text and eventually a build complete message. A new deployment image will be located in the deployment directory specified and a new installer will be in the installer directory specified

25. Common problems and pitfalls with the deployment utility  If anything goes wrong with the build then the error message probably has nothing to do with what is actually going wrong  Even if the deployment utility builds successfully you have no guarantee the deployment image will work. Test everything  Running vis in a deployment environment has less overhead than in a development environment, this can cause subtle timing differences that can change the test  Deployment images that just use raw vis are dangerous to open in a development environment

26. Tools and Techniques to fix deployments that just aren’t working  Load all your vis into a LabVIEW project and check for dependency issues  Create a LabVIEW auto opener vi

27. LabVIEW Auto opener

28. LabVIEW Auto Opener Explanation  The LabVIEW Auto Open works by opening up all of the vis in a directory and trying to load and then save them.  This will recover any vi with bad dependency links by auto finding them or letting you choose where to find them if needed  It will also find any broken vis and leave them open for further review

29. Best Practices to minimize problems with the deployment utility  Use LabVIEW Packed Project Libraries  Necessary Vis from vi.lib will get built into the Packed Project Library  LPP’s can be run under the LabVIEW runtime without modification  Remember to use the “do not check dependencies option”

30. Best Practices to minimize problems with the deployment utility  Use good relative paths  Single Main Sequence in Root Folder  SupportFiles Directory for packed project libraries, DLLs, limit files, and whatever else needs to be deployed  Source Directory for sequence specific vis  Source directory should have a LabVIEW project that builds a packed project library in the SupportFiles Directory.  Debug vis in source, change the sequence to use the packed project library when the code is stable

31. Best Practices to minimize problems with the deployment utility  Avoid Library Conflicts! When you build your PPLs if you reference any DLLS apply a prefix to them so they don’t fight

32. Best Practices to minimize problems with the deployment utility  Once all vis are built into packed project libraries and all paths are relative you technically don’t need to build a deployment image.  Very difficult to get to this point!  Still useful to do for versioning, installers, process flow, etc

33. Best Practices to minimize problems with the deployment utility  The less you have to rely on the Deployment Utility the more success you will have with it.

34. Questions?