Attachment 15 draft M_TMDE Technical Manual (1).docx

TMDE Technical Manual Table of Contents

1) Setting up modular TMDE

a. Cable connectivity and hardware physical location on bench

i. Introduction: The hardware contained on the FWS-S TMDE bench is self-contained. All of the hardware components are placed in a pre-set location, with alignment for the collimator and

b. ICD for hardware

c. Hardware List

2) Required software list when using a clean Windows 10 install

3) Rail and Reference Camera Alignment

4) Using hardware

a. NVLabCap

i. FOV

ii. MTF

iii. SITF/Noise

iv. POAnMAG

v. OCLOSS

b. Python Script Development

5) Troubleshooting Issues

Section 1: Setting up modular TMDE

A. Cable connectivity and hardware physical location on bench

The hardware contained on the FWS-S TMDE bench is self-contained. All of the hardware components are placed in a pre-set location, with alignment for the collimator and Picatinny rail in critical location. There are special instructions for aligning the Picatinny rail to the collimator in a separate section.

In general, should any hardware component fail, because every item on the TMDE bench is either vendor supplied or commercially available, a replacement is available. Additionally, there are additional replacement parts for most of the common items at C5ISR Center NVESD at Fort Belvoir, VA.

The ICD specifies how each component of Modular TMDE is connected to the main computer. Most of the test hardware (SBIR Blackbody, CI Systems Blackbody, and Agilent Power Supplies) is controlled by GPIB, which is a serial communication standard. Individual GPIB connections are not required to be made to the host computer, and hardware components that are intermediary GPIB connections are not required to be powered on in order for hardware further “downstream” to be controlled by the host computer. Figures XXX and XXX show how the GPIB connections are established to the three hardware components that utilize GPIB.

There are two reference cameras in the TMDE setup, and both use an Ethernet interface. To simplify cabling to both cameras, a POE injector is used to provide power to the reference cameras.

Most of the connections to the main control computer are intuitive, and figure XXX demonstrates the general location of all major hardware components.

Figure XXX: General location of various hardware components for Modular TMDE. Note Oscilloscope is not present on FWS-S variant.

Figure XXX: GPIB connections for the CI Systems Blackbody controller and the SBIR Blackbody and Target Wheel.

Figure XXX: GPIB connection for the two Agilent power supplies as well as the CI Systems Blackbody Controller.

B. Interface Control Document for FWS-S TMDE

Common TMDE Interface Control Document Version 0.1 02/19/2019 Document Number: ASEF-TMDE-ICD-2019-REV0.1 Contract Number: XXX

Table of Contents

List of Figures Figure 1: Top View of TMDE Layout with space denoted for additional interface hardware……..8

List of Tables

Table 1 - Interfaces from Common TMDE Host Computer……………………….…… Table 2 - Additional Interfaces from COTS Hardware Controllers to COTS Hardware……..…...4 Table 3 - Table 3: Qualification Methods for each interface in Common TMDE…………………16

Draft Modular MDE TM Error! No text of specified style in document.

Purpose of Interface Control This Interface Control Document (ICD) documents and tracks the necessary information required to effectively define the Common TMDE hardware system’s interface as well as any rules for communicating with the system in order to give the development team guidance on the test architecture for both the UUT and the TMDE. The purpose of this ICD is to clearly communicate all possible inputs and outputs from the system for all potential actions, whether internal to the system or transparent to users. The ICD was created during the Planning and Design Phase of the project and the intended audience is the project manager, project team, development team, and stakeholders interested in interfacing with the system. This ICD helps ensure compatibility between system segments and components.

Introduction This ICD describes the relationship between the Common TMDE Main controller computer (the source system), all auxiliary hardware, and the system under test (SUT).

This ICD specifies the interface requirements for the Common TMDE. It describes the concept of operations for the interface, defines the message structure and protocols that govern the interchange of data, and identifies the communication paths along which the project team expects data to flow.

For each interface, the ICD provides the following information:

A description of the data exchange format and protocol for exchange A general description of the interface Assumptions where appropriate Estimated size and frequency of data exchange

The interfaces to the Common TMDE host computer are found in Table 1. Additional interfaces from vendor specific TMDE hardware are identified in Table 2, but additional information is not known as commercial off-the-shelf hardware is not required to provide information like what is known in Table 1.

Table 1: Interfaces from Common TMDE Host Computer

Table 2: Additional Interfaces from COTS Hardware Controllers to COTS Hardware

Overview

The SBIR 900 Series Blackbody and Target Wheel is controlled over a GPIB control from the main host computer. The main host computer is physically located on the same work bench as the SBIR 900 Series Blackbody and Target Wheel. Within the main host computer, there exists a National Instruments PCIe GPIB card that is the controller for all of the GPIB interfaces. Typical communication between the host computer and the SBIR 900 series Blackbody and Target Wheel is discrete commands for setting a temperature or wheel position, or reading the Blackbody temperature or target wheel position.

The Newport Motion Controller is controlled over a GPIB control from the main host computer. The main host computer is physically located on the same work bench as the Newport Motion Controller. Within the main host computer, there exists a National Instruments PCIe GPIB card that is the controller for all of the GPIB interfaces. Typical communication between the host computer and the Newport Motion Controller is discrete commands for setting a position (in two dimensions for the System Under Test or one dimension for moving the LRF hardware in or out of position) or reading the position (in two dimensions for the System Under Test or one dimension for moving the LRF hardware in or out of position). Additionally, there is a command for setting the speed at which the motion stages move.

The Agilent Power Supplies (there are two located in each TMDE set) are controlled over a GPIB control from the main host computer. The main host computer is physically located on the same work bench as the Agilent Power Supplies. Within the main host computer, there exists a National Instruments PCIe GPIB card that is the controller for all of the GPIB interfaces. Typical communication between the host computer and the Agilent Power Supplies is discrete commands for setting a voltage and current limit or enabling the output to be enabled or disabled, or reading the voltage and current draw from the System Under Test.

The CI Systems Blackbody is controlled over a GPIB control from the main host computer. The main host computer is physically located on the same work bench as the CI Systems Blackbody. Within the main host computer, there exists a National Instruments PCIe GPIB card that is the controller for all of the GPIB interfaces. Typical communication between the host computer and the CI Systems Blackbody is discrete commands for setting a temperature or reading the Blackbody temperature.

The DRS Serial to Cameralink Converter Box is powered through any USB port on the main host computer. Since there is no data requirements for this USB protocol, the USB connection can be from any USB port on the host computer.

The DRS FWS-CS Command interface is a serial communication port that utilizes a USB port. There are specific port settings for the serial communications between the host computer and the system under test.

If the USB connection is plugged into a different physical connection on the host computer, the serial port will change. For this interface it is prudent to use the same port for all communications. All USB connections will be marked so that port re-enumeration is minimized.

Cameralink is the video format that is outputted from the Serial Converter Box. The cameralink output format is set through the USB FWS Command protocol, and the cameralink capture settings must be correct to capture the appropriate cameralink video from the system under test.

The three formats of the video are 1280x960x16 bits for NUC corrected, bad pixel corrected 14-bit imagery, 12-bit raw bayer imagery (for the visible channel), or 1280x960x24 for displayed imagery (both color and thermal imagery at the display are 1280x960x24).

The Mouse and Keyboard are standard PC peripherals. There are no special requirements for what port to use.

The host computer drives dual monitors. They are both set to 3820x2160 display resolution. Since the monitors are not able to be daisy chained, the display signals need to originate at the host computer.

The QR code scanner is connected to the host computer by a standard USB connection. There are no requirements for this USB connection to meet certain speed requirements.

The Laser Power Meter is connected to the host computer by a standard USB connection. There are no requirements for this USB connection to meet certain speed requirements.

Since it is unknown what Oscilloscope we are going to use, this section is currently blank.

Figure 1: Top View of TMDE Layout with space denoted for additional interface hardware.

Assumptions/Constraints/Risks Assumptions The largest assumption concerning this setup is that physical connections are not lost or changed during the use of this TMDE over its lifespan. Since the GPIB connections are in serial, if any one of the connections are lost then all devices after that disconnect will be inoperable.

Concerning the USB connections, the only connection that is critical to be maintained in the same physical USB location is the FWS Command port. This is required to be in the same physical USB connection because otherwise the communications port will change, and automatic connectivity to the FWS UUT may not occur.

The operating system is Windows 10, and the host computer that is performing these repairs is not ever going to be on-line, so there are no security issues related to on-line viruses.

Most of the testing for the System Under Test (SUT) will be automated, so there will be minimal user interactions in using the Common TMDE.

Constraints All software interfaces will be using the Python NVLabCap The End-User Environment will constrain a user in his/her ability to perform arbitrary functions with the hardware.

All resources will be available at all times. There will only be one service to communicate with hardware at any one time.

There are no requirements for interoperability beyond the TMDE software.

There are only USB protocol requirements for the Oscilloscope.

Risks

There are several connections that are required to be maintained to the host computer. If any of these connections are lost, the software will not function as intended. In order to mitigate this risk, cables will be tied down (where applicable) and cable strain will be avoided near the host computer.

The external system that is part of the TMDE hardware are the actual systems under test, which are in need of repair in order to be sent back to the depot (where the repair and diagnosis using the TMDE hardware is physically located). If the system is not fully functioning properly, there is a chance that the TMDE will not function as intended if signals are not being read from the system under test.

General Interface Requirements Interface Overview The systems under test, which are in need of repair in order to be sent back to the depot (where the repair and diagnosis using the TMDE hardware is physically located) will need to interface with the Common Base TMDE via the proprietary interface hardware.

Functional Allocation

The end user does not directly interact with this interface. Events are triggered by a command script through a Python based implementation of NVLabCap in the Common TMDE host computer. Simple set and read commands are sent through this interface.

The end user does not directly interact with this interface. Events are triggered by a command script through a Python based implementation of NVLabCap in the Common TMDE host computer. Simple set and read commands are sent through this interface.

The end user does not directly interact with this interface. Events are triggered by a command script through a Python based implementation of NVLabCap in the Common TMDE host computer. Simple set and read commands are sent through this interface.

The end user does not directly interact with this interface. Events are triggered by a command script through a Python based implementation of NVLabCap in the Common TMDE host computer. Simple set and read commands are sent through this interface.

The end user does not directly interact with this interface. No events are triggered by a command script through a Python based implementation of NVLabCap. This interface simply converts serialized video signals to a cameralink signal and is powered over a 5V USB cable.

The end user does not directly interact with this interface. Events are triggered by a command script through a Python based implementation of NVLabCap in the Common TMDE host computer. Simple set and read commands are sent through this interface.

The end user does not directly interact with this interface. No events are triggered by a command script through a Python based implementation of NVLabCap. This interface simply converts serialized video signals to a cameralink signal and is powered over a 5V USB cable.

The end user does directly interact with this interface. Events are triggered by normal user interactions.

The end user does not directly interact with this interface. Events are triggered by a command script through a Python based implementation of NVLabCap and the host computer’s video driver.

The end user does directly interact with this interface. Events are triggered by prompts in a command script through a Python based implementation of NVLabCap. Simple read serial number commands are sent through this interface.

The end user does not directly interact with this interface. Events are triggered by a command script through a Python based implementation of NVLabCap in the Common TMDE host computer. Simple set and read commands are sent through this interface.

The end user does not directly interact with this interface. Events are triggered by a command script through a Python based implementation of NVLabCap in the Common TMDE host computer. Simple set and read commands are sent through this interface.

Data Transfer Instructions: Briefly describe how data will be moved among component systems of the interface being defined. Include descriptions and diagrams of how connectivity among the systems will be implemented and of the type of messaging or packaging of data that will be used to transfer data among the systems. If more than one interface between these two systems is defined by this ICD, each should be identified in this section. A separate subsection may be included for each interface.

XXX[I think a VISIO style diagram would be sufficient for this task.]

Security and Integrity

Risk Management Framework individuals have reviewed the data transfer protocols of the Common TMDE and have determined that because there are no connections of the internet, NIPRNet, or SIPRNet, that there is a low probability of compromising the Common TMDE hardware or any connected systems. The movement of data between all systems are physically in the same room and the control computer is completely offline. There are no security requirements assuming this configuration.

Qualification Methods

Table 3: Qualification Methods for each interface in Common TMDE

Appendix A: Record of Changes Instructions: Provide information on how the development and distribution of the Interface Control Document will be controlled and tracked. Use the table below to provide the version number, the date of the version, the author/owner of the version, and a brief description of the reason for creating the revised version.

Table 8 - Record of Changes

None are required at this time Appendix B: Acronyms Instructions: Provide a list of acronyms and associated literal translations used within the document. List the acronyms in alphabetical order using a tabular format as depicted below.

Table 9 - Acronyms

Appendix C: Referenced Documents Instructions: Summarize the relationship of this document to other relevant documents. Provide identifying information for all documents used to arrive at and/or referenced within this document (e.g., related and/or companion documents, prerequisite documents, relevant technical documentation, etc.).

Table 11 - Referenced Documents

Appendix D: Approvals The undersigned acknowledge that they have reviewed the ICD and agree with the information presented within this document. Changes to this ICD will be coordinated with, and approved by, the undersigned, or their designated representatives.

Instructions: List the individuals whose signatures are desired. Examples of such individuals are Business Owner, Project Manager (if identified), and any appropriate stakeholders. Add additional lines for signature as necessary.

Table 12 - Approvals

C. Hardware List

Table 1: All Hardware required for FWS-S TMDE with links for parts

Table 2: All Hardware required for FWS-S TMDE with component functions for each part.

2) Required software list when using a clean Windows 10 install

Python (3.7 or later) https://www.python.org/ftp/python/3.9.0/python-3.9.0-amd64.exe

Matlab https://ssd.mathworks.com/supportfiles/downloads/R2019a/Release/9/deployment_files/installer/complete/win64/MATLAB_Runtime_R2019a_Update_9_win64.zip Notes: 1) Unzipped to Downloads directory

2) Run Setup to install

MySQL Community edition https://dev.mysql.com/get/Downloads/MySQLInstaller/mysql-installer-web-community-8.0.21.0.msi Notes: 1) Developer Default installation selected

2) Ignored “Product Requirements not satisfied” prompt

3) Had to retry downloads before successful install

4) Ignore server requirements for product configuration

PicoSDK 10.7.18 (64-bit) https://www.picotech.com/download/software/beta/PicoSDK_64_10.7.18.140.exe Notes: 1) Used all default options

Git for Windows https://git-scm.com/download/win Notes: 1) Used all default options

GStreamer https://gstreamer.freedesktop.org/download/ Notes: 1) Use MinGW 64-bit runtime installer

2) Install to C:\ (should be default installation path)

Conda Environment (Miniconda3) https://repo.anaconda.com/miniconda/Miniconda3-latest-Windows-x86_64.exe Notes: 1) install in user directory, do not "install for all users"

Install NATS (The government provided git Bundle):

Notes: 1) Delete any existing instances of C:\nats and run Install.bat.

2) This script creates a C:\nats directory and clones the included bundles into it.

3) It then sets up the Anaconda environment for NATS.

4) The script will PAUSE after completion to allow you to read through its results and check for issues.

Runing NATS:

Run run_nats.bat from any directory you put it in.

It will also PAUSE after execution to let you look through any errors.

Uninstalling NATS:

If for any reason something doesn’t install right or NATS doesn’t run properly and you have to make changes, one can run Uninstall.bat which removes the nats environment and deletes the C:\nats directory.

Manually running NATS:

From the anaconda script running in the c:\nats directory:

conda activate nats python src\scripter_driver.py

Deactivating environment:

conda deactivate Removing the nats environment:

conda remove -n nats --all

a. Instructions and dependency list

b. Download List

3) Rail and Reference Camera Alignment

The alignment of the hardware for the rail and reference camera to the collimator are critical. Most of the other test hardware items are not required to be finely aligned (the biggest alignment outside of this setup is of the short rail to the flooded field blackbody), but this alignment ensures that the rail is in line with the principal optical axis of the collimator.

The concept of this alignment is to hold and lock the rail and reference camera in place while moving the collimator either laterally or by adjusting the feet height to align the principal optical axis to the rail. After the collimator is aligned, the feet are then locked into place.

Additional equipment required:

-B.E. Meyers Laser with Geissele Alignment Railgrabbers (controlled by C5ISR Center) -Modified Cover for SBIR 900 Series Blackbodies and Collimators (controlled by C5ISR Center) -Reference flat mirror (controlled by C5ISR Center) -Laser safety goggles -Reference Scope (controlled by C5ISR Center)

i. Construct optical test hardware as shown in the below figures.

Figure XXX: Drawing of the mount for the optical rail as well as the reference camera mount.

Figure XXX: Horizontal Alignment aspect of the reference camera to the reference rail.

ii. It is not yet important for the reference camera to be perfectly aligned to the rail. Still, confirm that the reference camera is imaging and outputting video. This functionality will be needed for a later steps.

iii. Place the B.E. Meyers laser on the Picatinny rail near the center and lock the rail-grabbers into place using a torque wrench at 20ft/lbs. Also, place the modified Cover for SBIR 900 Series blackbodies and collimators at the exit aperture of the collimator.

WARNING: Safety glasses should be worn by any engineers/technicians for the following steps.

iv. Power on the B.E. Meyers laser and align the collimator so that the reference laser is positioned through the center of the modified cover. The collimator alignment requires either lateral, vertical, or tip/tilt adjustments on the feet of the collimator. Once the laser is aligned through the alignment pin of the collimator, do not adjust the location or position of the collimator.

v. Power off the B.E. Meyers laser and position it at the end of the rail closest to the collimator.

vi. Power on the B.E. Meyers laser and confirm that the laser is still positioned through the center of the modified cover. If it is not aligned through the cover aperture, adjustments to the collimator will be required.

vii. Power off the B.E. Meyers laser and position it at the end of the rail furthest from the collimator. (Nearest to the reference camera) At this point the laser is aligned only to the center aperture of the reference cover but it not aligned to the principal optical axis of the collimator.

viii. Power on the B.E. Meyers laser and confirm that the laser is still positioned through the center of the modified cover. If it is not aligned through the cover aperture, adjustments to the collimator will be required.

ix. Power off the B.E. Meyers laser.

x. Position the target wheel to an open target, and remove the blackbody.

xi. Position the reference flat so that it is laid against the surface of the target wheel as shown in figure XXX.

Figure XXX. Reference flat in position.

xii. With the modified cover still in place, power on the B.E. Meyers laser. Confirm that the laser is not only aiming through the center aperture of the modified cover but also that the laser is returning through the same aperture in the modified cover.

xiii. Power off the B.E. Meyers laser and position it at the end of the rail closest to the collimator.

xiv. With the modified cover still in place, power on the B.E. Meyers laser. Confirm that the laser is not only aiming through the center aperture of the modified cover but also that the laser is returning through the same aperture in the modified cover. If this is not occuring, adjust the rotation, tip, or tilt of the collimator until the laser is returning through the aperture of the cover. Lateral or vertical translations should not be required unless the system moves vertically or laterally during this step.

xv. Power off the B.E. Meyers laser and position it at the end of the rail closest to the reference camera.

xvi. With the modified cover still in place, power on the B.E. Meyers laser. Confirm that the laser is not only aiming through the center aperture of the modified cover but also that the laser is returning through the same aperture in the modified cover. If this is not occuring, adjust the rotation, tip, or tilt of the collimator until the laser is returning through the aperture of the cover. Lateral or vertical translations should not be required unless the system moves vertically or laterally during this step.

xvii. Remove the reference flat, modified cover, and B.E. Meyers laser from the test setup.

xviii. Use the provided blocks to lock the collimator into place. At this point the collimator should be aligned to the Picatinny rail along the principal axis of the collimator.

xix. Power on the provided electroluminescent panel (provided with TMDE) illuminate K-edge Target Position #2.

xx. Place the reference scope in position nearest the reference camera and reduce the magnification to its minimal value (3X).

xxi. Make mechanical adjustments to the reference camera so that the reference camera is parallel to the line of sight to the scope but also that vignetting is minimized.

xxii. Remove the scope from the rail.

xxiii. Open a live image from the reference camera. Ensure that the reference camera is viewing K-edge target position #2. Adjust focus on the reference camera until the image is at maximum sharpness. This is accomplished by using the MTF plugin in NVLabCap and maximizing the MTF response.

xxiv. Lock the focus on the reference camera. The reference camera should now be focused at infinity and in a position centered on the reference scope.

xxv. Place the scope back on the picatinny rail in the position closest to the reference camera without bumping it.

xxvi. While viewing the live image of the scope, adjust the diopter so that the reticle sharpness is maximized. This step sets the diopter to infinity projection (0 diopters).

xxvii. Using NVLabCap’s MTF plugin, measure the MTF through the scope of the knife edge target. Adjust focus on the scope so that the MTF is maximized. At this point, the reference camera, diopter, and scope focus are all set to infinity.

xxviii. Change the position of the target wheel to ocloss target #3.

xxix. Using NVLabCap, draw a boundary box around the center pinhole of the OCLOSS target.

xxx. Unmount the reference scope and move it to the center of the picatinny rail. (do not remove or adjust the boundary box on the live image)

xxxi. Confirm that the same boundary box is on the location of the same center pinhole target.

xxxii. Unmount the reference scope and move it to the edge of the picatinny rail furthest away from the reference camera. (do not remove or adjust the boundary box on the live image) xxxiii. Confirm that the same boundary box is on the location of the same center pinhole target.

xxxiv. Remove the reference scope.

4) Using hardware

c. NVLabCap

NVLabCap is an open source government owned and government developed software tool that is used to capture video from a variety of input sources and perform measurements from that imagery.

For Modular TMDE, NVLabCap’s measurements are used in both the NATS software but also as a standalone application that allows for quick checks for sensor performance. For information on the complete functionality of NVLabCap, refer to the NVLabCap technical manual.

i. FOV

The field of view widget is used to determine the field of view of a sensor based upon a calculation of a known target size at a known distance. The three targets that are currently used for the field of view measurement are either 4-bar, 3-bar, or square targets. All of the targets used for field of view calculation have a 1:1 total aspect ratio, though the aspect of the bars themselves are 2N −1 : 1, where N is equal to the number of bars for a given target. To calculate the field of view of a system under test, the first step is to open the video pipeline for the system under test and navigate the target controller to one of the aforementioned targets.

The field of view widget will allow a user to input all information required to calculate a field of view, but that information can also be directly pulled from the blackbody widget after a user inputs those parameters for each target and sets up the collimator focal length distance. It is important to note that while the measurement of the field of view is itself important and is useful for program requirements, the most important output of the field of view widget is the sample spacing (or instantaneous field of view) of the system under test. The measured MTF (which is measured in cycles per pixel) is converted to cycles per milli-radian by being divided by the measured ifov (measured in milli-radians per pixel).

For information regarding details of the Field of View measurement, refer to the NVLabCap technical manual.

ii. MTF

The Modulation Transfer Function (MTF) measurement widget allows a user to determine both a real-time (live) and a calculated MTF based upon live imagery or saved imagery. The MTF widget is useful for determining the optimum focus of a system under test as well as the calculated MTF of a system. The targets that are usually associated with this measurement are knife edge, square, and slit targets. The knife edge is optimum when a user wants to determine the MTF in the center location of the field of view of the system under test. The square target is ideal for simultaneous measurements of MTF in multiple orientations, like horizontal and vertical. (If a user holds down the shift key after drawing one region of interest, then a second (or third or more) region of interest will be created and multiple MTFs can be plotted at the same time.) The slit target is supported in this measurement as well but does not provide any advantages over the knife edge or square targets.

For information regarding details of the Modulation Transfer Function measurement, refer to the NVLabCap technical manual.

iii. SITF/Noise

The 3D Noise measurement (3DN) widget provides a means for testing all of the following measurements from a single set of multiple frame collections as a function of temperature: the signal intensity transfer function, the 3d noise calculation, bad pixel identification and bad pixel cluster size statistics, image uniformity as a function of temperature, regions that might fail the spurious imagery temperature difference specification, and how well the system under test was non-uniformity corrected.

For information regarding details of the 3D Noise measurement, refer to the NVLabCap technical manual.

iv. POAnMAG

The Point of Aim and Magnification (POAnMAG) measurement is used to determine the shift, rotation, and magnification induced when a device is placed in an optical path. This measurement is typically used for in-line optical systems that are typically unity magnification. The way that this measurement works is to utilize a reference camera that has a resolution (sample spacing) that is greater than that of the system under test. The reference camera is used to capture a 4-bar target (whose information is contained in the Field of View General Tab) to determine the location, orientation, and size of the 4-bar target with and without a device in the path.

For information regarding details of the POAnMAG measurement, refer to the NVLabCap technical manual.

v. OCLOSS

The Off Center Line of Sight, or OCLOSS measurement, is basically a really long name for distortion. It maps the movement of individual points across a target region. Consider OCLOSS to be image shift as a function of location. The OCLOSS measurement is used to determine if an inline sight has any magnification or shift across some region around some optical axis. The outputs of OCLOSS are in the form of a Matlab MAT file, but it is easily parse-able if data from an individual measurement needs to be extracted.

For information regarding details of the OCLOSS measurement, refer to the NVLabCap technical manual.

d. Python Script Development

Script Creation:

Read the included Script Creation Guide PDF document for a rundown of creating Scripts in NATS.

The documentation provided in the Script Creation Guide (SCG) and the sample scripts are thorough enough to get one started making scripts, but programmers must dive deeper into the code to know exactly what each page type does and what functions they offer.

The PageFactory class is the most important part of the software. It sets up methods for creating new pages of all types and each method references a different parent page class.

The page classes are defined in individual python files located in the src>gui>pages directory.

Script writers must understand the features that the PageFactory and page classes offer in order to build working scripts.

Basic script creation steps:

1. Start off with base code from a demo script

2. Follow the SCG format for page initialization by calling the new page method defined in PageFactory.

3. Add Configuration Pages as per SCG instructions (again, reusing demo code helps)

4. Link data / results (e.g. ROI) between pages by calling methods specific to PageFactory implementations

5. Assign page IDs to the wizard

6. Set page order

7. Run NATS in Script Testing Mode to ensure proper page layout (it should default to this)

5) Troubleshooting Issues

Software:

NATS shows errors:

“Undefined function or variable 'matlabrc'” or “Undefined function or variable 'ctfroot'” Delete this file and rerun nats_run: C:\Users\[username]\AppData\Local\Temp\[username]\mcrCache[version]

If reference camera is not available through NATS:

Check reference camera operability in National Instruments MAX Check reference camera ip settings using Pylon IP Configurator

Hardware:

If source hardware (CI Systems BB, SBIR BB) displays errors on startup or usage, refer to the technical manual for each hardware component.

image3.jpeg image4.png image5.emf image6.emf image7.jpeg image8.jpeg image1.png image2.jpeg