The easiest way to create a TestScript using M1 is to use the ScriptBuilder™ graphical environment in M1.  However, it is possible to create a TestScript using just an XML editor and the TestScript command documentation.

The purpose of this document is to provide an overview of how to create an M1 TestScript that can be loaded and run by M1 without using ScriptBuilder. A TestScript can do nearly anything you can do from the M1 front panel, but in an automated way. The most common use for a TestScript is to create a compliance test for some particular technology. The TestScript can be designed to automatically set up and take various measurements, and to compare the results to the relevant specifications. At the end of the test, the user will see a detailed Pass/Fail dialog showing how they performed on each individual test.

Getting Started

To get started, you'll need to have/know a few things:

• The specification you wish to write a TestScript for. This includes knowing the exact specs that you want to measure and how to obtain those measurements in M1. Note that if there’s a measurement that isn’t natively available in M1, it’s possible to create an M1 External Measurement DLL to compute that measurement. You may also be able to find the needed measurement in the M1 Apps Store.
  
• An XML editor – M1 TestScripts are XML files, and they can be edited with any text editor, but an XML editor will make the experience much better. There are a number of free XML editors available.
• A web browser. It is highly recommended that you visit the M1 Apps Store, and download some existing Compliance Tests. Looking through some examples will greatly assist you in putting together your own TestScript.

Procedure

Following is the suggested procedure for creating a TestScript without using ScriptBuilder. As noted above, this procedure assumes that you have already determined the exact parts of the spec you wish the TestScript to test, and understand how to create the required measurements in M1.

1. Run M1 to create log file. M1 OT automatically creates a logfile every time you run the program. Normally this file is just overwritten when you run M1 again, but if you’re developing a TestScript, this logfile can provide a great starting point. So exit M1 if it’s running and restart it so you’re starting off with a clean, empty logfile.
2. Set up measurement Views. Using M1 as you normally would, open the various Views that will be required to make the measurements for your TestScript. Be sure to set any options, such as turning Accumulate on or setting a Repetition Interval Analysis parameter, at this point.
3. Set Run Until/Event Triggering conditions to become specs. Use M1’s Run Until feature to define the various measurements for the TestScript. Be sure to set these up so that meeting the Run Until condition equates to failing the spec. For example, if your spec says that Peak-to-Peak Period must be a maximum of 100ps, you should set a Run Until condition on Period/Pk-Pk that will trigger when the value is greater than 100ps.
4. Click on the "Start ScriptBuilder" button on M1's Measurement Tools menu. Select the "Save your current settings as a starting point" and "Copy existing measurements into the new script" options. When ScriptBuilder starts up, click on "Save TestScript," and you have a starting point for your own TestScript.
5. Edit TestScript. Once you have saved the TestScript, you may open up the output file in your XML editor. Now it’s time to actually flesh out what the utility has left you with into a fully functional TestScript. Now would be a good time to also load up some existing TestScripts to help familiarize yourself with the various commands and their syntax. ASA has a document that provides a high level of detail on the various commands available, their parameters, etc. For the purposes of this quick guide, we’ll skip the details. But there are a number of major categories of changes/additions that you will need to make:
   • Change view and measurement names for easier understanding. As you look at the various commands already in your TestScript file, you’ll see that M1 has assigned the various Analyses and Views you created rather unimaginative names like “Analysis0” and “Histogram3”. You are free to change these to whatever you’d like to make it easier to tell exactly what Analysis or View you’re actually dealing with, e.g. “Analysis0” could become “Period” and “Histogram3” could become “Period Histogram”. There are a few suggestions/caveats however:
     1. When changing an existing name, be sure to do a global Find & Replace to propagate that name change throughout the entire file
     2. Your names cannot contain spaces or special characters – letters and numbers only, please
   • Change Run Until conditions into Run Until commands. You will find a number of Event Triggering/RunUntil commands in the file, one for each Run Until condition you set in Step 3. Following the example of the sample TestScripts, you will need to change these into a single Event Triggering/RunUntil command with a series of Event Triggering/RunUntilConditions underneath it.
   • Add dialog boxes for multiple choice if required. TestScripts can use the DialogBox command to show a dialog box giving the user up to six choices. Within the TestScript, only the code corresponding to the user’s choice will be executed. This can be very helpful, for example, for letting the user select which test point they wish to check for compliance at. Each individual section of the TestScript will then set it’s Event Triggering/RunUntilCondition’s appropriately for that particular test point. Individual sections could even open different sets of Views and make completely different measurements. If you look at some of the example TestScripts from M1 Compliance Apps, you’ll see how this feature greatly simplifies combining a number of different tests and/or test oints together into a single TestScript.

Helpful Tips

Below are a number of tips, do’s/don’ts, and other useful information pertaining to developing a TestScript. It is highly recommended that you read and understand all of these points before you begin writing code. Please note that this information is presented in no particular order with respect to perceived importance.

• In the Event Triggering/RunUntil command, it is very important that you include the NumberOfEvents parameter and provide a reasonable value for it. This ensures that M1 will stop acquiring data and present results at some point, even if no spec failures are found.
• A TestScript requires that the user have the same signal setup (i.e. same channel(s) on the scope) that you were using. It’s a good idea to include a MessageBox at the beginning of the TestScript to inform the user of how they need to set up their signal.