Marvin Test Solutions - Knowledge Base Articles

How to Create a Support Incident, Request an RMA or Instrument Calibration - Published on 6/19/2025

6/19/2025

Overview

This article will guide you through the process of creating a support incident using MTS’s M@GIC online support portal. The portal is a secure site that is using Multi Factor Authentication (MFA) to log in and can be used for Support, RMA, Licensing, or File Sharing between designated MTS users and/or customers. The example provided here will show incident creation for the purposes of requesting calibration on your MTS instruments or to request an RMA.

Login To M@GIC - MTS Support Portal

When you first login to your M@GIC account, you will see the home page shown above, if you don't have an account, you can create one.

Create a Support Incident

To request an RMA or calibration you must create a support incident. This is done by selecting the link outlined in red (above), labeled “Create a new incident”. Once you have done this you will see the screen shown below.

Enter New Incident Details

Example

For this example, you will be requesting calibration on a GX2065 with a serial number of 000250.

Starting with the drop-down box labeled “Support Type” (outlined in red box #1 above), you will select “Calibration”. (Note: if we wanted to request an RMA, we would simply select “RMA” instead of “Calibration”)

Next, you will select the product you would like to calibrate\RMA from the “Product” drop-down box. Again, in this specific example we are going to select “GX2065” from the list.

Now that you’ve selected the product you wish to calibrate\RMA, you will enter the serial number of that instrument. If you are requesting calibration\RMA for a quantity of more than one (of the same instrument\product) simply enter the corresponding serial numbers separated by a semicolon, eg 000250; 000280; 000222; 000301. In this way, it is more straight forward to open an incident for each different instrument (part number) that you’d like to calibrate or RMA.

In box 4 shown above, you can select your operating system. For the purposes of calibration or RMA, this detail is not critical however it is a required field so please select an operating system from the drop-down list.

Next, in the field labeled “Short description” (Box 5 on the prior page) you might enter something like “Calibration” or “RMA Request”,..something to this effect will suffice.

The last field is box 6, “Detailed description”, where you will expand upon whatever you entered into box 5. This is also where you can note anything you feel is relevant for us to know. For instance, say that you want to have seven instruments calibrated all on one PO; Four GX7400A’s, two GX1120’s and one GX2065… You could simply list the corresponding part numbers and their serial numbers here. If there is any ambiguity in your request, an applications engineer will contact you shortly to be certain we understand exactly what it is you are requesting.
Completing the above six steps you should have the page filled out similar to the screen below:

Finally, select the “Submit” button at the bottom right of the screen. (red box shown above)
After you’ve selected the “Submit” button, you should see the screen below, indicating that the incident has been created.

At this point an email is automatically sent out to all the M@GIC support engineers and one of us will be along shortly to process your request and help you with any questions you might have.

Terminate an ATEasy or Other MTS Software License - Published on 6/17/2025

6/17/2025

To terminate software license *:

Open the About dialog: For ATEasy/CalEasy or other MTS software, open the software (ATEasy IDE, CalEasy, etc.) and open the About dialog, for the ATEasy License Server About dialog can be opened from the Windows task bar at the server (network license).

For older Software - press: CTRL+ALT+SHFT+K from the About dialog (be sure to press and hold the first three keys before pressing the K key) to terminate the license, for newer software - click on License... or Set License... button and select Terminate License (if license was installed manually), or Terminate License Online (if you activate the license online) as shown here:

For offline termination select Terminate License, the license termination code will be displayed, write down the termination code, or copy to the clipboard (Ctrl+C), or take a screen capture and save to an image file (Alt+Prt SC keys, paste to MS Paint, Save). Log into Magic and, create an incident and paste the code or the screen capture file to notify MTS that the license was terminated. Note: If you don't have the termination code, the user Windows temporary folder (type %temp% in the Windows File Explorer) should have a file that start with "ALicK", attach that file to the incident.

For online termination, select the Terminate License Online, no additional steps are required.

* NOTE: After terminating the license, a new license will only be issued for a license that have current ATEasy subscription.

[:+[+ateasy+]+:]

Creating an RS170 Video Signal with WaveEasy - Published on 5/22/2025

5/22/2025

Overview

WaveEasy simplifies entry of complex analog signals by allowing the user to break the signal up into smaller, easier to define segments and sub-segments, which can easily be replicated in the pattern memory to create a complex signal.

This is especially true for signals that are of a repetitive nature, such as RS170 video. The RS170 signal will be discussed in a general sense during this article, but a full discussion of the characteristics of an RS170 signal is beyond the scope of this article, so knowledge of the RS170 signal format and timing is assumed.

It should also be noted that examples presented within this article were designed for download to the Geotest GX1110 Function Generator/Arbitrary Waveform Generator operating at 40 Ms/S (25 nS period).

For additional information about how to define waveforms in WaveEasy and load them to the GX1110 Arbitrary Waveform Generator, refer to Knowledge Base Article Q200138.

[:+[+GX1110+]+:]

The RS170 standard transmits a full image at a 29.99Hz rate. The image is transmitted in an interlaced format, with one half of the image being “painted” on the screen after each vertical retrace in an alternating Even/Odd frame format. The half-frames are transmitted at ~ 60Hz rate. A typical horizontal trace signal is shown in figure 1 using common nomenclature. The Even and Odd vertical retrace signals, represented in WaveEasy, are shown in figures 2 and 3.

Figure 1 - RS170 Horizontal Trace Signal (Black & White)

Figure 2 - Even Vertical Synchronization

Figure 3 - Odd Vertical Synchronization

Waveform Segments and Sub-Segments

To simplify their definition within WaveEasy, the even/odd vertical retrace synchronization signals are divided into 21 Segments (labeled "Fields"), each representing the time duration of one horizontal trace.  These segments share many common characteristics that facilitate using standard copy/paste functions to build up similar, but slightly different wave components.

In between the even/odd vertical retrace signals are the 241 horizontal trace signals that represent the interlaced image.  In addition, the even vertical synchronization signal has an added one-half horizontal trace field at its beginning (labeled field 263) and its end to accommodate the one-half horizontal scan line of each image frame.

The full image is composed of 21 even vertical retrace fields, plus 241 even horizontal trace fields, plus 21 odd vertical retrace fields, plus 241 odd horizontal trace fields, plus the 263rd horizontal trace tacked on to the even vertical retrace signal.  This is a total of 21+241+21+241+½+½=525 horizontal scan lines – one full video frame.

[:+[+waveeasy+]+:]

Each of the field segments making up the vertical retrace and horizontal trace waveforms are further divided into Sub-Segments, where individual wave components of each field can be defined. Figure 3 demonstrates this concept by defining the “Front Porch” of field #263's synchronization pulse as a 0V signal for a duration of 1.5uS (60 samples at 25 nS [40 MHz] sample rate).

Figure 3 - Sub-Segments of Field #263 - Even Vertical Sync Waveform

The composite overlay of multiple WaveEasy screen captures in figure 4a illustrates how each sub-segment of field #263, as represented by a change in voltage levels, can be defined. When arranged sequentially they produce the segment pulses of Field #263 within the even vertical synchronization waveform - figure 4b.

Figure 4a - Sequential Sub-Segments of Field #263 - Even Vertical Sync Waveform

Figure 4b - Field #263 Segment - Even Vertical Sync Waveform

The same process is used to define the remaining frames in the vertical sync waveforms. Where fields are identical to those already defined, copy and paste functions can be used to easily replicate those component waveforms. And where new pulse streams are required, sub-segments of existing fields can be copied and pasted where applicable into the new field (figure 5). The Preview Window (bottom of figure 5) displays all segments and sub-segments of the active waveform document with the hashed lines identifying the selected segment or sub-segment.

Figure 5 - Field #6 of the Even Vertical Sync Waveform

Waveform Functions

Similar processes can be used to define the horizontal trace waveform. However, the video content – the waveform that actually defines the intensity of the image as it is painted horizontally across the screen, is defined using canned Functions built in to WaveEasy. Figure 6a shows a single horizontal trace signal consisting of a black-to-white gradient. The horizontal sync signal can be seen at the beginning of the waveform, and was created using the same process that was used to create the vertical sync waveforms. But the video content (sub-segment Video 14+) was generated using the built-in WaveEasy SawTooth function (figure 6b). The formula for defining the SawTooth waveform is:

(0.55 + 0.45 * SawTooth(1.0005 * x))

Figures 6a and 6b - Single horizontal trace signal using the SawTooth function to generate the video content

If the same waveform were used for all of the 442 interlaced horizontal traces, this sawtooth waveform will generate a dark-to-white gradient across the screen from left to right. Many other simple built in WaveEasy functions can be used to create novel or useful test patterns (figures 7a and 7b).

Figure 7a - Triangle Function video signal and formula

Figure 7b - Sine Function video signal and formula

You also have access to complex functions such as Noise (figure 8a), or combinations of functions such as Square Pulses with Sine Modulation (figure 8b). The latter will generate vertical lines across the screen of varying white intensity.

Figures 8a - Noise Function video signal and formula

Figures 8b - Sine-Modulated Square Wave video signal and formula

Combining Waveform Segments

All of these component waveforms can be assembled to produce one full video frame. Figure 9 depicts an abbreviated video frame showing the full even/odd vertical sync pulses, each bracketing three horizontal traces (preview waveform image). Normally there would be 241 horizontal traces in between each even or odd vertical retrace. The large waveform occupying the center of the WaveEasy screen shows a magnified section of the preview waveform (hashed lines) where the signal transitions from blank horizontal traces (dark) to active video (represented by sine waves).

Figure 9 - Abbreviated full-interlace video frame

The process of assembling (loading) these waveforms into a full video frame within the GX1110 is easily done via software using the supplied GX1110 driver functions. The sequence would be to load the even vertical synchronization waveform (55,880 samples), followed by 241 copies of the horizontal trace waveform (2540 samples each), followed by the odd vertical synchronization waveform (53,340 samples), followed by the remaining 241 copies of the horizontal trace waveform. The total pattern size is 1333500 samples in duration – which when output at a 40 MHz sample rate, generates a video signal with a 29.99 Hz refresh rate – exactly as defined for RS170 video. Sample ATEasy code to demonstrate this concept is provided below and sample WaveEasy pattern files can be downloaded HERE.

GTWAVE Set OperationMode ArbitraryWaveformGenerator()
GTWAVE Set OutputState(aChannelA,aOutputDisabled)
GTWAVE Stop(aChannelA)

dwStart=0
! Load fields 1 to 21 of even vertical sync, pluse field 263 for one-half horizontal traces
GTWAVE Arb Waveform FileLoad(aChannelA,"Even VSync.WaveEasy",0,dwStart,-1)
dwStart=dwStart+55880

For i=22 to 262 ! Load horizontal trace fields 22 to 262 - Completes even interlace frame
    GTWAVE Arb Waveform FileLoad(aChannelA,"Sine.WaveEasy",0,dwStart,-1)
    dwStart=dwStart+2540
Next

! Load fields 1 to 21 of odd vertical sync
GTWAVE Arb Waveform FileLoad(aChannelA,"Odd VSync.WaveEasy",0,dwStart,-1)
dwStart=dwStart+53340

For i=22  to 262 ! Load horizontal trace fields 22 to 262 - Completes odd interlace frame AND full video frame
    GTWAVE Arb Waveform FileLoad(aChannelA,"Sine.WaveEasy",0,dwStart,-1)
    dwStart=dwStart+2540
Next

GTWAVE Set Amplitude(aChannelA,1.2)
GTWAVE Set Offset(aChannelA,0)
GTWAVE Arb Set SampleRate(aChannelA,40e+06)
GTWAVE Arb Set Waveform Length(aChannelA,0,dwStart)
GTWAVE Run(aChannelA)
GTWAVE Set OutputState(aChannelA,aOutputEnabled)

Accessing RESTful services, using OAuth and Rational DOORS Web services from ATEasy - Published on 3/27/2025

3/27/2025

This article discusses three separate methods to contact, request information, and parse the data returned by a RESTful web services. There are several source code highlights within this document and the complete ATEasy project is attached at the end of the article. The example project consists of three tasks demonstrating various methods of access.

The first task in the example retrieves data from demo services in both JSON and XML formats. The second task in the example implements the OAuth protocol to contact a commercial website. And the final task in the example specifies a method to access OSLC Requirements Management V2 Services provided by the Rational DOORS Web service from ATEasy.

The code examples discussed are located within the example program (see link below).

Making an HTTP Request

In the first example, we will use the .Net WebRequest class that is included in the System.Net namespace. This class allows ATEasy to programmatically access web services similar to the way a web browser accesses them and is the basis for the more advanced service requests found later in this article. The simplest, default HTTP method is GET where the client application requests that a server provide the data at a specified URL. In the example below, an request which acts as a client is created using the Create() method and and then immediately sent with the GetResponse() method.

request : System.WebRequest
ws : System.WebResponse

! Send an HTTP GET request to the JSON test server
request=WebRequest.Create("https://jsonplaceholder.typicode.com/todos/1")
ws = request.GetResponse()

By default, GetResponse() is synchronous and will report certain failures such as a timeout; in case of a timeout, the requested URL doesn't respond and there is no meaningful data in the ResponseStream. If the request was successful, the response from the server is recorded in the WebResponse object as well as in the ResponseStream property of the WebRequest object. The next step is to read the response data. The exact method would depend of the service requested and the formatting of the content. In this example, the server will respond with JSON-formatted text. HTML and XML are also covered in this article. This example reads the JSON and appends it to the log after the test has completed.

!Using StreamReader to read entire chunk
streamReader = new mscorlib.StreamReader(ws.GetResponseStream())
! Read line by line and print to log
repeat
sLine=streamReader.ReadLine()
Append sLine
until sLine=""

NOTE: If HTML is printed to the ATEasy test log, the text may be interpreted as HTML. This could have unexpected consequences such as causing some data to appear missing or may change the format of the test log. Avoid this by printing the HTML contents to a file for review, or by changing the Log's PlainText property to True, or replacing HTML tags as demonstrated in Test 1.4 of the included example.

Anything beyond a simple GET request requires the user to modify the WebRequest client object before sending it off. Once the object is created, all of the properties of the request are assigned to their default values and can be changed if they are read-write properties. Test 1.3 of the example demonstrates changing the request to a POST. After Create(), the ContentType is specified as JSON, the Method is changed to POST to update the items specified in the body, and the Timeout is extended. Immediately after this, the body of the request is populated with the values on the web server I am try to change This is done by write my JSON values to the RequestStream of my WebRequest. It is not demonstrated but a header can be added in a similar manner.

! Modify the header/body and make a POST request
request=WebRequest.Create("https://jsonplaceholder.typicode.com/posts")
request.ContentType="application/json; charset=UTF-8"
request.Method="POST"
request.Timeout=20000

try
  streamWriter=new mscorlib.StreamWriter(request.GetRequestStream())
  sLine="{\"title\": \"Marvin\", \"body\": \"Test\", \"userId\": 1}"
  streamWriter.Write(sLine)
  streamWriter.Flush()
catch
endtry

After this, GetResponse() can be used to send the request to the server. This code shown above is the equivalent of the following HTTP request. You can try this out by putting the following code into the DevTools console of your favorite browser.

fetch('https://jsonplaceholder.typicode.com/posts', {
  method: 'POST',
  body: JSON.stringify({
    title: 'Marvin',
    body: 'Test',
    userId: 1,
  }),
  headers: {
    'Content-type': 'application/json; charset=UTF-8',
  },
})
  .then((response) => response.json())
  .then((json) => console.log(json));
Promise {}
VM288:13 {title: 'Marvin', body: 'Test', userId: 1, id: 101}

These are the basics of HttpClient web requests and responses. The example includes additional examples of reading HTML and XML as these have generic data parsing tools available.

The Root services document

The root services document contains information about your organization's specific DOORS instance. ATEasy uses the information contained within this document to negotiate authentication to access the protected requirements as well as primary service catalog which all sub-catalogs and services are contained within.

The first Test in the "Accessing Rational DOORS" task, "Access RTN DOORS from Sample File", reads through a root services document that has been saved locally as an XML file. Because this root services document is not located on a web server, no special authentication is required to access and read it. We use a System.Xml.XmlReader to parse through the document.

xmlReader = XmlReader.Create("public_rootservices_copy.xml", settings, context)

Once the file is open, the example parses it node to node from beginning to end using a while loop. This example looks specifically with a node named oslc:ServiceProviderCatalog.

while (xmlReader.Read())
  select (xmlReader.Name)
  case "oslc:ServiceProviderCatalog"
    if xmlReader.HasAttributes
      sCatalogLocation=xmlReader.GetAttribute(iAttributes)
    endif
  endselect
endwhile

This test proves the ability to parse through a root services document and is built upon in subsequent tests.

ServiceProviderCatalog and ServiceProvider

In the previous section, we searched a root services document for a node named olsc:ServiceProviderCatalog. This node is the entry point for discovering services within the DOORS webservice. The olsc:ServiceProviderCatalog node in the root services document has an attribute which specifies the URL to the primary service provider catalog. This primary service provider catalog and all other catalogs contains a listing of Service Providers and/or child Service Provider Catalogs.

OAuth Credentials and Tokens

To access any services beyond the root services document, transaction requests must be authenticated with OAuth, an open authorization protocol (see also: IETF, The OAuth 1.0 Protocol). In addition to the location of the primary service provider catalog, the root services document contains information required for access with OAuth.

In the second Test of the example, Access RTN DOORS from RootService w/ OAuth, we retrieve the OAuth URLs from the root services document, provide our credentials and retrieve an access identifier. This exercise requires a functional DOORS Web service which has been configured for web / automated access. Your DOORS administrator will need to provide you with a consumer key and consumer secret. The second Test has a header section which the end user must fill with their own implementation-specific information:

!============================================================================
!This data is generic, configure the server and port before running this demo
sDwaServer="doors9501.com"
lPort=8443
sConsumerKey=""
sConsumerSecret=""
sRootservices="http://"+sDwaServer+":"+Str(lPort)+"/dwa/public/rootservices"
!============================================================================

sDwaServer is the URL of your DOORS web service

lPort is the port of the DOORS web service

sConsumerKey is provided by your DOORS administrator

sConsumerSecret is provided by your DOORS administrator

sRootservices is the address of the root services document. I assumed Rational DOORS Web Access version 1.4.0.2 or later.

With the correct information, the Test will retrieve the jfs:oauthRequestTokenUrl, jfs:oauthUserAuthorizationUrl, jfs:oauthAccessTokenUrl and use these URLs along with the user-provided information to load a log-in screen (via a pop-up Internet browser). After the user has put is his or her DOORS credentials, the Internet browser will respond with an identifier: a six digit query string value. This identifier is the access token required for access to documents beyond the root services document.

Depending on your organization's needs, the log-in process described can be optimized. For instance, instead of an external browser an ATEasy form can launch the log-in screen and automatically record and store the identifier.

An example: Crawling through your Database

All access attempts beyond the root services document must make use of the OAuth access token (identifier).  The final Test in the example demonstrates an algorithm for crawling through the DOORS web service.  The purpose of the crawler is to record the URL of all service provider catalogs and service providers within the database.

ATEasy keeps track of a list of to-be-searched URLs and already-searched URLS. Each URL in the to-be-searched list is accessed and parsed for service provider catalogs and service providers.  The URLs of these provider entities are added to the to-be-searched list as long as they do not already exist in either of the lists.  As URLs are searched, they are moved to the already-searched list.

Initially, the root services documents is the only URL in the to-be-searched list.

When the Test completes, the user can examine the already-searched list to see all of the service provider catalogs and service provider URLs.  While this Test is not particularly functional in itself, it demonstrates how a user may programmatically search for and locate a specific requirement with no previous knowledge of the database architecture.

ATEasy Example Code

"Unable to open HW.SYS/VXD" or "Unable to open HW Device Driver" error when opening ATEasy - Published on 3/7/2025

3/7/2025

Overview

ATEasy and other Marvin Test Solutions software used HW device driver to access hardware. This article explain how to solve and error message "Unable to open HW.SYS/VXD" or "Unable to open HW Device Driver..." that appear when starting ATEasy or other software. This error usally occurs when HW was not installed properly with Administrator privileges, or because of the HW driver is not the latest driver (see KB Q200362). To learn more about HW, see What is HW?

Figure 1: ATEasy Error

Solution

Download and install the latest HW driver:
Download HW.exe setup

If that does not work, you can try the following steps (after upgrading to the latest HW version):

Start the current HW driver manually using the command prompt as explained here:

1. Open the command prompt in Administrator mode: Open Windows Explorer, select the Windows, System 32 folder, Right-click cmd.exe and click on Run as Administratorr command. The Command Prompt window will open.

2. Type: cd\ and hit the Enter key.

3. Type: cd \Program Files\Marvin Test Solutions\HW, use Program Files (x86) when using a 64-bit machine. If that folder does not exist, you need to install HW from Marvin Test website HW product, downloads tab: Download HW

4. Now that we are in the file directory we can run the HWSetup.exe. Type: HWSetup install start and hit enter. This will begin the install process. When it finishes running you should receive confirmation of completion and some notes.

5. We can also check the status of HW by typing the command: HWSetup status.

Figure 2: Command Prompt

GT95015 Differential Digital I/O Breakout Adapter Board Product Information - Published on 3/1/2025

3/1/2025

The GT95015 is a breakout adapter that can be used with all MTS Digital I/O products that provide differential I/O signals. For ease of access to the digital signals, the GT95015 breaks out the 68-pin SCSI-2 connector (J1) pins to a dual row connector with 100 mil spaced pins, designated J2 on the board. In addition, the GT95015 provides three methods of terminating all of the I/O signals in order to best match the requirements of the UUT and the DIO instrument.

The basic connection between the GT95015 and the DIO instrument is accomplished using a SCSI-2 cable with 68-pin connectors on each end. The cable can be of any practical length as determined by the systems needs, however, consideration should be given to how signal or system timing might be affected as cable lengths are increased. The best approach would be to use the shortest cable practical (MTS part numbers for various length SCSI-2 cables are provided at the end of this document).
Cables connecting to the J2 100 mil pins may be individual wires, mass terminated connectors, or combinations thereof. Care should be taken to provide adequate ground returns for the signals used, again, giving consideration to how UUT loading, signal quality or system timing might be affected as cable lengths are increased.

The GT95015 supports three basic termination configurations; unterminated, bus termination and isolated termination, using SIP resistor packs in the locations provided. Refer to Figure 1 and Figure 2. Locations UR1, UR2, UR3, UR4, UR9, UR10, UR11 and UR12 are used for bus termination, along with jumpers JP1 – JP6. Locations UR5, UR6, UR7, UR8, UR13, UR14, UR15 and UR16 are used for isolated termination.

Figure 1: GT95015 Differential DIO Adapter

Isolated Termination
Isolated termination places a termination resistor across the differential signals using an eight pin single inline resistor package (SIP). The value of the SIP resistors is selected to match the characteristic impedance of the logic device and the cable and each SIP provides four resistors connected across four differential signals(see figure 2, UR5 – UR8 and UR13 – UR16). For example, if LVDS is being used, then the SIP’s should provide 100 ohm resistors. Care should be taken to orient the SIP’s so that pin 1 of the SIP is matched to pin 1 on the GT95015.
Bus Termination
Bus termination places a termination resistor from each of the differential signals to a reference termination voltage (see figure 2, UR1 – UR4 and UR9 – UR12), as determined by jumpers JP1 to JP6. The SIP’s used in the bus termination scheme are ten pin devices and provide nine resistors (one is unused) connected to a reference termination voltage. Care should be taken to orient the SIP’s correctly so that pin 1 of the SIP is matched to pin 1 on the GT95015.
The termination voltage is selected using jumpers JP1 to JP6 and can be configured to provide a single reference voltage for all signals, or split into two sixteen pin groups each with their own single or dual voltage references. Termination voltages can be applied to Connector J1 pins 33, 34, 67 and 68 or to connector J2 pins 65, 66, 67 and 68. This allows either the DIO instrument or the UUT to provide the termination voltage to the GT95015. However, caution should be exercised that termination voltages are not applied to both J1 and J2 pins simultaneously – especially if the voltages are of different levels or polarities, as damage may result to the GT95105, the DIO instrument, the UUT or all three.
Care should also be taken that if V+1 and V-1 are used, that JP5 is removed if they are different values or different polarities. Similar care should be taken that if V+2 and V-2 are used, that JP6 is removed if they are different values or different polarities

Figure 2: GT95015 Schematic

Click Here to View Large Schematic
Click Here to View Mechanical Drawing

MTS SCSI-2 Cable Part Numbers.
GT95021     2' shielded cable for GT5xxx/GX5xxx/GC5xxx (68pin SCSI-2 connectors on both ends)
GT95022     3' shielded cable for GT5xxx/GX5xxx/GC5xxx (68pin SCSI-2 connectors on both ends)
GT95028     10' shielded cable for GT5xxx/GX5xxx/GC5xxx (68pin SCSI-2 connectors on both ends)
GT95031     6' shielded cable for GT5xxx/GX5xxx/GC5xxx (68pin SCSI-2 connectors on both ends)
GT95032     6" shielded cable for GT5xxx/GX5xxx/GC5xxx (68pin SCSI-2 connectors on both ends)
GT95032-8 8" shielded cable for GT5xxx/GX5xxx/GC5xxx (68pin SCSI-2 connectors on both ends)

GT95014 Digital I/O Single-ended Beakout Adapter Board Product Information - Published on 2/25/2025

2/25/2025

The GT95014 is a breakout adapter for all MTS Digital I/O products with single-ended I/O signals. The GT95014 provides an interface between the 68-pin SCSI-2 connectors used on the MTS DIO cards and 100 mil spaced pins. In addition, the GT95014 provides the option of terminating all of the I/O signals to match the impedance requirements of the UUT and the DIO instrument.

Cabling

The basic connection between the GT95014 and the DIO card is accomplished using a SCSI-2 cable with 68-pin connectors on each end. The cable can be of any practical length as determined by the systems needs, however, consideration should be given to how signal or system timing might be affected as cable lengths are increased. The best approach would be to use the shortest cable practical.
The GT95014 is connected to the UUT via a 68-pin, 100 mil pin grid. Cables connecting to the 100 mil pins may be individual wires, mass terminated connectors, or combinations thereof. Care should be taken to provide adequate ground returns for the signals used, again, giving consideration to how UUT loading, signal quality or system timing might be affected as cable lengths are increased.

Configuration

The GT95014 supports two basic termination configurations, unterminated and parallel termination, using SIP resistor packs in the locations UR1, UR2, UR3 and UR4. Refer to Figure 1 and Figure 2.

Parallel Termination

Parallel termination places termination resistors in parallel from VCC and GND to the I/O signal using a ten pin single inline resistor package (SIP). The value of the SIP resistors are selected to match the characteristic impedance of the logic device and the cable, with each SIP providing eight pairs of resistors connected to eight separate signals (see Figure 2, UR1 – UR4). For example, if LVTTL signals are being used to drive a 100 ohm cable, then the SIP’s should provide the Thevenin-equivalent of 100 ohm termination resistors. Be careful to orient the SIP’s so that pin 1 of the SIP is matched to pin 1 on the GT95014.

Figure 1: GT95014 Single-Ended DIO Adapter

The VCC termination voltage is provided via pins 33 and 67 on connector J1, and pins 33 and 34 on connector J2. This allows either the DIO instrument or the UUT to provide the termination voltage to the GT95014. However, caution should be exercised so that termination voltages are not applied to both the J1 and J2 pins simultaneously – especially if the voltages are of different values, as damage may result to the GT95104, the DIO instrument, the UUT or all of the above.

Figure 2: GT95014 Single-Ended DIO Adapter Schematic

Click Here to View Mechanical Drawing

Instruments Installation on NI Linux Real-Time OS - Published on 2/13/2025

2/13/2025

This article details the process involved in using Marvin Test Solutions instrumentation when using an NI Real-Time target from a Windows host PC which superseded the deprecated Phar Lap OS. This includes the process to adding our instruments to the manifest and overcoming commonly encountered issues when installing the GtLinux software and adding MTS instruments. This process was most recently tested against Linux RT System Image 2024 Q3 and LabVIEW 2024 Q3 on the host computer.

First time installation: NI Linux Real-Time

GtLinux software package contains the shared libraries for all MTS instruments, but some NI Linux Real-Time OS specific modifications were be made to install this software.

Before starting installation of Marvin Test Solutions software, make sure that you are able to establish a connection to the remote target using NI-MAX software and then ensure the NI-VISA software is installed on the real-time target. Installing Software on NI Linux Real-Time

1. Download the GtLinux software package from the MTS website.
Download: GtLinux.tar

2. Follow the GtLinux instructions per GtLinuxReadMe.txt to deploy the software to the install directory by unpacking the tarball.

For example:

/usr/share/MarvinTestSolutions# tar -xvf ./GtLinux.tar

3. Using the -nirt option, finish installation per GtLinuxReadMe.txt

For example:

/usr/share/MarvinTestSolutions# sh ./install.sh -nirt

4. At this point, an optional verification can be performed. The command "ls -l /dev/HW*" should show the HWMTS driver. If this library is missing, the most likely cause if NI-VISA not being present on the Real-Time target. In this case, confirm step 1 was completed and retry installation of the GtLinux's install shell script.

If the HWMTS software is present, restart the target and confirm the instrument's presence in NI-MAX. Congratulations!

Troubleshooting

If an MTS device driver is not recognized and the chassis slot in known to be good, it is possible that the version of GtLinux was released before the instrument you are attempting to integrate.  If this is the case, the system installer could upgrade to the latest version of GtLinux or manually create an INF file using the NI-VISA Driver Wizard:

- Open the NI-VISA Driver Wizard.  This application is included with the NI-VISA software
- Select the PXI/PCI as the bus interface.

- In the "PXI/PCI - Device Information" wage, deselect 'This device has a subsystem ID' checkbox and fill out the VID, PID, Manufacturer Name, and Model Name.  This example is for the GX3500 FPGA PXI instrument

Manufacturer ID / VID is always 0x16E2 for Marvin Test instruments.
Product ID / PID usually matches the model number of the instrument.  In this example 0x3500
Manufacturer Name is always Marvin Test Solutions, Inc. for Marvin Test instruments.
Model Name should match the model name with the GX prefix.  A full description can be found in HW.inf.  In this example GX3500 Digital I/O FLEX FPGA Board
If the instrument is an express instrument, the 'This device is PXI Express' checkbox should be clicked.

This information can be found in the HW.inf file, usually located at C:\Program Files (x86)\Marvin Test Solutions\HW

%HW.GX3500DriverDesc%=HW, PCI\VEN_16E2&DEV_3500
HW.GX3500DriverDesc="GX3500 Digital I/O FLEX FPGA Board"

-Instrument prefix should match the model number (i.e. GX3500).  This should create an INF and INI to control the instrument.  These will need to be moved to the Real-Time target.

Install the instrument-specific INF
- Copy GX3500.inf created in the previous steps into /etc/nipal/devinit.d
- Copy libMtsIviVisaPlugIn.so to /usr/lib/x86_64-linux-gnu/MarvinTestSolutions/
- At this point, an optional verification can be performed.  The command "ls -l /dev/HW*" should show the HWMTS driver.  If this library is missing, the most likely cause if NI-VISA not being present of the Real-Time target.  In this case, install the software and rerun GtLinux's install shell script.
- Restart the system and verify the instrument's presence in NI-MAX as depicted below.

Related files

Sample GX3500 Configuration Files

National Instruments BIOS Compatibility software and MXI-Express - Published on 2/12/2025

2/12/2025

When using the National Instruments (NI) MXI Express interface (PCIe or ExpressCard) with a PXI or PXIe chassis, you may encounter problems with recognizing PXI/PXIe devices installed in the chassis (code 12 or 31 in Device Manager), with your computer locking up at boot, or with Windows crashes (blue screen). This is caused by the controller's (either a Desktop or Laptop) inability to enumerate these devices and allocate the appropriate resources through the MXI Express interface.

The following figure shows an example of the code 12 error in Device Manager.

Installing the NI BIOS Compatibility software and configuring your PCIe MXI Express card for compatibility mode, will force the BIOS not to allocate resources upon boot up. Resource allocation is done strictly through software.

Verify that your MXI Express PCIe board is supported in BIOS compatibility mode. Note that only the newer board revisions are capable of this. You can find a list of the supported part and revision values at Supported Boards

To resolve the issue, follow these steps:

Download and install the NI BIOS Compatibility software for Windows XP/Vista available at NI Compatibility Download

Once the software has been installed, shut down the computer and chassis.

Physically set the MXI PCIe card to compatibility mode by setting the correct jumper.

You can find instructions on how to switch your MXI PCIe card to compatibility mode at Switching MXIe Modes

Note that the laptop ExpressCard does not have any physical jumpers. Instead, it is switched through software control as per the instructions in the above link.

Start the chassis first, and then the computer. Any PXI/PXIe devices should now be found by Windows without errors.

Calling and Using Python Code from ATEasy - Published on 2/12/2025

2/12/2025

Introduction

NOTE: This article assumes knowledge of ATEasy and Python.

Overview

This article introduce the Python ATEasy driver that enables you to call Python scripts from ATEasy, The ATEasy Python Driver is a wrapper of the Python/C API that allows you to use and call Python modules (.py files) in ATEasy. ATEasy 2024 comes with ATEasy Python project that includes the following:

Python.prj - ATEasy Python example project file

Python.drv - ATEasy Python driver file

Python.prg - ATEasy Python example program file

Python.sys - ATEasy Python example program system file

Python.py - Python example program script file used by the ATEasy example program

Python/C API (Dynamic Link Library)

In order to use the ATEasy Python program you will need first to download Python and install it on your system. The Python installation package gives you access to the Python/C API's Dynamic Link Library (python.dll).

Open the Python Example project

The Python example project can be open from the the ATEasy Drivers folder, For ATEasy 2024 use following path: C:\Program Files (x86)\Marvin Test Solutions\ATEasy\2024\Drivers.

Figure 1: Open Python Example project

Example Project

The provided example gives an overview of how to access Classes, Methods, and Variables of a Python Module.

Figure 2: View of the Python Example Project

ATEasy Python Driver Operation

Below is the ATEasy Python Driver tree command:

Figure 3: Driver Commands

Initializing and Closing the Python Interpreter
Initializing the Python Interpreter is done automatically by the driver OnInit() event, it calls the Py_Initialize() DLL API (user can use the driver PYTHON Initialize() command to explicitly initialize the Python Interpreter).
Closing the Python Interpreter is done automatically by the driver OnEnd() event, it calls the Py_Finalize() DLL API which closes the Python Interpreter (user can also use the driver PYTHON Finalize() command to explicitly close the Python Interpreter).

Variables and Data Types - we use the following global variables:

Variable name	Variable Type	Description
avArray	Variant[1]	Array of variants
aucStrBytes	Byte[1]	Array of bytes
avArgv	Variant[2]	Array of Variants
hClientSocket	ASocket	A Winsock socket handle
hpyArgs	hpyObject	Pointer to a Python object representing the tuple array
hpyClass	hpyObject	Pointer to a Python object returned from PYTHON Get Object FromAttribute() driver command
hpyClassInstance	hpyObject	Returned pointer to a Python object
hpyClientSocket	hpyObject	Pointer to a Python Class instance class variable
hpyList	hpyObject	Pointer to a Python list object
hpyModule	hpyObject	Pointer to a Python object returned from calling the import example Python module script file
hpyReturn	hpyObject	Returned Pointer to a Python object

Example Code: Instantiate Python Class With Initializer From ATEasy
The following example Instantiate Python Class With Initializer From ATEasy, fills an array, and returns the first item of the array

hpyModule=PYTHON Module Import("Python")
if hpyModule<>0

TestStatus=PASS

else

TestStatus=FAIL

endif
! nInitNumber is a const short = 21
hpyObject=PYTHON Get Object FromAttribute(hpyModule, "PythonClass")
hpyArgs=PYTHON Set Args Tuple({nInitNumber})

! Reference and retrieve PythonClass instance class_variable
hpyClassInstance=PYTHON Call Object(hpyObject, hpyArgs)
hpyReturn=PYTHON Get Object FromAttribute(hpyClassInstance, "class_variable")
TestResult=PYTHON Get Long(hpyReturn)

Code Explanation:
hpyModule=PYTHON Module Import("Python"): Import the module named "Python.py": This function returns a Python Object pointer to the imported module, or NULL if an error occurs.
hpyObject=PYTHON Get Object FromAttribute(hpyModule, "PythonClass"): This function passed the hpyModule object, representing the attribute name instead of a C string
hpyArgs=PYTHON Set Args Tuple({nInitNumber}): Create a new tuple of length =21
hpyClassInstance=PYTHON Call Object(hpyObject, hpyArgs): Reference and retrieve PythonClass instance class_variable
hpyReturn=PYTHON Get Object FromAttribute(hpyClassInstance, "class_variable"): Reference hpyObject from attribute name.
TestResult=PYTHON Get Long(hpyReturn): set TestResult to the first long value in the tuple array

Example Code: Return a Struct
The following example reads a structure from the Python.py file, and verify the values of the structure members.

!Python.py file module  section
def GetStruct():

    volt=3.64
    cur=3.1
    res=3.64/0.0031

    myStruct=struct.pack('@3d',volt,cur,res)

    return myStruct

ATEasy code

hpyModule=PYTHON Module Import("Python")
if hpyModule<>0

TestStatus=PASS

else

TestStatus=FAIL

endif

hpyObject=PYTHON Get Object FromAttribute(hpyModule, "GetStruct")
TestResult=PYTHON Get Data(PYTHON call Object NoArg(hpyObject), &stMeasurement)
if stMeasurement.dVoltage=3.64

TestStatus=PASS

else

TestStatus=FAIL
exittest

endif

if stMeasurement.dCurrent=3.1

TestStatus=PASS

else

TestStatus=FAIL
exittest

endif

if stMeasurement.dResistance=(stMeasurement.dVoltage/0.0031)

TestStatus=PASS

else

TestStatus=FAIL
exittest

endif

Code Explanation:
hpyModule=PYTHON Module Import("Python"): Import the module named "Python.py": This function returns a Python Object pointer to the imported module, or NULL if an error occurs.
hpyObject=PYTHON Get Object FromAttribute(hpyModule, "GetStruct"): returns the python object named "GetStruct" form the file
TestResult=PYTHON Get Data(PYTHON call Object NoArg(hpyObject), &stMeasurement): fill the ATEasy declared structure named stMeasurement with the data form the module.
if stMeasurement.dVoltage=3.64: verifying that the dVoltage structure member is equal to 3.64
if stMeasurement.dCurrent=3.1: verifying that the dCurrent structure member is equal to 3.1

Conclusion

Embedding the Python interpreter using the ATEasy Python driver allowing users to utilize Python's new and exiting code, and python libraries to enhance and expand ATEasy application.

How to Save an ATEasy Test Log to a PDF file - Published on 12/10/2024

12/10/2024

Introduction

When saving an ATEasy Log, the Test Executive supports the following formats: Log Files (.log), HTML Files (.htm, .html), Text Files (.txt), and HTML Web Archive Files (.mht). From the Test Executive, the Save As selection can be accessed from the Log Menu (Figure 1). HTML is set as the default option, but the user can scroll through the format list to view and select other available options (Figure 2).

This article will demonstrate the process for implementing ATEasy Test Executive options for saving PDF Test Log files.

Figure 1 – Log Menu Save As

Figure 2 – Log Menu Save As Options

Overview

For the Test Executive to support saving a test log as a PDF file, a Procedure needs to be created that will perform the task. And the Test Executive needs to be customized to allow the operator a means to execute the new procedure. Since the Test Executive driver is included as part of the ATEasy installation, any modifications made directly to the driver risk being over-written when updating your ATEasy installation or applying patches. For this reason, the method presented in this article will avoid directly changing the Test Executive code, and instead will use the Test Executive Tools:Customize utility built into the Test Executive to add the functionality as an extension to the Test Executive. The Test Executive extensions are saved in the ATEasy USR file and become a permanent extension to the Test Executive - without the need to modify the Test Executive directly. Future versions of the ATEasy Test Executive released by Marvin Test Solutions can continue to take advantage of the added functionality.

The process for adding the PDF save function is:

-  Create "LogSavePdf" Procedure in the System module
-  Customize the ATEasyTest Executive to add a new Log Menu selection and a new Toolbar Button to call the PDF save procedure
-  Test the new procedure and Test Executive customizations

NOTE: The save as PDF function utilizes the Print-to-PDF functionality built into the Microsoft Edge® browser that is installed with Windows®. While there are many other applications that provide similar functionality, they would only be available to systems where those applications have been installed. Since Edge is installed with all later versions of Windows, the functionality described in this article is available without the need to install, or purchase, any other applications.

For details of how this process works, see: Convert HTML to PDF by Using Microsoft Edge

Create New Save PDF Procedure

A new procedure, LogSavePdf, is inserted in the System module, Procedures submodule. The procedure could be inserted into a driver, but this would require the driver to be installed in every ATEasy application where the functionality is desired. Placing it in the System module and using that module as the standard System configuration going forward, allows all future ATEasy applications the ability of saving PDF test logs.

The procedure is self-contained; it does not require any parameters, and variables used within the procedure are local to the procedure to support the save PDF process. The full variable list for the procedure is shown below.

logToSave: ALog
sPdfFile: String
sWinExecCmd: String
lFlagSignal: Long
hWinExecHandle: AHandle
sHtmlFile: String

The LogSavePdf() procedure uses existing ATEasy Test Executive controls and methods - specifically, the formTestExec.cdlg Common Dialog control and it's ShowSaveAs() method. The Common Dialog control is used to enter/select the PDF file to use for saving the test log, and has various properties associated with it that govern the look and operation of the dialog. The code below configures certain dialog properties before calling the ShowSaveAs() method, which then launches the file navigation dialog.

! Set Test Executive ShowSaveAs dialog properties
TestExec.m_frmMain.cdlg.DialogTitle = "Save Log As PDF"
TestExec.m_frmMain.cdlg.Filter = "PDF Log Files (*.pdf)|*.pdf"
TestExec.m_frmMain.cdlg.InitialDir = GetDir() + "\\"

! Call the Test Executive ShowSaveAs method/dialog
if TestExec.m_frmMain.cdlg.ShowSaveAs() = acdlgRetValCancel then return
TestExec.m_frmMain.cdlg.FilterIndex = 2 ! Reset the control filter to HTML (2)

A successful return of the ShowSaveAs() dialog will contain the PDF file name and path in the FileName property. This is used for saving both a PDF version of the test log, as well as a temporary HTML version of the log. The Edge Print-to-PDF function uses an HTML file as the print source, so a temporary HTML file is created using the same file name and path as the PDF file, substituting the ".HTM" extension in place of ".PDF". Previous versions of the HTML file, if any exist, are removed before saving the new HTML formatted test log.

! create HTML path/file - temporary
sHtmlFile = Replace(TestExec.m_frmMain.cdlg.FileName, ".pdf", ".htm")
lWinExecSignal = FileRemove(sHtmlFile) ! Remove old HTML file - if exists

As ATEasy's Test Executive supports Multiple UUT testing, where each UUT is provided its own test log tab, it is necessary to select the Active Log for the PDF conversion. This is done using the public Test Executive GetLog() procedure. This procedure will return the ALog object of the current active test log selected using the UUT tabs located above the test log results. The log object is saved to an ALog-type variable logToSave. The SaveAs() method for the ALog object is called, resulting in an HTML file for the active test log being saved. If there is an error during the save, an error message is displayed.

! get log object for active UUT
logToSave = GetLog(ateLogActive, - 1)

if logToSave.SaveAs(sHtmlFile, False) = alogSaveFailed
MsgBox("Unable to save log file: '" + sHtmlFile + "'", aMsgOk, "Save PDF Error") ! Note the single quote usage '
return
endif

The Edge Print-to-PDF command line script for printing an HTML file to a PDF file requires that the PDF file path and name to be surrounded by quotes. These quotes are added as prefix and suffix escape characters ("\""). The old PDF file is removed, and an Edge command line script is created as outlined in the article linked above. The command line is executed using ATEasy's WinExec() command to launch Edge in silent mode (headless) and print the temporary HTML file as a PDF file. After WinExec() completes, the temporary HTML file is removed.

! Create PDF path/file
sPdfFile = "\"" + TestExec.m_frmMain.cdlg.FileName + "\""

! Remove old PDF file - if exists
lFlagSignal = FileRemove(TestExec.m_frmMain.cdlg.FileName) ! remove old PDF

! create WinExec() command using Edge --print-to-pdf function
sWinExecCmd = "msedge.exe --headless --disable-gpu --run-all-compositor-stages-before-draw " + sHtmlFile + " --print-to-pdf=" + sPdfFile

! Execute WinExec command
hWinExecHandle = WinExec(sWinExecCmd)
lFlagSignal = WaitForSingleObject(hWinExecHandle, 10000) ! wait for WinExec signal

! Remove temporary HTML file
FileRemove(sHtmlFile)

Add Test Executive Hooks (Extension)

For the following section, refer to the Knowledge-Base article Adding Custom Commands to ATEasy Test Executive

To call the LogSavePdf() procedure we need to customize the Test Executive to add hooks to the LogSavePdf() procedure. We do this by defining a new Test Executive command, and linking that command to new menu selections, toolbar buttons, or form selections. From the Test Executive Tools:Customize menu, create a new User Command similar to the "SavePdf" command shown in Figure 3. Fill in the Name, Captions and Description, and enter the System Procedure created above in "Procedure" and click the Check Box. An error message will be displayed if the procedure cannot be found. Finally, link an image that you would like associated with the new command. This image can be BMP, JPG or PNG, and should be sized approximately 150 x 150 pixels.

This example used the following PNG image:

To add the PDF save function to the Test Executive menu and to the Test Executive toolbar, follow the examples shown in Figure 4 and Figure 5.

Figure 3 - Customize Command Figure 4 - Customize Menu Selection Figure 5 - Customize Toolbar

Testing The New Functions

To test the Save to PDF functions we added, we need a test program to generate a test log to save. Since the PDF save is designed to work with multiple UUTs, it would be helpful to generate a test log the uniquely identifies the UUT number in the PDF log. The Task/Test structure in Figure 6 below will simply display the UUT number as the Result value in the test log.

Figure 6 - Program Task/Test Structure

Running the project will open the Test Executive as normal, but new menu options and toolbar buttons are available that allow saving the test log as a PDF file, see Figure 7.

Figure 7 - Save PDF Menu and Toolbar Options

If the newly created System LogSavePdf() procedure is not copied to future projects, the Save PDF Log option in the Menu and Toolbar will be grayed-out - see Figure 8. This is a reminder to copy the procedure to any new project where the ability to save a PDF test log is desired.

Figure 8 - Save PDF Menu and Toolbar Options Disabled

Conclusion

This article demonstrated the process for adding a System procedure that uses the Edge Print-to-PDF capability to save an ATEasy Test Log to a PDF file. Also demonstrated were the steps to add Save As PDF options to the ATEasy Test Executive Log Menu and Toolbar.

A copy of the ATEasy SaveAsPdf Project can be downloaded here.

See also: Word VBA reference© and Document.ExportAsFixedFormat Method©

Using an ATEasy Exported DLL in LabView - Published on 11/22/2024

11/22/2024

Introduction

ATEasy provides means to create a DLL to export functions written in ATEasy. The DLL can be used within other ATEasy projects, bringing the functionality of the DLL into new ATEasy applications, or they can be used in applications written in different programming languages, such as 'C/C++', C#, Visual Basic®, LabVIEW® and others. This application note demonstrates how to export a simple set of ATEasy procedures to a DLL and use those procedures in a LabVIEW application. It will also address areas where special attention needs to be given.

Creating a DLL Project

ATEasy can create a DLL from any Procedure defined in the System module, or any Procedure or IO Table defined in an ATEasy Driver.

Note: Program module procedures cannot be exported, only driver or system modules can export procedures.

Going forward, the term "Procedure" will be used synonymously to represent either an ATEasy Procedure or an IO Table. When intending to generate a DLL, an ATEasy project needs to specify if the "Build" will produce an application (EXE) or a Dynamic Link Library (DLL). The process to build an EXE or a DLL is the same, the difference is whether the project has been configured to produce a DLL. This can be done either by creating the project using the Startup:Library Wizard (Figure 1), or by setting the project property Target Type to "Dynamic Link Library (DLL)" (Figure 2).

[:+[+ateasy+]+:]

Figure 1: Startup Library Wizard Figure 2: Project Properties

Note: When creating a project for DLL export, it is not necessary to include a Program module or a Driver module. However, both may be included without creating any adverse effects.

It is necessary to also flag which procedure to include in the exported DLL. This is done by opening the properties dialog for the selected procedure and checking the Export check box. This is an indication that, when the project is built, to include that procedure, and all procedures with the export check box checked, in the exported DLL.

For this discussion, an ATEasy project was created, and the project target type was set to produce a DLL. A driver named MyExample was created and four simple procedures were defined to add, subtract, multiply or divide two double precision floating point values, and return the results. Each of the procedures checked the export check box (Figure 3) in their respective properties.

Figure 3: Procedure Properties

Note: When installing ATEasy, two IDE bit-wise versions are included with the installation; ATEasy IDE 32-bit for 32-bit applications (running on 32 or 64- bit Windows), and ATEasy for 64-bit IDE for 64-bit application running on 64-bit Windows. The bit-version version of ATEasy IDE determine the bit-wise of the DLL that is created using the Build command. The generated DLL bit-wise must match the Bit-wise of the LabVIEW - 32-bit or LabVIEW 64-bit. If you are uncertain which version of ATEasy you are currently using, the "Help:About ATEasy" will identify whether you are running the 32-bit (x86), or 64-bit (x64) ATEasy, as shown in Figure 4.

Figure 4a: ATEasy 32-Bit (x86)

Figure 4b: ATEasy 64-Bit (x64)

Building the DLL and Exporting Header File

To compile the DLL, use the same commands from the Build menu that you would use to compile your EXE. Pay special attention to the Build Log for any errors or warnings. A clean build should produce a log similar to that shown in Figure 5. It will list all of the procedures included in the DLL, as well as the DLL name and path. A good idea is to place the resulting DLL in the appropriate Windows folder for 64-bit DLL's (System32), or 32-bit DLL's (SysWOW64) to avoid potential conflicts.

Note: When ATEasy builds a DLL, it's possible for some functions to be excluded in the header file. Excluding functions can occur if some aspect of the procedure you want to export is not supported in the export process. A common discrepancy is that ATEasy DLL's cannot export arrays to external applications. If you encounter such error messages, consider using a Variant in your function instead of an array. Variants can contain arrays, structures, arrays of structures or any other data type defined in ATEasy

Note: Trial versions of ATEasy cannot compile a project to either an EXE, or to a DLL. These functions are reserved only for paid license subscriptions.

With a clean DLL compile, the next step is to export a header file (.H) for your DLL so it can be used in applications written in other programming languages. Select the Active Project you just compiled and select "Export" from the File Menu. There are two export formats, "ATEasy DLL to C" or "ATEasy DLL to Visual Basic .NET" (Figure 5). While referring specifically to 'C' and Visual Basic programming environments, that is not to imply that these are the only two languages outside of ATEasy that the DLL or the exported header files can be used with. This example will use the 'C' header file to facilitate using the DLL within LabVIEW.

Figure 5: DLL Build Log and Export Header File

Importing the DLL Into LabVIEW

To use the ATEasy DLL in LabVIEW, open your LabVIEW application (32-bit or 64-Bit depending on your ATEasy build) and then use LabVIEW’s Import Shared Library Wizard to import your DLL functions. Please see this ni article Call a Dynamic Link Library (DLL) From LabVIEW© for more details.

Note: The LabVIEW Import Shared Library Wizard expects a procedure declaration for each procedure you want imported as a vi. ATEasy v2024 and later include this declaration in the exported header file, while ATEasy v2023 and earlier do not include the declaration. However, a simple modification to your header file will facilitate the LabVIEW wizard importing your ATEasy 2023 and earlier DLL functions. Find each of your ATEasy procedure calls in the header file, and for each, copy the procedure call and past a copy of it above the call, appending a semicolon ';' to the end, as shown in the example below:

double MyAdd(double dValue1, double dValue2);
double MyAdd(double dValue1, double dValue2)

The following figures outline the process of using the LabVIEW Import Shared Library Wizard. These screens were capture from importing the ATEasy DLL created above, using LabVIEW 32-bit.

As an alternative, if your version of LabVIEW does not support the Import Shared Library Wizard, or if you want to use a subset of the functions in your DLL, you can manually import DLL functions into LabVIEW using the "Call Library Function" Node. Add the Call Library Function Node vi to your LabVIEW wiring diagram and configure it for the return type (if any), and the number and types of parameters in the functions (Figure 6). The resulting vi's can then be used in your LabVIEW application, extending the functionality of ATEasy into the LabVIEW realm (Figure 7).

Figure 6: Configuring the LabVIEW Call Library Function Node

Figure 7: LabVIEW VI's Calling ATEasy Procedures

Summary

The process creating a DLL to facilitate exporting procedures from ATEasy to other programming languages is both straight forward and simple. Once exported by the DLL, the functionality of the procedure is available outside of the ATEasy. This includes any resources used by the exported procedure, such as other procedures, variables, forms and instrumentation. All resources used by the called procedure are embedded in the DLL providing maximum flexibility and utility.

A link to the ATEasy project and resulting DLL's and header file described in this article can be found here: MyExample Project

Configuring an ATEasy Instrument Driver with an LXI Interface - Published on 11/22/2024

11/22/2024

Overview

LXI provides a convenient interface for communicating with and controlling benchtop ATE instrumentation. This article demonstrates how to use an LXI interface to access an instrument's internal web services, use the Telnet application for instrument communication, and how to create a simple, yet useful driver for controlling LXI instruments within ATEasy®.

Basic LXI Guidelines

To communicate with an instrument using LXI, you will need to know two essential interface parameters: the IP address and the remote port.

In this article, the Agilent (Keysight) model 53220A Universal Frequency Counter will serve as a representative instrument. The 53220A provides multiple remote interfaces, and the front panel can be used to obtain the interface parameters used for remote communication. The instrument is configured with an IEEE 488 (GPIB) interface, a USB interface, and an LXI (LAN) interface. From the front panel (Figure 1), the configuration parameters can be viewed to assist the operator in setting up remote operations. The GPIB primary address is "3", the VISA resource descriptor for the USB port is "USB::2391::6151::MY50005754::0::INSTR", and the LAN/LXI IP address is "169.254.4.32".

Figure 1: Agilent 53220A GPIB, USB and LAN or TCP/IP Remote Communications Parameters

For LXI/LAN instruments, a web server is typically hosted on the instrument as a component of the instrument's operating system, and it can be opened and viewed from any browser (Figure 2). This web panel provides additional information beyond that displayed on the instrument's front panel, and can be used to configure the instrument's various remote parameters. In addition to the LAN information shown on the front panel in Figure 1 above, the web panel shows the VISA TCP/IP resource descriptor and both the TCP/IP socket port and the Telnet port.

Figure 2: Agilent 53220A Web Panel. LXI IP Address and TCP/IP Port Parameters are Highlighted

A quick and easy method to test for LXI communication is using the Telnet application that is provided with Windows®. Telnet provides bidirectional communication between a computer operating as a terminal, and a remote peripheral - in this case the Agilent 53220A. Communication is achieved by sending text commands to, and receiving text responses from, the peripheral device. To use Telnet on a Windows platform, the Telnet application needs to be installed. Type "Windows Features" in the Windows search box and select the Turn Windows features on or off option. Enable Telnet by checking the check box for Telnet Client as shown in Figure 3 below.

Figure 3: Enabling the Windows Telnet Client Application

Telnet has a few simple commands that can be viewed by typing "?/H" at the command prompt. To use Telnet as a terminal for the 53220A, open a socket for the device using the "O" command, provide the IP Address or mDNS Hostname, and include the Telnet Remote Port parameter shown in the 53220A web panel. The example as shown in Figure 4 is "O A-53220A-05754 5024". This command opens a port to the Telnet application. Simply type a valid command to set up the instrument or query a parameter. Shown in Figure 4 is the "*IDN?" identification query command.

Figure 4: Remote Communication Using the Telnet Terminal Application

Note: If your instrument does not provide the Telnet remote port information, a common default port used with Telnet is 5024.

ATEasy LXI Control

Once basic LAN communication has been established, controlling an LXI instrument from ATEasy is very simple. As is typical with most test solutions, there are several methods that can be used within ATEasy to communicate with external instruments. Knowledge Base Article # Q200194 discusses how to import an LXI function panel (a DLL based driver) into ATEasy. This produces a robust, high level interface targeted for the specific instrument that the driver was written for. But it falls short as a general purpose interface, such as when you need to communicate with a different device. Since LXI uses text communication, a generic text based IO approach covers virtually all LXI instruments. The following section describes an overview of how to create a generic LXI driver for instrument control using ATEasy IO Tables.

Note: Familiarity with creating and using ATEasy IO Tables is assumed.

Begin by creating a new ATEasy Project. Add a new Driver to the project (Figure 5). From the Driver Properties, select the General tab and give the new driver the default name of "LXI" (Figure 6). Select the Interface tab and scroll down the Interface list and select Winsock (Figure 7).

Figure 5: Adding a New Driver to the ATEasy LXI Project

Figure 6: Defining the Default Driver Name Figure 7: Defining the Driver Interface

Open the driver shortcut, select the Interface tab, and set the Interface to Winsock. Selecting the WinSock interface populates the tab with additional parameters. For the Remote Port parameter, enter the TCP/IP Socket Port value from the instrument web panel (5025). Enter the IP Address value from the web panel in the driver shortcut Address field (169.254.4.32). The driver is now configured to communicate with IP address 169.254.4.32 on remote port 5025.

Figure 8: Setting the LXI Driver Shortcut WinSock Interface Parameters

Referring to figure 9, create two IO Table procedures, one for sending commands to the LXI instrument (Send) and one to receive responses from the LXI instrument (Receive). The ATEasy online "Getting Started" manual has a section in the Drivers and Interfaces chapter that goes into detail of how to create IO Table procedures. Following that process, create a new IO Table procedure, and name it "Send". Insert an IO table "Output" operation, and define it as a "Parameter to ASCII" type operation. Insert another operation and configure it as a "Send" operation. The Send IO Table procedure will accept ASCII text as input, and write the text to the instrument specified by the driver shortcut's interface parameters - remote port 5025, address 169.254.4.32 in this example.

Create another new IO Table procedure, and name it "Receive". Insert an IO table "Receive" operation. Add another operation and configure it as an "Input", "ASCII to Parameter" type operation. The Receive IO Table procedure will receive ASCII text from the LXI instrument at the specified address, and save the text into the variable referenced in the procedure.

Figure 9: Generic IO Table Send/Receive Procedures

To utilize the ATEasy command completion feature, you can create ATEasy Commands. Commands are user defined statements that call associated procedures defined within the ATEasy application. Once defined, typing the command's name, LXI in this instance, pops up the ATEasy code completion window, allowing you to navigate the various syntax options of the command tree. Here, in Figure 10, two commands are defined, "Send" and "Receive", and attached to the IO Table Send and Receive procedures, respectively. The syntax to send a text command using the newly created ATEasy Command is "LXI Send("text String")"

Figure 10: Attaching Command to the IO Table Send/Receive Procedures

One of the more common problem areas experienced with text-based communication is correctly setting the I/O termination parameters. ATEasy supports a variety of I/O termination options. The Interfaces tab of the Driver properties provides a drop list of defined termination options - see Figure 11. The 53220A instrument this article was based on uses a line feed character (ASCII(10)), or escape sequence "\n") for both input and output termination. Other options are carriage return (ASCII(13), escape sequence "\r"), both carriage return and line feed, period (".") and None.

Note: For the 53220A, experimentation demonstrated that the text communication would hang or time out if the wrong termination was selected.

Figure 11: Setting IO Table Send/Receive Termination

A useful tool for verifying communication using IO Tables is the ATEasy Monitor. This built-in ATEasy utility will capture and display the text strings sent and received between ATEasy IO Table procedures and the instruments utilizing the IO Table driver. If, for example, you can verify text commands are being sent to an instrument, but queries go unanswered, it's a good indication that the termination character may be set incorrectly. If there is no communication at all, then perhaps the interface parameters, such as the Remote Port or the IP Address may be invalid. To enable the ATEasy Monitor, select it from the view menu, right-click within the Monitor window and select "Start Logging" from the list.

The SCPI commands below were taken from the "Scaling Example" on page 213 of the "Keysight 53220A/53230A 350 MHz Universal Frequency Counter/Timer" manual. A test was configured to send out the commands provided in the manual, and the exchange was captured and displayed in the Monitor window. Note that all SCPI communication was captured, including the "*IDN?" query/response and the "Syst:Err?" query/response, not just the scaling commands.

Figure 12: Monitored IO Table Send/Receive Communication

If you have problems using ATEasy or the LXI instrument panel with your LXI instrument, you may be having an issue with Windows Defender firewall. It may be necessary to change your firewall setting to allow blocked applications through the firewall, or to enable the Telnet or TCP/IP port. Below is a link that explains the process for allowing select applications through your firewall. The basic process is to open the Windows firewall settings, and select "Allow an app through Windows Firewall". A dialog will show information about apps that currently are allowed through the firewall. If you want to change app settings or add apps to the list, select "Change Settings". See Figures 13 and 14.

How to allow apps through firewall on Windows 10

Set Firewall to Allow ATEasy Through the Firewall

Figure 13: Opening Windows Firewall

Figure 14: Define Rules to Allow an Applications Through Windows Firewall

Figure 15: Define TCP/IP Port Allowed Through Windows Firewall

Note: You should check with your company's security policy before making changes to your firewall settings.

Summary

LXI provides a convenient interface for communicating with benchtop ATE instrumentation. This article demonstrated multiple processes for working with an LXI instrument over a TCP/IP interface, Web Panel, Telnet and an ATEasy driver. Topics also covered in the article are how to create an IO Table driver, how to configure the LAN driver interface, and how to use the ATEasy Monitor utility to monitor IO Table text communication.

Controlling LXI instruments with ATEasy, Telnet or the built-in web services is not difficult, but a little knowledge can help smooth the process.

The ATEasy project discussed in this article is provided via the link below.

LXI Project

Installing and Using ATEasy Network License - Published on 9/27/2024

9/27/2024

Note: This article was modified to reflect the latest ATEasy version (v10 156d, added Online activation). Please follow this even if the ATEasy clients are older version of ATEasy.

The server application, License Server (ALicenseServer.exe), must be installed in a computer that will be the ATEasy license server. The License Server computer must be a 32/64 bit Windows Operating System (Windows XP (sp3), Windows 7, 10, 11, or Windows Server 2003, 2008, 2012 or 2016, 2022, or newer, Virtual Machine installation is supported but only with online activation). The computer must be turned ON and connected to the network while the clients are running. Clients must be authenticated to the server to be able to retrieve licenses. We recommend to install it on one of the company servers (typically Windows Server) since it always turned on.

Setup the License Server

Download the latest ATEasy from ATEasy Product Page, it always best to use the latest ATEasy even if your license applicable to older ATEasy versions.

Run the ATEasy Setup program at the server computer as an administrator privileges user. Select Custom setup type.

Select the License Server option, un-check all the other options (unless you intend to run ATEasy on that machine).

After the setup is complete, the License Server icon will appear in the Windows Taskbar and will be added to the server services. You can verify the service being installed by right clicking My Computer icon on the server and selecting Manage and then followed by Services under Services and Application. The ATEasy License Server should be displayed in the list.

Install the License Key in the server

Stop License Server: Open Windows Services (Start, Run, Services.msc), Right Click on ATEasyLicenseServer and select Stop.
Verify that no ALicenceServer.exe instances are running by other users logged in to the machine using the Windows Task Manager Details page, if there are, you can safely close their instance using the End Task button.

Open Windows File Explorer and change the folder to ATEasy folder (i.e., C:\Program Files (x86)\ATEasy 9.0\), right click on ALicenseServer.exe and select Run as Administrator

Click on the ATEasy icon in the Task Bar and select About ATEasy License Server.

Click the Set License button to display the License Setup dialog box.

For Offline activation (computer have no internet access): Select Install Network License, an ATEasy Computer ID is displayed in the bottom field. The ATEasy Computer ID is used to identify the machine where the license is installed. With the ATEasy Computer ID and Serial Number printed on your ATEasy CD or purchase order, create a Magic support incident using your existing or create an account if you don't have one https://www.marvintest.com/magic/ to obtain a license string. Once you receive the license string, open the License Setup dialog box again as explain the prior steps. Paste the License String or File. Click OK.

For Online activation (computer have internet access): Select Activate License Online, Enter your marvintest.com account email, password and the ATEasy Serial Number. Click OK. Note: Server must have access to https://www.marvintest.com/* at all time in order to operate correctly.

The About dialog should display the # of license installed. It also shows the connected users and computers names they were connected from, the ATEasy version, and the remaining timeout period as shown here:

Close the license server and Start the service again.

Setup the Client

Perform these steps only after you have obtained and installed the license string or file on the server.
Client must be authenticated to the server (usually member of the domain).

Install ATEasy at the client workstation, using the ATEasy Setup program.

Start ATEasy.

Open the License Setup dialog box from the Help, About menu or if no license is found the dialog box should show.

Select Use Network License from the License Type list.

Select the server name from the License Location list. If the server is not displayed leave the dialog open for a few minutes to the server list to populate or type the server name (DomainName/ServerName for example: GEOTEST/SERVER1). If the name does not work, you can also type the Server IP address directly (requires ATEasy v148c or newer) instead of the name, for example 10.10.1.6/10.10.1.6 where 10.10.1.6 is the server IP.
Note: ATEasy v8 148b or older requires that the server name will be shorter than 15 characters, if it longer, create a DNS alias entry with smaller name. The client/server communicate using Windows Named Pipes protocol that uses ports 137 and 139 UDP and potentially 445 TCP.

Select the Timeout that your client can borrow a license from the server when no or bad connection to the server or you are traveling out of the office (available on ATEasy v9 152c or newer).

Click OK to complete the setup.

Viewing Usage History

At any time, you can view the license usage history by opening the license log file. The file, ALicenseServer.log, is a text file that resides in %ProgramData%\MarvinTest Solutions\ATEasy (C:\ProgramData\Marvin Test Solutions\ATEasy) folder. You can open the file by right click on the ATEasy License Server icon in the task bar or using Windows Explorer. Here is an example for license usage records:

- Authorize License,Wed May  6 09:33:08 2020,Success,Client=Tester@DESKTOP-VMRP0HL/DESKTOP-VMRP0HL ATEasy 10.0 (Build 156d) (Timeout 4 hours 0 minutes) Copies=50 Used=11
- Release License,Wed May  6 09:37:10 2020,Success,Client=JohnX@DOMAIN1/UNIT291-2 ATEasy 9.0 (Build 154c) (Timeout 3 hours 57 minutes) Copies=50 Used=10
- Authorize License,Wed May  6 09:37:48 2020,Success,Client=JoeM@DOMAIN1/UNIT291-2 ATEasy 9.0 (Build 154c) (Timeout 4 hours 0 minutes) Copies=50 Used=11

Removing the License Server

Perform these steps to terminate the ATEasy license and remove the license server from a system that was previously serving licenses.

Terminate the license using the steps found in the Terminate an ATEasy Software License article found linked at the bottom of this article

Close all ALicenceServer.exe instances using the Windows Task Manager Details page by selecting instances and clicking the End Task button.

To uninstall all ATEasy elements:

Open the Uninstall a Program or Add or Remove a Program app, locate your version of ATEasy and select Uninstall

Follow the ATEasy Setup Dialog prompts to remove ATEasy and the License Server

To uninstall only the License Server:

Open the Uninstall a Program or Add or Remove a Program app, locate your version of ATEasy and select Modify

In the ATEasy Setup Dialog, select Modify, and Uncheck License Server

Hit Next to complete the modification

White Paper: Signal Switching Transparency in High Channel Count Test Systems - Published on 9/24/2024

9/24/2024

Signal switching subsystems are arguably the heart of all automatic test systems. Instrumentation is typically selected through careful analysis of test requirements and the associated levels of accuracy needed to accomplish successful unit under test (UUT) evaluation and qualification. While this approach will provide a solid starting point, and may even be suitable as-is for small test system implementations, actual test results may prove disappointing in larger configurations where numerous sources of measurement error are compounded in the signal routing / measurement path.

Download the white paper to learn about maintaining signal switching transparency in high channel count test systems.

Security Notification: Marvin Test Solutions HW driver Security Advisory for CVE-2024-26054, CVE-2024-26055, CVE-2024-26056 - Published on 5/20/2024

5/20/2024

We were recently notified of a potential security vulnerability in the HW Driver that applies to all versions (1.0 - 5.0.4.0).

To date, we have not received any report of any bad actors that exploited the vulnerability but we have taken an action to address it and improve the cyber-protection of the HW Driver.

The vulnerability was fixed and a new and improved HW Driver software package v5.0.5.0 is now available to replace the existing HW driver. The new version is backward compatible with all prior versions and you should not see any issues with using your other MTS software such as HW, GXDMM, GTDIO, GXFPGA, etc.). More details about the vulnerability is available in the HW ReadMe.txt found in the HW download area, list below.

Addressed CVEs

The following are the CVEs issued:

CVE-2024-36054 Description-- Hw64.sys in Marvin Test HW.exe before 5.0.5.0 allows unprivileged user-mode processes to arbitrarily read kernel memory (and consequently gain all privileges) via IOCTL 0x9c4064b8 (via MmMapIoSpace) and IOCTL 0x9c406490 (via ZwMapViewOfSection).

CVE-2024-36055 Description-- Hw64.sys in Marvin Test HW.exe before 5.0.5.0 allows unprivileged user-mode processes to arbitrarily map physical memory with read/write access via the MmMapIoSpace API (IOCTL 0x9c40a4f8, 0x9c40a4e8,
0x9c40a4c0, 0x9c40a4c4, 0x9c40a4ec, and seven others), leading to a denial of service (BSOD).

CVE-2024-36056 Description-- Hw64.sys in Marvin Test HW.exe before 5.0.5.0 allows unprivileged user-mode processes to arbitrarily map physical memory via IOCTL 0x9c406490 (for IoAllocateMdl, MmBuildMdlForNonPagedPool, and MmMapLockedPages), leading to NT AUTHORITY\SYSTEM privilege escalation.

Affected Products

The HW driver is bundled with many of our products including ATEasy and other software driver packages such as: GXDMM, GTDIO, GXFPGA, GXPIO, and more.

Solution

Update you HW and install HW v5.0.5.0 or newer. Download HW.exe and install it using the following link:
HW download

Testing Multiple UUTs in ATEasy - Published on 5/20/2024

5/20/2024

Introduction

ATEasy 8.0 adds Multiple UUT Testing feature – the ability to test Multiple UUT’s in Sequential, Parallel or Mixed mode, using common test processes. This article provide an introduction to Multiple UUT testing, illustrating the capability with a simple test example that can be download and run on any Windows© platform.

ATEasy Structure Overview

When developing test application using ATEasy, the test processes are organized into easy to read sequences of measurements.  This is possible because of the structured development environment provided by ATEasy.  The structure is achieved by using different Modules to organize code and test objects specific to the processes designed for the modules.  The three modules used for holding the test objects are the Driver module, the System module and the Program module.

Driver modules are used to hold any reusable code; for example, instrument drivers (collection of API functions specific to a particular instrument), application drivers (like the Excel® driver) and commonly used procedures and utilities, such as the ATEasy Test Executive.  The System module contains hardware configuration objects; i.e., objects used to control the configuration of the system.  Common System module objects are procedures that initialize instruments as part of a power-up or shut-down sequence, or in this example, procedures for opening and closing the Excel spreadsheet for data collection.  The Program module contains objects for making measurement and testing or validating the Unit Under Test (UUT), or Device Under Test (DUT) - the two terms are used interchangeably in this article.  Additional information about the ATEasy modules can be found in the ATEasy On-Line documentation.

The example presented here uses two drivers, one for the ATEasy Test Executive and an Excel spreadsheet driver based on the Excel ActiveX library.  The drivers are installed in the Driver folder under the System module.  The System module itself contains the code for opening and closing an Excel spreadsheet - not explicitly part of the test or measurement process, but used for collecting the test results for each of the DUT's being tested.  The Program module contains the actual test code, or more accurately, the measurement code and pass/fail evaluation parameters.  It is the System and Program modules that we will focus on for code development in the example.  We will also focus on how to use the ATEasy Test Executive to enable testing multiple devices - without additional code development.

Figure 1 below shows the ATEasy Workspace window, which highlights the structure of the ATEasy application discussed above.  Easily identifiable are the Program module - called Multi_Uut, the System module, and the Excel and Test Executive drivers installed in the Driver folder under the System module.

Figure 1: ATEasy Application Structure

System Module

Before discussing the System module code, we need to insert the drivers mentioned above.  These are the Test Executive driver and the Excel driver.  The Test Executive driver is included with the ATEasy installation and is located in the "Drivers" folder under the ATEasy folder.  The Excel driver is also included with the ATEasy installation, but is located in the "Examples" folder under the ATEasy folder.  The Excel driver utilizes the Excel Active-X library that comes installed with the Microsoft Excel application - implying that this example will not run without Excel having been installed in the system.  A copy of the Excel driver is included with this article as additional functions specific to the example program were added to the driver.

Another aspect of ATEasy's embedded structure are Module Events.  While a detailed discussion of module events is well beyond the scope of this article (refer to the ATEasy On-Line help), the general definition of a module event is a container for code that will be executed in a deterministic order within the application.  The primary System Events used are the OnInitProgram event (executed whenever a Program Module starts), and the OnEndProgram event (executed whenever a Program module ends).

The System.OnInitProgram event opens an Excel spreadsheet (Workbook) called "MultiUUT.xlsx", and creates a Worksheet for each UUT being tested.  Each worksheet is renamed with the UUT number associated with the worksheet.  The System.OnInitProgram event also initializes a System variable to the number of devices being tested.  As testing for each device initiates a unique thread, i.e., a copy of the Program module, for executing test code, the variable is called m_nThreadCount.  The System.OnInitProgram event code is shown below:

Procedure OnInitProgram(): Void Public ! Occurs when a program has started.
--------------------------------------------------------------------------------
sPath: String: 256
nRow: Short
nColumn: Short
nSheet: Short

{

If m_nThreadCount=0

  m_nThreadCount=App.UutCount ! The number of devices being tested
  sPath=GetDir(aGetDirCurrent)+"\\MultiUUT.xlsx"
  FileRemove(sPath) ! Delete old versions of the Workbook file

  Excel File Open New(, App.UutCount, xlwb) ! Create a new Workbook file
  Excel Show Application(True) ! Show the Workbook - comment to hide the Workbook

  For nSheet=1 to App.UutCount ! Repeat for each device - rename the Worksheet to UUT #
    Excel Set Worksheet Name(xlwb,nSheet,"UUT "+Str(nSheet)) ! New function added to Excel driver
    For nColumn=1 to 2 ! Repeat for each Task - add Worksheet column headers
      Excel Set Value(xlwb,nSheet,Chr('A'+nColumn)+"1","Task "+Str(nColumn))
      For nRow=1 to 16 ! Repeat for each device pin - add Worksheet row headers
        Excel Set Value(xlwb,nSheet,"A"+Str(nRow+1),"Pin "+Str(nRow))
      Next
    Next
  Next

  Excel File SaveAs(xlwb,sPath) ! Save the Workbook
EndIf

}

The System.OnEndProgram event counts down the m_nThreadCount variable as each Program module thread completes. When the last thread closes, the System.OnEndProgram event saves the Workbook and closes the Excel application. There is also a System.OnAbort event that is executed in the event that the operator aborts the test process. As the code performs the same function as the System.OnEndProgram event, only the System.OnEndProgram event code is shown below:

Procedure OnEndProgram(): Void Public ! Occurs when a program has completed.
--------------------------------------------------------------------------------
{

m_nThreadCount=m_nThreadCount-1 ! Decrement the thread count by 1

If m_nThreadCount=0 ! If the last Program thread is complete, save the workbook and close Excel
Excel File Save(xlwb)
Excel File Close(xlwb,True)
EndIf

}

In addition to the m_nThreadCount System variable, another System variable, "xlwb" is defined to hold the Excel Workbook object. For completeness, the definition for both System variables is shown below:

Variables
--------------------------------------------------------------------------------
xlwb: EXCEL.Workbook Public
m_nThreadCount: Short Public

Program Module

The Program module executes code for controlling instruments in order to make a measurement. Each measurement is compared against a pass/fail parameters to determine is the measured value is within defined limits. For this reason, each measurement is contained in an object called a Test. The Test object contains the code for controlling source and measurements and the pass/fail parameters. This example simulates performing a continuity test on a 16-pin IC. The measurement is simulated using a random number generator that produces mostly pass results, with some fail results thrown in for completeness. As in a real test case, continuity is checked against the Vcc and Gnd power pins, which produce positive voltage in the range of 0.6V to 0.7V, or negative voltage in the range of -0.7V to -0.6V, respectively. The code for the simulated measurements for Pin 1 are shown below:

!"Task 1 : "Continuity Vcc"
--------------------------------------------------------------------------------
Test 1.1 : "Pin 1"
--------------------------------------------------------------------------------
Min = 0.6
Max = 0.7
{
TestResult=0.599+(Rnd()/321254.9)
}

...

Task 2 : "Continuity Gnd"
--------------------------------------------------------------------------------
Test 2.1 : "Pin 1"
--------------------------------------------------------------------------------
Min = -0.7
Max = -0.6
{
TestResult=-0.701+(Rnd()/321254.9)
}

...

The Vcc and Gnd continuity measurements are organized into another structure called a Task. A Task is a collection of measurements that are organized by some common theme - in this case, the tests are organized by the power pin the continuity is being measured against - Vcc and Gnd. Figure 2 below shows the example Program Module Task/Test structure. The tasks are "Continuity Vcc" and "Continuity Gnd", while the tests are Pin 1 to Pin 16.

Figure 2: Program Module Task/Test Structure

Like the System module, the Program module also supports module events. The Program.OnEndTest event will execute at to conclusion of each and every test in the task/test sequence. This is a logical place to collect the results of each test and write them to the Excel workbook. The data is organized in the workbook by UUT number (worksheets), the task (columns) and the UUT pin number (rows).

Three properties within the application facilitate this organizational capability. They are the App.UutIndex, Task.Index and Test.Index properties. The App.UutIndex keeps track of which UUT is being tested. Using the value of this property, you can point to the worksheet associated with the UUT currently being tested. The Task.Index keeps track of which Task is currently being executed. You can use this property, with some minimal conversion, to point the worksheet column to store the test results in. And, likewise, the Test.Index can be used to point to the worksheet row to store the test results to. The Program.OnEndTest code is shown below:

Procedure OnEndTest(): Void Public ! Occurs when a program test has completed.
--------------------------------------------------------------------------------
sRow: String: 8
sColumn: String: 8
{

sColumn=Chr('B'+Task.Index) ! Convert the Task.Index to Excel column characters - works up to "Z" columns
sRow=Str(Test.Index+2) ! Convert the Test.Index to Excel row string

! Write TestResult to worksheet referenced by App.UutIndex, column sColumn, row sRow
Excel Set Value(System.xlwb,App.UutIndex+1,sColumn+sRow,TestResult)

}

Program modules, by default, run tasks and tests in sequential mode, and will run the task/test in the same thread. ATEasy supports two types of sequencing for Multiple UUT testing, sequential and parallel. Sequential sequencing is as described above and runs the task/test in a common thread, while parallel sequencing runs tasks and tests in different threads. For Multiple UUT testing, ATEasy supports these test methods using a combination of special module events, synchronization classes, and application properties. These synchronization classes and events are described in the ATEasy on-line documentation, and are beyond the scope of this introductory article.

Test Executive

In this simple application, Multiple UUT synchronization is handled by the ATEasy Test Executive. The ATEasy Test Executive must be properly configured in order to test multiple UUT's. First, you must make sure to include the ATEasy Test Executive driver in the drivers list, run the application - typically it is the last driver in the list of drivers included in the System:Driver folder. When an ATEasy application is run with the Test Executive included, the Test Executive user interface will be displayed, allowing control of the test process and a test log report of the test results - as shown in figure 3 below.

Figure 3: Standard Test Executive

For the following instructions, refer to figure 4 below. To configure the Test Executive for Multiple UUT support, while the Test Executive is visible, then from the Test Executive toolbar or menu list, open the Tools:Customize:Options menu, and from the list of parameters, select and set the Enable Multiple UUT's parameter True. The default number of UUT's is 4, although the default can be changed and saved, so may not be the same as in this example. Also set Default UUT Switch Level to Test . After closing the Customize dialog, the Test Executive user interface will update to show a tab for each UUT. Each UUT's tab shows the test log test results and a tree of the UUT program tests, the tab caption shows the UUT index number, the program name and an icon that will show whether the UUT is running (right box), stopped (box). The icon is colored by the UUT status: green for PASS red for FAIL, black for None as shown in figure 5 and 6 below.

Figure 4: Test Executive Configuration

Figure 5: Multi-UUT Test Executive

Running the tests using the default sequential test mode will run all of the Tests and Tasks for each UUT in sequence. You may notice an Excel workbook was opened when the ATEasy tests were started. If you click on the Excel workbook to give it focus, you will see the test results being populated in sequential worksheets in Task/Test sequential order. Figures 6 and 7 illustrate this process.

When all of the tests have completed for each UUT, the Excel workbook is saved and closed. You can open the workbook to review the test results. By design, each time the tests are run, the old workbook is deleted and a new workbook created, so if you want to keep the old test results, make sure to create a backup of the file before running the Test Executive again.

Figure 6: Multi-UUT Test Executive

Figure 7: Excel Workbook with Captured Test Results

The test mode can be changed from sequential to parallel, and and UUT count can be changed from 4 to up to 10 in the Tools:Controls:Option, as shown in figure 8. Observing the Excel workbook while running in parallel mode shown the worksheets being updated in a scattered appearing manner. Each UUT's tasks/tests are being run in their own thread, and update their respective worksheet when a measurement is completed. As this happens very rapidly, the worksheet updates appear scattered, but are actually following a the processes defined.

Figure 8: Changing UUT Count and Test Sequencing

You can also change the UUT count and the program associated to each UUT can be different (if your project have multiple programs). This can be done from the Test Executive Select Program dialog (see the Test Executive on-line help). In addition, you can set the UUT count and the program associated with each index programmatically, See the ATEasy TestExecMultipleUuts.prj example located in the ATEasy Examples folder..

This example can be run on any system with Microsoft Office (ATEasy EXCEL driver) installed and running a licensed or evaluation version of ATEasy.  Additional information about ATEasy's Multiple UUT testing capabilities and synchronization objects can be found in the ATEasy on-line documentation.

Download the Multi-UUT.zip Example Files:  Click Here

More articles on Multi-Site/Multi-UUT Testing
KB Article #Q200340 - Multisite Digital Test System Design
KB Article #Q200356 - Multi-site-Production-Test-Development-in-ATEasy
KB Article #Q200239 - Synchronizing-Resources-for-Multiple-UUT-Testing

Multi-site Production Test Development in ATEasy - Published on 5/20/2024

5/20/2024

This article discusses the test development architecture and features available in the TS-900e and TS-960e series semiconductor test stations when creating a test program for multiple site parallel testing.  It covers built-in ATEasy tools for semiconductor testing, ICEasy abstraction layer drivers for model independence and scalable test program development, as well as some considerations for measuring performance.

Single site testing is use of a test station, test equipment and software to evaluate a single die.  The necessary stimulus and measurement channels are routed to a test socket mounted on a device interface board (DIB) attached to the test station.  When testing completes, the device-under-test (DUT) is classified and binned according to the test results.  After the test is complete, a new DUT is tested by moving the IC out of the test socket manually or with an automated handler, or by moving the test head to the location of the next die in queue.

Multiple site testing involves testing multiple dies in parallel on the same test station, which is achieved by using duplicate test sockets or test heads, sharing instrument resources or augmenting the test station with duplicate test instruments to operate in parallel.  Coordination of these instruments and any shared resources is regulated by the test program's underlying software.

Software Considerations when Designing for Multi-Site Testing

ATEasy’s approach to multi-site testing is to design a single Test Program file (.PRG) from which multiple identical instances can be created and executed against a physical DUT.  Since identical copies of test software are run against various ICs, the test program should be written is a way which allows it to scale up to the amount of DUTs the load board and instrumentation is capable of supporting.

When multiple instance of a Program are started, an identical instance of the test program is created for each configured DUT based upon the configured value of App.UutCount, as described below. These programs can be executed sequentially or in parallel based on user configuration.  Usually, both tests sites will use an identical test program to test DUTs of the same series although it is possible to configure the test program to test different ICs in parallel.

Since the test code is identical, a method to differentiate the Program instances and sockets was devised.  During test execution, the ATEasy reserved project variable App.UutIndex is automatically set to reflect the active Program instance at the moment the test code is executing.

When enabling multi-site testing, an ATEasy reserved property, App.UutIndex, is used by the test program instance to differentiate between test programs and to determine which instruments should be used for stimulus and measurement.  During test program execution, App.UutIndex will update to report a value between 0 and App.UutCount-1 where App.UutCount is the value configured by the user via the Select Program/Profile dialog or SetUutCount() command.

See the ATEasy help article for more information on using "App.UutIndex".

Design Efficiency

Efficiency can be quantified by comparing the multisite test time with single-time test time as follows:

This can also be represented mathematically as follows:

Where:

N is the number of sites

t_N is the test time for N sites

t₁ is the test time for a single site

In the best case scenario: a single site takes 100 mSec and two sites in parallel also 100 mSec to test, t_N and t₁ are equal and the equation simplifies to 1 or 100% efficiency. This example is truly parallel. Conversely and a worse scenario, if a single site takes 100 mSec and two sites take 200 mSec, t_N - t₁ is equal to (N-1) * t₁ and the efficiency equation simplifies to 0 or 0% efficiency, which is more representative of serial operation. A more realistic example would be converting a single site test of 100 mSec to a quad site test which takes 130 mSec to complete all 4 dies. Test time growth would be 30 mSec and 3 sites were added to the system resulting in a 90% efficiency.

To evaluate this in another way, we define a simplified cost-to-test formula as the cost of the test station plus operational costs divided by the parts produced.

In the previous example, 1 unit was tested in 100 mSec. The parallel testing paradigm improved this to 4 units in 130 mSec. Let's assume that operational costs for the single unit amounts to 0.50 cost units.

Evaluating multi-site testing improvement is a matter of find the ratio between the original cost-to-test and the multisite cost-to-test.

The cost-to-test improvement is 0.5 / 0.165 or approximately 3 times (i.e 3 parts tested for the price of 1 part).

Configuring Multi-Site Domains Using Driver Shortcuts

All ATEasy drivers, including drivers such as the GX5296.drv for digital input/output (DIO) and AgNA.drv for vector network analyzer (VNA) are designed to initialize instruments when the system module is initialized and store the driver handle for each initialized instrument. During initialization, test sites are separated in the Driver shortcut parameters using a ‘;’ delimiter. For instance, a VNA driver shortcut with the ResourceName of “PXI17::0::INSTR;PXI18::0::INSTR” will use PXI17::0::INSTR for the first site in which App.UutIndex=0 and PXI18::0::INSTR will be used for second site in which App.UutIndex=1.

Calls to these instruments will have a parameter nDomainIndex or nHandleIndex which will route the command to the appropriate instrument. The default index value is 0, which is the App.UutIndex when only one instrument exists. If developing for multi-site testing, the usual input argument will be App.UutIndex.

In addition to setting the Driver Shortcut parameters through the Properties Editor, the configuration can be done dynamically during system initialization. Dynamic configuration is not required in most cases as the slot number and resource string will not change unless a PXI instrument is inserted or removed.

ICEasy Structure for Multi-Site Testing

The ICEasy driver resolves the problem of resource allocation and App.UutIndex value allowing the user to write a test program which scales to the number of test sites automatically. A top-level command of a test program written by a test engineer using ICEasy does not reference the App.UutIndex property. The reference to App.UutIndex occurs in the abstraction layer of the driver.

The command written by the test engineer would look like this:

! Measure nChannel at a rate of 60 Hz and assign to TestResult
TestResult=ICEasy DIO Measure Voltage(nChannel, 60)

If this command were written using low-level or direct instrument commands, each command would need to be written to pass the App.UutIndex in the nDomainIndex parameter. The same test code in a test program using direct driver commands would be written like this GX5296-specific example:

DIO Measure Voltage (nChannel, TestResult, 60, , , , App.UutIndex)

In either scenario, the test program would support both single-site and multi-site testing as App.UutIndex value would remain at its default value of 0 for a single DUT.

Configuring a Single Instrument to Service Multiple Test Sites

If an instrument has multiple independently operating channels, the instrument may be configured to support expansion to multiple test sites. As an example, consider a test station which includes two Source Measure Units (SMUs), each with four channels. If these cards are initialized using the method suggested in the Driver Shortcuts section, they could support two test sites with the first test program instance sending all commands to the first board and the second test program instance routing all commands to the second board. If the test program only utilizes two channels per site, then a total of four channels would be unused.
To remove this inefficiency, ICEasy can be configured with some instrument classes to specify the number of channels to be used per site (the domain size).

! Configure the SMU to use 2 channels per DUT
ICEasy SMU Set DomainSize(2)

In this example, the two SMU test station will direct commands from the first site to channels 1 and 2 of the first SMU and the second program will control channels 3 and 4 of the first SMU. The second SMU would not be needed for this test configuration, but would automatically be used if up to two more test sites were added to the system.

Because the model of the instrument is unknown by the ICEasy driver, the board’s maximum channel count must be written into the ICEasy interface driver (e.g. ICEasy_GX3104.drv). This value will be used to determine if the specific model is capable of supporting a split domain and how many channels are supported. The test program will notify via exception if the domain size requested is beyond the capacity of the selected instrument model. For backwards compatibility, the default domain size is equal to the maximum channel count of the board.

System, Program and Test Variables

Each instance of the Program module has unique instances of all the Program and Test variables which are independent from the Program instances from the other DUTs. These variables can be accessed from the test code and procedures without any modifications or concerns. Variables in the System module and Drivers are not duplicated and are shared by all Program instances. This means that multiple Program modules could attempt to write to or read from the same data in parallel. This behavior could lead to one thread accessing stale data or data intended for another Program or overwriting data which another thread intends to access. To mitigate this potential issue, the test developer should avoid the use of System variables in the Program modules. If System variables are used, access to these variables should be protected with a synchronization object and each thread should have a copy of the variable that is independent from the other instances.

See the following ATEasy help article for more information on multithreading and synchronization "Multithreading Considerations", "Procedure Properties"

Configuring your Test Application to Support Multiple UUTs

The default state of ATEasy and the Test Executive is to use single-site testing. To configure for multi-site testing, multiple UUTs must be enabled and test programs must be assigned to each site. Enabling multiple UUTs can be done manually or programmatically.
Manual configuration

Launch a single-site application which utilizes the Test Executive.

From the Test Executive menu, open the Customize dialog by clicking the menu item Tools | Customize

Navigate to the Options tab and switch the ‘Enable Multiple UUTs’ value to True.

After multiple UUTs is enabled, the DUT count can be set to a value greater than 1 and test programs can be assigned to the DUTs.

From the Test Executive menu, open the Select Program/Profile dialog.

Change the UUT Count to the desired number of test sites.

Enable Run Parallel. The default option is to execute the test programs sequentially.

Programmatic configuration

In a system or driver module, call the following command to enable execution of multiple test programs

TestExec Customize Options Set (ateOptionsEnableMultipleUUTs, True)

In a system or driver module, call the following command to set the DUT count to match the number of parallel test sockets available

! Configure for two DUTs
TestExec Execution SetUutCount(2)

Assign the test program to the test sockets, making sure to set the test mode to parallel

! Assign programs, setting sites 0 and 1 run the same test program in parallel
TestExec Execution LoadProgram("DualSiteExample", , aUutRunModeParallel, 0)
TestExec Execution LoadProgram("DualSiteExample", , aUutRunModeParallel, 1)

Final Considerations

When designing for multi-site applications:

Modify the Driver Shortcut parameters to add the extra domain using the ‘;’ delimiter so instruments are initialized into different domains and can be called using a single driver

At the Test level of your code, avoid the use of commands which target a specific instrument driver. Instead of calling DIO directly, use an abstraction layer like ICEasy.drv which can handle the task of directing the command to the correct instrument domain and supports instrument replacement

Only Program variables are duplicated in a multi-site application. If a System or driver variable is used, check to ensure that access is protected with a synchronization object and the variable can support access from multiple-threads without impacting other Test Programs

More articles on Multi-Site/Multi-UUT Testing
KB Article #Q200340 - Multisite Digital Test System Design
KB Article #Q200242 - Testing Multiple UUTs in ATEasy
KB Article #Q200239 - Synchronizing-Resources-for-Multiple-UUT-Testing

Synchronizing Resources for Multiple UUT Testing - Published on 5/20/2024

5/20/2024

Introduction

With the introduction of ATEasy v8, Multi-UUT testing was added. It is the ability to test Multiple UUTs in Sequential or Parallel mode. Program modules running tasks and tests in sequential mode will run in the same thread, while parallel tasks and tests will run in different threads. ATEasy® supports multi-UUT test using a combination of special module events, synchronization classes, and application properties. This article provides an overview on what these items are and how to use them to create ATEasy programs with the capability to test multiple UUTs within a single test application. This article also presents an example use-case which will show how to use some built-in synchronization features of the Test Executive available in ATEasy v10.

Synchronization Classes

For multi-threaded tests, it is necessary to synchronize control of your test resources. This is done using Synchronization Classes. Synchronization classes are used when access to a resource must be controlled to ensure integrity of the resource. The synchronization classes available in ATEasy are AEvent, ASemaphore, AMutex, and ACriticalSection.

[:+[+ateasy+]+:]

Here are summaries for each synchronization class.

Figure 1: ATEasy Synchronization Objects.

For more information on each synchronization class and example code, search "Synchronization Objects" in the ATEasy Help document.

Events and Properties

There are two Module Events and several Application Properties and Procedure Properties to support synchronizing resource control when testing multiple UUTs and managing test execution.

The module events are supported in each ATEasy module (System, Driver and Program), and are used when running in sequential mode:

OnInitSwitchUut: The OnInitSwitchUut event occurs just after ATEasy switches from one UUT to another.

OnEndSwitchUut: The OnEndSwitchUut event occurs just before ATEasy from one UUT to another.

The application object properties (i.e. App.UutCount) supporting multi-UUT test are:

UutCount: The UutCcount defines the number of devices to test when testing multiple UUTs at the same time, either in sequential, parallel, or both. This number is 1 for single UUT (default) or greater for multiple UUTs.

UutIndex: The UUT index returns the current index of the UUT running. This number is in the range of 0 to App.UutCount-1.

UutRunMode: The UutRunMode defines how the UUT tests are run (parallel or sequential). All UUTs running in sequential run mode will run on the same thread. UUTs running in parallel mode will each run in separate threads.

UutSwitchLevel: Sequential test mode only, the UutSwitchLevel property is used to define when ATEasy switches between sequential UUTs. You can set the switch level to program, task, or test.

UutLog: The UutLog property is used to set or retrieve the log control of the specified UUT index.

UutNextIndex: Sequential test mode only, the UutNextIndex property can be used to skip or redirect ATEasy to run specific UUTs.

UutProgram: A Program object that is used to store the UUT test results and hold the UUT test requirements for each test in that program.

Procedures have two properties, a Synchronize Resource Name and a Synchronize Checkbox that are used for multi-threading or Multiple UUTs with parallel run mode applications – see Figure 2 below.

Figure 2: ATEasy Synchronization Properties.

Synchronize Checkbox: When Synchronize is checked, it allows only one thread to execute the procedure with the specified (optional) Synchronize Resource Name. Other threads executing Tasks, Tests, or Procedures with the same name will be suspended until the procedure is complete.

Synchronize Resource Name: The Synchronize Resource Name text box is only enabled if Synchronize is checked. Any series of characters/string can be used for the name.

Example Use-Case: Multiple UUT Test For Various Temperatures

The following example explains how to set up a multi-UUT application where the same program in running repeatedly for various temperatures in parallel mode and each iteration executed with different temperature set. Since the UUT programs are running in parallel, for each iteration we must wait until all UUTs are completed for the next iteration with different temperature to be set, and then resume all UUTs to run the program again (OnEndTask for the last task).

In ATEasy v10 the Test Executive has two commands, WaitAll and ResumeAll, which help test programmers with multi-UUT synchronization. The WaitAll and ResumeAll commands were created to aid test programmers in testing multiple UUTs by providing a framework to handle the synchronization. The WaitAll and ResumeAll commands take care of implementing the synchronization objects presented above so the test programmer does not have to.

To demonstrate how to use these functions, we will imagine a possible use-case scenario. In this example we have a test system that does a variety of tests for a UUT. The system is capable of testing multiple UUTs at once. The goal of the tests is to gather data on the UUTs at different temperature levels.

To accomplish this, we need to do the following:

1. Add the TestExec driver to the System Module.
2. Add variables to the System Module to keep track of the temperature.
3. Write tests and supporting procedures for the UUT in the Program Module.
4. Add logic to the Program Module's Events to increase temperature and re-run the tests.
5. Configure the Test Executive for multiple UUTs.
6. Run and verify the application.

System Module

First we will add the TestExec driver to the project. This should be done in the System Module, as shown in Figure 3.

Figure 3: Add the TestExec driver to the project.

Next we add the variables shown below which will be used to handle the temperature of the system.

Variables
================================================================================
        nEndTemp: Short Public = 80              ! Last temperature to test.
        nIncrementTemp: Short Public = 10        ! Amount to increment temperature each iteration.
        nStartTemp: Short Public = 50            ! Starting temperature.
        nTestTemp: Short Public                  ! Current temperature.

Program Module

The program module is used to execute code for making measurements/testing the UUT. We will add some dummy tasks and tests for the purpose of this example. The first task is some voltage tests for the UUT. The second task is some current tests for the UUT.

The following step is optional - in the first test of each Task we add a print statement to show the temperature. These print statements appear on the test log and provide a way to document the temperature before the tests run.

Below is a snippet of the Program module that shows the tasks, tests, and the code within.

Tests
================================================================================

Task 1 : "Voltage Tests"
--------------------------------------------------------------------------------
        Id = Task_1

Test 1.1 : "3v Test"
--------------------------------------------------------------------------------
        Id = _3vTest
        Pin = "1"
        Unit = "V"
        Type = Other
{
        print "[Task 1] UUT: "+str(app.UutIndex)+" - Temp: "+str(nTestTemp)

        TestStatus=PASS
}

Test 1.2 : "5v Test"
--------------------------------------------------------------------------------
        Id = _5vTest
        Pin = "1"
        Unit = "V"
        Type = Other
{
        TestStatus=PASS
}

Task 2 : "Current Tests"
--------------------------------------------------------------------------------
        Id = Task_2

Test 2.1 : "100mA Test"
--------------------------------------------------------------------------------
        Id = _100mATest
        Pin = "1"
        Unit = "mA"
        Type = Other
{
        print "[Task 2] UUT: "+str(app.UutIndex)+" - Temp: "+str(nTestTemp)

        TestStatus=PASS
}

Test 2.2 : "500mA Test"
--------------------------------------------------------------------------------
        Id = _500mATest
        Pin = "1"
        Unit = "mA"
        Type = Other
{
        TestStatus=PASS
}

In the Program module's Procedures we add a procedure to change the oven temperature. For the purpose of this example, we place a trace statement in the procedure to simulate a temperature change. The trace statement is different from the print statements used above. Print statements go to the test log, while trace statements go to the debug log. In our trace statement, we output the new oven temperature that was set and the controlling UUT. The code snippet below shows the procedure SetOverTemp() that was created for changing the oven temperature.

Procedure SetOvenTemp(dNewTemp): Void
--------------------------------------------------------------------------------
        dNewTemp: Val Double
{
        ! Enter code to set oven temperature
        trace "\r\n[Temperature Change] Oven Temperature: "+Str(dNewTemp,10)+" - Controlling UUT: "+Str(App.UutIndex)
}

Figure 4 below is what the project looks like in the workspace-view after adding the tests and procedure.

Figure 4: The workspace view after adding tests and procedure.

Program Module Events

In the Program Module's Events we add code that changes the temperature after all tests have completed, and then re-run the tests. We repeat until we reach the user-defined limit (This was set using the variables we created in the System Module Variables).

First we start in the Program Module's Event called OnInit(). This event occurs when a program has started. In this event we set the starting temp of the oven. Here we will be using TestExec's functions, WaitAll and ResumeAll.

Procedure OnInit(): Void Public! Occurs when a program has started.
--------------------------------------------------------------------------------
{
        ! Set the oven's starting temp.
        if TestExec Execution WaitAll(ateUutsSyncFirstCallerReturnsFirst)
                nTestTemp=nStartTemp
                SetOvenTemp(nTestTemp)
                TestExec Execution ResumeAll()
        endif
}

TestExec Execution WaitAll:
This command is used to synchronize all UUTs when running in parallel mode.
after all UUTs called the function the last one will return and call call cmdResumeAll to release them from waiting.

TestExec Execution ResumeAll:
This command is used to resume all UUTs that were suspended by the WaitAll command.

In this event (Program.OnInit), we want to set the initial temperature at the very beginning before any UUT has ran their tests. Therefore, we will input ateUutsSyncFirstCallerReturnsFirst as the input for the enUutsSyncReturns parameter.

Next we move to the Program Module's Event called OnInitTask(). This event occurs when a program task has started. This is an optional step - we add a trace statement here to output the task number, UUT index, and the current temperature. We will use these trace statements later to verify that our program worked correctly.

Procedure OnInitTask(): Void Public ! Occurs when a program task has started.
--------------------------------------------------------------------------------
{
trace "[Program.OnInitTask() Event] Task "+Task.Number+" UUT Index: "+Str(App.UutIndex)+" - Current temp: "+str(nTestTemp)
}

In the Program Module's Event called OnEndTask() we handle changing the oven's temperature and re-running the tests. Here we will be using the functions WaitAll() and ResumeAll().

Procedure OnEndTask(): Void Public ! Occurs after a program task has completed.
--------------------------------------------------------------------------------
{
        ! if this is the last task in the program
        if task.Index = program.TestsCount-1
                ! check if we reached the temperature limit
                if (nTestTemp < nEndTemp)
                        ! one UUT will increment the temperature
                        if TestExec Execution WaitAll()
                                nTestTemp=nTestTemp+nIncrementTemp
                                SetOvenTemp(nTestTemp)
                                TestExec Execution ResumeAll()
                        endif
                        ! go back to first task of the program to begin the next iteration
                        Task endevents 1
                EndIf
        endif
}

In our application, we want to increment the temperature after all UUTs have finished testing.

Finally, we move on to the Program Module's Event called OnEnd(). This event occurs when a program has been completed. After the program has ended (the temperature limitation has been reached), we will create a trace statement telling us that the UUT has ended. This trace statement will be used later to verify that the program worked correctly. In this event we also reset the testing temperature variable (nTestTemp) back to the initial temperature so we can press Run again without having to close and reopen Test Executive.

Procedure OnEnd(): Void Public ! Occurs when a program has completed.
--------------------------------------------------------------------------------
{
        trace "[Program.OnEnd() Event] UUT "+str(app.UutIndex)+" has ended."

        if TestExec Execution WaitAll()
                nTestTemp=nStartTemp
                TestExec Execution ResumeAll()
        endif
}

Test Executive

Multiple UUTs can be added in the Test Executive user interface. But before we can begin using multiple UUTs, we need to verify that the option is enabled. Start by running the project and Test Executive will open. We can check the multi-UUT option by navigating to Test Executive's menu bar and going to Tools > Customize. In the Options tab locate the option called "Enable Multiple UUTs" and set the value to True. Then click OK to go back to Test Executive.

Figure 5: Enable Multiple UUTs.

We are going to add multiple UUTs to our test. Click on the folder icon on the top left labeled "Select..."

Figure 6: Click to Display the Select Program Dialog.

The Select Program Dialog screen will pop up. Change the UUT Count value to 4 and make sure the Run Parallel check box is unchecked. We will first test our application with 4 UUTs running in sequential mode. After you have finished setting up the UUTs as shown in Figure 5, press OK.

Figure 7: 4 UUTs running in sequential mode.

You'll notice that there are now 4 tabs, one for each UUT we created. Press "Start" or the F5 hotkey to run the program. After the program has finished, you can see the test logs for each UUT by switching through the tabs. The print statements from our tests appear in these logs. The print statements show the task number, UUT index, as well as the temperature. We can see that the tests start at a temperature of 50 degrees, increment by 10 degrees each iteration, and end at 80 degrees.

Figure 8: Test Executive finished running.

Next we'll check out the trace statements we created in the Program Module Events. The debug log is found in the ATEasy IDE; see Figure 9. We are able to verify that the order of execution in our application is correct.

Figure 9: Debug log for sequential mode.

Now we can verify our project is working for parallel run mode. There are no code modifications needed; just launch Test Executive again and go back to the Select Program Dialog. This time we are going to do 4 UUTs running in parallel run mode. Check the "Run Parallel" check box and press OK.

Figure 10: 4 UUTs running in parallel mode.

Press "Start" or F5 to run the program again. This time the UUTs are run in parallel. As with the sequential mode, we can go to the debug log to read our trace statements and verify the order of execution is correct.

Figure 11: Debug log for parallel mode.

Click here to download the Multi-UUT-Sync.zip example files.

Note: The example contains also the test executive driver that was used at the time the example was written , make sure to update the TestExec shortcut to point to that file.

More articles on Multi-Site/Multi-UUT Testing
KB Article #Q200340 - Multisite Digital Test System Design
KB Article #Q200242 - Testing Multiple UUTs in ATEasy
KB Article #Q200356 - Multi-site-Production-Test-Development-in-ATEasy

White Paper: The Future Direction of Test, Maintenance, and Instrumentation - A Supplier’s Perspective - Published on 5/10/2024

5/10/2024

The Future Direction of Test, Maintenance, and Instrumentation - A Supplier’s Perspective

This presentation focuses on current and future ATE trends and challenges for military and aerospace test applications. Originally presented at AUTOTESTCON 2016.

Download the presentation

SemiEasy Semiconductor Production Test User Interface and Features - Published on 4/12/2024

4/12/2024

SemiEasy is a drop-in software drivers that includes a suite of add-on features to the ATEasy Test Executive designed to streamline the transition from test development to production test. It is intended to be added to a finished test program but can be used in the test engineering lifecycle from the beginning of test design through test closure as it augments ATEasy test design features rather than replacing them.

SemiEasy Main Features

Simplified user interface for Production Testing ATEasy's default log output displays test numbers, names, limits and results for each test performed on the device-under-test (DUT). This information is most valuable when developing the test program, but is not useful in a Production environment where the goal is to quickly evaluate DUT performance, bin the device, record findings, and ready the next DUT for testing. SemiEasy displays information useful for bulk testing such as average test times, parts per lot, and binning results for the current lot. The SemiEasy User Interface is examined in greater detail later in this article.

STDF Automated Logging SemiEasy's UI is modelled after STDF's record fields and provides recognizable elements to users who are familiar with STDF record format. To improve efficiency, test results are recorded quickly during test execution and append to the file when the die is changed or the test head is moving.

Handler Integration SemiEasy includes access points at the beginning and end of each program run to let the user inject automated handler instructions to prepare the next die for testing and to bin dispositioned dies.

ICEasy programming interface ICEasy driver provides a way to operate the instrument in order to write tests an easy to use programming interface. The ICEasy contains commands to map pins, simplified commands to operate DIO, SMU SWITCH and the VNA instruments, pre-defined tests (e.g., continuity, force current/voltage-measure voltage/current, etc.).

ICEasy IDD Test Example:

SemiEasy User Interface Features

Simple interfaceThe features most important for Production test are prominent immediately after program launch. Features which are useful in development such as Loop on Test and Pause on Failure are available through the Test Executive menu. Test results information is maintained in separate tabs provided for quick analysis.

Test Statistics At a glance job statistics such as record information, test time statistics, STDF file location, and job status.

Binning Information Sortable binning information which updates as parts complete testing.

Job Information Test Program auto-fills Job Information (Handler type, Operators, IDs, image of the DUT, etc.) after the first job is completed. Future jobs require minimal or no configuration.

SemiEasy and other System Drivers

The source for SemiEasy (SemiEasy.drv) is stored in the SemiEasy.drv and is distributed with ATEasy. It takes advantage of the STDF automated logging driver for the recording of test data (STDF.drv) as well as the Handler interface driver (Handler.drv) which can be used to initialize an automated test handler, wait for a ready signal from the handler and inform the handler of binning information when testing has concluded. The SemiEasy driver also operates as an add-on to the Test Executive (TestExec.drv) allowing users to leverage Test Executive features if they require it for test applications. All of these drivers must be included to use SemiEasy.

To add these drivers to your system:

Right click on the System Drivers sub-module and select Insert Driver command.

Select the SemiEasy.drv, TestExec.drv, STDF.drv or SemiEasyHandler.drv file from ATEasy Drivers folder and select Open in the Insert dialog to insert.

Handler Interface Driver

The handler adapter provides locations within the SemiEasy job cycle where optional code can be executed.  The purpose of this is to provide a means for communication with an automated test handler which will load, unload and bin DUTs. At the beginning of the job SemiHandlerInitialize() will be called once to establish communication with the handler.  When the test program starts, SemiEasy makes a call to SemiHandlerGetSites() to both notify the handler that test execution software is ready to begin testing and to get information about available test sites.  This command should return a status of 0 when the handler has loaded the DUT or an error code if the handler is unable to comply.  Error code are reported to the test operator.  After the test execution has completed, SemiEasy makes a call to SemiHandlerSetBins() to notify the handler that testing has completed and to inform the handler of any relevant binning information.
When a physical handler is being used to place and bin parts, SemiEasy should be set to run continuously by selecting Repeat Run.  In this mode, SemiEasy will automatically contact the handler when it is ready for the next part and execution is determined by a ‘ready to start’ signal.

By default, and for cases where a physical handler does not exist, SemiEasy will use the provided SemiEasyHandlerManual.dll which receives API calls and generates positive responses but does not attempt communication or impede the test execution is any way.  When using this manual control driver, the operate will have to set up and activate each test run by manually interacting with the control buttons. You can replace the handler DLL with you actual handle. SemiEasy comes with few drivers (along with their source code, for example Epson NS6000).

The following diagram provide overview of the handler interface architecture:

For more information on the SemiEasy Handler Adapter, visit the SemiEasy chapter in the TS-9xx-5G User's Guide.

Related Documents
TS-900e-5G/TS-960e-5G User's Guide
KB Article #Q200356 - Multi-site Production Test Development in ATEasy

How to Configure CalEasy Standard Interfaces Using ATEasy Panel and Control Applet - Published on 3/26/2024

3/26/2024

Steps to Configure CalEasy Standard Instruments Using the ATEasy Panel and Control Applet

The following steps will show you how to configure a GPIB or PXI Standard instrument for use in CalEasy, a common and necessary step for calibration of instruments.

Configuring a GPIB Interface

Open the ATEasy Interfaces: Tools->ATEasy Interfaces...

Click on 'National Instruments GPIB boards' and Click the 'Change...' button (for this example we are using NI GPIB interface)

Click the 'Settings...' button to set the National Instrument GPIB Board

Configure the ATEasy Board Address

ATEasy Board Settings	NI MAX
Interface Number is Configured by NI-MAX. 0 for GPIB0, 1 for GPIB1, etc. The Primary address is the device's GPIB address that ATEasy uses to access the board. Typically, it is set to 0, unless you have a device already using that address

Add the Standard Instrument by clicking on Tools->Standards/Instruments

Select the Standard and fill-in the Information

Select GPIB for Interface Type and Click 'Set' to setup the GPIB Address

Configuring a PXI Interface

Click Tools->Standards/Instruments

Select Standard and fill up the information

Select Interface PXI for Interface Type

Set Address using 0xabb format

a - represents the chassis number (e.g. 1 for chassis 1)
bb - represents the slot number (e.g. 01 for slot 1)

Click 'Add' and to start using in CalEasy

Conclusion

[:+[+CalEasy+]+:]

ATEasy Drivers Configuration - Published on 1/11/2024

1/11/2024

ATEasy (.drv) Drivers

An ATEasy driver provides a way for ATEasy application to communicate with a device or an instrument. The driver can provide command statements and that are used by the application to program the device or instrument. It can also provide procedures, librarries, forms, libraries, variables, types if they defined as public. Once the driver is inserted to the ATEasy system, it must be configured before using it. ATEasy drivers can be implemented using ATEasy code that comprise by procedures or IO Tables, or using an external library such as DLL, ActiveX or .NET. You can also create a driver by importing a function panel driver (.fp), the import will create a DLL based driver. Once the driver is created and inserted to the system, it must be configured. The configuration depends on the driver implementation and there are two main types:

Interface Based Drivers - Includes GPIB, VXI, COM (RS232), USB, File and more. These driver are implemented using IO Table. A interface based driver can support multiple interfaces, for example if the instrument supports GPIB and USB, the driver properties will show:

Figure 1: ATEasy Driver Interfaces property page supporting multiple interfaces

None Interface Drivers - based on ATEasy code functions

Interface Based Drivers

Interface based drivers are implemented using an IO Table or the internal API built into ATEasy.

Figure 2: Gp155x ATEasy driver, the procedure GetFrequency() was created using the IO Tables for Send and Receive.

Drivers for interface based drivers can also be made using the Internal library. ATEasy has built-in support for hardware interfaces such as COM, GPIB, VXI, USB, and WinSock(TCP/IP).

Figure 3: The ATEasy Internal library showing WinSock (TCP/IP) functions

Configuring an Interface Based Driver

In this example, we will configure the Ag9xxxx driver for Agilent’s Infiniium Series Oscilloscopes that is provided with ATEasy.
1. Find out what the device's interface is. This can be found in the instrument description:

Figure 4: The description states the interface type is Winsock, USB, or GPIB.

2. Go to the driver's module (not the shortcut!), right click, and go to Properties.

Figure 5: Right click the driver module and select Properties.

3. Click on the Interfaces tab and check-off the interfaces used.

Figure 6: Enable the interfaces supported by the driver.

4. Then go to the driver’s shortcut, right click, and go to Properties.

Figure 7: The driver’s shortcut can be found in the workspace view on the right-hand side.

5. In the Interfaces tab choose the interface to be used and fill in the required information.

Figure 8: The three interfaces that were checked-off can be chosen here.

Non-Interface Based

Non-interface based drivers are implemented by inserting libraries/DLLs, importing function panels, or inserting IVI drivers. Non-interface based drivers communicate via a low level abstraction layer, HW or VISA. To configure the driver for communication, the Slot Number or the VISA Resource must be specified.

Configuring a Non-Interface Based Driver

Marvin Test Solution's PXI/PCI Explorer can be used to find the slot number or VISA resource of an instrument. That slot number or VISA resource can then be plugged into the driver properties to allow the driver to communicate with the instrument. Below is an example of identifying the slot number of an instrument and then entering it into the driver properties under the Misc tab.

Figure 9: PXI/PCI Explorer - Instrument is in slot 3.

Slot number 3 is now placed in the Driver shortcut's Properties, Misc tab as shown below.

Figure 10: The driver's Properties - Instrument is identified by slot number.

Alternatively, you can also identify the instrument by it's VISA resource, as shown below.

Figure 11: PXI/PCI Explorer - Instrument is VISA resource PXI17::0::0::INSTR.

This VISA resource is then entered into the ResourceName field in the Misc tab of the driver properties window. Shown in figure 12 below.

Figure 12: The driver's Properties - Instrument identified by VISA resource.

TS-9XXe-5G Blind Mate Interface Repeatability - Published on 9/8/2023

9/8/2023

Introduction

The increase in operating frequency of RF semiconductor devices presents challenges when interfacing to the device under test (DUT) through automated test equipment (ATE). One of the critical challenges in testing large volume, mmWave RF semiconductors is maintaining repeatable measurements through many cycles of docking/undocking test fixtures.

mmWave Uniqueness

Higher frequencies (shorter wavelengths) mean that the electromagnetic wave will travel more on the surface of the transmission line (skin effect) . For any material, the losses increase as the frequency increases. Connectors/Interfaces used in mmWave test must be fabricated from materials that support the shorter wavelengths, and the geometry of the interface internal structures must also be smaller. In short, extreme mechanical precision is required in all fabricated parts of the RF interface to ensure repeatable, accurate measurements.

Common Issues With ATE RF Interfaces

In the context of ATE, blind mate interfaces often suffer because of misalignment or incorrect mating force. Either misalignment or incorrect mating force can contribute to a resonance at certain frequencies, creating a loss of energy through the transmission line. This is known in the industry as a "suck out". For the case of incorrect mating force, this is illustrated in the figure below. For misalignment a similar phenomenon is observed.

Figure 1 - Mating Force Plot

Below is an example of a real world "suck out". You notice that at around 30GHz, unexpected loss of energy can clearly be observed. In this particular case, a manufacturing defect of five thousandths of an inch (5 mils) in the blind mate interface connector cavity is the cause.

Figure 2 - 30GHz "Suck Out"

TS-9XXe-5G 1.85mm Blindmate Solution

The RF blindmate interface on the TS-9XXe-5G:

1.85mm (67GHz) geometry (usable up to 53GHz, Keysight VNA limit).

Sexed design with floating interface.

Keyed fixture, using both coarse and fine alignment pins.

Single locking cam, dual release mechanism.

All mechanical tolerances are held at +/- 0.001".

Figure 3 - ATE Side of Blindmate Interface

Figure 4 - Fixture Side of Blindmate Interface

Materials used in TS-9XXe-5G RF Blindmate Interface:

Outer conductor (housing) is 303 stainless steel per ASTM A582 and passivated per AMS 2700 Method 1 type 2.

The material used meets the requirements of DFARS (Defense Federal Acquisition Regulation Supplement); DFARS requires that the steel must be smelted in the US or EU.

Center conductor is BeCu Alloy UNS C17300 per ASTM B196, heat treated to condition TH04.

Center conductor plating is gold per MIL-DTL-45204, Type II, Grade C, .000100”-.000150” thick over electro-plated Nickel per QQ-N-290A, .000150” - .000300” thick.

Plastic Bead is Neoflon per ASTM D1430 or AMS 3650.

TS-9XXe-5G 1.85mm Blindmate Repeatability Demonstrated

Below is a composite (overlay) of the S21 (insertion loss) and S11 (return loss) measurements of our 1.85mm blindmate interface over 100 mating cycles. You will notice the marker values in the top right corner of the measurement window stays almost entirely within one tenth of a dB throughout the 100 mating cycles.

Conclusion

Marvin Test Solutions TS-9XXe-5G blindmate RF interface offers a robust, reliable and repeatable RF blindmate solution that allows users to utilize the full bandwidth of the system's 53 GHz Keysight VNAs.

Accessing the Windows Registry using the WinReg.h DLL API from ATEasy - Published on 7/31/2023

7/31/2023

Overview

The Windows® Registry is a database that stores information and settings used by the Windows Operating System kernel, device drivers, and applications. You can access the registry information using the APIs that are included in the ADVAPI.dll installed with Windows. This article demonstrates how to access the registry within an ATEasy® application using these APIs. You will learn how to find the DLL API functions declaration in the WinReg.h header file and how to declare them in your ATEasy application. An example will demonstrate how to query the number of COM ports by using the declared API functions to access the registry key HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM.
Similar examples can be implemented using .Net assembly (System.Microsoft.Win32, Registry and RegistryKey classes); however in this example we show how to access the registry using DLL APIs.

Note: Familiarity with ATEasy and the ATEasy IDE is assumed.

Adding ADVAPI32.dll Library to an ATEasy Module

The ADVAPI32.dll library is part of the Windows OS and contains ADVanced API services.  It provides access to functionality beyond that available with the Windows kernel, such as restarting/shutting down the system, managing services, managing user accounts and access to the Windows registry.  The DLL covers a broad range of functions, but those we are interested in - the registry APIs - are defined in the header file WinReg.h.  Definitions for the registry functions can be found in this WinReg link.

The Working with External Libraries chapter in the ATEasy Getting Started manual explains how to link a DLL to your ATEasy application.  The Getting Started manual is also accessible from ATEasy Help.

You must determine which ATEasy module makes the most sense to have or use the ADVAPI library: as a Driver, within the System module, or within the Program module.  Since it's likely these functions could be used in many applications, the most logical place for them to reside would be within an ATEasy driver.  In fact, the ATEasy Test Executive includes the ADVAPI.dll as a component of that driver.  In this example, the DLL will be placed in the System module.

Note: The functionality discussed in this article can also be achieved by simply including the ATEasy Test Executive driver in your application instead of adding the advapi.dll and declaring the needed functions.

With ATEasy open, double-click the System icon in the Workspace to open the System document. Right-click on the Libraries submodule within the System document and select Insert Libraries Below. Hit enter. From the Insert Library dialog that pops up, select the DLL tab and click on the navigation tool to select the DLL File Name, and navigate to the advapi32.dll file. Click on Insert.

Note: Advapi32.dll is available in 32 or 64-bit DLL and is located under your Windows, System32 folder for 32 or 64-bit Windows respectively. For 64-bit Windows, the 32-bit DLL will be located in the C:\Windows\SysWOW64 folder.

Figure 1: Install the Advapi32.dll

Declaring Registry Functions

After adding the DLL, the procedures list is empty (Figure 2).  Unlike a COM/ActiveX or .NET library, a DLL does not contain information that would allow ATEasy to automatically declare the functions residing within the library.  To use the API functions, you need to first declare them in the application.  For each function you intend to use, you must define its name, define the number and the types of parameters, define how parameters are passed (as a value or a pointer), and define the return data type, if any (void if none).  To save time, and to avoid possible errors when declaring DLL functions, ATEasy has a utility that will import DLL functions from a properly constructed header file (Figure 3).  The procedure for declaring DLL functions from a header file is to right-click on the advapi32 DLL icon that you just installed and select Import C Header File (.h).  After resolving any data type ambiguities, ATEasy will declare all of the functions defined in the header, as well as their data types, and any variables defined in the header file.

Figure 2:  Empty ADVAPI32 Procedure List                                                                               Figure 3:  Import C Header File

There are many more functions defined in the ADVAPI DLL than we need.  To keep the scope of this article focused on only what is needed, we will manually declare only the three functions we will use.  They are RegOpenKeyEx, RegCloseKey, and RegEnumValue.

To declare the functions, the process is identical to adding any procedure in ATEasy.  Right-click in the empty procedure list and select Insert Procedure Below.  Enter RegOpenKeyEx and hit enter.  Right-click on the RegOpenKeyEx procedure we just created and select Insert Parameter Below.  Enter hKey as the parameter name and define the type as Val AHandle.  Hit enter.  Continue the same process to add additional parameters "after" hKey, entering the appropriate name and parameter type as shown in figure 4.  Repeat the same process to declare the RegCloseKey and RegEnumValue functions.

Figure 4: Function (Procedure) List

The declared functions and parameters require some additional modifications in order to be used in our example.  Refer to Figure 5 for the following.  Right-click on the RegOpenKeyEx function and select Properties.  This will open the Properties page for the selected object.  Set each of the functions to Public, Type Stdcall and Returns a Long value.

Windows APIs with string parameters have 2 flavors supporting ASCII and Wide/Unicode versions.  For the RegOpenKeyEx and RegEnumValue we will define an Alias for the ASCII version of the function, RegOpenKeyExA and RegEnumValueA, respectively.

When passing parameters into an ATEasy procedure, you may pass the parameter by reference pointer (Var), or by value (Val).  The Optional modifier defines whether the parameter is required or is optional.  For optional Val type parameters, you may also define a default value that the procedure will use if the parameter is omitted.  The example in Figure 5 shows that parameter dwSamDesired is an optional DWord parameter, passed by value, and the default value is 0x20019₁₆

When complete, the function list and associated parameters should look like those shown in figure 4.

Figure 5: Function and Parameter Properties

Query COM Ports Procedure

With the registry API functions declared it is now possible to open the registry and query the number and name(s) of the COM ports available to the system. The COM port information is stored in the HKEY_LOCAL_MACHINE registry key, under the HARDWARE\DEVICEMAP\SERIALCOMM subkey. Figure 6 shows an example of Windows RegEdit application opened to the Serial COM Port subkey.

Figure 6: Registry Access Using RegEdit

Use the function RegOpenKeyEx to open the registry. Parameters for this function include the registry key and subkey, and it returns a handle to the specified subkey. The key HKEY_LOCAL_MACHINE contains information about the local computer system. It is a predefined registry key and its handle is a constant value of 0x80000002₁₆. You can use this value for the RegOpenKeyEx hKey parameter, or you can define an ATEasy constant variable as part of the ADVAPI link and reference the key by the descriptive variable name instead. Figure 7 shows constant variables for HKEY_LOCAL_MACHINE and several other registry constants. Note that these constant variables are defined in the Constants submodule under the ADVAPI DLL and are declared as Public. The values for these keys and subkeys can be found in the WinReg.h header file.

Figure 7: Registry Key/Subkey Constants

The serial ports are enumerated in the HARDWARE\DEVICEMAP\SERIALCOMM subkey. This parameter is passed as a literal string, but could also be replaced by a constant string variable. Once the key/subkey is open, use RegEnumValue to return parameters stored there. The function returns one indexed value name for the key each time it is called, until no more entries are available. Checking the status returned indicates whether a valid entry was returned or not. After the last call to the RegEnumValue, you must close the subkey using RegCloseKey.

The code in the QueryComPorts() procedure demonstrates the full process of opening the SERIALCOMM subkey, returning the name for each serial port enumerated in the system, and closing the subkey. Reading the enumerated serial ports is an iterative process returning each port name sequentially until the returned status indicates there are no more entries, up to 100 serial ports.

The commented Print statements were used for diagnostics during development and were left commented to provide an opportunity to learn more about the operation of these API calls.

Figure 8: QueryComPorts Procedure

Testing The Registry Access

The final step to demonstrate the registry query is to call the QueryComPorts() procedure from the Program module. The code calls the procedure and iteratively displays the COM port name for each serial port found in the register using the Append statement. Figure 9 shows the Program code. The full example can be downloaded here.

Figure 9: Calling Registry APIs

Summary

This article demonstrates how to access the Windows Registry using the Windows advapi.dll APIs. We manually declared three APIs to open, read and close a registry key. The Public System procedure QueryComPorts() was created to perform the register access, which was called from the Program module. The result listed each COM port found in the Registry Key/Subkey HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM, and returns a count of the number of COM port entries found - see Figure 10.

Figure 10: One COM Port, COM4 Found

Appending Multiple Digital Test Patterns to Reduce Test Time - Published on 7/28/2023

7/28/2023

Introduction

Digital test programs, especially semiconductor test programs generated from multiple simulation files such as STIL, WGL, VCD, EVCD or ATP normally encompass a large number of test vectors. This number of digital test vectors is compounded by the required number of digital tests. This greatly reduces the overall test throughput as the digital instrument is required to load and reload these digital patterns for each test. The large memory capacity and the direct memory access of the Marvin Test Solutions GX5296 allows these digital test vectors to be loaded once at program load time and directly accessed for each test.

The following article describes how to streamline a digital application by merging digital test patterns using the provided driver function GtDio6xFileAppend to generate a single compressed file that can be loaded once at program load time.

This article assumes that the reader has some basic knowledge of the GX5296 or GX5960 series of dynamic digital instruments. As the GX5296 uses the GtDio6x driver, this example can also be easily applied to any of the GX5960 series of digital instruments. For a complete example of using this functionality, refer to the GX5296TestsUsingOneFile program included at the end of this article.

[:+[+gx5296+]+:]

The benefits of using the appended file approach are as follows:

Provides a group of digital test sequences that can be quickly accessed without reloading the digital file

Designed to easily run using the appended file or the existing digital files

Appended file is created in a nondestructive manner that does not change existing files

Easily sustainable to update and/or add additional test functionality

Provides a location for a preamble step that runs prior to the test to set up the device under test (DUT) prior to running a test

Tests can be placed in any order as test identity is located within the appended file

The Preamble Step

Often digital tests require some sort of preamble to set up the DUT to a certain state prior to running a test. Each test in an appended file can be described as a block of one or more Steps. The first block of steps is reserved to provide a preamble for DUT setup and a launch point to jump to the desired test (Refer to Figure 1).

If the timing of the preamble step requires a different timing than the preceding tests, then the timing set used in the preamble step can be programmed to a unique timing set and or Clock Per Vector (CPV) setting.

If no preamble step is necessary to setup the DUT then the Preamble Step 0 should be at least 10 vectors in length with all used channels set to dynamic and all vectors set to tristate. This can easily be created using Dio6xEasy and saved to a file. The Preamble step used in this example is one step in length.

Figure 1 – The Preamble Step and Step Sequencing

GtDio6xFileAppend Driver Function

The GtDio6xFileAppend function has several options that allow the user to customize appending files as follows. The GtDio6xFileAppend function is nondestructive, meaning that it will retain the original files while creating a new appended file. Also, the procedure does not require any hardware to run.

Parameters	Comment
sFirstFileName	The first or main file name to append to the destination file
sAppendedFileName	File name to add after the first file to the destination file
sDestinationFileName	Appended or destination file name
dwStartStep	Starting step to append at, use -1 to append at after the last step
dwNumberOfStepsToAppend	The number of steps to append, use -1 to append all steps
dwVectorOffset	Vector memory offset to begin appending at, use -1 to append after last vector
dwNumberOfVectors	The number of vectors to append, use -1 to append all vectors
dwFlags	Allows the user to control which sections of the file to append. See flag definition below
nStatus	Return status 0 if success negative if failure

The dwFlags parameter allows the user to control which sections of the file to append. Each bit represents a section of the file as follows:

Flags	Definition	Comment
0x0000	File Append All	Append all, this is the default
0x0001	Ignore number of channels	Don't error if the number of channels in each file is not equal
0x0002	Remove Last Step Flag	Removes all last step flags from the appended file
0x0004	Remove first file last Step Flag	Removes all last step flags from the first or main file

File Append Procedure

The GX5296TestsUsingOneFile ATEasy test program FileAppend Procedure (shown below) is used to create the appended test file. As previously stated, each merged file is separated by its last step flag. To further identify the location of each test, this procedure marks the first step of each appended test file with its filename (without extension). To simplify programming, this procedure adds the file path and extension (.Dio6x) to each filename string. The the main goal of this procedure is to combine all digital test files into a single file. The default (-1) is used for all GtDio6xFileAppend options. The dwFlag parameter is set to zero.

Procedure FileAppend (sFirstFile, sAppendedFile, sDestinationFile) : Void
  sFirstFile          Val String       First file used to apppend
  sAppendedFile       Val String       File to append to the first
  sDestinationFile    Val String       Appended file destination
  StepCount           Long             Step count of test files
  nFileHandle         Short            File Handle
  sFirst              String           Saved base first file name
  sAppend             String           Saved base Append file name
  sDestination        String           Saved base Destination file name
{
  !Save basic file names to set the step names
  sFirst = sFirstFile
  sAppend = sAppendedFile
  sDestination = sDestinationFile

  !Add the file path to each file name files are stored in the directory DioFiles
  sFirstFile = GetDir(aGetDirCurrent)+sFirstFile+".dio6x"
  sAppendedFile = GetDir(aGetDirCurrent)+sAppendedFile+".dio6x"
  sDestinationFile = GetDir(aGetDirCurrent)+sDestinationFile+".dio6x"

  !Append the files to the destination file
  Dio File Append(sFirstFile, sAppendedFile,sDestinationFile,-1,-1 ,-1 ,-1,0)

  !Open the first file to get the Step size
  if sFirst <> sDestination
      !Don't mofify existing files
      Dio File Open(sFirstFile,adio6xFileOpenModeRead, adio6xFileBoardTypeGx5296)
  else
      Dio File Open(sFirstFile,adio6xFileOpenModeReadWrite, adio6xFileBoardTypeGx5296)
  endif

  Dio File Get Handle(nFileHandle)
  Dio Get Step Count(lStepCount,nFileHandle)

  !Determine if destination file is already open
  if sFirst <> sDestination
     !Close first file and open destination
     Dio File Close(nFileHandle)
     Dio File Open(sDestinationFile,adio6xFileOpenModeReadWrite,adio6xFileBoardTypeGx5296)
     Dio File Get Handle(nFileHandle)
  endif

  !Name the appended step
  Dio Set Step Name(lStepCount,sAppend,nFileHandle)
  if sFirst <> sDestination
     !Name the preamble step
     Dio Set Step Name(0,sFirst,nFileHandle)
  endif
  Dio File Close(nFileHandle)
}

Loading the Appended File from an ATEasy Test Program

In order to use the appended file, the programmer must find a method to load the file only once. This is best performed by creating a new driver to place the FileAppend procedures and other routines. The load file command used to load the appended file could then be placed in the driver's OnInitProgram event. The advantage of using a separate driver to load the file is that it will be loaded prior to the start of the main program and therefore will not affect the test time. To simplify this example, the appended file is loaded on the first run of a DUT. This means that the test time of the first DUT test run will be increased by the load time of the appended file. The test time of all other runs will be unaffected.

In either case, two system level global variables are required to use appended files in a program. The first is a flag to determine the appended file load state, and the second is an array of structures that contains each appended file name, location and T0 Clock. A program local variable bUseAppendFile is used to allow the programmer to easily switch from using the appended file to using the original digital files. Recall that the FileAppend function is nondestructive and therefore the original files remain unchanged. When using an appended digital file, the user must be careful not to use any DIO reset commands after loading the file.

[:+[+ateasy+]+:]

The ATEasy program OnInit event contains the code to selectively load the appended file. The user only needs to change the bUseAppendFile variable to False to switch modes and bypass loading the appended file and use the original digital files. When the appended file is enabled, the PrepareDioFile procedure determines if the appended file needs to be created. If no appended file exists, the program will create the appended file as shown.

Procedure PrepareDioFile(sAppendFileName, nTotalTests, asTestNames): Void
--------------------------------------------------------------------------------
sAppendFileName: Val String    ! Name of appended file
nTotalTests: Val Short         ! Number of tests to append
asTestNames: Val String[]      ! List of file names to append
nCntr: Short                   ! Counter
pstFileStatus: structFileStatus! Get file status structure
{
   !Create the appended file if it does not exist
   sAppendFileName=GetDir(aGetDirCurrent)+"\\"+sAppendFileName+".dio6x"
   if FileGetStatus(sAppendFileName,pstFileStatus) <> True
       !Append Preamble to first Scan test and create the appended file
       asTestNames[0]=GetDir(aGetDirCurrent)+asTestNames[0]+".dio6x"
       asTestNames[1]=GetDir(aGetDirCurrent)+asTestNames[1]+".dio6x"
       FileAppend(asTestNames[0],asTestNames[1],sAppendFileName)
       For nCntr=2 to nTotalTests-1
           !Append all other test files to the appended file
           asTestNames[nCntr]=GetDir(aGetDirCurrent)+asTestNames[nCntr]+".dio6x"
           FileAppend(sAppendFileName,asTestNames[nCntr],sAppendFileName)
       next
   endif
}

Once the appended file has been loaded, the last step flag of the Preamble step is set to False. This is required, as a Jump instruction cannot be placed on a last step. The procedure GetAllStartingStepInfo gets the location of each named step from the passed asTestList variable array and sets test name, step address and T0 clock information for each test name. An error will occur if the test name is not found. The test name is not case sensitive. For more information regarding the GetAllStartingStepInfo procedure refer to the GX5296TestsUsingOneFile example.

Procedure OnInit(): Void Public! Occurs when a program has started.
  sFileName             String         Filename of appended string
  nTotalTests           Short          Total number of test in appended file
  asTestList            String[1]      Array of test names in appended file
{
  !Log Total test time in OnEnd event
  dTstTimer=Tick()
  !Set to false to use original digital files
  bUseAppendFile=True
  !Set the name of the append file
  sFileName="GX5296TestsUsingOneFile"
  !Set the total tests in appended file including preamble step
  nTotalTests=3
  !List all test names,
  redim asTestList[nTotalTests]
  asTestList = {"GX5296TestsUsingOneFilePreamble","GX5296TestsUsingOneFileScan1",\
                "GX5296TestsUsingOneFileScan2,GX5296TestsUsingOneFileScan3"}
  !Load appended file if enabled and not loaded
  if (bUseAppendFile=True) AND (m_bAppendFileLoaded<>True)
      !Create appended file if necessary
      PrepareDioFile(sFileName,nTotalTests,asTestList)
      !Add file path and extention
      sFileName=GetDir(aGetDirCurrent)+sFileName+".dio6x"
      !Load the Appended file
      Dio File Load(sFileName,0,0,0,0)
      !The preamble step cannot have its last step flag set
      Dio Set Step Last(0,False)
      !Creates the m_aStep array of starting steps and clocks
      GetAllStartingStepInfo(nTotalTests,asTestList)
      !Prevent the file from being reloaded
      m_bAppendFileLoaded=True
  endif
}

GtDio6xFileLoad Driver Function Flags

The GtDio6xFileLoad(nHandle, pszFileName, dwFileStartStepOrVector, dwStartStepOrVector, dwNumOfStepsOrVectors, dwFlags, pnStatus) function provides a simple method to load only the portions of the digital file that are required to run a test. The definitions of the dwFlags are as follows:

Flag	Definition	Comment
0x0000	File Load All	Load the complete file
0x0001	File Load Vectors	Load the file Vector memory
0x0002	File Load Record	Load the Record memory
0x0004	File Load Channel Settings	Load the Channel settings
0x0008	File Load Step Settings	Load the step settings
0x0010	File Load Timing Settings	Load the timing setting
0x0020	File Load General Settings	Load the General settings
0x0040	File Load Disable Unused Channels	Unused channels will be set to disabled
0x0080	File Load Reset Domain	Reset Domain performed prior to load
0x0100	File Load Reset Unused Channels Data	Vector memory of Unused channels will be 'Z'
0x1000	File Load File Load Range Of Vectors	Load a range of vectors specified StartStep and NumSepsOrVectors

Using the Appended Files in a ATEasy Test Program

A typical test program normally contain some sort of shorts and opens testing, some digital only tests and maybe some mixed digital/analog tests. As the shorts and opens test alone changes the channel mode of the DIO, clearly the channel state of the DIO must be restored prior to any digital testing. Also the timing of one or more of the appended files may need to be changed to restore the DIO to the same state as the original file. If the test requirements do not require any changes in the channel settings, sequencer or the timing, then the file load step can be omitted since the digital resources would already be loaded. This example assumes that the channel timing and general settings would need to be reloaded for each test run.

The System Global flag bUseAppendFile determines if the test will use the original or appended file. When using the appended file, the same load file command is executed with the flags set to only load the Channel, Timing and General settings. The program also calls the procedure GetStartingStepInfo to get the clock and starting step for the test. Recall that during the appended file load, the last step flag of the last preamble step is cleared.

To match the timing of each test, the GtDio6xSetClock function sets the T0 clock and CPV of the preamble step (Step 0) to match the test file. The test file is then load with the indicated flags.

Unless the start address precedes the Preamble step address, the starting step is programmed as a jump location on the preamble last step (Refer back to Figure 1).

The RunBurst procedure simply executes the digital burst and waits for its completion with a programmed timeout. When the burst has been completed, the Real Time Compare error counter of each board is queried and the total number of failures is reported. For more information regarding the GetStartingStepInfo and the RunBurst procedures, refer to the GX5296TestsUsingOneFile example.

Procedure RunDigitalTest(sfileName): Void    Runs test sequence from test or appended file
  sfileName              Var String          Input File Name
  dClock                 Double              T0 Clock from test file
  lCpv                   Long                Clocks Per Vector from append file
  lErrorAddressCount     Long                RTC Error Address count per board
  lFailures              Long                RTC Fail count per board
  lStartStep             Long                Starting step of test in appended file
  lTotFailures           Long                RTC Totlal Failures found
  nBrdCnt                Long                Number of found boards
  nCntr                  Short               Board counter
  nFileLoadFlags         Short               Flags used to load file
  nHandle                Short               Handle of each board to get RTC data
  sTestFile              Short               Modified file name with path and extention
{
  sTestFile = GetDir(aGetDirCurrent)+sfileName+".dio6x"
  if bUseAppendFile = True
      !Get the Preamble step CPV value
      Dio Get Step Clock(0,dClock, lCpv)
      !Search appended file for the test name and get the starting Step and Clock
      GetStartingStepInfo(sFileName,lStartStep,dClock)
      !Set the preamble step to dClock
      Dio Set Step Clock(0,dClock, lCpv)
      !Only Load Channel, Timing and General Settings
      nFileLoadFlags = 0x20+0x10+0x4
  else
       nFileLoadFlags = 0
  endif

  Dio File Load(sTestFile,0,0,0,nFileLoadFlags)

  if bUseAppendFile = True
      ! Set Jump address for burst
      if lStartStep=1
          !Remove any Step 0 jump command
          Dio Set Step Control(0,adio6xControlActionNone, lStartStep, \
              adio6xControlConditionUnconditional, 1,0,0)
      else
          !Set the jump command
          Dio Set Step Control(0,adio6xControlActionJump, lStartStep, \
              adio6xControlConditionUnconditional, 1,0,0)
      endif
  endif

  !Run the digital burst and wait for completion with timeout
  RunBurst()

  !Get the total number of boards in the domain
  Dio Get Board Count(nBrdCnt)

  !Find the total error count of all boards in domain
  nCntr=0
  lTotFailures=0
  repeat
      if nCntr=0
          Dio Get MasterHandle(nHandle)
      else
          Dio Get SlaveHandle(1,nCntr,nHandle)
      endif
      ! Get board Error Count
      Dio Get RealTimeCompare ErrorCount(lErrorAddressCount,lFailures,nHandle)
      lTotFailures = lTotFailures+lFailures
      nCntr=nCntr+1
  until nCntr=nBrdCnt

  TestResult = lTotFailures
  Test.Type=atestTypePrecise
  !Expected value
  Test.Value=0
}

Calling Digital Tests

The ATEasy test program includes three examples of SCAN files generated using provided STL files and converted using Dio6xFIT. For an example of file conversion see Knowledge Base article #200330. The calls to the following tests assume that DUT power has already been applied to the unit. The Test Type used for these tests is Precise and the expected value is 0, for zero errors for a pass condition. Recall that the RunDigitalTest procedure shown above sets the TestResult variable to the total number of Real Time Compare errors found.

Test 1.1 : "Scan Test 1"
--------------------------------------------------------------------------------
  Id = Test3
  Type = Precise
{
  !Execute Scan chain 1
  RunDigitalTest("GX5296TestsUsingOneFileScan1")
}

Test 1.2 : "Scan Test 2"
--------------------------------------------------------------------------------
  Id = Test7
  Type = MinMax
{
  !Execute Scan chain 2
  RunDigitalTest("GX5296TestsUsingOneFileScan2")
}

Test 1.3 : "Scan Test 3"
--------------------------------------------------------------------------------
  Id = Test6
  Type = MinMax
{
  !Execute Scan chain 3
  RunDigitalTest("GX5296TestsUsingOneFileScan3")
}

GX5296 File Append Example

The following is a link to the GX5296TestsUsingOneFile.Zip ATEasy test program. Download this file and extract the files onto your hard drive. The contents of the compressed ZIP file are as follows:

Gx5296 Append Example Files	Description
GX5296TestsUsingOneFile.wsp	ATEasy Workspace file
GX5296TestsUsingOneFile.prg	ATEasy Program file
GX5296TestsUsingOneFile.sys	ATEasy System file
GX5296TestsUsingOneFile.prj	ATEasy Project file
GX5296TestsUsingOneFileScan1.dio6x	Scan Test 1 digital file
GX5296TestsUsingOneFileScan2.dio6x	Scan Test 2 digital file
GX5296TestsUsingOneFileScan3.dio6x	Scan Test 1 digital file
GX5296TestsUsingOneFilePreamble.dio6x	Preamble digital file
GX5296TestsUsingOneFile.dio6x	Appended Test file

GX5296TestsUsingOneFile.zip

Installing, Upgrading and Acquiring ATEasy Software Licenses - Published on 6/1/2023

6/1/2023

The ATEasy® Test Executive And Development Studio provides several types of licenses to end users. This article will focus on installing or upgrading a Single License, or installing or extending the 30-Day Trial License. Article was updated to ATEasy 10 156d to include Online activation.

ATEasy includes one 30-day license which can be used after first running the installation. During the 30-day license, ATEasy is fully functional with minimal limitation (the ability to create executables). After the 30-day license has expired, ATEasy will no longer be functional. A single software license or a 30-day license extension must be installed in order to continue using ATEasy.

Using the 30-days Trial/Evaluation License

Start ATEasy

If no license is currently installed, ATEasy will automatically bring up the License Setup dialog box when first started. The 30-day license can be selected.

If a license is currently installed (such as a 30 day license) and you need to extend the trial period or upgrade to a newer ATEasy version, then go to the Help File Menu and click on About ATEasy.... Proceed to the offline activation to request a 30 days extension trial license.

Opening the License Setup Dialog

The dialog is automatically opened when you start ATEasy with no license installed, or from the Tools, About ATEasy menu when you click on Set License button as shown here.

Installation of a single software license using Online Activation

Open the License Setup dialog

Select Activate License Online

Enter your marvintest.com account information: email and password and the ATEasy Serial Number (displayed on your Sales Order or product DVD

Click OK to Activate. Note: the client must have access to https://www.marvintest.com/* at all time on order to operate correctly.

Installation of a Single Software License Using Offline Activation

Open the License Setup dialog

Select Install Single License, Retrieve the 10 character ATEasy Computer ID.

Go to https://www.marvintest.com/magic and create a M@GIC incident to request the License String. If you need a 30-day extension license, include this request in the M@GIC incident post. Include the ATEasy Computer ID and your ATEasy Serial Number (printed on your Sale Order or CD) in the incident. A M@GIC account must be created before an incident can be created.

The same process can be done If you need an upgrade to your current license, for example a license to upgrade from ATEasy version 8 to 9. The upgrade license is normally displayed under your M@GIC account under the licensing tab (so no incident needs to be created - just install the new version and type in the license displayed in M@GIC); however, if you can't see the license in your M@GIC account you will need to create an incident and request it.

Fill in the Licensed To and Organization fields with your name and company name.

Enter the License String received in the MAGIC incident into the License String/File field and click OK.

Note : The same offline activation process described above can be used when installing a single software license for other Marvin Test Solutions products such as CalEasy, WaveEasy, and GTDIO-FIT.

Understanding Switching Used in Automated Test Equipment - Published on 5/10/2023

5/10/2023

Introduction

The switching employed in Automated Test Equipment (ATE) can be as complex as any other component of a test system. The ultimate specifications of the test system directly depend on the integrity of the switching used. In order to design an ATE system the designer must understand the best components to design a switching system capable to perform the required tests. The following article describes typical switching components used in today's modern test systems. For more information about PXI products, services and support options visit our web site at http://www.marvintest.com

Basic Test System

To test a device, component, or subassembly effectively, a test system must set up prescribed input conditions and monitor its responses. Testing generally means applying a stimulus to a unit under test and checking the response, as shown in Figure 1:

Figure 1: A Simple Test System

Almost all stimulus and response signals are electrical, but they could be non-electrical, such as heat, light, or motion. Non-electrical signals are usually converted to, or from, electrical signals to permit computer control or data analysis. Electrical signals are measured, or sourced, by the following common test instruments:

Measure - Oscilloscope, voltmeter, frequency counter, spectrum analyzer, waveform analyzer

Source - Power supply, current source, pattern generator, pulse generator, frequency synthesizer

Source/Measure - Ohmmeter, capacitance meter, network analyzer, signature analyzer

Measure and source functions can be combined in the same instrument and even in the same leads, for example, an Ohmmeter that measures voltage and source current on two leads. In basic test systems, the source and measure instruments are connected to the unit under test (UUT) by direct interface wiring. A better test system makes these connections via switching. The purpose of employing a switching system is to:

Test several UUTs during one test session

Test multiple points on a UUT

Connect many measure or source instruments

The various configurations are shown in Figures 2 - 4. These basic configurations may be combined to form systems that are more complex. In most systems, it is best to measure the output of the source instruments directly. This feature may require additional switching.

Figure 2: Multiple Test Points

Figure 3: Multiple Instruments

Figure 4: Multiple UUTs

Switch Types

When designing the switching portion of a given test system, it is important to define the configuration and implementation of the individual switches that connect the instrumentation to the unit under test (UUT). There are three terms used to describe switch configurations:

Number of poles (e.g., single/double/triple pole)

Single/double throw

Contact form

The term "pole" refers to the number of common terminals contained within a given switch. Figure 5A shows a single-pole switch in the open position. The term "throw" refers to the number of positions in which the switch may be placed that create a signal path or connection. A complete description of Figure 5A is single-pole, single-throw, normally open (SPST-NO).

Figure 5B shows a single-pole, double-throw (SPDT) switch. One terminal is normally open (NO) and the other is normally closed (NC). The third terminal is the common terminal such that only one terminal can be connected, depending on the state of the switch. A complete description of Figure 5B is single-pole, double-throw (SPDT).

Figure 5: Single Pole Switch

Figure 6 shows a double-pole, double-throw (DPDT) switch. Both poles are actuated simultaneously when the relay is energized.

Figure 6: Double Pole Switch

The “form”, or “contact form”, is a term used by relay manufacturers to describe the contact configuration of a relay. “Form A” refers to a single-throw, normally open switch. “Form B” refers to a single-throw, normally closed switch, and “Form C” indicates a double-throw switch. An alternate designation for a double-throw switch is a Change Over (CO). Using this nomenclature scheme, virtually any contact configuration may be described.

Automated Test Systems

Simple semi-automated test systems have been designed in the past using the required instrumentation as part of a test fixture. This type of test system is normally designed to test a single module or circuit card. Any automation for this type of system uses the built-in capability of the instruments to run the required tests. The test results for these types of systems are manually recorded on a data sheet. The switching included in this type of system is manual and the test fixtures are usually built in-house.

As the need for testing increases or as test requirements become more complex, a computer controlled test system is usually the best choice. Advantages to automated test systems include:

As operator intervention is less, there are fewer chances for test errors

Test results are more often more accurate and more consistent

Data can be more effectively analyzed since they are compiled into a database

Complex calculations are possible

Throughput of units under test is higher

When automating the test system, switching functions must also be automated. In systems where the signals are electrical, a programmable instrument called a scanner, matrix, programmable switch, multiplexer, or switching network is employed.

Designing Automated Test Systems

Designing switching systems for an automated test system requires knowledge of the input/output signals to be switched and the test routine to perform the test. Automated test systems are usually designed with the flexibility to handle a variety of signals because test requirements change frequently.

The first step in designing a test system is to produce a Test Requirements Document (TRD), which outlines the system configuration and switching needs. Given that versatility is of utmost importance, designing the switching function may be one of the most difficult parts. To help design a switching system, one of the following switching topologies may be used, alone or in combinations. Figure 7 shows the basic topology.

Figure 7: Switch Topology Block Diagram

Basic Switch Topology

This basic switch topology connects one input to one output. It is generally used in control applications to:

Connect a UUT to a load

Connect a power supply or control signal to the UUT separate from other source-measure-interface circuitry

Initiate an independent element of the system, for example, a device with non-electrical input or output, such as a motor or transducer

Marvin Test Solutions' GX6315 provides 3x15 independent single-pole, double-throw (SPDT) relays that may be used for power switching in the basic switch topology. The GX6338 provides 3x38 independent single-pole, single-throw (SPST) relays that may be used for low current switching in the basic switch topology. For more information about the SPDT and SPST configurations, refer to the section on “Switch Types”.

Multiplex or Scan Topology

The multiplex or scan topology is used to connect one instrument to multiple UUTs or multiple instruments to a single UUT. The connections can be sequential (such as scan in Figure 8) or non-sequential (such as multiplex in Figure 9). In addition, multiplexing permits more than one simultaneous connection - for example, routing the UUT output to an AC voltmeter and to a frequency counter.

The 1:X configuration is sometimes used to connect a source to many points or a single point to many measure instruments. The X:1 configuration is used to connect several sources to a single point or many points to a single instrument. To synchronize source and measurement connections, a 1:X/X:1 pair can be switched together.

As shown in Figure 8, the scan topology is equivalent to a rotary selector switch. With this type of topology, there are two common versions:

Make-Before-Break, which makes the new connection before breaking the existing connection

Break-Before-Make, which breaks the existing connection before making the new connection

Either of these types can be implemented in a test system. Unless otherwise indicated, the non-shorting type is assumed.

Figure 8: Scan Topology

Marvin Test Solutions' GX6264 is Multiplexer/Scanner that can be used for the scan topology. All products are of the Break-Before-Make version, although it is possible to switch multiple points simultaneously using different Scan Groups.

Figure 9: Multiplex Topology Diagram

Switch Matrix Topology

The switch matrix topology connects multiple inputs to multiple outputs. With this configuration, multiple instruments are often connected to multiple points on a UUT. Though the switch matrix topology is the most complex, it certainly is the most versatile. Figure 10 illustrates the switch matrix topology in simple terms.

The switch matrix topology provides the most flexible switching method. However, the following issues must be addressed when using a switch matrix: stubs (unused relays) may generate electrical noise if the frequency is above 10 MHz. If you are using a switch matrix to switch high frequency signals, use the "cleaner" switch paths with shorter stubs. For example, the bottom-left switch shown in Figure 10 is the “cleanest” path since it has the shortest stubs. The top-right switch in the same figure is the “noisiest” path as it has the longest stubs.

The flexibility provided by the switch matrix means that any point could be connected to any other point. Extreme care should be taken when developing the control software to prevent shorts between low impedance sources (such as power supplies). A typical method to prevent such shorts is to use a resistor in series between the power supplies and the switch matrix if these signals are for measurement purposes only.

Figure 10: Switch Matrix Topology Diagram

Marvin Test Solutions' GX6616 is a true switch matrix that can be used when the switch matrix topology is selected. This product has 6 groups of 2x16 and offers multiple configurations from 2x96 to 6x16 (any of the 6 points may be connected to any of the 16 points).

Switching Instrument Criteria

Every time a signal passes through a connecting cable or switch point, errors may be introduced. It is important to select the correct switching elements and proper topology carefully in order to maintain the integrity of the signal.

Newer switching elements come very close to the ideal switch. The ideal switch is:

An open circuit (zero capacitance, infinite ohms) when open

A short circuit when closed (zero ohms)

Completely isolated from the other switches

A discrete channel completely isolated from the others

All of these factors are critical in high accuracy and low level signal applications. In many systems, different types of switches must be included to balance the technical and economic limitations.

The following is a list of important factors when choosing a switching instrument:

Cost

Cost of expansion/adding more boards

Switching topologies available

Minimum/maximum number of switch points

Variety of switching elements available

Electrical specifications

Ability to upgrade as the system requirements change

Switching System Topologies

In a typical Automated Test System one or all of the three switching topologies can exist: Switch, Scanner/Multiplexer, and/or a Switch Matrix. These various topologies with some additional specialized information are shown below. The various switching topologies can be combined to meet the requirements of the test system.

As illustrated in block diagram form, the basic switch topology connects one input to one output. This input can be one or more signal lines, connected through Form A, B, or C switching elements. One pole is required for each signal line, with all poles controlled together. Figure 11 shows an example using each switch topology.

Figure 11: Basic Switch Topology (Form A, B, C)

Typical applications for this switch topology are power and control applications. Because each switch is independent and isolated, more than one switch can be closed at the same time.

Hardware that implements the basic switch topology often provides the flexibility to select Form A, B, or C switching and the number of poles controlled together. If the test system designer is willing to do external wiring, then any topology can be built from the basic switch topology.

The Marvin Test Solutions GX6315 can be used to perform all switching functions shown in Figure 11. As this product contains 45 individually controlled high current single-pole double-throw (SPDT) form C relays with a contact rating of 7A per channel it is an ideal candidate for power supply switching. The COM and NO poles of the relay will be used in the first example, the COM and NC poles will be used in the second, and two relays (COM, NO, and NC) will be used in the third.

Scanner/Multiplexer Topologies

Most scanner and multiplexer topologies connect one input to “n” outputs or “n” inputs to one output. These are the most commonly used topologies in signal switching for small systems. The simplest scanner is a Form C contact as shown in Figure 12A, switching a supply to either of two loads. Implementing this with two Form A contacts creates a simple multiplexer. The supply can now be connected to either one or both loads as seen in Figure 12B.

The major advantages of multiplexing over scanning are:

Multiplexing permits an all-open state

Multiplexing permits any order; scanning is sequential

Multiplexing allows simultaneous connections; scanning does not

Figure 12: Basic Scanner Multiplexer

The multiplexing method is the most used because it provides the most flexibility. In addition, sequencing of multiplex connections can be programmed in any order. Scanning is most often used in stand-alone systems without computer control. When designing a multiplex test system, the designer must consider the consequences of simultaneous connections in the system in case of software error or hardware failure (stuck relay). Various strategies can be used to handle this, from reconfiguring the switching or adding protection circuitry to adding software checks in the test program.

Multiplexing and scanning are used in a test system to connect one instrument to multiple UUTs or multiple instruments to one UUT. Sample configurations are shown in Figures 13 and 14. Figure 13 shows 2-pole multiplexing of high and low connections to the UUT. The same hardware can be used as both the 1:N and N:1 blocks. Figure 14 shows a ground-referenced system with 1-pole switching. Two additional multiplexers are used to connect the same instruments to a second UUT.

Marvin Test Solutions' GX6264, GX6315, and GX6338 may be used in the examples shown in Figures 12, 13 and 14. The GX6264 offers programmable configuration of differential (2 wire) and single-ended (one wire).

Figure 13: Two Pole Multiplexing

For multiplexed switching, Form A SPST-NO contacts are used almost exclusively. One- and two-pole configurations are common, with more poles used in special situations (i.e. guarding).

Configurations equivalent to multiple pole configurations can be built from single-pole multiplexers controlled together. However, proper shielding, guarding, and noise cancellation are often more difficult. Control can also be synchronized to implement a 1:N/N:1 switched pair.

Figure 14: Switch Topology (Form A, B, C)

Matrix Topology

The matrix topology is used to connect any input to any output. Simultaneous connections are possible with one input driving many outputs or, less often, several inputs driving one output. The most common terminology to describe matrix size is by rows and columns. As shown in Figure 15, any row can be connected to any column by closure of the relay at the intersection or crosspoint of a row and column. The main advantage of a matrix switching system is the flexibility of the connections allowed. The matrix topology connects multiple instruments to multiple points on a UUT, or multiple instruments to multiple UUTs. Direct connections between source and measure instruments are also possible.

Figure 15 (exploded view) illustrates a crosspoint implementing a 3-pole, Form A, switching of high, low, and guard signals. This type of structure permits maximum flexibility when connecting instruments and the UUT to the matrix. When designing the matrix, the number of poles per crosspoint is related to how the instruments are connected to the matrix. Single-pole matrix switching is the most common type.

Marvin Test Solutions' GX6616 is true switch matrix that may be used in the examples shown in figures 15, 16 and 17. These products offer a single-ended configuration of up to 6 rows by 16 columns or 2 rows by 96 columns. In the differential (2-wire) configuration, these products may be used to switch 3 rows by 16 columns or 2 rows by 48 columns. Using several boards, these products may be used to create unlimited switch matrices.

Figure 15: Matrix Topology

In switching matrices, two connection methods can be used, as shown in Figure 16. The common ground system is used in high frequency systems where low impedance returns and coaxial cabling are required. The switched low configuration is used in low frequency or DC applications where floating measurements are required.

Figure 16: Single Pole Matrix

Two-pole matrix switching is used for differential (balanced) systems or to create 4-wire measurements. An example is shown in Figure 17A where a digital multimeter (DMM) instrument makes a 4-wire measurement using two 2-pole rows of the matrix.

The 2-pole configuration can also used for guarded source or measure connections involving high impedance or low level signals as shown in Figure 17B. Since guarding isolates sensitive lines from adjacent circuitry, the construction and wiring of hardware for guarded systems differs from that used in a general-purpose 2-wire matrix.

Figure 17: Two-Pole Matrix

For sensitive measuring applications, the 3-pole matrix switching method is useful. The 3-pole method isolates the high and low signals from the other signals. This is done by additional shielding which is not at circuit low or earth potential. The 3-pole configuration is also used for isolating source/measure signal pairs with a driven shield (guard).

Switching matrices may be used as building blocks for larger matrices by interconnecting them along the columns or rows. Matrix blocks can be connected to form a long narrow matrix. This is useful when a large number of instruments and UUT connections are required, but only a few signals are used for each test step.

As the following points illustrate, the matrix topology is the most efficient method because it offers:

Reduced hardware and cost

Straightforward programming

Maximum switching flexibility via software control

Maximum test flexibility to run different devices or different test programs

However, there are several of the drawbacks to matrix switching:

Safety considerations as it is difficult to confine hazardous signals to certain paths

Increased crosstalk between paths

Shunt loading and impedance matching limits bandwidth

Additional cost of switches for every possible signal path

Lower reliability due to more switches and increased possibility of misconnection

Switching Elements

When a switch turns on, it behaves according to the characteristics and properties of the switching element. Therefore, any element chosen for use in a switching system should approach the ideal switch model.

Figure 18 illustrates the schematic representations of the four types of electrically controllable switching elements. Because of the advancement of relay designs, the relay family of switching elements offers the best overall performance at a reasonable cost.

Figure 18: Switching Elements

Each of the four types shown above has advantages and disadvantages. For Automated Testing purposes however, the Relay offers the best performance. A FET switch is the fastest switch of the group, although it has a high ON resistance and the switchable signal level is typically limited. The Triac is a good solution for high current, high voltage switching but is rarely being used in ATE. The same holds true for the Solenoid Switch, although some applications require its use. Since the relay is the most common switching type used in ATE systems, the rest of this section will focus on types of relays and their advantages.

Types of Relays

Of the many types of relays, only a few are suitable for ATE applications. Among the more common types are electromechanical (armature) and dry reed. Table 1 compares some key parameters of these two relays.

Table 1: Relay Comparison Typical Specifications

Maximum Relay Voltage

The maximum voltage that a relay can reliably switch at is determined by:

The gap (spacing) between the contacts

The dielectric of the gas inside the relay

An arc will develop if the gap is too small between the two contacts. Arcing is common when switching high voltage, but if the relay has the proper gap, arcing is reduced.

In addition, the environment affects the degree of arcing. A humid or highly oxygenated environment promotes arcing and a dry climate reduces arcing. Open relays allow ambient air into the switching area while sealed relays contain a controlled internal environment from the relay manufacturer. Mechanical type relays are made as open or sealed units. Reed relays, by virtue of their construction, are always sealed.

When the voltage across the relay contacts exceeds the maximum switching voltage specified for the relay, arcing is usually present. An arc due to an AC signal is usually reduced as soon as the voltage level drops to zero.

Maximum Relay Current

Typical relay specifications break down maximum current into maximum carry current and maximum switched current.
Carry current is defined as the current that can be passed by previously closed contacts. The cross-sectional area of the path from pin to pin through the switch limits carry current.

Switched current is the maximum current that can be interrupted by the relay. Contact plating and material are the primary factors in the switched current specification. If a high current is switched constantly across the contacts, the heat rises and arcing at the contacts degrades them at a rapid rate. In extreme cases, the contacts may “weld” together. If the specified life of the relay is to be attained, the power rating of the relay must also comply with the current and voltage values.

Maximum Relay Power

The maximum power that a relay can switch relates to the temperature rise in relation to reasonable contact life. An over-power condition dramatically shortens relay life. Signal handling relays have their power rating specified in either volt-amps (VA) or watts. Relays that have their power rating given in watts are DC relays. If the relay is a DC type, the relay’s power must be used to rate the relay’s power handling capability.

AC type relays are designed to handle AC loads and are usually rated in volt-amps. When power is rated in VA, the power factor is not a consideration and volts switched times amperes switched or carried is the calculation used.

Contact Potential

EMF (Electromotive Force) is generated when two dissimilar metals come into contact. Because a relay contact is typically a plated alloy, even the two supposedly similar halves of the contact are not the same. There are differences due to alloy composition and the working of the metal as well as the thermal EMFs generated by the plating to the alloy junction.

In addition, EMF is generated when heat is conducted along the leads of the switch. The difference in the heat flow between the different leads causes a thermal EMF. A secondary source of thermal EMF is from winding inconsistencies and variations in coil wire diameter. In a reed relay, these radiate heat, which causes temperature variations in the switch.

In a test system, these thermal EMFs add a voltage error to the measurement system. Depending on the relay, this error may range from less than a microvolt to tens of millivolts. If the error is significant with respect to the sourced or measured reading, the thermal EMF must be known and compensated.

Relay Operating Speed

The rate at which the contacts may be cycled for reliable operation is known as the operating speed. It is limited by the actuation and release times. Actuation time is measured from when power is applied to the coil until the contacts have settled. Release time is the opposite of actuation time. It is measured from the time power is removed from the coil until the contacts have settled again (including bounce).

An operating frequency, or repetition rate, lower than that allowed by the switching times is often specified for a relay. This is done to limit temperature rise and allow for contact settling. Of these two, temperature rise is more critical. When a relay is used near its power or voltage rating, the duty cycle must be adjusted to allow for cooling time. A lower operating frequency or altered duty cycle produces cooler temperatures.

Relay Contact Resistance Versus Life

Contact resistance is the resistance across a closed set of contacts. This parameter is typically measured using a four-wire configuration with nominal voltage applied to the coil. Unless otherwise specified, a contact resistance specification is for new conditions.

For dry switches, the contact resistance is inversely related to the contact area. Electromechanical relays with large contacts have a lower contact resistance than a reed switch with relatively small contacts.

Life, or the number of operations for which a relay is expected to perform, is typically limited by mechanical operations and by the number of operations under a certain load until a specified resistance across closed contacts is reached. Without an end-of-life contact resistance specification, the life under load specification is meaningless. Dry switches typically have a life specified to a contact resistance less than 1 or 2 Ohms.

A relay may fail in one of several modes, including mechanical (actuation) failure and contact failure. A coil wire break, a glass seal fracture or reed fatigue in reed switches, or an armature mechanism failure in electromechanical relays can cause mechanical failure. A relay contact failure can occur when excessive heat or a high current or voltage pulse causes the contacts to weld. Oxidation, excessive charring and pitting, or insulating deposits on the contacts can cause an open circuit.

Because actual contact life is important, much effort has gone into finding and choosing “good” contact materials. Gold, silver, and palladium have traditionally been used for their good electrical conductivity and relatively low susceptibility to oxidation. Increasingly, rhodium and ruthenium are being plated over more traditional contact materials to increase the contact life. Rhodium’s structure is cubic, which is more stable than that of earlier contact plating. For even greater stability, the hexagonal structure of ruthenium is used.

Relay Inductance

A relay coil also produces inductance because it is a coil of wire. As an inductor, the current in the coil cannot be changed instantaneously, since V=L(di/dt), without generating an excessive voltage spike. A diode is often used across the coil with the cathode at the positive voltage end of the coil. The suppression or “back” diode will conduct the coil current when the relay drive is removed. See Figure 19.

Figure 19: Suppression Diode

Insulation Resistance

Insulation resistance (IR) is a measure of the resistance between two isolated pins on the relay. Available insulator materials provide a wide range of insulation resistance (105-1014 K Ohm) in various environments. The primary factor to limiting IR is bulk leakage and surface leakage. Bulk leakage is through an insulating material, usually after it has absorbed moisture from the environment. Surface leakage is across the surface of the material, usually due to contamination such as salts or flux and/or other chemicals from fingers. The properties of some insulators change with applied voltage, so it is important to evaluate IR at or above the expected operating voltage.

Relay Capacitance

All the components of a relay have inherent capacitances that are determined by the materials and physical configuration of the relay.

The typical capacitance from switch contacts to the coil is 0.2 - 15 pF. This capacitance can couple noise or other signals from the contacts to the control lines, and vice versa. Noise can also be coupled to a different switch through its contact-coil capacitance if it is driven by the same coil supply. An electrostatic shield between the switch and the coil can reduce noise by as much as a factor of 110. In addition, there is also capacitance across open contacts. This type of capacitance depends on the contact area and the gap of the switch and is typically less than 2 pF. These inherent capacitances, due to physical characteristics of the relay, are one factor in limiting the frequency of the signal the relay switches.

Signal Frequency

To obtain higher switching rates and good RF performance, specialized contacts and relay architectures are used. Operating frequencies greater than 50 MHz are possible with these types of relays. Inter-contact capacitance and contact circuit loss are factors that determine how well a relay is suited to high frequency applications. In addition, the design of the printed circuit board (PCB) also contributes to the selection of RF relays. Beveled etched signal paths and ground-guards are integrated into newer switch matrix PCB designs.

Alignment of Card Slots at Assembly Level - Published on 5/2/2023

5/2/2023

Taken from Paul Shklanko email dated 10/20/2019:

Hi Paul,

There is an issue with a GX7210 returned by a customer under RMA 18266. There appears to be a backplane alignment within the chassis. Please review my evaluation notes below and work with Roger on the disassembly of the chassis addressing the following.

1. Confirm the conclusion.

2. Determine the root cause for this failure. Note that the customer purchased 18 of this chassis model at one time and may have a stockpile of unpacked units.

I have copied QA to this message to keep them in the loop. I also copied Tero as the incident has been assigned to him.

Reported Problem:
- The customer reported that the GX1632e Prototype board (PXIe) did not fit in a chassis slot.
- The customer unpacked another new GX7210 and had no issues with that chassis.

Evaluation Results of Returned Chassis:
- Confirmed that I was not able to install a PXIe instrument in slots 2 (PXIe) and slots 3 through 8 (PXI-H).
- Confirmed that I was able to install a PXIe instrument in slots 19 and 20 (PXI-H).
- Confirmed that I was able to install a PXI-H Instrument in slots 3 through 8 (PXI-H).

Instruments used For Evaluation:
- PXIe: Used GX1632e and GX3800e.
- PXI-H: GX6384.

Conclusion:
- Upon examination it was noted that the P4 connector of the PXIe instrument is hitting the shroud of the backplane XP4 connector. This is the case for slots 2 through 8 (PXIe and PXI-H). This is shown in the photograph below.
- The PXIe P3 connector (keying) constrains the P4 connector causing the clearance issue.
- This was not caught by Production test as the PXI-H card fits all hybrid slots. This is what is used by Production test. There is no P3 connector therefore there is room for tolerance of a misalignment.
- Gap analysis – Production must add a step in the process for all GX72x0 chassis configurations assembly to use a PXIe instrument in slots 2 and 21. The same should be added for GX76x0 chassis assembly.

From Paul Lipert 10/29/2019:
Rejection steps performed:
Paul Shklanko confirmed customer rejection and determined preliminary cause 10/20/2019. It was believed that there was a misalignment occurring at the Backplane level relating to connectors (PN’s 214443 and 973028).
Evaluated the structure of the Backplane (2524-300-000-ASSY) and the horizontal extrusions (PN 131799) as to how they interconnect to each other. With the (40) screws that attach the back plane to the extrusions, it seemed improbable that any misalignment would be allowed.
Researched the (2) connectors (PN’s 214443 and 973028) with relation to the Backplane itself. Found no inconsistencies outside of what the PCB drawings allow.
Continued research into the potential conditions of extrusions (bow from manufacturing) and if they could cause the PCB cards to not properly align into the Backplane components. By loosening the top (20) screws and providing an offset of the extrusion in the middle section enabled the sample PCB Express card to have proper fitment. Slot 10 demonstrated the greatest visible fitment interference.

Actual Findings:
CN: EZ-A1-AA-00 – From MTS Inventory – SN: 00012 – Fit slot 10 perfectly prior to adjustment.
CN: EZ-A1-AA-00 - From MTS Inventory – SN: 00017 – Fit with slight interference prior to adjustment.
CN: PZ-AA-AA-000 Express - From An Thai – SN: 00016 – Did not fit prior to adjustment.

Described and demonstrated findings to assembly supervisor and technician. Instructions were relayed as to how the backplane is to be assembled through evaluation steps alignment. Chassis assembly was reassembled per instruction, passing fitment check of all slots.
Cause: Installation of Express Cards were not used for alignment / validation of fitment steps at extrusion / backplane assembly level.

Corrective Action:
MAI instructions shall be updated to include fitment verification of Hybrid, Legacy and Express Cards as follows:
IS: Install backplane (item 4) using screws (item 17). Verify backplane and card guide alignment by inserting Hybrid, Legacy and Express Cards. Adjust alignment of upper and lower extrusions as required for proper fitment of all cards below:
• Hybrid: Slots 1 thru 10, 19-21.
• Legacy: Slots 11-18.
• Express: Slots 1 thru 10, 19-21.
WAS: Install backplane (item 4) using screws (item 17). Verify backplane and card guide alignment by inserting a 3U card into 3 slots (2, 10 and 20) and align backplane prior to tightening screws. Loctite/Torque per drawing.
Video and photo link: K:\PaulLi\RMA 18266

How to Display an Animated GIF File in an ATEasy Form - Published on 4/26/2023

4/26/2023

In ATEasy form's, animated GIF files are supported by the ALog control. To display an animated GIF in a log control, set the control to HTML mode (PlainText property set to False), and then append an image tag with the GIF file.
The image file is defined using the HTML IMG tag and can then be inserted into the ALog control using the Append method.

The height and width of the image can be specified using the height and width attributes.
For example, the following line links the image to the "C:\geotest.gif" file and sets the image height and width to 42.

The image is then appended to the ALog control using the Append control as follows:

log1.Append("")

To hide the ALog's scrollbar, which is displayed by default, insert the following into ALog's OnLoad event:

log1.Document.body.setAttribute("scroll", "no")

The image can be positioned in the ALog control by setting the ALog control margins. For example, inserting the following settings into AForm's OnLoad event will align the image in the Top-Left corner of ALog control :

log1.Document.Body.LeftMargin=0
log1.Document.Body.TopMargin=0

Here is the complete code for displaying the animated GIF in a log control:

Sleep(1)                             !Wait for Form objects to complete loading

frmHGForm.Visible=True               !Make the form visible
sImageDir=GetDir(aGetDirCurrent)     !Get the current directory location
sImageName=sImageDir+"\\Logo.jpg"    !Logo file name. Put the Logo on the top of the form
imgLogo.LoadFromFile(sImageName)     !Load the logo
imgLogo.Visible=True                 !Make it visible

!Set the ALog Window to HTML mode to display the animated image file
logHGWid.PlainText=False
!Remove the Scroll bar
logHGWid.Document.body.setAttribute("scroll", "no")
!Position the image in the Top-Left corner of the ALog control
logHGWid.Document.Body.LeftMargin=0
logHGWid.Document.Body.TopMargin=0
!Clear the ALog window
logHGWid.Clear()
!Get the dimensions of the ALog control for the image height and width settings
fHeight=logHGWid.Height-4
fWidth=logHGWid.Width-4

!HTML Image string
sImageName=""
!Place the image in the ALog window
logHGWid.Append(sImageName)

An ATEasy application that demonstrates how to load an animated GIF file into a form can be downloaded by clicking on this link Q200225 Example. The application opens a window that displays a spinning hourglass. The main section of code can be found in the OnLoad event for the program form.

Simulation with ATEasy - Published on 4/13/2023

4/13/2023

Overview

Simulation is the emulation or imitation of one or more components of a test system during code development or operation of the system. This includes simulation of:

Test system instruments

Test system software

Unit Under Test

Often while developing test programs, an engineer is face with the challenge of writing test code for missing instrumentation.  Typically, compiling and running test programs with missing or malfunctioning hardware will result in run-time communication errors.  Simulating the missing or malfunctioning hardware allows the code developer to compile and run programs without producing error conditions that can be a nuisance to work around, allowing code flow to be tested sooner and optimized more efficiently.

Where test development is divided among multiple engineers, simulation allows concurrent code development among a team of software developers.  In this instance, the system hardware is often a limited resource (i.e., one system but many programmers), but need not be a development limitation.  Linking code development to system access creates an unnecessary bottle-neck that can dramatically reduce productivity and lengthen time to deployment.  Developing, debugging and running an application on a desktop, sans the hardware, frees up system time, provides better resource utilization and speeds up development and debugging times.  Then, when hardware becomes accessible, the time spent with the hardware can be more focused, allowing this limited resource to be used more efficiently.

A further benefit of simulation within the ATEasy environment is the ability to trace and analyze the performance of your code, and the performance of the instruments when running in the system.  ATEasy allows combined use of instrument simulation and instrument control simultaneously.  A simulation routine can place timing structures around the instrument commands to measure performance of the instrument while in operation.  This is accomplished without modifying the instrument driver or otherwise impacting the test program.  Once performance parameters have been established, the simulation can simply be disabled, allowing the program to run normally.  No code changes are required.

Implementation

To support a full, robust simulation, ATEasy v9.0 introduces several new Simulation Procedures and Simulation Properties, as listed below:

AApp.Simulate Property: Set or return the application’s Simulation Mode property; True - simulation is turned on, False - simulation turned off. Default is False.

SetSimulateProcedures (sProcedureOrSubModule): Defines the procedure, IO table, or module to be simulated. You can pass in a module shortcut name, sub-module name or a procedure included within the sub-module. Note, SetSimulateProcedures() should occur before any ATEasy calls of an instrument API procedure or IO Table.

OnSimulate (obModule, procCallee, penSimulateStatus) Event: Occurs when a defined procedure or IOTable is called while in simulation mode (App.Simulate=True), where:

obModule:  The module object that initiated the OnSimulate event.  The module has various properties associated with it, one of which is obModule.Name.  The property obModule.Name refers to the name of the module object that initiated the OnSimulate event.  Example obModule.Name=“DMM” implies the name of a DMM driver module.
procCallee:  The name of the Procedure within the module object that initiated the OnSimulate event.  Example "DMM.SetFunction" indicates that the OnSimulate event was initiated by the “SetFunction” procedure contained within the “DMM” driver module.
penSimulateStatus:  Enumerated status indicating how to proceed with the simulation handling, where:
enSimulateDone:  Simulation handled, return to caller
enSimulateCallNext:  Simulation not done, call next handler
enSimulateCallSimulated:  Call original simulated callee

GetSimulateParameter (sParameterName ): Returns a pointer to the parameter referenced in the intercepted API procedure, allowing you to set or return the parameter value of the callee procedure. Example, “p=GetSimulateParameter("pdMeasurement")” returns a pointer to the pdMeasurement parameter referenced in the API procedure that initiated the OnSimulate event.

As with all structured processes within ATEasy, simulation uses events to control the simulation process – specifically, OnSimulate Events.  Runtime access to the instrument API’s is accomplished by redirecting procedure calls to the simulation code contained in the OnSimulate event.  The redirection is selective by identifying, or registering which instrument API’s to redirect.  This is done using SetSimulateProcedures(), and is typically done very early in the applications execution.  The redirected procedure can be any type of procedure within the ATEasy application, including IO tables, user defined procedures or DLL procedures linked to the ATEasy application.  Also supported are redirecting all procedures within a sub-module name or module shortcut.

To activate the redirection (enable simulation), the application property “Simulate” must be enabled (set to True).  This can be done from the Conditions menu, or programmatically using the App.Simulate property.  When a simulated API procedure is called, ATEasy redirects control to the OnSimulate event.  Here, the programmer has access to the name of the module containing the calling API procedure (obModule), the name of the procedure itself (procCallee), and the procedure’s parameter list (using GetSimulateParameter).  The programmer is free to define any level of procedure simulation, from very simplistic, to very complex, depending on what is required.  The process for simulating an instrument is:

1.  Set the project requiring simulation as the Active Project.
2.  Add code to select the procedures, IO Tables or modules that are simulated.  Recommendation; Add a driver to your system that takes care of the simulation processes.  This simplifies adding or removing simulation to a project.
3.  Implement the OnSimulate() event to handle simulation.

Use the GetSimulateParameter() function to retrieve the pointer to the simulated procedure parameter(s). This can be used to set or access the value for parameters.

Before returning from the OnSimulate() event, set the penSimulateStatus parameter to let ATEasy know what to do next.

Optionally, you can also:

Use the GetCallerName() to determine where the call was made from and what procedure called your simulated procedure.

Use the Program, Task and Test internal variables to determine the location of the call within your program. This will allows you to return different values for different tests.

4. Turn ON Simulation and run/debug your application:

Turn on Simulation by Checking the Simulate from the Conditions menu

Run your application with /simulate command -line.

Set the App.Simulate property to TRUE (in code),

Examples

Basic Simulation
This example demonstrates creating a driver to implement the instrument simulation. The first step after creating the new driver, is to define the instrument procedures that will be simulated. Figure 1 below defines that all of the Digital Multi-Meter (DMM) driver procedures and all of the Power Supply (PS) driver procedures will be simulated. Other simulation options for the DMM and PS drivers can be used, as shown in the commented code of figure 1.

Figure 1: Defining simulated procedures in the driver OnInit event

The OnSimulate event contains code to simulate the procedures that initiated the simulation event. In the example shown in Figure 2, the name of the calling module and the calling procedure are used to select the type of simulation response. Here, the DMM.Measure procedure is simulated to return the value “6.0” to the pdResult parameter, and the DMM.GetSystemIdentification procedure is simulated to return the string “34401A” to the psID parameter, masking the DMM Initialization Instrument ID Query error. Every different procedure in an instrument driver could potentially have a unique simulation process. At the conclusion of the simulated response, the simulation status is set to done, indicating no further action will be taken and control will return to the caller (penSimulateStatus=enSimulateDone).

Figure 2: OnSimulate event in the simulation driver

To test the simulation, the simulation mode must be enabled (Figure 3) and a call to the DMM driver is required. In the ATEasy “DMM Test” (Figure 4), the test calls the DMM SetFunction and Measure functions. ATEasy will intercept both API calls, but specifically traps the measure function and returns the value “6.0” to TestResult via the “pdResult” parameter, as illustrated in the images provided (Figure 5).

Figure 3: Enabling simulations from the Conditions menu

Figure 4: Testing the simulation

Figure 5: Simulating the Dmm.Measure function

To avoid confusing simulated tests from real tests, the simulation function in ATEasy has been further enhanced to indicate if a test run used simulated processes. The Test Executive report shown in figure 6 clearly identifies that the simulation mode was enable and operating during the tests.

Figure 6: Test Executive showing simulated test results

Performance Measurement Simulation
This example demonstrates how to measure the performance of an instruments API. Calls to the instrument driver are maintained and communication with the instrument still takes place. The core of the performance measurement is achieved by surrounding the instrument's API call with the Tick() function. this provides a timestamp of the duration of the instrument procedure. The full performance simulation example is provide here:

Procedure OnSimulate(obModule, procCallee, penSimulateStatus): Variant Public ! Occurs when a simulated procedure or IOTable is called in simulation mode.
--------------------------------------------------------------------------------
obModule: Val Object
procCallee: Val Procedure
penSimulateStatus: Var Internal.enumASimulateStatus
pParm2: Any
pParm1: Any
lStart: Long
sProc: String: 32

{

If bIgnoreSimulate
penSimulateStatus=aSimulateCallSimulated
return 0
endif
sProc=procCallee

Select sProc
Case "GTDEMO.GtDemoRelaySwitch"
bIgnoreSimulate=TRUE
pParm1=GetSimulateParameter("enRelay")
pParm2=GetSimulateParameter("enRelayState")
lStart=Tick()
procCallee(pPArm1,pParm2)
lCountTime=lCountTime+Tick()-lStart ! total time
lCount=lCount+1 ! total calls
bIgnoreSimulate=FALSE
Case "GTDEMO.GtDemoBuzzerSetState"
bIgnoreSimulate=TRUE
pParm1=GetSimulateParameter("enBuzzerState")
lStart=Tick()
procCallee(pPArm1)
lCountTime=lCountTime+Tick()-lStart ! total time
lCount=lCount+1 ! total calls
bIgnoreSimulate=FALSE
EndSelect

Append sProc+" Time (mS): "+Str(lCountTime)
penSimulateStatus=aSimulateDone

Return 0

}

The program module that contains the Tasks and Tests that are used to call the instrument functions, and resulting test report are shown below:

Figure 7: Calling the instrument functions from within a test

Figure 8: Performance measurements test results

Other Simulation Technologies

IVI provides simulation that is configured using VISA resource manager (NI-MAX or Agilent VISA). To support simulation, you need to configure the resource manager with a different driver that was written especially to support simulation, only some vendors offers it. IVI simulation is designed to simulate drivers, to ignore errors, provide range checking for parameters and inject errors..When using an ATEasy IVI based driver that support simulation, ATEasy supports IVI simulation as well the same way as other development tools, ATEasy simulation is not specific to a technology (i.e. IVI) and can simulate any call including program, system, driver and UUT. It also does not require any external driver to be written, it provides additional benefits such as testing your application logic at any level, measuring performance and program flow, debugging tool . ATEasy simulation can also be injected to your application without changing any of your application exiting code.

Conclusion

ATEasy v9 simulation is a powerful feature and offers users the following benefits & capabilities:

Develop and verify test programs without needing valuable time on the tester or needing access to a UUT.

Compile and run the test program without any hardware or UUT

Supports concurrent test program development from multiple developers

Trace and analyze test program performance

Provides test engineering with a consistent way to characterize and validate test programs logic including parameters range checking, error injecting, return value and parameters, and more

Calling Unmanaged DLLs Functions from Powershell - Published on 4/5/2023

4/5/2023

Introduction

All Marvin Test Solutions (MTS) driver packages, like GxDMM, comes with a Windows DLL and accessible from PowerShell (PS). This article demonstrates how PS can access MTS unmanaged libraries, like GxDmm.DLL, to interface and control the Gx2065 instrument.

PS is a cross-platform task automation solution built on the .NET Common Language Runtime (CLR) is made up of command-line shell, a scripting language, and a configuration management framework that runs on Windows, Linux, and macOS. All modern versions of Windows operating systems ship with PowerShell installed, allowing access to a readily available tool where we can create scripts for automating tasks without the need of additional IDE (Integrated Development Environment). See resource [1] to learn more about PowerShell.

PowerShell DLL Support

It may be of value to discuss what are unmanaged and managed codes. Unmanaged codes are NOT developed in .NET environment such as Win32 API or C/C++, or COM components, while managed codes like C# are developed in .NET. Managed code execution is managed by CLR. Since MTS DLLs are unmanaged, bridging the gap between the unmanaged code in the DLL and the managed code is necessary. This is done through the concept called Marshalling where the unmanaged data types are converted to managed. See KB article [2] from resources section for more information. MTS software packages include the C# class that takes care of this step. Figure 1 illustrates how PowerShell access the functions in the DLL.

[:+[+Gx2065+]+:]

Figure 1: Overview of DLL, C# Class, and PowerShell Interface

Process

The simplest way to find PowerShell is through the Windows search bar. The PowerShell ISE (Integrated Scripting Environment) is used to demonstrate interfacing and controlling the Gx2065 instrument. PowerShell ISE provides the environment to develop the script as well as the command line to interact with the instrument.

Figure 2: Launching PowerShell

Figure 3: PowerShell ISE Editor

Import C# Class and Assign to a new Type

C:\Program Files (x86)\Marvin Test Solutions\GxDmm

GxDmm.cs

Add-Type -TypeDefinition @"paste C# code here"@

" "

Figure 4: Importing C# Class

Members access

GxDmmGetDriverSummary

Considerations

Conversion from C++

Since DLLs could be originating from C++, this may impose a problem in the .NET environment. See resource [3] for reference when converting data types from C++ to C# to ensure compatibilities.

Symbol Declaration

The default for integers is Int32. Uint16, Int16, and others must be explicitly declared. The following are examples of how to declare symbols.
[Uint16] $unsign16 - unsigned integer16
[Int16] $sing16 - signed integer16
[Uint32] $unsign32 - unsigned integer32
[UInt64] $sing64 - unsigned integer64
[Int64] $sing64 - signed integer64

$count = 10
$arrayMeasurements = New-Object double [] $count - declares an array of double with 10 elements.
$Summary=[System.Text.StringBuilder]::new()
$Summary.Length=256

Var Access/[ref]

To access by reference, use [ref] before the symbol when passing it as a parameter.
$Version and $Status are passed by reference on [GxDmm]::GxDmmGetDriverSummary($Summary, 256, [ref] $Version, [ref] $Status)

Summary

Calling MTS DLLs from PS is fairly straightforward process. The software packages include the C# classes and ready for implementing in PS script.

Find out the functions in DLL

Create a class to contain prototype functions that are linked to the DLL functions

Import the class in PowerShell using Add-Type -TypeDefinition cmdlet (COPY/PASTE)

Call the method in the class as you would in any other managed method

Example

Gx2065 Example

Resource

[1]
PowerShell Overview
PowerShell
[2]
Using DLL in .NET environment
KB Article #Q200191
[3]
Data type Conversion
KB Article #Q200210 - Data type Reference table

2022 Air & Space Forces Assn. Air, Space & Cyber Conference - Weapons and Munitions Panel - Published on 10/13/2022

10/13/2022

The Air Force has adopted the mantra of CSAF Gen. C.Q. Brown, Jr. to “Accelerate Change or Lose”, and the operational concept of Agile Combat Employment (ACE), which demands innovative approaches such as agile, tailored force packages, dispersed deployments, and multi-capable Airmen to respond quickly to threats.

This panel discussion addresses the challenges of this new CONOPS and solutions to realize its potential, including commonality, interoperability, and streamlined logistics to provide resilience and ensure warfighter readiness and effectiveness.

Of note is a discussion led by Marvin Test Solutions’ CEO, Major General Stephen T. Sargeant, USAF (Ret.) summarizing years of Armament Maintainers’ “desirements” and how they have evolved to requirements under ACE. Focusing on those “desirements”, Marvin Test Solutions has been working for a decade to design and develop test equipment to meet the requirements needed to enable Multi-capable Airmen — innovative armament test solutions that are ready to deploy today.

Click Here to View the recorded session

Getting Started with ICEasy - Published on 9/26/2022

9/26/2022

ICEasy is an ATEasy add-on module that is used to facilitate the programming of Marvin Test Solutions’ Dynamic Digital IO (DIO) boards for semiconductor test applications. This article provides an overview of how to use ICEasy for creating and executing test programs.

Pin Mapping between DIO channels and UUT pin names

Creation of Pin Groups and nested groups as well as providing the ability to perform various test functions on a group

Simplified programming

Faster creation of predefined tests (Continuity, IDD, IDDQ, Voltage Threshold, Leakage, etc.)

Sweeping functions and Plots (Shmoo, I/V Curve, etc.)

Virtualization of the digital subsystem, allowing reuse of ICEasy based code with future MTS boards

Simulation of your test program, allowing you to test and run your program with no hardware using the simulation mode.

Configuration ICEasy System

To use ICEasy, You must have ATEasy v9 (or newer). Your ATEasy Project System files should first have the DIO driver (in this example, GX5295.drv) followed by ICEasy (ICEasy.drv) and the ICEasy_GX5295 board driver (ICEasy_GX5295.drv). The SIM driver is an application custom driver and is used for simulation if simulation is needed.

Once the drivers are inserted you need to configure the DIO driver shortcut. This requires setting the driver parameters as required, usually setting the MasterNumber to 1. You also need to set the INIFileInitialization parameter to 1 if the DIO is configured using the INI file or it is set to the Master/Slave slot number in your DIO domain. We recommend using the INI file initialization versus setting the Master/Slave boards since it ensures that information displayed in the panel matches the ICEasy board and channel numbers. Since the DIO driver is inserted prior to the ICEasy driver, the DIO driver will be initialized prior to ICEasy, ensuring that initialization of the ICEasy driver will succeed.

Pin Mapping

Prior to using ICEasy, you will need to map the DIO channels to the DUT/UUT (Device/Unit Under Test) pin names. DIO Channels are 0 based, so if the first board is a GX5295, the channel numbers will be 0-31, the second card’s channels will be 32-63, etc. The order of the DIO cards can be set from the GTDIO Panel’s (installed with the GX5295) Configuration page and this setup will be saved to the INI file.

The following command is used to map a DIO channel to a UUT pin:

ICEasy Map Add (sPinName, vPinNumberOrPinList, enPinType, vInstrumentName, \
iInstrumentChannel)

To create a pin group, use the following:

ICEasy Map Add Group (sGroup, asGroupOrPinList)

Other available mapping commands reside under ICEasy Map group of commands.

To map channels you usually place the code in the Program.OnInit() event as shown here:

ICEasy Map Add("CLR", 1, enPinTypeDigitalInput, "ICEasy_GX5295", 0)

In this example we mapped the UUT CLR pin (has a unique index or id of 1) to the DIO channel 0 (last argument).

You can also specify the Pin type as a digital Input/output, and assign the board driver’s shortcut name used to control the pin (ICEasy_GX5295). Additional examples of mapping other UUT pin channels are shown here:

ICEasy Map Add("CLK", 11, enPinTypeDigitalInput, "ICEasy_GX5295", 17)
ICEasy Map Add("D1", 3, enPinTypeDigitalInput, "ICEasy_GX5295", 2)
ICEasy Map Add("D2", 4, enPinTypeDigitalInput, "ICEasy_GX5295", 7)
ICEasy Map Add("D3", 7, enPinTypeDigitalInput, "ICEasy_GX5295", 6)
ICEasy Map Add("D4", 8, enPinTypeDigitalInput, "ICEasy_GX5295", 3)
ICEasy Map Add("D5", 13, enPinTypeDigitalInput, "ICEasy_GX5295", 10)
ICEasy Map Add("D6", 14, enPinTypeDigitalInput, "ICEasy_GX5295", 13)
ICEasy Map Add("D7", 17, enPinTypeDigitalInput, "ICEasy_GX5295", 14)
ICEasy Map Add("D8", 18, enPinTypeDigitalInput, "ICEasy_GX5295", 9)
ICEasy Map Add("Q1", 2, enPinTypeDigitalOutput, "ICEasy_GX5295", 1)
ICEasy Map Add("Q2", 5, enPinTypeDigitalOutput, "ICEasy_GX5295", 4)
ICEasy Map Add("Q3", 6, enPinTypeDigitalOutput, "ICEasy_GX5295", 5)
ICEasy Map Add("Q4", 9, enPinTypeDigitalOutput, "ICEasy_GX5295", 8)
ICEasy Map Add("Q5", 12, enPinTypeDigitalOutput, "ICEasy_GX5295", 15)
ICEasy Map Add("Q6", 15, enPinTypeDigitalOutput, "ICEasy_GX5295", 12)
ICEasy Map Add("Q7", 16, enPinTypeDigitalOutput, "ICEasy_GX5295", 11)
ICEasy Map Add("Q8", 19, enPinTypeDigitalOutput, "ICEasy_GX5295", 16)
ICEasy Map Add("VCC", 20, enPinTypeVcc, "ICEasy_GX5295", 31)
ICEasy Map Add("GND", 10, enPinTypeGnd)

Note that some pins are marked as VCC and some as GND. The available pin types are displayed when you type the argument for this parameter.

Pin Group Mapping

Addressing UUT pins individually can be cumbersome. When a repetitive function is needed for controlling / accessing or measurement that involve many pins you can create a Pin Group. The following example demonstrates pin group definitions:

ICEasy Map Add Group("Reset Pins", {"CLR"})
ICEasy Map Add Group("Clock Pins", {"CLK"})
ICEasy Map Add Group("Input Pins", {"D1", "D2", "D3", "D4", "D5", "D6", "D7", "D8"})
ICEasy Map Add Group("Output Pins", {"Q1", "Q2", "Q3", "Q4", "Q5", "Q6", "Q7", "Q8"})

In this example the Input Pins group contains 8 pins D1-D8.
You can also define nested groups. A nested group can combine groups and pins with a name assigned to a new group. The following example shows the use of a nested group:

ICEasy Map Add Group("IO Pins", {"Reset Pins", "Clock Pins", "Input Pins", \
"Output Pins"})
ICEasy Map Add Group("Power Pins", {"GND", "VCC"})
ICEasy Map Add Group("All Pins", {"IO Pins", "VCC"})

In this example IO Pins is comprised of 4 groups and has a total of 18 pins.

Using the Digital Instrument’s PMU Capabilities

ICEasy has several commands that facilitate parametric testing using the digital instrument’s PMU (Parametric Measurement Unit). The commands work on a single pin or on a group. For a single pin the returned variant will contain a single double precision value. When a group is passed in, the measurement command will return a variant containing an array of measurements. The following commands are available:

Measurement Commands:

ICEasy Measure Voltage (vGroupOrPinNameOrIndex, iMeasureRate): Variant

ICEasy Measure Current (vGroupOrPinNameOrIndex, iMeasureRate, iMaxDigits): Variant

Stimuli Commands:

ICEasy Set Voltage (vGroupOrPinNameOrIndex, dVoltage, dMaxCurrent)

ICEasy Set Current (vGroupOrPinNameOrIndex, dCurrent, dVCommHigh, dVCommLow)

Stimuli and Measurement Commands:

ICEasy Set Voltage MeasureCurrent (vGroupOrPinNameOrIndex, dVoltage, dCurrentLimit, \
        vMeasurePinNameOrIndex, iMeasureRate, iMaxDigit, iDelayMeasure): Variant

ICEasy Set Voltage MeasureVoltage (vGroupOrPinNameOrIndex, dVoltage, dCurrentLimit, \
        vMeasurePinNameOrIndex, iMeasureRate, iDelayMeasure) : Variant

ICEasy Set Current MeasureCurrent (vGroupOrPinNameOrIndex, dCurrent, dVoltageHighLimit, \
        dVoltageLowLimit vMeasurePinNameOrIndex, iMeasureRate, iMaxDigit, iDelayMeasure) \
        : Variant

ICEasy Set Current MeasureVoltage (vGroupOrPinNameOrIndex, dCurrent, dVoltageHighLimit, \
        dVoltageLowLimit vMeasurePinNameOrIndex, iMeasureRate, iDelayMeasure): Variant

The stimuli and measurements commands can be used to perform parametric tests such as:

Continuity, Short, Open tests

Power Consumption (IDD, IDDQ)

Input Voltage Threshold (VIH, VIL)

Input Leakage (IIH, IIL)

Output Voltage Level (VOH, VOL)

These commands can also be used to perform other device characterization procedures such as Functional Tests, IV Curve, and Shmoo Plots.

Example – Performing a Shorts Test

The following code shows how to perform a shorts test by checking for a shorted protection diode or checking for a short to other pins.

! set all pins to 0V
ICEasy Set Voltage("All Pins", 0)
! force sink a small current of -500 uAmp and then measure voltage
TestResult=Abs(ICEasy Set Current MeasureVoltage(“D1”, -0.5))
! restore pin setting
ICEasy Set Voltage(“D1”, 0)

Example – IDD Test
The following code shows how to test for IDD, standby current.

! turn on Vcc and then measure IDD
TestResult=ICEasy Set Voltage MeasureCurrent("Vcc", 4.50)
! turn off Vcc
ICEasy Set Voltage("Vcc", 0)

Vector Commands

ICEasy provides the ability to write (and read) vectors to the digital subsystem, execute them, and return an error count. The following are some of Vector commands:

ICEasy Set Vectors (vGroupOrPinNameOrIndex, vVectors, iVectorStart, iVectorsCount, \
iRepeatCount)

ICEasy Run Vectors (vGroupOrPinNameOrIndex, iVectorStart, iVectorsCount, iFrequency, \
iStrobeDelay): Long

The first command Set Vector writes vectors to a group or pin, starting at the DIO vector memory iVectorStart, and repeating the array of strings passed using the vVectors iRepeatCount value. The number of vectors is defined by iVectorsCount. vVectors are the written vectors. Vectors are an array of strings where the first element corresponds to the first vector etc. Each string character op-code corresponds to a digital subsystem channel.
...

Click Here to continue to read and download the rest of this article

PXI Bus expander configuration - Published on 9/16/2022

9/16/2022

It is often necessary to join two or more PXI buses, or a PXI and a PCI bus together in order to control more than one chassis concurrently. This can be accomplished by the use of a PXI bus expander that introduces a PCI to PCI bridge between the two adjoining systems (either PC to Chassis, Laptop to Chassis, or Chassis to Chassis). Several vendors offer solutions with a diverse set of configurations. This article will list the devices that Marvin Test Solutions offers, along with their respective configurations.

When choosing the PXI Bus Expander that is right for your application, make note of the configuration type and the bus types that will be bridged.

The following is a list of possible configurations and solutions that Marvin Test Solutions offers:

Desktop PC to Chassis

For example Desktop to GX7600 PXI Express Chassis

PCI to PXI (GX7000A, GX7100A, and GX7300 chassis only)

GX7990 - 132 MB/s with a copper parallel type connector

GX7992 - Star Fabric type connector

MXI-4-C - 132 MB/s with copper serial type connector

MXI-4-F - 132 MB/s with fiber optic connection allowing a long cable length up to 200 meters

PCI Express to PXI (GX7000A, GX7100A, and GX7300 chassis only)

MXI-EXPRESS - x1 lane, single port (one chassis)

MXI-EXPRESS - x1 lane, dual port (two chassis)

PCI Express to PXI Express (GX7100E, GX7200, GX7600) Chassis only

MXIe1-EXPRESS - 192 MB/s Express x1 connection

MXIe4-EXPRESS - 798 MB/s Express x4 connection

Laptop to Chassis

ExpressCard to PXI (GX7000A, GX7100A, and GX7300 chassis only)

MXIe1-PXI-L - ExpressCard Laptop Interface

ExpressCard to PXI Express (GX7100E, GX7200, GX7600) Chassis only

MXIe1-EXPRESS-L - ExpressCard Laptop Interface

Thunderbolt to Chassis

Thunderbolt to PXI Express (GX7100E, GX7200, GX7600) Chassis only

MXI-E Thunderbolt - Thunderbolt 3 Interface

Chassis to Chassis

PXI to PXI (All chassis GX7000A, GX7100A, GX7300, and GX7600 )

GX7990-1 - 132 MB/s with a copper parallel type connector

GX7992-1 - Star Fabric type connector

MXI-4-C - 132 MB/s with copper serial type connector

MXI-4-F - 132 MB/s with fiber optic connection allowing a long cable length up to 200 meters

The above mentioned part numbers represent a kit, that includes two devices, each attached to its respective bus, and a cable that connects them. Each part in this kit can also be ordered separately upon request.

White Paper: Sustainment Challenges and Approaches for Legacy ATE Systems - Published on 9/14/2022

9/14/2022

Lifecycle management is the bane of existence for many test engineers. Opportunities to transition to that next new exciting project can be hampered by the need to keep deployed automatic test equipment (ATE) operational, especially as these systems continue to be pushed beyond their initial life projections.

Multiple alternatives for legacy ATE sustainment are available and range from the stockpiling of spares to leveraging the secondary market to acquiring COTS instrumentation to the development of exact FFF replacements with each having its own set of advantages and disadvantages; timeline, budget, future support projections, engineering resources and the size of the deployed ATE and TPS footprint must all be considered during the evaluation.

Download this white paper to learn how to analyze the available alternatives and choose the best approach.

Download the white paper

Calling DLL functions from MATLAB using C Header Files - Published on 9/14/2022

9/14/2022

Introduction

MATLAB® support using and calling DLL Windows libraries, This article shows how to use a library GXAO.DLL and the C Header file to call and control the GX1648 instrument. The GXAO.dll and the GxAo.h are provided with the GXAO software package. The example was written with MATLAB® 2020b.

MATLAB® DLL Support

It is useful to note that after MATLAB® release 2015b, 32-bit DLL are no longer supported. Currently, the required tools are provided in a core installation of MATLAB® 9.9 without the addition of toolboxes[1]. Once a library is loaded, you can view[2] and call its C-compatible functions. More information about troubleshooting, limitations, data types etc. regarding MATLAB®'s C -interface is available on MathWorks' website[4], all of which is a recommended read when preparing to use driver libraries from MATLAB®.

Method

Firstly, the shared library needs to be loaded. This can be achieved by using the MATLAB® function loadlibrary(libname, hfile). In the included example, we are modifying the GxAo.h to simplify and remove the included using modified GxAo.h named m_GxAo.h for hfile argument. It includes Windows.h before GxAo.h. There are also other ways to include the needed Windows.h using overrides like loadlibrary(libname,hfile,Name,Value), master headers and so on. Different methods were tested to load libraries. The one used in the provided example was deemed the most stable out of the ones that were experimented with. Once library is loaded successfully, you can inspect the callable functions using another tool libfunctionsview[2].
Calling loaded functions is done using the MATLAB® function [x1,...,xN] = calllib(libname,funcname,arg1,...,argN) . The function accepts loaded libname, funcname and funcname's arguments[1]. The return values are ordered and correspond to the function prototypes, which are easy to view for example with MATLAB® function libfunctionsview, header file or by following the instrument's function reference available in its user's guide. Using libfunctionsview has the added benefit of mapping data types to Matlab. Please refer to MatlabGxAoExample for examples on how to load, initialize variables and call library functions.
Note that when working with MATLAB® data types and especially when passing pointers, it is not uncommon to crash MATLAB® if not declaring the DLL function parameters properly, using for example libfunctionsview will help with this problem.
he example provided includes a modified header file, m -file as well as a published run of the script using GX1648 that is supported by the GXAO software package.

Summary

Calling Marvin Test Solution DLL functions used to control instruments from MATLAB® is fairly straightforward. MATLAB® loadlibrary and calllib functions and the DLL C header are used to perform this task.

References

[1]
Matlab provides functions loadlibrary and calllib to load and call library functions:

Mathworks:loadlibr

Mathworks:calllib

[2]
Reading library function signatures gives an easy way of initializing MATLAB® variables correctly. A GUI is provided for reading library functions signatures:

Mathworks:libfunctionsview

[3]
A MATLAB® example was written and published using the above knowledge and is available to download:

Example files
- MatlabGxAoExample.zip

Published run
- MatlabGxAoExample.pdf

[4]
MATLAB® external language interface for C libraries:

Mathworks:C Libraries in MATLAB

ATEasy Crash Analysis Tool - Published on 9/14/2022

9/14/2022

What is the ATEasy crash analysis tool?

The ATEasy Crash Analysis Tool replaces the default exception window generated by Windows when any application crashes. It is designed to provide the user with additional support when developing and debugging ATEasy applications. The ATEasy Exception Window created provides a snapshot of your information at the moment the exception was generated. It displays the exception as reported by Windows and a listing of the ATEasy procedure call stack organized by the user running threads. More information regarding the ATEasy internal libraries is logged to the Windows Application Events Log to be used for user bug tracking and application debugging by Marvin Test Solutions engineers.

The crash analysis tool is available in ATEasy version 8 and later.

The following window shows the generic exception as displayed by Windows when it traps the application exception:

The Windows Generic Exception Dialog

The following window shows the ATEasy Exception window:

The ATEasy Exception Dialog

Exit will close the ATEasy Exception window and the ATEasy application without saving any information.
Save... will prompt the user to select a file location to save the event log with ATEasy events including the currently reported error and other events related to the most recent ATEasy session.
Save All... will prompt the user to select a file location to save the event log with all ATEasy events currently in the Windows Event log including time-stamped exceptions that may have occurred in previous sessions.

If the Dump (.dmp) checkbox is checked, a dump file will be created and zipped. The zip file will be placed in the same directory as the event log created during a Save... or Save All... button press. The dump file contains a memory snapshot of the ATEasy or ATEasy application at the time of the crash.

The event file and dump file can be uploaded to a Magic incident for further analysis by Marvin Test Solutions engineers to debug and possibly fix the issue caused by the application or by internal ATEasy error.

Breakdown: What does the log information mean?

Sample Exception Log Window Information:

Unhandled exception at 0x1051b628 (Base address = 0xfdd0000) in C:\Program Files (x86)\Marvin Test Solutions\ATEasy\2021\ATEasy.exe : Memory access violation 0xc0000005
Thread (Current) Index=0, ID=0x4164, Handle=0x1430, UUT=-1
  ATEasy Call Stack
    ATEasyExceptionProcedure (Program=Language, Type=Procedure) Line 6
      Parameters
        astNested=??????
        al={0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
      Local Variables
        dw=0
      Internal PCode
        ...
  Internal Call Stack
    ...
Thread Index=1, ID=0x2464, Handle=0x0, UUT=-1
  ...
Thread Index=2, ID=0x940, Handle=0x0, UUT=-1
  ...
Thread Index=3, ID=0x46e4, Handle=0x0, UUT=-1
  ...

The Threads Call Stack tree view displays the following information:

Thread. The first line always displays the thread where the crash occurred. This could be a user thread running ATEasy code or a thread created by the ATEasy development environment or the ATEasy run-time. If your application is multi-threaded, additional user threads are also displayed at the time of the crash as top level items of the tree view.

Call Stack and PCODE. The items below each of the threads are the call stack followed by PCODE (pseudo code) information (only for the current thread). The current thread top item is the position in the code where the crash occurred. The position can be a procedure or test followed by a line number in the ATEasy code. For the current thread the next line shows the position in the PCODE followed by a PCODE memory dump of the procedure or test that caused the exception

Getting more information with the Windows Application Event Log

The ATEasy call stack will help you pinpoint where the error occurred. If you still require assistance with analyzing the crash, you can send Marvin Test Solutions the Windows Application Event Log filtered for ATEasy events from the Windows Events Viewer.

How to access the Windows Application Event Log for ATEasy events?

Open the Event Viewer application.

Navigate the tree view to Event Viewer | Applications and Service Logs | ATEasy

Each entry in the Event Log corresponds to a documented crash.

Saving the log

After clicking on an entry in the Event View, the Actions panel on the right will be updated with additional options, including "Save Log File As..." The Event Viewer allows you to save to a file with different file formats, select the the EVT log for Windows XP (EVTX for Windows Vista+) and submit to Marvin Test Solutions by uploading the file to your support incident.

The ATEasy Crash Analysis Tool.

What causes these exceptions?

ATEasy catches several common exceptions and attempts to notify the user without allowing the application to crash. This protection does not generally extend to external libraries such as DLLs, COM/ActiveX or .NET assemblies that are called by your ATEasy application. Common cause of these exceptions are:

Buffer Overrun: Error occurs when more data is given to an array than it was allocated. For example calling a DLL function passing in a string that was not sized properly prior to the call, than the DLL function write to the buffer and corrupts the memory which later on cause a crash when accessing the corrupted memory. Generally this shows as memory access violation (0xC0000005) but could also shows as unexpected behavior since memory is corrupted.

Buffer Not Allocated: Similar to buffer overrun, however the crash will show exactly the location of the problem. Usually memory access as well (0xC0000005). Most likely passing a NULL string to a DLL that does not check for that. The crash occurs when the DLL attempt to write to address 0.

DLL Parameter Mismatch: Parameter expected by DLL are not configured properly: wrong number of parameters or wrong data type.

Exception Thrown from an External Library: Exceptions generated from DLL/ActiveX or .NET will be passed up to ATEasy for reporting.

White Paper: Organizational Level Armament Test Reimagined - Published on 9/14/2022

9/14/2022

Armament testing is challenging, and problematic on good days, but when the aircraft and munitions advance exponentially faster than the test equipment it quickly becomes a daunting task. Challenges such as numerous testers to utilize and master, along with outdated test equipment, have taken a toll on many maintainers over the years, and prevent full realization of Agile Combat Employment (ACE).

Download this white paper to learn how innovative solutions such as the SmartCan have the potential to rewrite armament testing models, finally advancing the required test equipment into the digital era.

Download the white paper

Using HW PXI/PCI Explorer Applet - Published on 8/16/2022

8/16/2022

Introduction

The PXI/PCI Explorer is a PXI/PCI based VISA compatible resource manager control panel applet that provides the following features:

Compatible with VISA standard for PXI/PCI cards (see VISA, IVI Foundation for more information)
Generates or maintain VISA PXI configuration files: PXISys.ini, PXIeSYS.ini
Supports PXI specification's chassis, controller, and peripheral module ini files
Displays device resources: IRQ, DMA, Memory, IO
Displays device information: Slot, Device and Manufacturer ID, Alias
Supports name or numeric alias for devices
Allows dynamic scan of system devices (see Scanning a PXI system to learn about system resources)
Displays PCI bus, bridges, slots and more
Displays PXI slots with PXI symbols
Displays and provides a way to change the current VISA status, resource and PXI trigger manager

Notifies of available MTS software updates
Exports PC/PXI system information for MTS diagnostics/troubleshooting

PXI/PCI Explorer is provided with the MTS (Marvin Test Solutions) HW driver - Hardware Access Software package that provides the services:

Programming API used by instrument drivers to provide access to instrument configuration, memory, IO registers, DMA and interrupts resources
Access to PCI/PXI instruments PC PCI / PXI bus devices and resources such as memory, IO registers, DMA and interrupts
Windows device driver for PCI/PXI instruments. Supported Marvin Test Solutions instruments are listed in the HW.inf file

The MTS HW driver is included within all MTS software packages, including ATEasy and instrument drivers such as GxDmm, GxCnt, GtDio, etc. It is also available as a stand alone package.

To download the current HW software click here.

[:+[+ATEasy+]+:]

PXI/PCI Explorer

To open the Explorer application, click on the Windows Start button, Marvin Test Solutions, or double click on the desktop icon as shown below:

The MTS PXI/PCI Explorer contains three tabs: Slots, VISA and Status. The Slots tab displays the current hardware including chassis, buses, controllers and cards. The VISA tab displays the current installed version of VISA and allows the user to change the active resource and trigger managers. The Status tab contains a listing of the current PXI and PCI files needed to communicate with the installed hardware.

Slots Tab

The Slots tab displays the current hardware, including all found chassis, buses, controllers and cards. The tab page consists of a tree view that opens to display the PXI System, Chassis and Slots contained in the system. The following is an example of the Slots tab on a Gx7600 chassis using the Gx7944 embedded controller.

Figure 1: PXI/PCI Explorer Embedded Controller

PXI System Context Menu and Slots Tab Buttons

The PXI System Context Menu is available by right clicking on the PXI system and selecting the desired option as shown below. There are 4 Buttons on the PXI/PCI Explorer Slots Tab: Display Options, Reset Chassis List, Scan for New Devices and Save. In addition is an Identify Controller As pull down menu. These buttons and pull down menu provide an alternate selection method to the PXI System Context Menu and are described below,

Figure 2: PXI System Context Menu

Display Options: When selected brings up a list of options that can be selected to change the Slots page view. These devices include third party PXI devices as well as MTS devices, and any peripherals on the PCI bus. Any or all of these options can be selected. By default all PXI devices initially detected during panel startup are displayed.

Figure 3: HW Display Options

Reset Chassis List: When selected forces the PXI/PCI Explorer to re-scan the PXI / PCI bus and displays the current devices and or new chassis found in the system. Pressing this button can also trigger an alignment of the cards below a chassis.

Scan for New Devices: When selected forces the PXI/PCI Explorer to re-scan the bus for any new PXI or PCI devices, but does not check for a new chassis. If new cards have been installed in the chassis or a device driver was just installed and the card still displays PCI device, pressing Scan for New Devices will reload the device list to show the current names of the installed instruments.

Save: After making any changes to the PXI/PCI Explorer, when selected settings are saved to the PXISys.ini file. If the settings are not saved to the PXISys.ini file, devices may not initialize or function properly when used.

Identify Controller As: The Controller is normally identified when the PXI/PCI Explorer is scanned however if this is in error the controller type can be selected manually using the pull down menu.

Populated PXI/PXIe Slots

The Slots display information about the PXI/PXIe hardware found in the system. When expanded it displays the slot type, the current VISA status (If installed) and other board specific resources. This includes the slot number of the module, legacy slot, alias and folders that contain the current device and PXI settings. These resources can be displayed or in some cases edited as detailed below.

VISA Resource: The VISA resource is displayed along with its current status. The VISA resource number is comprised of the bus and device number of the module. In the case of the GX5295 installed in slot 9, the bus number is 4 and the device number is 12. The VISA resource name is normally used to initialize third party instruments that only support VISA however this name can also be used to initialize an MTS module using the MTS driver GxXXXInitialize function, where XXX is the mnemonic of the instrument such as DIO, CNT, DMM, etc. For example, Dio Initialize Master(1, 0, "PXI4::12::INSTR") initializes the GX5295 located in Slot 9. The VISA resource number is not editable.

nSlot: The nSlot number is comprised of the chassis (0x100) and the slot number (0x9). The value is displayed in hexadecimal. The nSlot number 0x109 indicates that the instrument is installed chassis 1 slot 9 and can be used to initialize the instrument using the MTS GxXXXInitialize function. The nSlot number is especially useful to initialize instruments in multiple chassis. For example, Dio Initialize Master(1,0x109) initializes the GX5295 located in chassis 1, Slot 9.The nSlot value is not editable.

Figure 4: HW Visa Resource and nSlot

Legacy nSlot: This number is by default the same as the nSlot number minus the chassis number (0x100) and is displayed in decimal. It can have a value of 2 - 255 or can be unassigned. This number provides a shortcut to initializing an instrument using only the Legacy slot number as apposed to using the nSlot number above, i.e. 9 instead of 0x109. For example, Dio Initialize Master(1,9) initializes the GX5295 located in slot 9. The Legacy nSlot number can be used to initialize any Marvin Test Solutions instruments using the MTS GxXXXInitialize function.

Since slot numbers are virtual constructs in PCI, it sometimes happens that when installing the instrument drivers, Windows resolves the slot number incorrectly. If this happens, the slot number can be edited by selecting the Legacy nSlot field and choosing the correct slot number from the combo box that appears below the buttons.

Using the Legacy nSlot number to initialize a module is also useful if an instrument is moved in the system causing the system configuration to change. Since the Legacy nSlot is virtual it can simply be remapped in PCI/PXI Explorer to match the existing test program and thus avoiding changes and or recertification.

Figure 5: Select Legacy nSlot

Alias: An Alias can be used to identify an instrument using a name without having to define the location of the instrument. To add or change the Alias name, select the Alias field and type the desired name into the text box that appears below the buttons of the Slots tab. For example two Alias names DUT1 and DUT2 are defined in PXI/PCI Explorer below to be used as an example to initialize two GX5295's without specifying a device slot or VISA resource name.

Figure 6: Using Alias Names in PXI/PCI Explorer

To use the Alias names in an application the HW driver must be installed along with all other instrument drivers. If using ATEasy the HW driver is automatically initialized. If using third party software tools the user must call HwOpen() to initialize the HW driver. After adding the GX5295 driver be sure to set the Skip On Init variable to 1 to skip automatic initialization of the instrument. The following ATEasy procedure can be used to initialize two GX5295's using Aliases "DUT1" and "DUT2" as defined in PXI/PCI Explorer detailed above:

ATEasy Procedure DioAliasInit(): Void
-------------------------------------------
  lSlot: Long
{
  !Using an PXI-PCI Explorer Alias to Initalize the GX5295
  !Use "Skip On Init" to disable automatic initialization of the GX5295

  !The following procedure uses the HW and GX5295 driver functions,
  !Long HwPciGetAliasChassisSlot(sAlias) Returns nSlot used by GXXXInitialize
  !Void InitializeMaster(nMasterNumber,nSlot,sVisaResource) Master board Init
  !Void HwOpen() is automatically called by ATEasy

  !Initialization for GX5295 Master 1
  lSlot = HW Pci Get AliasChassisSlot("DUT1")
  Dio Initialize Master(1,lSlot,"")

  !Initialization for GX5295 Master 2
  lSlot = HW Pci Get AliasChassisSlot("DUT2")
  Dio Initialize Master(2,lSlot,"")
}

For a detailed explanation of using Alias's to initialize MTS instrumentation refer to Knowledge Base article Using an Alias to address PXI instruments.

Device Settings: To view the Device Settings open the folder under the desired module. This folder displays the Bus, Device, Function, Device ID, Vendor ID and the memory allocated for the module. The information described in the Device Settings can be useful in finding specific modules in a chassis using the Device ID and the Vendor ID and the supplied HW driver.

The Device Settings can help to determine if the module has the correct resources allocated. For example, if no Memory is displayed, then the module was not allocated memory resources on system boot-up. In this case the device driver may need to be installed prior to installing the hardware to allow these resources to be allocated. A module may also have interrupts enabled, this would also be indicated in the Device Settings. The device settings are not editable.

Figure 7: Device Settings

The Device Settings can also be obtained programmatically using HW driver functions such as PciGetSlotDevice. The PciGetSlotDevice function can be used to not only provide information on all devices in a system but allow the user to write a driver using the information returned in the HWPCIDEVICE structure. The following is an ATEasy procedure that displays the Device Settings of all devices found in the chassis.

Procedure DisplayDeviceInfo(): Void
--------------------------------------------------------------------------------
lSlot: Long
nCntr: Short
stPciDevice: structHWPCIDEVICE
{
!DisplayDeviceInfo
!This example demonstrates using the HW driver library function HwPciGetSlotDevice
!to obtain PCI/PXI device configuration of each slot of a system. The variable
!stPciDevice is defined as a HWPCIDEVICE structure. The for-next loop prints
!the information found in each populated slot

Log.PlainText=True
ClearLog()

HW Initialize()             ! Must be called before any HW call
HW Pci AssignDeviceSlot()   ! Assign slots to all devices

for lSlot=0 to HW_MAX_SLOTS-1
    HW Pci Get SlotDevice(lSlot, stPciDevice) ! Get the device in the specified slot
    if stPciDevice.dwVendorId<>0              ! if populated slot, print the device info
       append "    Slot ";lSlot;" - Bus ";stPciDevice.dwBus;", Device ";\
              stPciDevice.stPciSn.dwAsUlong and 0x1F;\
              ", Function ";(stPciDevice.stPciSn.dwAsUlong shr 5) and 0x7
       append "     - VendorID 0x";ucase(str(stPciDevice.stPciCfg.wVendorId, 16));\
              ", SubVendorID 0x";ucase(Str(stPciDevice.stPciCfg.stType0.dwSubVendorID, 16))
       append "     - DeviceID 0x";ucase(str(stPciDevice.stPciCfg.wDeviceId, 16));\
              ", SubSystem 0x";ucase(Str(stPciDevice.stPciCfg.stType0.dwSubSystem, 16))

       for nCntr=0 to 7
           select stPciDevice.aResDesc[nCntr].ucType
           case 1
              append "     - Port:      0x";\
                     ucase(Str(stPciDevice.aResDesc[nCntr].Address1, 16));\
                     " Length 0x";ucase(str(stPciDevice.aResDesc[nCntr].Address3, 16))
           case 2
              append "     - Interrupt: 0x";\
                     ucase(Str(stPciDevice.aResDesc[nCntr].Address1, 16))
           case 3
              append "     - Memory:    0x";\
                     ucase(Str(stPciDevice.aResDesc[nCntr].Address1, 16));\
                     " Length 0x";ucase(str(stPciDevice.aResDesc[nCntr].Address3, 16))
           endselect
       next
    endif
next
}

For more information on using the HW driver PciGetSlotDevice function and the HWPCIDEVICE structure refer to HW.h and Hw.drv files included on your system. In addition refer to Knowledge Base articles Scanning a PXI system to learn about system resources) and What is HW driver?.

PXI Settings: To view the PXI Settings open the folder under the desired module. This folder displays the Bus, Device, Slot Path, Local Bus Left and Local Bus Right and any External Backplane Interface.

Figure 8: PXI Settings

VISA Tab

The VISA tab allows the user to view the current VISA status as well as display or control the Active Resource Manager and the PXI Default Trigger manager, as detailed below.

Figure 9: VISA Tab of PXI/PCI Explorer

VISA Status Displays the current status of VISA on the system. This includes whether it is installed, working properly and the current VISA version.

Active Resource Manager When using strictly 3rd party tools to control hardware it is recommended to select the 3rd party as the Active Resource Manager. When using Marvin Test Solutions software tools or 3rd party tools that are not listed in the drop-down menu it is recommended to select Marvin Test Solutions as the Active Resource Manager. This setting can be changed using the pull down menu to select the desired manager.

PXI Default Trigger Manager When using strictly 3rd party tools to control hardware it is recommended to select the 3rd party as the PXI Default Trigger Manager. When using Marvin Test Solutions software tools or 3rd party tools that are not listed in the drop-down menu it is recommended to select Marvin Test Solutions as the PXI Default Trigger Manager. This setting can be changed using the pull down menu to select the desired manager. If an application does not require triggering then this setting can be ignored.

Software Tab

The Software tab allows the user to see all registered MTS software as well as the currently installed and latest available software versions. The user can also access upgrade links and configure how often they would like to check for upgrades.

Figure 10: Software Tab of PXI/PCI Explorer

Marvin Test Solutions Installed Software
This grid displays the list of all software currently registered on this PC alongside the installed version.  The information is pulled from the local Windows registry.  The latest available software version is also displayed if the computer has access to the Internet.  If the latest version is newer than the current version, a link will be displayed which will open the default web browser and open the product's software page where the user can download a setup installer.

Check for Updates
This button checks immediately for updates and provides feedback in the form of a pop-up message.  PXI/PCI Explorer will check for updates once when the software is first launched and will perform automatic update checks if this feature is enabled.

Automatic update checking
If enabled, PXI/PCI Explorer will check for updates every X days as long as the PXI/PCI Explorer is open.  To facilitate this, clicking the X button on the PXI/PCI Explorer main form will close the window but the software will continue to run in the Windows notification area.

Status Tab

The Status tab displays the required PXI/PCI files. The files listed on this tab are used to provide communication to the hardware connected to the PXI, PXIe, PCI and PCIe slots instrumentation included in the system. An installation problem may exist if a named file is displayed and the file size and modified fields of that file name are empty. In that case it is recommended to reinstall the HW driver. The Status tab also displays the HW driver version number as well as the Driver / Service status.

Figure 11: Status Tab of PXI/PCI Explorer

Status Tab Buttons

There are 4 Buttons on the PXI/PCI Explorer status tab: About This PC, Device Manager, System Information, and Export Information as described below.

About This PC This button opens the About PC Windows settings page. This allows users to view and or edit Windows Security settings, Device settings and Windows Specifications.

Device Manager This button opens Windows Device Manager utility. This utility allows users to view and or edit the hardware connected to the computer. This utility will highlight specific nonfunctional hardware and allows the user to install the proper hardware drivers.

System Information This button opens Windows System Information utility. This utility allows users to view or edit advanced information about Hardware Resources, System Components and the Software Environment.

Export Information This button opens a 'Save File' dialog when the user can specify the location of a zip file. This file will be created and filled with system information generated by the Microsoft System Information tool as well as all information that is presenting within the PXI-PCI Explorer Utility. This zip file can be used to provide valuable diagnostic information to MTS customer support engineers when troubleshooting an issue with MTS hardware and software.

Notification Icon

When the PXI/PCI Explorer is closed by clicking the X button in the top-right corner, it will minimize to the Windows Notification area. From here, it can continue to perform periodic checks for software updates if this feature is enabled.

Figure 12: PXI/PCI Explorer Notification Icon and menu

When the notification icon is right clicked, a context menu will provide three options:

Open: Opens the PXI/PCI Explorer main form.

Update: Initiates an immediate update check, re-opens the PXI/PCI Explorer main form and switches to the software page.

Exit: Closes PXI/PCI Explorer. Automatic update checks will stop until the next time the application is launched.

Conclusion

PXI/PCI Explorer is an application that is used to view and modify PXI and PCI bus configurations. This application is also a tool to help users easily identify, troubleshoot and correct issues with the hardware in a system. For more information on the HW driver refer to Knowledge Base articles, Scanning a PXI system to learn about system resources), Using an Alias to address PXI instruments and What is HW driver?.

ATEasy Licensing Q&A - Published on 7/13/2022

7/13/2022

General

Q. What kind of licensing does ATEasy have?

A. ATEasy® has two types of licenses: Single-User and Network.

A Single-User license is installed on one computer and allows you to use ATEasy on that computer. A Network license is installed at a network server and allows users to work from any computer connected to that network, limited to the number of licenses that have been purchased (concurrent license).

Q. Can I distribute my ATEasy application?

A. Yes. ATEasy applications compiled to EXE file are Royalty-Free. You will have to install the ATEasy run-time on each machine that the executable will run.

Q. Will my license work with any version of ATEasy?

A. Licenses are purchased for a specific version of ATEasy only and will not work with newer versions of that product.

[:+[+ateasy+]+:]

Q. I installed a license for version 9.0. Can I use version 10.0 with that license?

A. No, You cannot. If you have an active subscription plan, You can request a license that will work with all the ATEasy versions including 10.0 and 9.0. Contact our support using Marvin Test Solutions website (M@GIC portal) and request a license upgrade.

Q. I bought a license for version 6.0. Can I use version 4.0 with that license?

A. Yes, You can. A license for specific version support ATEasy v3.0 and newer up to the version of the license purchased. For example if your network license server have a 7.0 license, client can run version 3.x-7.x.

Q. What does a one year subscription provide?

A. The one year subscription & support provide one full year of free technical support as well as one full year of free upgrades and unlimited access to ATEasy downloads. With subscriptions you will get a new license if an upgrade to the product is released during that year.

Q. If I did not buy a subscription and a new version has been released. Can I buy a subscription to upgrade my license?

A. You can renew your subscription if your subscription has expired less then two years ago. This renewal cost most than normal renewal. Check with our sales representative for special pricing .

Q. If I did not buy a subscription, can I still use ATEasy?

A. Yes, You can still use ATEasy with the version that you have purchased with no subscription.

Q. Can I buy an ATEasy upgrade if I did not renew my subscription?

A. No, upgrades are provided only for current subscribers. You will have to buy a new license. Please check with our sales representatives to learn how to renew your subscription.

Q. Can I use Single License or Network License on a VM (Virtual Machine)?

A. You can install ATEasy on a VM, Only Network license (as a client) can be used. Single license (software or USB based) will not work on a VM. Network License Server can be install on a VM provided it uses online activation and provides licenses to ATEasy clients. Running ATEasy on a VM have limited access to instruments; hardware and common instrument such as PXI cannot be controlled from a VM.

Single License

Q. What kind of single-user license is available for ATEasy?

A. ATEasy is offered with either a Hardware Key, or a Software Key License. Hardware licenses use a device that plugs into the computer's Parallel or USB port to provide the license. Software Licenses use a string of characters that are entered into the ATEasy License dialog box (located under the About ATEasy dialog). Software licenses can be activated on-line for computers that are connected to the internet or offline using a license string.

Q. Can I move the key or transfer the license from one machine to another?

A. Yes you can. Hardware keys can be moved from one computer to another by unplugging the device and plugging it into another computer. Software keys can be transferred to another machine (up to three times) by requesting a license transfer from Marvin Test Solutions (by requesting it using your M@GIC/support account). This process involves terminating the license (see Q200060) and installing a new license obtained from Marvin Test Solutions (see Q200089) .

Q. I've purchased several copies of single-user license. Can I buy subscriptions for part of my single-user licenses?

A. Yes you can. However, only the licenses with subscriptions can be upgraded when a new release is available as the upgrade is by serial number.

Network License

Q. What is the minimum number of licenses allowed with network license?

A. 3 or more. You cannot purchase a network license with one or two licenses.

Q. Can I buy subscription for part of my Network licenses?

A. No you cannot. Subscriptions for network licenses must be purchased for all licenses that are included in that network license.

ATEasy Drivers - Quick Guide to finding or creating an ATEasy Driver - Published on 7/8/2022

7/8/2022

Given an instrument, how do you find or create an ATEasy® driver for it? In this article we will cover the ways to find/create an ATEasy instrument driver.

The following diagrams present a quick guide for finding or creating an instrument driver. Follow the steps from top to bottom.

If the driver exists in the ATEasy Drivers folder or user forums - use it. Otherwise, look for a function panel (.fp file) driver using ATEasy Insert Function Panel driver command. The function panels that are imported conform to the Plug and Play Instrument standard or IVI-C standards .

Once you download it, it can can be automatically converted to an ATEasy driver using the ATEasy command: Insert, Import Function Panel. The import command creates a full driver including libraries (DLL function declarations), wrapper procedures to provide exception and error handling and handle hiding, and the driver commands used by the application to access and interface with the driver.

Function Panel drivers are also called VXI Plug and Play drivers; see https://ivifoundation.org/VXIPlug_Play/default.aspx for a description of these drivers. There are thousands of these around, including all of the NI LabWindows/CVI drivers. Here are some examples of websites from the instrument manufacturers or companies that publish these drivers that you can use:
- https://www.ni.com/docs/en-US/bundle/teststand/page/tsref/infotopics/plug_play_drivers.html
- https://www.keysight.com/us/en/lib/resources/miscellaneous/vxi-plug--play-drivers-1441449.html
- https://downloads.pickeringtest.info/downloads/drivers/Sys30/

If none of the drivers described in step 1 is available, create a driver from scratch. Three methods to create a driver can be used as shown in the diagram.

For the first method, if the instrument manufacturer published a library in one of these formats: Dynamic Link Library, ActiveX or .Net assembly, we insert the library under the driver Libraries sub-module. If you are inserting a DLL you will need to define the DLL functions or if you have C .h header file, you can import it. Next, you create ATEasy procedures to hide handles, provide error handling and offer easier initialization. Once the wrapper procedures are written, you can create commands and attach the procedure to these commands. The commands will serve as the main method for using your driver.

If the instruments use a standard interface (i.e. GPIB, COM, VXI or USB, TCP/IP/LXI), we create an IO Table to send or receive data from the instruments or we use the ATEasy internal library to communicate with the instruments. ATEasy offers a rich set of functions to communicate with these standard busses.

The third method will use the ATEasy internal library to write the procedures and the driver commands used to interface with the driver.

White Paper: 21st Century Test Equipment for 21st Century Maintainers - Published on 4/26/2022

4/26/2022

Agile Combat Employment (ACE) is a USAF operational concept that enhances warfighters’ resiliency and survivability through the use of a streamlined and reduced logistics footprint to support small, lethal, and survivable force packages via highly-maneuverable deployments.

Currently deployed O-Level armament test equipment is unable to test multiple aircraft with a single system — handheld or otherwise — limiting the successful execution of the ACE CONOPS.

Download this white paper to learn how the handheld SmartCan enables ACE, providing faster setup and test times, comprehensive test coverage, and data capture for predictive maintenance, replacing heavy big-box test sets with no compromise in performance.

Download the white paper

Integrating ATEasy with the WATS Manufacturing Intelligence platform - Published on 3/17/2022

3/17/2022

Eiger Design GmbH has developed an ATEasy® driver that provides an interface to the WATS Manufacturing Intelligence platform. The driver supports all of the ATEasy Test Types (eg MinMax, Tolerance, String etc) and has support for uploading graphs to WATS, as well as test results.

WATS gives access to all test and repair data collected during manufacturing. Through high level dashboards and reports you can drill into data to find root cause for failures. WATS is either hosted as a cloud instance or installed on premise. All reporting and analysis are done through your web browser but there are also APIs that you can use to programmatically interact with, for integrating with your own enterprise software solutions. Below is a typical dashboard showing yield and failures for your products:

Here is an example showing the actual measurements with limits during investigation of a failure:

The driver provides all the required setup and features needed to configure an ATEasy test and transfer data to WATS for further analysis. The driver requires very little code; in fact, in many cases, only two code lines are required as the driver heavily utilizes events to make all the required connections in the background. This will allow logging to be added quickly to existing programs.

A simple Initialization line configures the required WATS parameters such as ‘Process’, ‘Part Number’, ‘Revision’, ‘Serial Number’, etc for each set of Tests. In the example, this is called from the Test Program’s OnInit Event.

A second procedure call informs the WATS Driver about the test configuration. This can be called from either:

1. The Test Program’s OnInitTest Event – this case is used when the user sets ATEasy’s test using the Test Properties dialog.

2. The Test case itself – this case is used when the user defines test properties within the test code. The procedure must be called after the test properties have been set. This method is used in the provided example.

Screenshot from WATS showing data from supplied ATEasy example test program.

To download and test the driver visit: www.eigerdesign.com/wats

A prerequisite for testing the analysis platform is a WATS account, register for free here: https://register.wats.com/

Upgrading ATEasy USB License Key - Published on 1/19/2022

1/19/2022

In this example we will show how to upgrade to ATEasy 2021, however the same procedure applied to other versions.

To upgrade your USB License Token follow these steps :

Download and install the new ATEasy (e.g. ATEasy 2021 setup).

Ensure that the License key is plugged. The key driver should be installed and the Device Manager should show the token driver as shown here:

If not, install the key driver by running the Hardware key driver, run "C:\Program Files (x86)\Marvin Test Solutions\ATEasy\2021\HardwareKey\HardwareKeySetup.msi"-

Run the new ATEasy IDE (32 or 64-bit)

When ATEasy starts, it checks the license and if it find that the version in the key is older - it will Prompt to Upgrade as shown here:

If you don't get the above message, You are on a trial license or the hardware key driver was not installed. To change the trial license open ATEasy, Help, About, Click Set License... and select Hardware Key License from the License Type drop list and you should see the message.

Click Yes and enter the upgrade ID. The upgrade ID should show in your Magic portal licensing tab, If it does not and you are entitled for an upgrade (support and subscription is current), open a support incident and ask for an upgrade.

To confirm the upgrade, open the ATEasy About dialog from the Tools menu: the License type should show Hardware key License with the ATEasy SN (1) as shown here:

Your USB License Key is now ready to use with the new ATEasy.

Introduction to ATEasy 2021 - Published on 12/20/2021

12/20/2021

Summary

ATEasy 2021 (v11) contains numerous enhancements to the test development environment, run-time and Test Executive.

The following list describes the main changes in this version:

Revamped IDE user interface - New tabbed user interface to include improved layout, colored tabs, multi-tab panes, and improved sizing and docking.

64-bit support - additional 64-bit IDE and run-time, ability to mix 32 and 64-bit software components

Code Editor/Beautify Code/Auto Completion - Many, many improvements, including Syntax error highlight, Beautify code, auto completion improvements, improved informational tooltip and parameter suggestion and many more.

Compile/Build - show multiple compiler errors.

Cyber Security updates to enable developers customize the IDE and the test application comply with DOD Application Security and Development (ASD) and DISA Security Technical Implementation Guide (STIG). See KBase article for more information.

~100% backward compatible, with EXEs, DLLs compiled with older versions, and prior version source files, install side by side with your existing ATEasy version facilitates side by side test application migration

Detailed Changes and New Features

IDE Changes:

New tabbed documents interface with multiple panes instead of MDI child interface

Colored tabs, same base color per document type (blue - programs, yellow - systems, green - drivers).

Group same document tabs together and use same color.

Active Tab is displayed with x and bold/red title to close them directly.

Tabbed documents can be dragged and ordered.

Additional tab panes can be created to split the main window vertically by dragging the tab to the client area of the mainframe.

Document windows are always maximized in their tab pane.

Improved handling of sizing and docking, docking hints when dragging a window.

New menu/toolbar images

Large or small toolbar buttons size

New Theme selection

64-bit support:

New additional x64 version of IDE and run-time to create and run 64-bit Executables or DLLs.

Ability to mix call/use 32/64-bit DLLs/.Net/ActiveX from 32 or 64-bit target platforms using the revised library properties. .

One setup to install both IDEs (x86/x64) on x64 Windows.

Same driver or module can be used for 32/64-bit applications.

Code Editor:

Highlight all occurrences of variables/procedures/command items when placing the caret on one.

Highlight statement keywords when placing caret on opening keyword.

Highlight closing parentheses and array index bracket when placing the caret on open parentheses or array index bracket.

Description view always shows in green text color.

New option Show Syntax Errors to underline compiler errors while viewing or typing code.

Beautify Code and Auto Completion:

Beautify code while typing or scrolling or using the new Beautify Code command.

New Standard toolbar buttons to Beautify selection or enable/disable it.

Selection can be: selected text, procedure(s), test(s), form(s) and all the way to a whole project and its documents.

Fix statement indentation.

Indentation while typing using key.

Strip/append/leave space between operators.

Fix statements text case.

Fix variables, procedure and commands (in process) text case.

Auto complete statements using keys.

Improved and added colors to tooltip for functions and commands.

Selection can be: selected text, procedure(s), test(s), form(s) and all the way to a whole project and its documents.

Fix statement indentation.

Indentation while typing using key.

Strip/append/leave space between operators.

Fix statements text case.

Fix variables, procedure and commands (in process) text case.

Auto complete statements using keys.

Improved and added colors to tooltip for functions and commands.

Improved parameter suggestion and tooltip to show automatically when caret is placed after '(', ','.

New Go To Implementation command - can be invoked by right clicking on a command item, shows the procedure assigned to the command.

Compiler/Build:

Compiler now shows up to 200 errors instead of just one (new).

Build log clearly highlights compiler steps.

Workspace window:

New Folders or external files of any type can be inserted at workspace top level items.

New Reorder Alphabetically command used to reorder Variables, Types, Procedures, Forms, IO tables, DLL Types, Procedures and Constants.

Monitor window:

New Filters for Driver shortcuts, interface address in addition to interfaces filter.

New Save and Open commands to save the monitor window records to a file.

Options dialog:

Text Editor page:

Show Syntax Errors - new option to underline in red syntax errors (Default: checked).

Workspace page:

Theme Selection - Select from multiple available themes to customize the look of your IDE

Code Beautify options:

Statement Indentation - correct indentation of the current statement (when document is modified and the user uses up/down arrows or left click in the code (Default: checked)).

Smart Spacing - correct spacing of the current statement (when document is modified and the user uses up/down arrows or left click in the code) (Default: checked).

Complete Statement<(Ctrl+Enter> - when typing keys, insert a skeleton for the current statement (Default: checked).

Smart Indentation - when typing the enter key, indent the statement relative to the surrounding statement as needed (Default: checked).

Text Spacing: None, Strip, Append - add or remove a single space between assignment and other operators for consistency (default Strip)..

Correct Case: Statement, Symbols - correct the statement (lowercase), and symbols such as variables/procedures/commands text case to match the symbol definition.

Other page:

Notify Updates On Start - displays a message box when ATEasy starts if a version update is available (Default: checked).

Check Project Before Run - check for compiler error and parse the whole project before we start running (Default: checked).

Status Bar

New pane to show a red flag image in the status bar when a new version update is available, double clicking on the flag invokes the Check For Update command.

Compare Folders window:

Swap button used to swap the right and left folders path.

Faster files comparison using file size/modified time, and new command/option Compare File Content (default) to compare using file content if files size are the same.

Help menu:

ATEasy Web Page command.

Support Web Page command.

User Forums Web Page command.

Check for Updates... command - check web for version update. If a newer version is available; information about the current and newer version is displayed with an option to download the update setup.

Run-Time:

32 and 64-bit versions of run-time.

Load and use 32/64-bit DLLs/ActiveX/.Net (no controls) with 32/64-bit EXE or DLL.

APointer data type that is 32 or 64-bit size to match teh IDE/application 32 or-64
bit size

AForm.OnMove(): new event.

Pos(): New optional parameters to perform Reverse find and ignore case.

EnumConst(): New function to return enum constant name, description or value.

Licensing Updates:

License activation/termination/moving using MTS web service using user email, password and license serial number.

Allow using license server on a VM using MTS web licensing service.

Allow using ATEasy on a VM using MTS web licensing service.

Improve on premise licensing log.

Test Executive (TestExec.drv):

Reduced Test Executive overhead by x10.

New option to set how many runs when using Repeat Run.

New Option to set delay between runs when using Repeat Run.

SemiEasy.drv/STDF.drv (Semiconductor add-on for the test executive):

Support for STDF (Standard Test Data Format) file format for test log/results.

Commands to support software/hardware bins.

New test executive pane to display production yield, software and hardware bins.

Setup:

Installation folders:

\Program Files\Marvin Test Solutions\ATEasy\2021 for x86 Windows for 32-bit ATEasy and on x64 Windows for 64-bit ATEasy.
\Program Files (x86)\Marvin Test Solutions\ATEasy\2021 for 32-bit ATEasy running on x64 Windows.

No asking for installation folders or for program group.

No /TARGETDIR setup command line option.

Shared using symbolic links for Examples and Drivers folders since same driver/module can be used for 32/64-bit applications.

Windows Startup menu group now shows under: Marvin Test Solutions ATEasy 2021.

HW 4.9.8 included - see HW readme.txt for list of changes.

Compatibility and System Requirements

ATEasy 2021 is compatible with 32/64 bit Windows operating systems including Windows XP (SP3), Vista, Windows 7, 8, 8.1, 10, 11 and Windows Server 2003, 2008 (also R2) and 2012 (also R2). Windows 9x and Windows 2K are no longer supported. No special software or hardware is required beyond Windows requirements.

ATEasy 2021 is ~100% backward compatible with prior ATEasy versions, no change in ATEasy file format. Forward compatibility is provided for version 4.0-8.0 (unless new features are used). EXE and DLL compiled with older versions of ATEasy can be used with X run-time.

See the ATEasy ReadMe.txt for a complete list of all changes and new features included in this release.

ATEasy 2021 can be downloaded here.

How to obtain ATEasy Single License or a Trial License Extension - Published on 9/21/2021

9/21/2021

ATEasy® single license (GT800-SL) can be set up from the ATEasy License Setup dialog box. This dialog is displayed either when starting ATEasy with no license or trial license expired, or from the About ATEasy menu item under the Help menu.

If you do not have a license, you can activate a 30-day trial version of the ATEasy software.

The trial license contains full ATEasy functionality for 30 days. You are allowed one 30-day trial period on the computer on which you install ATEasy.

Follow these steps to setup an ATEasy Single license:

Install ATEasy using the ATEasy Setup program.

Start ATEasy.

Open the ATEasy License Setup dialog box.

Select Install Single License from the License Type list. An ATEasy Computer ID is displayed in the bottom field. The ATEasy Computer ID is used to identify the machine where the license is installed.

[:+[+ateasy+]+:]

|

With the ATEasy Computer ID and the ATEasy Serial Number (located on the outside of the CD case or on your purchase order), create a new support incident using your M@gic (www.marvintest.com/magic) user account to obtain a license string or file. You will need to paste both Serial Number and the ATEasy Computer ID to the incident. You can start using ATEasy by activating the trial version until you receive the license string or file.

Once you receive an email with the license string, open the ATEasy License Setup dialog box again.

Select Install Single License from the License Type list.

Type or paste in the ATEasy License String or select the license File. Click OK.

ATEasy Application Module Events Sequence - Published on 9/21/2021

9/21/2021

Solution:

The following list represents the sequence in which ATEasy application module events execute:

system: OnInit
drivers: OnInit (from start to end)
system: OnInitSystem
system: OnInitProgram
drivers: OnInitProgram
program: OnInit
system: OnInitTask
drivers: OnInitTask
program: OnInitTask
system: OnInitTest
drivers: OnInitTest
program:OnInitTest
program:OnEndTest
drivers: OnEndTest
system: OnEndTest
program:OnEndTask
drivers: OnEndTask
system: OnEndTask
program:OnEnd
drivers:OnEndProgram
system:OnEndProgram
system: OnEndSystem
drivers: OnEnd
system: OnEnd

[:+[+ateasy+]+:]

Note drivers are called : for InitXXX from top to bottom for EndXXX from bottom to start)

Abort Sequence:
system: OnAbort
program: OnAbort
drivers: OnAbort
system: OnAbort

Reset sequence: first call abort sequence if running that execute reset procedure than zero variables, then:
program: OnReset
drivers: OnReset
system: OnReset

Error sequence:
source module: OnError
program: OnError
drivers: OnError
system: OnError

See Also: ATEasy ModuleEvents.prj located in the ATEasy examples folder.

White Paper: Instrument, Hardware and Software Simulation in a Test System - Published on 9/21/2021

9/21/2021

The simulation requires running the application with a subset of instrumentation or without any instrumentation and with or without the Unit Under Test (UUT). In simulation mode some of the instruments or the UUT may not exist, which requires that the simulation environment filter and mask out errors as well as be able to return different values for various application states.

The simulation environment must also accommodate various data types including scalar, arrays, strings, structures, etc. Additionally, the simulation environment should not require modification of the application code; ideally the same code will run in the simulated or non-simulated environment.

The solution presented by this paper details the implementation of a simulation system that is created by enhancing the application run-time engine which is part of a commercial application development software environment (ATEasy®).

Download white paper

[:+[+ateasy+]+:]

DC Characterization of ICs Using PXI Instrumentation - Published on 9/21/2021

9/21/2021

DC Parametric Measurement Units (PMU), also known as Source Measure Units (SMU), can be used in one of two modes to perform dc characterization tests on the input and output lines of digital devices:

Method 1: Force voltage and measure current. With this method the PMU applies a constant voltage and using its on-board measurement capability it measures the current being drawn by the device/pin being tested. The voltage being supplied by the PMU can also be measured.

Method 2: Force current and measure voltage. With this method the parametric measurement unit either forces a constant current across a device or sinks a constant current from a device pin and then measures the resultant voltage. The PMU sink/source current also can be measured.

This article will demonstrate how DC parametric measurement units (PMU) can be used to perform DC characterization tests on digital devices. The tests described here can be conducted on a wide variety of digital devices from semiconductor IC's to printed circuit boards and can be performed using the built-in DC Parametric Measurement Unit (PMU) capability of the Marvin Test Solutions GX5295 Dynamic DIO cards. When operating in force voltage mode, the GX5295 PMU can supply a programmable constant voltage between -2V and +7Vdc. The PMU has eight current ranges that can be used for the Force Current or Measure Current modes.

[:+[+GX5295+]+:]

These ranges are:

-32mA to +32mA.

-8mA to +8mA.

-2mA to +2mA.

-512uA to +512uA.

-128uA to +128uA.

-32uA to +32uA.

-8uA to +8uA.

-2uA to +2uA.

More information on the GX5295 can be found on the Marvin Test Solutions website.

The following terms will explain some of the DUT parameters that can be measured using the PMU:

VIH: (Voltage Input High) The minimum positive voltage applied to the input which will be accepted by the device as a logic High.

VIL: (Voltage Input Low) The maximum positive voltage applied to the input which will be accepted by the device as a logic Low.

VOL: (Voltage Output Low) The maximum positive voltage from an output which the device considers will be accepted as the maximum positive Low level.

VOH: (Voltage Output High) The maximum positive voltage from an output which the device considers will be accepted as the minimum positive High level.

IIL: (Low Level Input Leakage) The input leakage current measured when the input is a logic Low.

IIH: (High Level Input Leakage) The input leakage current measured when the input is a logic High.

IOS(H): (High-level short-circuit output current) The short-circuit output current when the output is at a logic High

IOS(L): (Low-level short-circuit output current) The short-circuit output current when the output is at a logic Low

Output Voltage Level Testing (VOH, VOL, IOS)

Output Voltage Level tests are used to verify the operation of a digital output when used under its specified loading conditions. They can also be used to simulate a worst-case loading condition to observe how a DUT will perform when an output is loaded beyond its specified limit, for example when shorted to ground.

When performing these types of tests the test current range should be chosen to adequately test the output without damaging the device-under-test (DUT).

The following example shows how to perform a VOH test on a digital output. The purpose of this test is to ensure that the DUT can maintain an output voltage that is above the logic High threshold while supplying its maximum rated drive current.

In this test the PMU will be programmed to sink current from the DUT output, simulating a load condition.

[:+[+ateasy+]+:]

Figure 1 below shows how the DUT and GX5295 are connected. To perform this test the DUT is powered up. One GX5295 channel (Ch1 in this example) is used to apply an input logic level that forces the DUT output to a logic High. As GX5295 channels can be set to either digital or PMU mode on a per-pin basis the type of signal applied to the input (a logic High/Low or a constant voltage value) will depend on the DUT test strategy. A second GX5295 channel (Ch2 in this example) is set to PMU Force Current/Measure Voltage mode with an initial sink current value that will not damage the DUT output pin. The PMU is then used to force a sink current from the minimum to the maximum test values. At each test current value the DUT output voltage is measured to ensure it is within its specified voltage range for a logic High. The actual PMU test current can be measured also. These measured values can be used to generate an I-V Curve trace for possible fault-finding in the event of an output failure. The testing technique shown here can also be used for VOL and IOS testing.

Figure 1: VOH testing using the GX5295

The following GX5295 pseudo code (ATEasy) shows how VOH testing is performed on the circuit in Figure 1 above

/*
! Declare the following variables
short nMasterNumber  !The number of the master in the chassis. There may be multiple masters in a chassis
short nMasterHandle  !The handle of this master GX5295
short nSlot          !The slot where this master is located
short nDensity       !The amount of memory in MB on the card
short nBanks         !The number of banks on the card
short i
short nStatus        !Procedure return value
double dPmuCurrent   !PMU Current value
double dMeasV        !Voltage measured at the PMU pin
double dMeasI        !Current measured at the PMU pin
char sError[255]     !Used to store error string
*/

! Initialize variables
nMasterNumber = 1  !GX5295 is Master 1 in the PXI chassis
nSlot = 10         !It is located in slot 10
nDensity = 256     !There is 256MB of memory on the card
nBanks = 1         !One memory bank

!Initialize the GX5295
DioSetupInitialization(0, nMasterNumber, nSlot, nDensity, nBanks, nMasterHandle, nStatus)
if nStatus<0
   DioGetErrorString(nStatus, sError, 255)
   error nStatus, sError ! generate exception
endif

DioInitialize(nMasterNumber, nMasterHandle, nStatus)

!Set Logic High to 5.0V and a Low to 0.0V
DioSetupOutputVoltages(nMasterHandle, 1, 1, 5.0, 0.0, nStatus)

! Set channel 1 mode to output a logic High
DioSetupChannelMode(nMasterHandle, 1, 1, 3, nStatus)

! Set channel 2 mode to PMU Forced Current mode
DioSetupChannelMode(nMasterHandle, 2, 2, 4, nStatus)

for i=0 to 16
    dPmuCurrent = -0.25*i  !Run test in 0.25mA increments
    ! Set channels to sink dPmuCurrent and the current range to -8mA to +8mA.
    DioPmuSetupForcedCurrent(nMasterHandle, 2, 2, dPmuCurrent, 1, nStatus)
    !Allow time for the DUT output to settle
    Delay(200)

    ! Measure channel 2 output current using a 50rps measurement rate
    DioMeasure(nMasterHandle, 2, 4, dMeasI, 50, 0, 0, nStatus)

    ! Measure voltage at channel 2 using a 50rps measurement rate
    DioMeasure(nMasterHandle, 2, 5, dMeasI, 50, 0, 0, nStatus)
    print "Ch2 measured output current="+str(dMeasI)+" Measured Voltage = "+str(dMeasV)+"\n"
Next

DioReset(nMasterHandle, nStatus)

Input Leakage Testing (IIL, IIH)

Leakage current tests are performed by applying a constant voltage, in steps over a specified test voltage range, to the DUT input pin and measuring the input current at each step. As leakage currents are often in the uA range, the PMU should be set to its more sensitive current ranges to achieve more accurate measurements.

To perform an Input Leakage Test the DUT is powered up and the PMU pin is set to Force Voltage/ Measure Current Mode. At each input voltage setting the PMU measures the current being drawn by the input and then verifies the value against the DUT specification. The actual test voltage that the PMU is sourcing can be measured also.

The testing technique shown here can also be used for VIL and VIH testing.

Figure 1: Input Leakage testing using the GX5295 PMU capability

White Paper: PXI Based Flightline Test Sets - Published on 9/21/2021

9/21/2021

Abstract

In the past decade, PXI has proven to be a powerful and robust standard that is suitable for most Mil-Aero test applications. PXI-based testers are widely used today in engineering test stations, as production acceptance testers, environmental stress screening testers, as well as full-fledged Intermediate-Level and Depot-Level testers. A lesser known fact is the success of PXI for field and flight-line test applications.

This paper discusses several flightline and backshop test applications based on Commercial-Off-The-Shelf (COTS) PXI products. The applications include a Field Test Set for the Maverick missile system, a back-shop test set for the Alternate Mission Equipment (AME) for the F-35 Joint Strike Fighter (JSF), a back-shop armament test set for the TA-50 and FA-50 aircraft, and a portable test set for the C-130. These four testers are all based on an ultra-rugged COTS PXI platform - the MTS- 206 / 207 which has been successfully deployed since 2004 and has demonstrated the ability to operate reliably in any operational theater. The four testers demonstrate PXI’s viability as an ultra-rugged field and flight-line platform - offering performance and capabilities that were previously only achievable with custom electronics or MIL-SPEC VME products.

Download the complete white paper

[:+[+MTS-207+]+:]

How to set up and control an LXI instrument from ATEasy - Published on 9/21/2021

9/21/2021

ATEasy® can interface with a wide variety of software and hardware, allowing users to leverage a plethora of instrumentation and driver implementations from within their ATEasy applications.

One such interface is LXI which takes advantage of the speed, flexibility, and standardization of the Local Area Network and the TCP/IP protocol. ATEasy can communicate with network enabled instrumentation in one of the following ways:

Natively through IOTable based ATEasy drivers - An ATEasy driver can be created and its interface property set to WinSocket. This allows IOTable communication to be routed to the Local Area Netork via TCP/IP protocol.

By way of importing IVI-C .FP Function Panel files to automatically generate a fully featured ATEasy driver which calls a vendor supplied DLL

Using other type of software component (.NET, ActiveX, DLL, LabView, etc.)

This article will discuss the second option.

[:+[+ateasy+]+:]

ATEasy can communicate with LXI (and other interfaces such as VXI, GPIB, etc.) instrumentation through the use of IVI-C drivers and the IVI/VISA hardware abstraction layer. The following steps will allow a user to automatically create an ATEasy driver for a particular LXI instrument, install all applicable libraries for IVI/VISA, configure VISA to recognize the LXI instrument, and finally to configure the ATEasy driver to interface with VISA.

Use the following procedure:

Ensure that the VISA layer along with the IVI shared components (1.5+) are installed. The IVI shared components can be found at: IVI Foundation Shared Components

Find and install the LXI compliant IVI-C driver package. This is usually available on the vendor’s website. Alternatively, the IVI Foundation Driver Registry can be searched at IVI Driver Registry

Import the .FP file from the IVI-C driver package into ATEasy. From the ATEasy menu, select Insert | Import .FP file (.fp). Enter a default name for the driver and then click the Browse button to browse for the .fp file. The .fp file is usually located in the instrument specific folder located in C:\Program Files\IVI Foundation\IVI\Drivers\ You can specify %VXIPNPPATH% in the path field before cllicking on the browse button to use the IVI-C path variable. Also make sure to mark the Convert VISA Basic Types to ATEasy Types checkbox.

Make sure the new driver is inserted in the driver folder of the system module as shown below.

Start NI-MAX (Measurement & Automation Explorer) in order add the LXI instrument to the database.

Right click on Devices and Interfaces and select Create New…

Select VISA TCP/IP Resource and click Next.

Select Auto-Detect of LAN Instrument and click Next.

Select the LXI instrument from the list of scanned network devices and click Next.

Enter a descriptive alias. This alias will later be used in the ATEasy driver to address this particular instrument. Click Finish

The LXI device will now appear in NI-MAX under Devices and Interfaces. Device specific information will be shown including the IP Address and hostname.

In ATEasy, right click on the driver shortcut and select properties. Click on the Misc tab and enter the LXI instrument’s alias into the ResourceName field (the Change button must be clicked to store the value).

The new ATEasy driver can now be used to control the LXI instrument.

Using the Winsock (TCP/IP) ATEasy Driver Interface - Published on 9/21/2021

9/21/2021

The following walkthrough demonstrates the creation and configuration of a WinSock interface based ATEasy® driver for sending/receiving TCP/IP messages to a remote server. Typically the Winsock interface is used to control LXI instruments however in this article you will be connecting to a mail server and sending email messages to the server following the SMTP protocol to send an email.

It should be noted that there are easier ways to send an email programmatically than by using Winsock. This walkthrough is meant to demonstrate the use of ATEasy to perform the functions of a Telnet terminal automatically. For a simplier way to send an email through ATEasy, please look into using the .NET framework's System.Net.Mail namespace to send emails (DotNet.prj example).

This walkthrough mirrors a task that would normally be executed using a Telnet terminal (telnet.exe), as shown in the image below. Using ATEasy, you are able to simplify and automate Telnet communication.

[:+[+ateasy+]+:]

Step by Step Walkthrough

1. Create a new ATEasy application
2. Create New Driver and name it EMAIL
3. Open the properties editor and examine the Driver properties for EMAIL. Check the WinSock interface to enable it.

4. Click the Driver shortcut. Change the interface to WinSock and configure it to the target mail server. For this example, we will deliver the message through the domain GEOMAILSERVER on SMTP port 25.

5. We must now create several IOTables to handle the communication between your computer and the mail server:

Create the Hello IOTable as shown below. The Hello IOTable receives the server’s greeting message and initiates a dialog by introducing itself to the server.

Create the MailFrom IOTable as shown below. The MailFrom IOTable sends the email address of the sender of the email to the server. After receiving this, the server sends back an acknowledgement message.

Create the RcptTo IOTable as shown below. The RcptTo IOTable sends the email address of the intended recipient of the email to the server. After receiving this, the server sends back an acknowledgement.

Create the DataSend IOTable as shown below. The DataSend IOTable informs the server that you are ready to transfer a message and sends the email subject, header and body. Upon completion of transmission, the server sends back an acknowledgement that the message has been received and will be delivered.

Create the Disconnect IOTable as shown below. The Disconnect IOTable informs the server that you have finished and waits for the server to close the connection.

6. Once all the IOTables have been created, we want to create a procedure within the EMAIL driver to call all of our IOTables.  The procedure SendEmail is shown below.

7.  The final modification to the EMAIL driver will be the creation of a command for use in the other modules of your ATEASY project.  Insert a new command, rename it to Send and attach it to the EmailSend procedure.

Now that the driver is completed, we can use the Send() command in our Program module to send tests.  But we will need to open the Monitor window to observe the messages that are sent and received.  If it is not already open, hit the keyboard shortcut ALT+6 or use the menu bar View | Monitor to open it.  With the monitor window open, you are ready to send your email.

The parameters of the command are (Sender, Recipient, Subject, Message) so a proper command could be:

Email Send("ATE@awesome.com","victorb@geotestinc.com","EMAIL Driver Test", "This message was sent courtesy of ATEasy!")

The ATEasy Monitor Window shows the messages that are being sent and received:

And, of course, the final product (Microsoft Outlook):

Controlling a GX3500 FPGA Design Using Register Reads and Writes - Published on 9/21/2021

9/21/2021

Introduction

To understand how to access registers on the GX3500 FPGA instrument, it is necessary to have a design that utilizes registers.

This document is segmented into two sections; the first provides an overview of a 128 Channel Static I/O designed for the GX3500. It is assumed that the reader is already familiar with the process of creating designs for the GX3500 using the Altera Quartus II Design tools (refer to chapter 5 of the GX3500 User’s Guide: GXFPGA Tutorial and Examples).

The design is implemented as four 32-channel bi-directional ports and is double-buffered to support simultaneous updates on all 128 channel for both writing and reading logic states.

With a functioning FPGA design, the second section of the document describes how to load the design file into the GX3500 FPGA, how to connect the GX3500 I/O ports, and how to read and write registers within the FPGA design to facilitate operation of the static digital I/O.

[:+[+GX3500+]+:]

Design Overview

Address Decoding
The Gx3500 supports two types of PCI bus read and write operations; to registers using PCI Bar 1, and to RAM using PCI BAR 2. The static digital I/O design uses registers to control writing and reading the I/O ports, so will use the PCI BAR1 chip select signal for address decoding – which is synonymous with Chip Select 1 (CS[1]). The BAR 1 signal can access a 1024 byte address range (0x400), and access must be on a 4-byte alignment (256 DWords). Figure 1 shows the address decoding logic, using five address signals (Addr[6..2]), to provide 32 write enable signals (WE[31..0]) and 32 read enable signals(RE[31..0]). These signals are used with latched registers to write to the I/O ports (WE[x]) and read from the I/O ports (RE[x]).

Figure 1: Register Address Decoding

Port Control
There are four identical I/O ports (Figure 2), one for each 32 channels. Each port supports full bi-directional capability with per-channel direction control. The output registers are double-buffered. This allows for all four ports (128 channels) to be updated simultaneously. The first stage output data is written using the WE_Data signal, and the tristate control will be written using WE_Tristate. These signals will come from the WE[31..0] signals, and are unique for each port. The second output stage is written using the WE_UpdatePort signal. This signal will also come from the WE[31..0] signals, but is common to all ports in order to facilitate the simultaneous update of the I/O ports. There is read access to the data and tristate control registers for both stages of the output registers using RE_Tristatelatch, RE_DataLatch, RE_TristatePort and RE_DataPort.

Figure 2: Port Control Logic

All channels on all four ports (128 I/O channels) are sampled simultaneously using the RE_SamplePortIO signal, and the sampled data is stored in a latched register for later retrieval using the respective port’s RE_PortIO signal. Since each port tristate control register can be read, you can deduce whether the sampled input state was generated by the GX3500 or the UUT.

Register Mapping
The following is the read and write register offsets for controlling ports A – D:

Write Functions:
Offset	(Hex)	Function
0	(0x0)	WE[0]: Write data to Port A latch
4	(0x4)	WE[1]: Write data to Port B latch
8	(0x8)	WE[2]: Write data to Port C latch
12	(0xC)	WE[3]: Write data to Port D latch
16	(0x10)	WE[4]: Write tristate control to Port A latch
20	(0x14)	WE[5]: Write tristate control to Port B latch
24	(0x18)	WE[6]: Write tristate control to Port C latch
28	(0x1C)	WE[7]: Write tristate control to Port D latch
80	(0x50)	WE[20]: Simultaneous Update Port A – D
Read Functions:
Offset	(Hex)	Function
0	(0x0)	WE[0]: Read data from Port A latch
4	(0x4)	WE[1]: Read data from Port B latch
8	(0x8)	WE[2]: Read data from Port C latch
12	(0xC)	WE[3]: Read data from Port D latch
16	(0x10)	WE[4]: Read tristate control from Port A latch
20	(0x14)	WE[5]: Read tristate control from Port B latch
24	(0x18)	WE[6]: Read tristate control from Port C latch
28	(0x1C)	WE[7]: Read tristate control from Port D latch
32	(0x20)	WE[8]: Read data from Port A output
36	(0x24)	WE[9]: Read data from Port B output
40	(0x28)	WE[10]: Read data from Port C output
44	(0x2C)	WE[11]: Read data from Port D output
48	(0x30)	WE[12]: Read tristate control from Port A output
52	(0x34)	WE[13]: Read tristate control from Port B output
56	(0x38)	WE[14]: Read tristate control from Port C output
60	(0x3C)	WE[15]: Read tristate control from Port D output
64	(0x40)	WE[16]: Read sampled data from Port A input latch
68	(0x44)	WE[17]: Read sampled data from Port B input latch
72	(0x48)	WE[18]: Read sampled data from Port C input latch
76	(0x4C)	WE[19]: Read sampled data from Port D input latch
80	(0x50)	WE[20]: Simultaneous Sample Port A – D to input latch

Figure 3: Read/Write Control for Ports A, B, C and D

The GX3500 Static I/O design files and the SVF file can be downloaded from here.

Software Control

To control the GX3500 design, you simply initialize the instrument driver, load the Serial Vector File created when the FPGA design was compiled, and write and read the register locations used in the design.

The GX3500 API, distributed as a DLL, contains these and other function for accessing memory, enabling or bypassing the expansion board relays and an assortment of other miscellaneous functions. Refer to the GX3500 User’s Guide for a full list of the API functions and their calling convention.

Code for controlling the GX3500 FPGA Static IO is provided for three different programming environments; ATEasy®, “C” and LabView.

These examples assume the GX3500 is installed in slot 12 of a PXI chassis, that the SVF file produced using the Altera Quartus II design software is called “Static_IO.svf”, and that the SVF file is located in the same directory that the application program resides in.

[:+[+ateasy+]+:]

ATEasy Example (using the ATEasy GX3500 Driver)

dwData:DWord[4] ! Contains output state for 32-bit ports A- D
dwTristate:DWord[4] ! Contains tristate control for 32-bit ports A-D
dwInput:DWord[4] ! Contains data read from four latches A-D
i:Long ! Index counter

Driver Initialize (12) ! Initialize driver for instrument in slot #12
FPGA Load (".\\Static_IO.svf",TARGET_VOLATILE,MODE_SYNC) ! Load SVF file to volatile FPGA memory
FPGA Set ExpansionBoardBypass(0b1111) ! Set the expansion bypass – signals route from the FPGA to the connectors
For i=0 to 3 ! Repeat for port A - D
    FPGA Write Register(i*4,4,dwData[i]) ! Write to Data Latch WE[i]
    FPGA Write Register((i+4)*4,4,dwTristate[i]) ! Write to Tristate Latch WE[i+4]
Next
FPGA Write Register(80,4,0) ! Simultaneous Update all 128 I/O pins (tristate and data)
FPGA Read Register(80,4,dwData) ! Simultaneous Sample all 128 I/O pins
For i=0 to 3 ! Repeat for port A-D
    FPGA Read Register(i*4,4,dwInput[i]) ! Read sampled state from Latch RE[i]
Next

“C” Example

int    nHandle, nStatus, i;
DWord    dwData[4], dwTristate[4], dwInput[4];

GxFpgaInitialize (12, nHandle, nStatus);  \\ Initialize driver for instrument in slot #12
GxFpgaLoad (nHandle, 0, "Static_IO.svf" ,0,, pnStatus);  \\ Load SVF file to volatile FPGA memory
GxFpgaSetExpansionBoardBypass (nHandle , 0xF, pnStatus);  \\ Set the expansion bypass
for(i=0;i<4;i++){  \\ Repeat for port A - D
    GxFpgaWriteRegister (nHandle ,i*4, dwData[i], 4, nStatus);  \\ Write to Data Latch WE[i]
    GxFpgaWriteRegister (nHandle ,(i+4)*4, dwTristate[i], 4, nStatus);  \\ Write to Tristate Latch WE[i+4]
}
GxFpgaWriteRegister (nHandle ,80, 0, 4, nStatus);  \\ Simultaneous Update all 128 I/O pins (tristate and data)
GxFpgaReadRegister (nHandle, 80, dwInput[0], 4, nStatus);  \\ Simultaneous Sample all 128 I/O pins

for(i=0;i<4;i++){  \\ Repeat for port A - D
    GxFpgaReadRegister (nHandle, i*4, dwInput[i], 4, nStatus);  \\ Read sampled state from Latch RE[i]
}

LabView Example

Figure 4: LabView Example Control Panel

Figure 5: LabView Example Frame 0 Diagram

Figure 6: LabView Example Frame 1 Diagram

Figure 7: LabView Example Frame 2 Diagram

Figure 8: LabView Example Frame 3 Diagram

Figure 9: LabView Example Frame 4 Diagram

How to calculate the frequency measurement accuracy of the GTX22x0 series of Time Interval Counter PXI Cards - Published on 9/21/2021

9/21/2021

Many factors can effect the accuracy of frequency measurements taken on any instrument.

Main factors that effect accuracy are:

1) Signal noise
2) Instrument timebase accuracy
3) Gate time used to measure the signal
4) Calibration cycle

[:+[+GTX2200-Series+]+:]

The frequency measurement accuracy for the GTX2200 series can be found using the following formulas:

Slew Rate
Slew Rate (S_R) = 2 x PI x V_p x f where PI = 3.14159265 V_p = peak amplitude of the sine wave being measured (in volts) f = frequency of the signal being measured

Trigger Error
Error due to noise superimposed on the input signal from both internal and external sources E_n = rms noise of input signal (100MHz bandwidth)

Least Significant Digit (LSD)

Resolution (Hertz)

Accuracy (Hertz)

The following Excel file can be used to calculate the accuracy GTX22x0 Accuracy Spreadsheet .The values for Signal Frequency, Signal Noise (E_n), Measurement Gate Time and Instrument Timebase accuracy can be adjusted to observe the effects of these parameters on the overall measurement accuracy.

A Sample of ATEasy IDE Customizations - Published on 9/13/2021

9/13/2021

This article discusses some of the ways you can customize the ATEasy development environment to improve your programming experience. ATEasy lets you improve your development experience by providing the user with control of:

Test Log standardization

Modification of Variable prefix macros

Code Editor Fonts

Workspace Colors

Menus and Toolbars

External Tools

In this article, we are specifically examining menu / toolbar customization and workspace optimization.

[:+[+ateasy+]+:]

Add User-Defined Tools to the Menu

Many times, while developing an application using ATEasy, a developer will need to access additional applications outside of ATEasy. Examples of types of these applications can be software front panels for instruments, programmer resources such as a hex editor or calculator, or shortcuts to informational resources such as ATEasy forum. If an application is used repeatedly, it is best to create a menu item within ATEasy to open the external application with just one click.

Let's start with a simple example. Here is the process for adding a toolbar item to open the Calculator application:

In ATEasy, open the Customize dialog box by selecting from the menu bar: Tools | Customize...

Select the Tools tab from the Customize dialog box.

First click the New (Insert) button at the top of the Menu contents list box.

Enter the name Calculator in the newly created item.

Enter Calc.exe in the Command text box.

At this point, you can click the Test button to open the Calculator application. Additionally, you can close the Customize dialog box and select your newly created Calculator from the Tools menu.

User-created tools are assigned a 1-indexed designation based upon their position in the Menu contents list box. Notice from the above image that PXI/PCI Explorer is first on the list (Tool 1) and Calculator is second on the list (Tool 2).

Customize the Toolbar

Let's continue by adding the Calculator to the toolbar:

In ATEasy, open the Customize dialog box by selecting from the menu bar: Tools | Customize...

Select the Commands tab from the Customize dialog box

Select Tools from the Categories list

Click and drag Tool 2 to the toolbar

Assigning a Keyboard Shortcut to a Command

At this point, you can use the Calculator toolbar item. But we can further improve utility by adding a keyboard shortcut to the Calculator button that we just created.

Assigning a keyboard shortcut to a menu item:

Open the Customize dialog box by selecting from the menu bar: Tools | Customize...

Select the Keyboard tab from the Customize dialog box

Select Tools from the Category drop-down list

Select UserTool2 from the Commands list

Click the label field under Press New Short Key. At this point, the next thing you type will be entered as a shortcut key.

Press Ctrl Alt and C

Finally, click Assign

Using the New Tool Command

You can now access your user-created tool in three ways:

Select Calculator from the Tools menu

Click the Tool 2 button on the toolbar

Press Ctrl+Alt+C while the ATEasy IDE is in focus

Remember that within the custom tool creator, you can also program in hard coded arguments or you can prompt the user to enter arguments by enabling the Prompt for Arguments checkbox. In the following example, the called application is Internet Explorer and the argument is a website. When the user selects this menu item, an new browser window is opened to the MTS Forums for convenient discussion of ATEasy problems and solutions.

IDE Color Customization

The color of the toolbar and IDE can be customized to personalize your workspace. This customization is available in the Workspace tab of the Options dialog. Hue and saturation can be changed with the slider controls and the default color scheme can be restored by clicking the Reset button.

Customizing the Code/Description Views using the Options dialog, Text Editor page

To change the way code and descriptions are displayed, Select Tools | Options from the menu to open the Options dialog. Select the Text Editor tab to modify the way that your source code is displayed within ATEasy. The 'Face' drop-down list allows you to choose from any of your currently installed fixed-pitch or mono-spaced fonts. Font size can be increased for readability or reduced to optimize screen real estate.

In the Tabs group, you can also optimize screen real estate by modifying the Width value of Tabs. The default setting (4) sets each tab equal to 4 blank spaces. Source code can be made more compact by reducing the width value, while increasing the value makes the structure of your code more obvious and readable.

Changing Options settings such as the Tab Width does not modify the underlying ATEasy code. Changing the settings only alters the way that the code is displayed to the development computer's current ATEasy user. The source code remains the same. Because of this, several programmers can share the same ATEasy test application files without impacting other developers' user experience. Plus, the customization changes made will persist between ATEasy sessions.

Where to go from here

To learn more about customization of the IDE, use the ATEasy on-Line help to search for the following topics:

Customizing the IDE

Options (Tools Menu)

F-35 Armament Maintenance and Sustainment Test - Published on 9/13/2021

9/13/2021

The F-35 Lightning II is the latest 5th generation aircraft and is operating in ever-increasing numbers worldwide. With only a stray voltage / continuity O-Level test set employed in the current sustainment plan, maintainers will be unable to detect several of the MIL-STD-1760 bus failure conditions until actual weapons are located on the aircraft. In addition, they will lack O- and I-level troubleshooting capabilities for the F-35’s sophisticated armament and weapons as there is no other armament test system planned for use outside of the depot since the F-35 program only calls for a two level maintenance concept. Knowing that previous attempts to establish only two levels of armament maintenance for legacy 4th and 5th generation aircraft have not been successful, Marvin Test Solutions invested its own resources to be able to provide war fighting test enhancements if and when needed by F-35 operators.

Summary

Marvin Test Solutions’ highly successful, ultra-rugged MTS-235A F-35 production and depot level test set is proven and also suitable to deploy as the I-Level Armament Test Set if F-35 users elect to implement three levels of armament maintenance.

The MTS-235A Armament Test Set is ready and available today for immediate deployment.

Digital I/O Hardware Handshaking Using GX5280/GX5290 Series - Published on 9/13/2021

9/13/2021

Overview

Often, testing devices with digital interfaces requires the ability to wait for the device to respond to specific pattern sequences sent to it. This is especially true for devices that incorporate bus transfers that use hardware handshaking to synchronize the data transfer. The GX5280/GX5290 digital instruments family of cards provide sixteen external event inputs that can be used in support of this handshaking process. This article explains how to use the external events to perform synchronous Pause/Resume operations with the device under test (DUT).

External Events

The GX5280 and GX5290 digital IO instruments (DIO) provide sixteen external input signals that can be used to pause and trigger (resume) the digital pattern sequences. This ability to pause, and then resume pattern sequencing based on hardware signaling is essential for performing closed-loop handshaking of data transfers. Figure 1 below provides a functional block diagram of the external event control.

[:+[+GX5280+]+:]

Figure 1 - External Events Block Diagram

There are three pairs of registers that define how the external events can be used, labeled as the 'D' event', the 'T' event and the 'P' event.  Each register pair has a sixteen bit event pattern, and a sixteen bit event mask for ignoring unused bits - where a logic '1' enables an event input signal, and a logic '0' disables, or masks, the corresponding input.  Together, the event/mask combination defines a sixteen bit value that is passed to the pattern sequencer for evaluation.

The 'D' and 'T' events are used to trigger the pattern sequencer.  Triggers can be based on a single pattern match of the 'D' or 'T' event, or can be used in combination to define a trigger sequence that must be met in order to qualify as a valid trigger - as in a pre-trigger followed by the actual trigger.  The event order can be defined either as 'D' followed by 'T', or 'T' followed by 'D'.

The 'P' event will force the DIO sequencer to pause pattern execution when the defined event condition is met.

The DIOs do provide software commands that can pause and trigger pattern sequencing, but software control is not synchronized to the data flow, and typically cannot operate at speeds the DUT is capable of, or data transfer protocols require.  Control registers built into the instrument pattern sequencer can be used to pause execution at a specific vector, but the control register is only one state deep - meaning that without software intervention, only one pause command can exist in the entire pattern sequence.  Reprogramming the pause vector using software can be used to extend the one-shot pause command, but slows the handshaking process to what might be unacceptable timing.

Note: The GX5295 only provides eight external event inputs. Otherwise, the functionality described in this article applies to the GX5295. The GX5296 and GX5960 series instruments use a completely different architecture and are not covered in this article.

At-Speed Hardware Handshaking

Utilizing the external event inputs and unused IO pins on the DIO, at-speed hardware handshaking can be achieved. By connecting unused pin(s) from the J1 connector to the external event inputs on the J3 connector, you can program a hardware "pause" at virtually any vector, or any number of vectors in the full pattern length of the instrument - effectively turning the unused IO channels into additional pause commands. For example, if IO channel 30 (J1-P31) is connected to external event input signal 2 (J3-P3), then IO channel 30 becomes the pause control signal if the 'P' event is defined as Mask=0x0004, and Event=0x0004. Then any vector where IO channel 30 is programmed to a logic '1' will force the DIO into a paused state. Assuming the DIO is acting as the controller in a data transfer involving handshaking, programming a 'P' event at the vector(s) where the controller must wait for the DUT to acknowledge the data transfer forces the entire DIO domain (all IO channels) into a Paused-Waiting-For-Trigger state. Continue triggers can be generated via software, come from the external trigger input, be received from the PXI backplane, or come from using the same external events used to force the pause state.

If the DUT handshake response is also connected to external event inputs, say event signal 0 (J3-P1), and you elected to use the 'D" event to resume pattern sequencing, then you would define the 'D' event trigger as Mask=0x0001, and Event -0x0001. When the DIO is paused, a logic '1' on event input 0 will trigger the instrument and continue pattern execution.

What's The Catch?

There are some caveats to using external events:

Events are level sensitive, and are not generated by rising or falling edges

The pause is not immediate. It takes a minimum of 16 vectors to effect a pause. The maximum run-on depends on the pattern rate. Reasons for variations in the vector run-on are described below:

There is an approximately 350 nS propagation delay for pause events to be available to the pattern sequencing logic.

There is a 16-state stimulus/response pipeline that must be considered when using DIO loop-back for pause control.

Synchronous External Event Pause/Trig requires only 1 vector to initiate the pause.

Asynchronous External Event Pause/Trig requires a minimum of 2 vectors to initiate the pause.

A maximum of 8 vectors can be used for initiating a pause. The DIO pipeline will retain pause event states which could initiate a pause immediately after a continue trigger is received if the pause signal is applied across too many vectors.

At high data rates, ground bounce can cause false or intermittent Pause/Trigger operations as the bounce could exceed the vector period the instrument is running at.

The approximate 350 nS propagation delay and 16-state pipeline will delay pausing the DIO pattern from a minimum of 16, to a maximum of approximately 50 vector states. The patterns immediately following the pause signal should be programmed with static states so as not to vary the logic states presented to the DUT while waiting for the handshake acknowledge. The length of the run-on depends on the data rate of the DIO, for reason explained below.

Figure 2 - Low Data Rate Pause Timing

In Figure 2 above and Figure 3 below, the propagation delay (Tpd) is the same duration (~350 ns). Figure 3 has been stretched to better show the timing detail. You can see in Figure 2 that Tpd is less than 1 vector period, so its effect is contained in the first clock cycle after the pause signal. The pattern clock is slow enough that the effect of Tpd is hidden (contained) in the vector where the pause trigger is generated (blue clock cycle). So the pause run-on is affected only by the instrument pipeline, and the DIO pauses at 16 vectors after the pause event (red clock cycle).

Figure 3 - High Data Rate Pause Timing

In Figure 3, the vector clock is running much faster, and the same Tpd duration extends across multiple pattern clocks. During Tpd, pattern clocks (yellow clock cycles) have no effect in moving the pause trigger state through the instrument pipeline. So, in effect, the pause run-on is extended by the number of pattern clocks contained in the duration of Tpd - five clock cycles in the example. The vector in which the pause occurs is 21 vectors after the pause event (red clock cycle) - 16 vectors for the pipeline + 5 vectors for Tpd. If the DIO is running at 100 MHz (10 nS) period, an additional 35 clocks could occur during Tpd (350 nS / 10 nS period) - give or take. At high data rates, and due to minor variations in Tpd delays, there is some ambiguity concerning the exact vector where the pause will take effect, so the pipeline and Tpd run-on should be characterized for the data rate at which the test pattern will be run.

Examples of this are shown in Figure 4:1 - 4:6 below. Each image is a screen capture of the GtDio panel running the same test pattern. In each case, the pause signal was programmed at vector 5000. The only difference between the screen captures is the data rate at which the pattern was executed. Reviewing the highlighted fields of Figure 4:1 shows the pattern clock is running at 1 MHz. The period, 1 uS, is well above the Tpd value, so the pause takes effect at vector 5016. Subsequent figures show different pattern clocks, up to 100 MHz, and the resulting pause vector for each.

Figure 4 - Pause Vector at 1 MHz - 100MHz Data Rate

Conclusion

While the GX5280 and GX5290 Digital IO instruments provide pattern control using programmable registers and/or software commands, utilizing unused DIO resources can extend the functionality of the DIO instruments to support multiple pause/resume points across the entire depth of the UUT test pattern, or within multiple pattern sets that can be pre-loaded into the 64M vector DIO pattern memory.

[:+[+GX5290+]+:]

White Paper: Next Generation Armament Test - A Former USAF Armament Maintainer's Perspective - Published on 9/13/2021

9/13/2021

Armament test is challenging, problematic on good days, and incredibly daunting when aircraft and munitions advance faster than their associated test equipment. Innovative solutions such as the MTS-3060A SmartCan have the potential to rewrite the armament test paradigm by advancing test equipment into the digital era, revolutionizing the way units prepare and execute combat missions in the 21st century and providing next generation support to our warfighters.

Download the white paper

Passing an array from a .NET object to an ATEasy callback procedure - Published on 9/10/2021

9/10/2021

An ATEasy procedure can be used as a callback function when passed to an external library such as a .NET assembly or Windows DLL.

This article will describe how an ATEasy callback procedure can be made to accept an array parameter from a calling .NET object.

In this example, a simple .NET class called MyClass will be used to pass an array of bytes to an ATEasy procedure.

The MyClass constructor will accept one parameter of type MyCallback which is declared as a delegate accepting one parameter of type Object.

The following c# code describes this class:

[:+[+ateasy+]+:]

using System;
using System.Collections.Generic;
using System.Text;

namespace ArrayTest
{
   public class MyClass
   {
      public delegate void MyCallback(Object msg);

      private MyCallback m_callback;
      private byte[] m_data = new byte[3];

      public MyClass(MyCallback callback)
      {
         m_callback = callback;    // save the ATEasy procedure pointer
      }

      public void Test()
      {
         m_data[0] = 0;
         m_data[1] = 1;
         m_data[2] = 2;
         m_callback(m_data);    // call the ATEasy procedure with array
      }
   }
}

Using Object as the parameter type for the delegate, instead of an array, allows the .NET object to convert the passed in array to a Variant when invoking the ATEasy callback procedure.

The ATEasy callback procedure should be created as shown below. The only parameter should be of type Val Variant.

The procedure VarDimSize should be called to determine the number of elements contained within the data parameter.

Procedure MyCallback(data): Void
---------------------------------------------------------------------------
data: Val Variant
size: Long
{
    size = VarDimSize(data, 0)

    print "Received " + Format(size, "0") + " bytes"

    ! fails here since no data in array (index out of bounds)
    print "No Data Received"

}

Finally, the .NET class can be instantiated and invoked from ATEasy as follows:

tester = new ArrayTest.MyClass(MyCallback)
tester.Test()

Note that tester is of type ArrayTest.MyClass and MyCallback is the name of the ATEasy callback procedure.
Calling Test() will result in an array being filled by the .NET object, and passed to the ATEasy callback procedure.

Using Excel File to Load Test Parameters to an ATEasy Program - Published on 9/10/2021

9/10/2021

The article shows how to read Microsoft Excel file that has test parameters such as min, max values and to modify the program tests requirements dynamically.

The example reads a Microsoft Excel file and store the new parameters in the program test objects. Each row in the Excel file contains the test id (test to read the parameters to) , test min, test max and additional extra parameter that is loaded to the ATest.Tag property (access from the test using test.tag).

Using the Example

The code to read the Excel file and apply the parameters resides in the ExcelTestParameters.drv driver and it uses the ATEasy® EXCEL driver. To use the driver:
1. Insert the ExcelTestParameters.drv to your system
2. Insert the Excel.drv to your system
3. To load the parameters to your program use the following code:

if not EXCELTESTS ReadTestParametersFile("C:\\ExcelTestParameters.xlsx", "Sheet1")
abort
endif

this code typically can reside in Program.OnInit event.

Example Code

The ExcelTestParameters.drv export one command / procedure that is used to load the parameters:

Procedure ReadExcelTestParametersFile(sFile, sSheet): Bool
--------------------------------------------------------------------------------
    sFile: Val String
    sSheet: [Val] String = "Sheet1"
    xlwb: Excel.Workbook
    xls: Excel.Worksheet
    vrA: Variant
    vrB: Variant
    vrC: Variant
    vrD: Variant
    iRow: Long
    sRow: String
{
    EXCEL Initialize()
    ! open excel file
    try
        EXCEL File Open Existing(, sFile, xlwb)
    catch else
    endtry
    if not xlwb
        MsgBox("Unable to open Excel Workbook File: '"+sFile+"'")
        EXCEL Quit()
        return False
    endif

    ! verify the worksheet exist and get the object
    try
        xls=xlwb.Sheets.Item(sSheet)
    catch else
        MsgBox("Bad Excel Worksheet: '"+sSheet+"' found in File: '"+sFile+"'")
        EXCEL File Close(xlwb, False)
        EXCEL Quit()
        return False
    endtry

    ! read row B to empty row
    ! each row has columns: 1=testid, 2=min, 3=max, 4=parameters
    for iRow=2 to 9999
        sRow=str(iRow)
        EXCEL Get Value(xlwb, sSheet, "A"+sRow, vrA)
        if vrA=""
            exitloop ! last test
        endif

        EXCEL Get Value(xlwb, sSheet, "B"+sRow, vrB)
        EXCEL Get Value(xlwb, sSheet, "C"+sRow, vrC)
        EXCEL Get Value(xlwb, sSheet, "D"+sRow, vrD)
        try
            Program.Tests(vrA).Min=vrB
            Program.Tests(vrA).Max=vrC
            Program.Tests(vrA).Tag=vrD ! extra parameters
        catch else
            MsgBox("Bad Test ID: '"+vrA+"' found in Row: '"+sRow+"', in File: '"+sFile+"', Sheet: '"+sSheet+"'")
            EXCEL File Close(xlwb, False)
            EXCEL Quit()
            return False
        endtry
    next

    EXCEL File Close(xlwb, False)
    EXCEL Quit()
    return True
}

Running the Example

Running the example will open the ATEasy Test Executive with the new test parameters as specified in the spreadsheet:

How to Improve the Example

1. Use the program name as the sheet name; every sheet in the workbook can be used for one program.
2. Add support for other test type. Once the test is located the routine can check the test type and load parameters accordingly.
3. You can use the testid also for sequencing (similar to the profile driver)

Example Files

Download ATEasy ExeclTestParametrs project files

Programming I/O Width on the GX5290 Series - Published on 9/10/2021

9/10/2021

The GX5290 series of DIO cards have a programmable I/O width feature that allows the user to trade I/O channel width for vector memory depth. The GX5292, GX5292e, GX5293 and GX5295 cards each offer 256MB of vector memory and the GX5291 offers 128MB of vector memory. Under software control, the vector memory can be configured to support channel widths shown in the table below.

Vector Width	GX5292/GX5292e/GX5293/GX5295 Vector Depth	GX5291 Vector Depth	Corresponding DIO Channels
32 Ch	64Mbit/Ch	32Mbit/Ch	Ch0-31
16 Ch	128Mbit/ch	64Mbit/ch	Ch0-15
8 Ch	256Mbit/ch	128Mbit/ch	Ch0-7
4 Ch	512Mbit/ch	256Mbit/ch	Ch0-3
2 Ch	1Gbit/ch	512Mbit/ch	Ch0-1
1 Ch	2Gbit/ch	1Gbit/ch	Ch0

Additional information on this subject can be found in the GTDIO Programmers Reference Manual under the DIOWriteOutMemory() and DIOWriteDirectionMemory() functions.

Configuring DIO cards for vector widths of 4, 2 or 1

To utilize all of the vector memory when using vector widths of 4, 2 or 1 channel(s), the vector data needs to be packed into a DWORD array (32-bit boundary) before it can be transmitted. The vector data is packed into the DWORD array starting at the LSB of the first DWORD array element. For example, a vector array with the following 32 4-bit hexadecimal values starting at element 0 as shown here in this ATEasy example:

0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F,0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F

will be packed into the DWORD array called adwTxData[] starting at element 0, as follows:

adwTxData[0] = 0x76543210
adwTxData[1] = 0xFEDCBA98
adwTxData[2] = 0x76543210
adwTxData[3] = 0xFEDCBA98

From the above example, it is clear that the packing process is very straightforward and utilizes all available vector memory. To perform the packing function the programmer can use either the GX529x driver DioDataPack() function or can write a custom function to pack the data.

Direction control information will also need to be packed into a DWORD array in the same way as the transmit data array.

It is important to note that when writing the DWORD array to the DIO cards Output Memory (DioWriteOutMemory()) or to the Direction Control Memory (DioWriteDirectionMemory()) that the dwSize parameter is the number of vectors to transmit not the number of elements in the DWORD array.

For example, using the data from the above array the DioWriteOutMemory() and DioWriteDirectionMemory() functions will be as follows:

[:+[+gx5295+]+:]

DioWriteOutMemory(nMasterHandle,adwTxData,0, 32, nStatus)
DioWriteDirectionMemory(nMasterHandle, adwDirCtrl, 0, 32, nStatus)

Notice the dwSize parameter is 32 not 4.

Note: If the DIO card is receiving data, this data will be stored in the receive memory in a packed format in the same way the transmit data is packed above. To analyze the received data it can be unpacked from the DWORD format to its original width using the DioDataUnpack() function.

Configuring the DIO cards for vector widths of 8 and 16 channels

When using vector widths of 8 and 16 channels the transmit data and direction control data does not need to be packed as this process is done automatically by the DioWriteOutMemory() and DioWriteDirectionMemory() functions. The only requirements for using these widths are:
1) When using a vector width of 8 channels the vector data must be in a BYTE array and
2) When using a vector width of 16 channels the vector data must be in a WORD (16-bit) array.

Below are two examples showing how the data can be packed. Example 1 uses the DioDataPack() function and Example 2 uses standard compiler shift commands.

Example 1: Transmit a number of 4-bit elements previously stored in BYTE array called aucFileData[]. The number of elements to transmit is indicated by dwFileSize. This example assumes that the vector data is stored as one 4-bit vector per array element.

To pack the 4-bit data, 8 elements at a time are transferred to a temporary BYTE array (aucTemp[]) and then the DioDataPack() function is used to write the data to each element of the adwTxData[] DWORD array.

!Pack the 4-bit data into adwTxData[] (a DWORD (32-bit) array)
k=0
for i=0 to dwFileSize-1
   !Transfer 8 4-bit elements to be packed into a temporary array aucTemp[]
   for j=0 to 7 do
       aucTemp[j] = aucFileData[i]
        i=i+1
   next
  !Now pack the lower 4 bits of the first eight elements of the aucTemp[] array
  !into the adwTxData[] array starting at location 0. This is the data to be transmitted.
  DioDataPack(4, 8, 0, 1, adwTxData[k], aucTemp, nStatus)
  k=k+1
  !Undo the last increment from the above For {j} loop because For {i} loop will also increment i
  i=i-1
next

!Write the adwTxData array to the Output memory. Remember the dwSize parameter is the
!number of vectors to be transmitted not the number of elements in the adwTxData array.
DioWriteOutMemory(nMasterHandle,adwTxData,0, dwFileSize,nStatus)

Example 2: Transmit a number of n-bit wide elements (where n=4,2 or 1) previously stored in BYTE array called aucFileData[]. The number of elements to transmit is indicated by dwFileSize. This ATEasy example assumes that the vector data is stored as one vector per array element.

This example is written using standard compiler shift commands instead of using the DioDataPack() function. It uses the ATEasy GX529x driver commands but also expands on the above example by working with vector widths of 4, 2 or 1. First, the DIO instrument I/O configuration is read and based on the channel width value (nChWidth), the data mask (nMask) and number of channels (nNumCh) variables are assigned appropiate values. nMask is used to mask the unwanted vector data bits in each aucFileData[] array element and nNumCh is used to shift the data during the packing process.

!Get the DIO I/O Configuration information
DIO Get IOConfiguration(nMasterHandle, nChWidth, nDir)

!Set the nMask and nNumCh variables depending on the channel width
select nChWidth
  Case aChannelsWidth4  !Using a vector width of 4 Channels
      nMask = 0x0f  !Mask out upper 4 bits. In this example data is in lower 4 bits
      nNumCh = 4    !Number of DIO channels. Used to shift data for packing purposes
  Case aChannelsWidth2  !Using a vector width of 2 Channels
     nMask = 0x03   !Mask out upper 6 bits. Data is in the lower 2 bits
     nNumCh = 2     !Number of DIO channels. Used to shift data for packing purposes
  Case aChannelsWidth1  !Using a vector width of 1 Channel
     nMask = 0x01   !Mask out upper 7 bits. Data is in the LSB
     nNumCh = 1     !Number of DIO channels.
endselect

!Now pack the vector data into DWORD (32-bit) array called adwTxData[]
i=0  !Used to count through the vector data array dwFileData[]
k=0  !Used to count through the adwTxData[] as data gets packed
while i < dwFileSize
    j=0
    !Pack aucFileData[] elements into 32bit boundaries
    while j<(32 div nNumCh) and i < dwFileSize
      adwTxData[k]=adwTxData[k] or ((aucFileData[i] and nMask) shl (j*nNumCh))
      i=i+1 !Increment aucFileData[] counter
      j=j+1 !Increment while loop counter
    endwhile
    k=k+1   !Increment adwTxData[] counter
endwhile

!Write the adwTxData array to the Output memory. Remember the dwSize parameter is the
!number of vectors to be transmitted (dwFileSize) not the number of elements in the
!adwTxData array.
DIO Write Memory Out (nMasterHandle,adwTxData,0,dwFileSize)

Program examples

An ATEasy application that demonstrates how to setup a GX5295 DIO card for various vector widths can be downloaded by clicking on this link Q200226.zip. The application has three tests:

InitializeDIO. This initializes the GX5295.
4ChWidthDLL: This is example 1 above. This uses the GTDIO DLL commands to setup the card for a 4 channel vector width and to transmit a clock pattern on all four channels.
nChWidthATEasy: This is example 2 above. It uses the GX5295 ATEasy commands to setup the card for a 4 channel vector width and to transmit a clock pattern on all four channels. To change the configuration to output on two channels or only one channel, replace the aChannelsWidth4 parameter value in the configuration setup line.

[:+[+ateasy+]+:]

DIO Setup IOConfiguration(nMasterHandle,aChannelsWidth4, 0x0)

with aChannelsWidth2 for a two channel vector width or to aChannelsWidth1 for a single channel vector width.

Accessing ATEasy Internal Classes from other programming languages - Published on 9/10/2021

9/10/2021

ATEasy has many documented methods for accessing externally developed code and software.  DLLs, ActiveX objects, and .NET classes can be imported.  Command line utilities, VIs, and scripts can be run from within the ATEasy environment.

Should the need arise, ATEasy code can be exported to be used by other development environments.  ATEasy projects can be compiled to DLLs which can be linked within other languages.  Parameters described in a DLL procedure that are defined as ATEasy basic data types (Short, Long, Word, DWord, etc.) are easily passed and cast as a native type in the calling language.

The article Comparing C/C++, C#, VB and ATEasy Basic Data Types can be used as a reference for setting compatible basic data types.  But, ATEasy Internal classes such as ATest, ATask, and ALog can require a bit more work.  This article details the process using C++ and C#.

[:+[+ateasy+]+:]

IDispatch: Using the methods and properties of an ATEasy object

ATEasy objects and classes are ActiveX/COM objects. The COM IDispatch interface allows the programmer to access an object's property and method list at run-time. ATEasy reserved objects such as Program, System, and Test can be passed out of ATEasy and used using the IDispatch interface. The ATEasy object's members can subsequently be read and altered.

Example 1: Creating The DLL - C++

The DLL we are creating within Visual Studio will contain three exported functions:

ATEasyClassSet() : Set a value to the specified property of the referenced object.

ATEasyClassGet() : Get the value of the specified property of the referenced object.

ATEasyClassMethod() : Call a method of the referenced object.

The project created is a Win32 console application that will be compiled to DLL. The project code was created in Microsoft Visual Studio 2005 and entitled IDispatchExample. It is provided at the bottom of this article.The Microsoft knowledge base article (retrieved from web.archive.org) How To Use Visual C++ to Access DocumentProperties with Automation details the automation of Excel operations using the IDispatch interface. We will reuse the helper function Autowrap() included within that article. The Autowrap() function ensures that your request is formatted properly and provides some user notification in case of an error while performing the get, set or call. Each of the following three exported functions will make a call to Autowrap:

ATEasyClassSet(): Setting an object's property

//PURPOSE: Sets the specified value vtParam to the specified property, sProperty on the object pATEasyObject

void WINAPI ATEasyClassSet(IDispatch *pATEasyObject, LPOLESTR sProperty, VARIANT vtParam)
{
AutoWrap(DISPATCH_PROPERTYPUT, NULL, pATEasyObject, sProperty, 1, vtParam);
}

ATEasyClassGet(): Getting an object's property

//PURPOSE: Gets the value of the specified property, sProperty of the specified object pATEasyObject and returns it in the referenced variant pvtParam.

void WINAPI ATEasyClassGet(IDispatch *pATEasyObject, LPOLESTR sProperty, VARIANT *pvtParam)
{
AutoWrap(DISPATCH_PROPERTYGET, pvtParam, pATEasyObject, sProperty, 0);
}

ATEasyClassMethod(): Calling an object's method
C supports calling functions with a variable number of arguments. Autowrap() supports variable arguments because we will be utilizing objects which are undefined within the DLL. The ATEasyClassMethod() function will take 4 variants as parameters and then check to see if each variant has been defined before calling Autowrap() (you can define it with more optional parameter in ATEasy if you use more than 4 arguments). It is assumed that if a variant is undefined within ATEasy, it will be passed to the DLL with the variant type VT_ERROR.

//PURPOSE: Executes the specified object pATEasyObject's method sMethod.  This method supports 0 to 4 parameters.

void WINAPI ATEasyClassMethod(IDispatch *pATEasyObject, LPOLESTR sMethod, VARIANT vtParam1, VARIANT vtParam2, VARIANT vtParam3, VARIANT vtParam4)
{
   if (vtParam1.vt==VT_ERROR && vtParam1.lVal==VT_ERROR_ARGMISSING)
   {   AutoWrap(DISPATCH_METHOD, NULL, pATEasyObject, sMethod, 0);
      return;
   }
   if (vtParam2.vt==VT_ERROR && vtParam2.lVal==VT_ERROR_ARGMISSING)
   {   AutoWrap(DISPATCH_METHOD, NULL, pATEasyObject, sMethod, 1, vtParam1);
      return;
   }
   if (vtParam3.vt==VT_ERROR && vtParam3.lVal==VT_ERROR_ARGMISSING)
   {   AutoWrap(DISPATCH_METHOD, NULL, pATEasyObject, sMethod, 2, vtParam2, vtParam1);
      return;
   }
   if (vtParam4.vt==VT_ERROR && vtParam4.lVal==VT_ERROR_ARGMISSING)
   {   AutoWrap(DISPATCH_METHOD, NULL, pATEasyObject, sMethod, 3, vtParam3, vtParam2, vtParam1);
      return;
   }
   AutoWrap(DISPATCH_METHOD, NULL, pATEasyObject, sMethod, 4, vtParam4, vtParam3, vtParam2, vtParam1);
}

The specific error type with be "ArgMissing" which is defined as 0x80020004. In the header, this can be declared as follows:

#define VT_ERROR_ARGMISSING 0x80020004

Testing the DLL with ATEasy - C++

Now that the DLL has been created, we can create an ATEasy application to test it.

The first step is to define the DLL in ATEasy. The ATEasy Internal Class should be passed as a Val Object. The property or method specifier should be a Val BString and the parameter data should Val or Var Variant, depending on whether you are sending or retrieve data. I started by creating a new library within my program module called IDispatchExample and defining the DLL procedures as such:

Procedure ATEasyClassMethod(pATEasyObject, sMethod, vtParam1, vtParam2, vtParam3, vtParam4): Void
--------------------------------------------------------------------------------
   pATEasyObject: Val Object      !Specifies the ATEasy Object to access
   sMethod: Val BString           !Specifies the method to call
   vtParam1: [Val] Variant = VarEmpty ! Optional parameter 1
   vtParam2: [Val] Variant = VarEmpty ! Optional parameter 2
   vtParam3: [Val] Variant = VarEmpty ! Optional parameter 3
   vtParam4: [Val] Variant = VarEmpty ! Optional parameter 4

Procedure ATEasyClassGet(pATEasyObject, sProperty, pvtParam): Void
--------------------------------------------------------------------------------
   pATEasyObject: Val Object      !Specifies the ATEasy Object to access
   sProperty: Val BString         !Specifies the property to get the value of
   pvtParam: Var Variant          !The returned value

Procedure ATEasyClassSet(pATEasyObject, sProperty, vtParam): Void
--------------------------------------------------------------------------------
   pATEasyObject: Val Object      !Specifies the ATEasy Object to access
   sProperty: Val BString         !Specifies the property to set the value of
   vtParam: Val Variant           !The value to be set

For the ATEasyClassSet test, the TestResult is intentionally set outside the Min/Max bounds. The ATEasyClassSet procedure is used to set the Min/Max bounds to 40 and 50. We expect this test to PASS if the ATEasyClassSet procedure is working.

Test 1.1 : "Modified Test Properties"   ! ATEasyClassSet Test
-------------------------------------------------------------
Type = MinMax
Min = 5
Max = 5
{
   TestResult=42
   IDispatchExample.ATEasyClassSet(Test, "Max", 50)
   IDispatchExample.ATEasyClassSet(Test, "Min", 40)
}

For the ATEasyClassMethod test, the TestResult is set to 42 and the Min/Max bounds have been set to 40 and 50. Within the test Test.Min and Test.Max have been used to set the Min and Max bounds to 5 and 10. The procedure ATEasyClassMethod is used to call the Test Object's Reset method. This should return the Max/Min bounds to 40 and 50 and will cause this test to PASS.

Test 1.2 : "Reset Method Called"   ! ATEasyClassMethod Test
-------------------------------------------------------
Type = MinMax
Min = 40
Max = 50
{
   TestResult=42

   !Manually set the Test properties
   Test.Max=5
   Test.Min=10

   !Call reset method from DLL, returning Test Properties to design-time default
   IDispatchExample.ATEasyClassMethod(Test, "Reset")
}

The third test simply demonstrates the use of ATEasyClassMethod when a parameter has been provided. In this implementation, up to four parameters can be included with a method call. If this is working correctly, you should see the message "I am working!" appended to the end of this test.

Test 1.3 : "Log Append Called"  !ATEasyClassMethod w/ Param Test
----------------------------------------------------------------
Type = Other
{
   IDispatchExample.ATEasyClassMethod(Log, "Append", "\r\n///////////////////\r\n")
   IDispatchExample.ATEasyClassMethod(Log, "Append", "// I am working! //\r\n")
   IDispatchExample.ATEasyClassMethod(Log, "Append", "///////////////////\r\n")
   TestStatus=PASS
}

The fourth and final test retrieves the file location of the Log object natively and also uses ATEasyClassGet to retrieve the Log's FullName property externally. The two values are compared and, if they match, the test will PASS.

Test 1.4 : "Get Log Properties" !ATEasyClassGet Test
----------------------------------------------------
Type = String
String = ""
{
   !Retrieve the application's file and path natively
   Test.String=Log.FullName

   !Retrieve the application's file and path using IDispatch
   IDispatchExample.ATEasyClassGet(Log, "FullName", varTest)
   TestResult=varTest
}

Example 2: Creating The DLL - C#

The DLL we are creating within Visual Studio will contain three exported functions:

ATEasyTestSetMinMax() : Set the min and max properties of the referenced object.

ATEasyTaskGetTestCount() : Get the value of the TestsCount property of the referenced object.

ATEasyLogClear() : Call the Clear() method of the referenced object.

The project created is a Console Application (.NET 3.5 framework) that will be compiled to DLL. The project code was created in Microsoft Visual Studio 2008 and entitled ATEasyNetInterface. Make sure that you set the output of this project to Class Library. Change the default Class Name to Interface. Finally, add references to "C:\Windows\System32\AteRt.dll" and "C:\Windows\System32\AteCtl.dll". The project is provided at the bottom of this article.

ATEasyTestSetMinMax(): Sets a ATEasy test object's min and max properties

//PURPOSE: Sets the specified values iMin and iMax to the specified ATest object pExtObject

public void ATEasyTestSetMinMax(ref Object pExtObject, int iMin, int iMax)
{
   AteRtLib.ATest ATEasyObject = (AteRtLib.ATest)pExtObject;
   ATEasyObject.Min = iMin;
   ATEasyObject.Max = iMax;
}

ATEasyTaskGetTestCount(): Getting an object's property

//PURPOSE: Gets the value of the TestsCount property from the specified ATask object pExtObject and returns it in the reference parameter iTestCount.

public void ATEasyTaskGetTestCount(ref Object pExtObject, ref int iTestCount)
{
AteRtLib.ATask ATEasyObject = (AteRtLib.ATask)pExtObject;
iTestCount = ATEasyObject.TestsCount;
}

ATEasyLogClear(): Clear the log of the specified ALog file
The Clear() method that is being demonstrated does not require any parameters be passed in. When creating a method which requires one or more parameters, they will have to be passed in or hard-coded within this class.

//PURPOSE: Executes the specified ALog object pExtObject's Clear() method.

public void ATEasyLogClear(ref Object pExtObject)
{
AteCtlLib.ALog ATEasyObject = (AteCtlLib.ALog)pExtObject;
ATEasyObject.Clear();
}

Testing the DLL with ATEasy - C#

Now that the DLL has been created, we can create an ATEasy application to test it.

After creating the ATEasy Test Application, insert the .NET assembly that we just created (ATEasyNetInterface.dll) into the Program module. Also, include the mscorlib assembly. Then create these variables:

obNetInterface: ATEasyNetInterface.Interface
vExtObj: Variant
obNetObj: mscorlib.NetObject
lTestCount: Long

For the first test, the Log clear() method is called, which causing the application and program header to be erased from the Test Log.

Test 1.1 : "Call Method"
--------------------------------------------------------------------------------
  Id = Call_Method
  Type = MinMax
{
   !Create instance of .NET class
   obNetInterface=new ATEasyNetInterface.Interface()
   !Load Test object into variant
   vExtObj=Log
   !Load Test object variant into mscorlib.NetObject
   obNetObj=vExtObj
   !Send Test object to .Net DLL along with new properties
   obNetInterface.ATEasyLogClear(obNetObj)
}

For the second test, the TestResult is set to 42 and the Min/Max bounds have been set to 0 and 10. The call to ATEasyTestSetMinMax will return the Max/Min bounds to 40 and 50 and will cause this test to PASS.

Test 1.2 : "Set Properties"
--------------------------------------------------------------------------------
  Id = Set_Properties
  Type = MinMax
  Min = 0
  Max = 10
{
   !Set TestResult outside of the bound of the test so the test will fail if the Min/Max aren't changed
   TestResult=42
   !Create instance of .NET class
   obNetInterface=new ATEasyNetInterface.Interface()
   !Load Test object into variant
   vExtObj=Test
   !Load Test object variant into mscorlib.NetObject
   obNetObj=vExtObj
   !Send Test object to .Net DLL along with new properties
   obNetInterface.ATEasyTestSetMinMax(obNetObj, 40, 45)
}

The third test demonstrates the use of ATEasyTaskGetTestCount to retrieve a property of an ATEasy object.

Test 1.3 : "Get Property"
--------------------------------------------------------------------------------
  Id = Get_Property
  Type = Precise
  Value = 3
{
   !Create instance of .NET class
   obNetInterface=new ATEasyNetInterface.Interface()
   !Load Test object into variant
   vExtObj=Task
   !Load Test object variant into mscorlib.NetObject
   obNetObj=vExtObj
   !Send Test object to .Net DLL along with new properties
   obNetInterface.ATEasyTaskGetTestCount(obNetObj, lTestCount)
   TestResult=lTestCount
}

Applications

Integration of ATEasy and a scripting language.

Passing ATEasy objects out to be parsed externally.

Downloads

VS2005 C++ Project
ATEasy Test Workspace for C++ DLL
VS2010 C# Project
ATEasy Test Workspace for C# Assembly

How to Modify ATEasy HTML Test Log Tests Table - Published on 9/8/2021

9/8/2021

This article is a step by step walk-through on how to change TestExec's HTML output log using FormatLogString() and GetLogString().

In this example, a new column for a time stamp will be added for the MinMax and Other test types.

It is recommended to only make modifications to the System Module (as shown in this example) or to create another driver.

It is not recommended to modify the TestExec driver, that way you can update ATEasy to new versions without worrying about losing your changes or re-merging your work.

[:+[+ateasy+]+:]

Using FormatLogString to Change the Format of a Test Type

1. Insert the TestExec driver to your project.

Figure 1: Insert TestExec to your project.

2. In the System.OnEndTest() event use the GetLongString() procedure to find the original header and test strings.

Figure 2: GetLogString() in System.OnEndTest.

The HTML strings for the header and tests are traced to the Debug Log:

Figure 3: The header string for Min/Max tests.

Figure 4: A test string for a Min/Max test.

3. Both strings need to be modified to add a new column for the time stamp. In this example the new column was added to the front and named "Time". After the time-stamp column was added, the strings were assigned to variables sHeader and sTest in the System.OnInitTest() event.

Figure 5: The modified strings assigned to sHeader and sTest.

Note:

In this example the strings were separated into different lines for readability. Leaving the string as one line is also valid.
Put a backslash before each of the inner quotations to use quotation marks inside of a string declaration. Ie: sString="Bob said "hello" to Joe." becomes sString="Bob said \"hello\" to Joe."
In sTest, the procedure STime() is used to get the current time.
In sTest, FONT COLOR was removed from the Status field because ATEasy will add the color automatically when the test status is evaluated.
The data in the sTest string need to be replaced by the appropriate field parameters. For more information on the field parameters, use the ATEasy Help (F1) and search for "FormatLogString" in the Index tab.

4. In the System.OnInitTest() event use the FormatLogString() procedure to change the format of Min/Max tests. Be sure to use "atestTypeMinMax" as the input for the enTestType parameter to specify the Min/Max test.

The System.OnInitTest() event should look like Figure 6:

Figure 6: FormatLogString in System.OnInitTest().

5. Run the project in TestExec to see the new format for Min/Max tests.

Figure 8: TestExec with time stamps added to Min/Max tests.

Polish Before Moving On

6. Notice an issue with the test log; the Min/Max tests are repeating the header for every consecutive Min/Max test. This occurs because TestExec prints the header if a new header format is applied. We can accommodate this behavior by only applying the modified test header once per task.

To start we need to add a couple of variables. Since we have been making our time-stamp changes to the System Module, we will place these new variables into the System Module's Variables.

Variables
================================================================================
lPreviousTaskNumber: Long ! Keeps track of the most recent task number that was ran.
ucTestedTypesFlags: Byte ! Each bit keeps track on whether a test type's header had been applied.
! Bit / Test Type
! 0 / MinMax
! 1 / Other
! 2 / Ref2
! 3 / RefX
! 4 / Tolerance
! 5 / Precise
! 6 / String

Now we add some code to only apply the header once per task. To do this, our application first needs to check if the current test's task number is different than the previous. If it is different, reset our ucTestedTypesFlags variable.

For each test type, we check the bit in the ucTestedTypesFlags variable for each respective test type. If the new format had not been applied for this task yet, it will apply the new header and test log format at the same time (using aFormatLogDefault). Then set the test type's bit in the ucTestedTypesFlags variable to 1, signifying that we have applied the header for this test. Since we are currently working on the Min/Max test, the bit we want to check/raise will be bit 0 (we have decided this in the comments of the ucTestedTypesFlags variable). If the test header was already applied in the current task (respective test type bit in ucTestedTypesFlags is 1), then we can exclude the header and only apply the new test string format (using aFormatLogIgnoresHeaderParameter).

Finally, we want to record the current task number to the variable lPreviousTaskNumber. It will be used to compare with the next test's task number to determine if the flags variable ucTestedTypesFlags needs to be reset. Figure 7 shows the final result of the System.OnInitTest() event.

Figure 7: Only apply header once per task.

Now when we run the program we see that the header is correctly shown once for consecutive Min/Max tests. Figure 8 shows the test log after adding a time-stamp to Min/Max tests.

Figure 8: TestExec log with time-stamps for MinMax tests.

Repeat to Modify the Format of Another Test Type

7. Steps 2 through 6 can be repeated for another test type. Figure 9 below shows what the System.OnInitTest() event looks like after repeating steps 2 through 6 for the "Other" test type. Use "atestTypeOther" for the enTestType parameter in FormatLogString to specify the changes are for the test type "Other".

Figure 9: System.OnInitTest() event with Other test type modified.

Tests of type Min/Max and Other now have a time stamp column.

Figure 10: Tests of type Min/Max and Other have a time stamp column added.

Download

The project included below was completed to add the time-stamp column for all test types (MinMax, Other, Precise, Ref2, RefX, String, and Tolerance).
Click here to download the example project used in this article as a .ZIP.

White Paper: Target Simulators for Modern Munitions - Published on 9/8/2021

9/8/2021

Precision guided weapons with optical guidance systems have become the munition of choice for advanced militaries throughout the world in the past few decades and to ensure these weapons are mission ready, a variety of field test sets and target simulators have been deployed.

However, many of these test sets are now obsolete, not supportable, or extremely expensive to keep in service.

This white paper addresses the requirement for new test solutions that can replace these legacy test sets and target simulators as well as offering test commonality for supporting a wide range of weapon systems.

Download white paper

[:+[+MTS-916+]+:]

White Paper: Flightline Testing of Laser-Guided Munitions - Published on 9/8/2021

9/8/2021

Read the white paper, "Flightline Testing of Laser Guided Munitions," to learn more about the key features of the MT1888 Series including:

Lightweight, handheld design suitable for flightline, backshop, and depot testing

Eye-safe operation, no protective goggles required

Simulated returns from "laser painted" targets

Support of all U.S. laser-guided weapons

LCD screen and membrane switches select PRF and PIM laser code selection (MT1888A and MT1888A+)

Remote control option (MT1888A+)

Download white paper

Customizing the ATEasy Test Executive to Add Context Menus to Test Nodes - Published on 9/8/2021

9/8/2021

In the Test Executive ATEasy driver, the formTestExec creates the test tree view and the test nodes dynamically by reading data from the Program module (or Profile). The precise location of the node creation is with the driver procedure FillProgramTree(). To add a context menu to allow right-click operation of a node, we will need to create an AMenu of type Popup at design-time and display it at run-time. In addition, each item in the AMenu will need to have an associated event procedure attached, which can be accomplished using a generic function call and the currently selected node.

This project involves modifying the Test Executive driver which may be shared between multiple projects. Because of this, it may be prudent to make a backup copy of the TestExec.drv before proceeding.

Create a new popup menu at design-time

TestExec.drv includes several forms including the main Test Executive GUI class named formTestExec. This form already includes a populated menu bar, mnuTestExec, but we will be adding our own secondary menu which will be invisible until it is needed. To create the new pop-up menu:

Click on the AMenu Control icon from the Controls Toolbox. Click and drag anywhere within your formTestExec to add a new menu to the form. Rename this menu of Type bar to mnuContext.

Click on the entry and open the properties editor. By default, this entry is type Bar which means it will appear as a bar near the top of the form. Change the type to Popup, which means it will contain other menu items.

In the Properties window change the Name of the selected object to mnuPopup, change the Caption to My Popup, and uncheck the Visible property. This will allow us to hide the menu when it is not in use.

Select the menu that is contained within our mnuPopup and open the properties editor. By default, this menu is type Item which means it is a menu item intended to execute some function.

In the Properties window change the Name of the selected object to mnuHighlight, and change the Caption to Highlight Node.

[:+[+ateasy+]+:]

Next, add the code that will perform the highlight operation:

Double-click the Highlight Node menu item. This should take open mnuHighlight’s OnClick() function.

Add the following code:

f_node.BackColor=aclrYellow

The variable f_node does not exist yet, so create the form variable as follows:

f_node : MSComctlLib.Node

Display the popup menu when a user right-clicks a node

First, we will create an event to fire when the nodes are right-clicked. Since the Test Executive already makes use of a custom mouse-click event, we will add our code to that event. Go to the formTestExec’s procedures list and select OnTreeViewMouseUp(). This event fires each time a mouse button is released over the tree view. Add the following lines to the beginning of the procedure:
! If the user executed a right-click

If Button=aMouseButtonRight
    ! Add the toolbar offset to the y-location of the popup
    y=y+tbr.Height
    ! Display the context menu
    Form.PopupMenu(mnuPopup, aformPopupMenuRightButton, x, y)
EndIf

Leave the rest of the code in OnTreeViewMouseUp() alone.
Run the project and try right-clicking the nodes.

Download the modified TestExec here.

Logging ATEasy Test Results to a CSV file, Excel worksheet, or a Database - Published on 9/8/2021

9/8/2021

This article demonstrates, through a programming example, a method for the automatic logging of test results to a records based format. The techniques presented in this article can be adapted to work with any data storage mechanism. Specifically, the example creates, opens and appends test results to a local CSV file, an ADODB based database, an Excel file, or some combination of the preceding.

The code presented in this example resides in the AUTOLOG driver that is included with this article below.

Algorithm

The process for automatic test logging is as follows:

Create the log file

Log the test results as they are accumulated

Finalize the log file

[:+[+ateasy+]+:]

Create the log file

To ensure that a new record is created each time we run the test program, a new external log file is created in the OnInitProgram() event. In the example, we use three functions within OnInitProgram() to create three different logs: CreateNewCsvFile(), CreateNewExcelFile(), and CreateNewDBTable().

The purpose of creating the log before the tests are run is to both ensure that we are going to be able to save to the target location and to allow ourselves an opportunity to record any header data before the test data begins accumulating.

In the case of logging to a text file, a file needs to be created (storing the file handle in a global variable) and header information including the serial number, start time, program name is recorded. The log file will remain open for the duration of the program execution; we can append test results to the file using the file handle created. CSV is an example of a text file and CreateNewCsvFile() demonstrates this method behavior:

m_hCsv=FileCreate(sFilename)
FileWrite(m_hCsv, "Test Id,Test Name,Pin,Unit,Min,Result,Max,Status",,"\r\n")

Accumulating results

By the time the OnEndTest() event is called, the Test object will be updated with the latest test results. This is an ideal place to record the latest test results to the log file. In our example, we use three functions within OnEndTest() to append to the logs: AppendCsvResults(), AppendExcelResults(), AppendDBResults().

In the case of appending to a compliant ADODB, the record needs to be accessed and then a new record can be created and filled out. AppendDBResults demonstrates this method:

obRecordSet.Open("SELECT * FROM TestsResults", sConnection, ,adOpenDynamic)
obRecordSet.AddNew()

obRecordSet.Fields.Item("TestId").Value=Test.Id
...
obRecordSet.Fields.Item("Result").Value=Test.Resul
...
obRecordSet.Update()
t

Or Using EXCEL driver (AppendExcelResults()) :

EXCEL Set Value(m_xlWorkbook,,"A"+sCurrentExcelRow, Test.Id)
...
EXCEL Set Value(m_xlWorkbook,,"F"+sCurrentExcelRow, Test.Result)

Closing the log file

Depending of the record type that you are utilizing, you may need to perform some sort of termination procedure such as writing footers, closing file handles, and releasing objects that were instantiated during the creation phase of the algorithm. This is the complement to the Create- type procedures so it is appropriate to put it in to the OnEndProgram() event.

Using the Example

This example workspace attached to this article uses The AUTOLOG Driver Shortcut properties to enable/disable the logging. If the Driver Shortcut properties are empty, no automatic logging will be performed. By default, the properties should be entered as followed: If you like to use the logging in your application, include the AUTOLOG.drv in your project System.

DatabaseConn = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=c:\\MyLog"

ExcelFile = "C:\MyLog"

CsvFile = "C:\\MyLog"

Using these properties will create three files in the C:\ root directory: MyLog.mdb, MyLog.xls and MyLog.csv.

Figure 1. Microsoft Execl XLS File Output

Figure 2. Microsoft Access MDB Database File Output

Where to Go From Here

This example only allows you to log results from Min/Max test types. If the ability to update the properties of another test type were needed, the code in the various Create- and Append- procedures would need to be updated.

Download the AutoLogger Example Files: Click Here

Semiconductor Continuity Test Using the GX5295 Digital IO w/ PMU - Published on 9/5/2021

9/5/2021

Introduction

Prior to testing the functionality of a semiconductor device, it is often a requirement to verify the structural integrity of the device including connections from the tester to the device. DC Parametric Measurement Units (PMU's) which are used to perform dc characterization tests on a device by forcing a voltage and measuring a current, and by forcing a current and measuring a voltage. This same PMU can be used to verify the integrity of connections between the UUT and tester.

This article focuses on how the the per-pin PMU capabilities of the GX5295 can be used to perform continuity and shorts / opens tests on the device under test. The test programs are written in ATEasy, although any modern programming language could be used. All screen captures are of the ATEasy application. The tests described here can be conducted on a wide variety of devices, from semiconductor IC's to printed circuit boards, so the ATEasy application was written to allow easier migration to other devices.

[:+[+GX5295+]+:]

Continuity Test

The first step in the test process, and the focus of this article, is to determine if the Device Under Test (DUT) is connected to the tester resources – in this case the GX5295 Digital IO (DIO). This test is called a “Continuity” test, and it verifies continuity between the tester and DUT by detecting the ESD diode found on IC pins. Tester-to-DUT continuity is measured by forcing a small current on to the DUT pins, and measuring for the presence or absence of a voltage. This utilizes the Force Current, Measure Voltage (FIMV) capability of the GX5295’s PMU. The ESD protection diode is a semiconductor device, and the voltage developed across it when a current flows is consistent with the voltage drop across a semiconductor junction. If the ESD diode is not present, or in the case of continuity tests, if the tester is not connected to the DUT pin, current will not flow through the ESD diode and the voltage will be inconsistent with semiconductor junction voltage drops. If the ESD diode is defective, then other voltage anomalies can be detected, such as “0” volts measured across an ESD diode in cases where the diode is shorted.

Pin Mapping

Before any test or measurement can be performed, you must define the system configuration. An ATEasy "Command" was created that allows the test programmer to define the number of DUT's (Device Under Test) installed in the test fixture, and their pin counts. For additional information about defining commands in ATEasy, refer to the ATEasy Help/Commands on-line documentation. It is assumed that all of the DUT's are of the same type device. The command specifys the number of DUT devices to test (nCount), and the number of pins per DUT (nPins), takes the form:

Dut Define Counts(nCount, nPins)

In order to force currents and measure voltages on DUT pins, it is necessary to define in software the connections between the tester resources and the DUT IO. In this example, pin mapping is performed using another special command defined in ATEasy that will store the “Tester-Channel to DUT-Pin” correlation in a structured array. The pin-map structure also holds the DUT pin name and pin type (Output, Input, IO, Vcc1:4 and Ground) - which is useful for providing information about the pins being tested. When used, the “Dut Define PinMap” command specifies the DUT pin_type, the DUT pin_name, the DUT pin_number, and an array containing the DIO channel numbers channel_number. An array is used for the DIO channel numbers to support mapping pins from multiple DUT devices to appropriate DIO channels.

[:+[+dioeasy+]+:]

The command takes the form:

Dut Define PinMap pin_type ("pin_name", pin_number, channel_number[])

The sample device used is an SN74HC273 octal latch in a 20-pin TSSOP package. The commands for defining the number of DUT devices, the DUT pin count, and the DUT/DIO pin mapping are shown below.

Note: The DIO channel array is defined in line with the pin mapping commands for clarity, but could be entered via oteher means, such as reading from a file or spreadsheet, or by entering the channel numbers from a dedicated GUI, to mention a few:

Dut Define Counts(1,20)

Dut.DioChannels={0}
Dut Define PinMap Input ("Clr-", 1, Dut.DioChannels)
Dut.DioChannels={1}
Dut Define PinMap Output ("Q1"  , 2, Dut.DioChannels)
Dut.DioChannels={2}
Dut Define PinMap Input ("D1"  , 3, Dut.DioChannels)
Dut.DioChannels={7}
Dut Define PinMap Input ("D2"  , 4, Dut.DioChannels)
Dut.DioChannels={4}
Dut Define PinMap Output ("Q2"  , 5, Dut.DioChannels)
Dut.DioChannels={5}
Dut Define PinMap Output ("Q3"  , 6, Dut.DioChannels)
Dut.DioChannels={6}
Dut Define PinMap Input ("D3"  , 7, Dut.DioChannels)
Dut.DioChannels={3}
Dut Define PinMap Input ("D4"  , 8, Dut.DioChannels)
Dut.DioChannels={8}
Dut Define PinMap Output ("Q4"  , 9, Dut.DioChannels)
Dut.DioChannels={-1}
Dut Define PinMap Ground ("Gnd" ,10, Dut.DioChannels)
Dut.DioChannels={17}
Dut Define PinMap Input  ("Clk+",11, Dut.DioChannels)
Dut.DioChannels={15}
Dut Define PinMap Output ("Q5"  ,12, Dut.DioChannels)
Dut.DioChannels={10}
Dut Define PinMap Input  ("D5"  ,13, Dut.DioChannels)
Dut.DioChannels={13}
Dut Define PinMap Input  ("D6"  ,14, Dut.DioChannels)
Dut.DioChannels={12}
Dut Define PinMap Output ("Q6"  ,15, Dut.DioChannels)
Dut.DioChannels={11}
Dut Define PinMap Output ("Q7"  ,16, Dut.DioChannels)
Dut.DioChannels={14}
Dut Define PinMap Input  ("D7"  ,17, Dut.DioChannels)
Dut.DioChannels={9}
Dut Define PinMap Input  ("D8"  ,18, Dut.DioChannels)
Dut.DioChannels={16}
Dut Define PinMap Output ("Q8"  ,19, Dut.DioChannels)
Dut.DioChannels={1000}
Dut Define PinMap Vcc1   ("Vcc" ,20, Dut.DioChannels)

Note: Two special pin mapping parameters need to be mentioned. First, the "-1" DIO channel specified for the DUT "Gnd" signal indicates that this DUT pin is not mapped to any DIO channel. In this case, this is due to the layout of the DUT load board, which connected the DUT Gnd pin to a ground plane, rather than a DIO channel. Second, specifying DIO channel "1000" for the DUT "+5V" Vcc pin means the Vcc pin is connected to one of the four auxilliary IO pins on the GX5295. These "Aux" channels are mapped to DIO channels starting at 1000. Specifying DIO channel 1000 as the DUT Vcc input means that the GX5295 AUX 0 channel will be supplying the Vcc voltage for the DUT.

Continuity Measurement

To test for continuity, another ATEasy command has been defined. This command accepts the DUT number and the DUT pin. The DUT pin is a type Variant and can accept the DUT name, as defined by the pin mapping command, the DUT pin number as a text parameter, or the DUT pin number as a numeric parameter. Two other parameters are passed by reference (pointer) and return the DUT pin number and DUT pin name associated with the DUT pin Variant. The command returns a type Double voltage measurement for the specified pin after a small negative current is first applied to the pin. The command takes the form:

dMeasurement = Dut PMU Measure Continuity (nDutNumber, varDutPin, pnDutPin, psDutPin)

As an object oriented programming language, ATEasy allow a unique name for each test defined in it’s Task/Test structure (see ATEasy Help/Test). The test name is accessible as a text string at run-time using the "Test" object variable and the “Name” property, as shown below:

string = Test.Name

This simplifies the overall test program to simply calling the Dut PMU Measure Continuity() command using Test.Name, and defining the Test.Name to be either the DUT pin name, or the DUT pin number. The example below measures continuity on the DUT pin defined by the test name, and using ATEasy’s internally defined TestResult variable to store the continuity measurement. The continuity measurements can all be invoked the same for each test:

TestResult=Dut PMU Measure Continuity (1, Test.Name, pnDutPin, psDutPin)

An example of the ATEasy Task/Test structure is shown in figure 1 below. Notice that each test name is unique and the same as the names used in the pin mapping commands from above. Notice also that each test provides the minimum and maximum voltages for determining the Pass/Fail status of the continuity test (Min/Max parameters are visible just above the highlighted command). ATEasy will automatically evaluate the measurement returned to TestResult against the Min/Max parameters to determine the Pass/Fail status of each continuity measurement, and will automatically report the results of the evaluation to the Test Log (standard output) or Test Executive (ATEasy’s Test Management driver utility).

Figure 1: Continuity Task/Test Structure and Test Command

The Test PMU Measure Command is attached to a procedure call where the continuity measurement occurs. The procedure, TestContinuity, is located in a driver called DUT, as are the commands discussed in this article. The procedure calls another procedure, _GetPinInfo, which searches the structure array for the name or number of the DUT Variant pin passed in by the command, and when found, extracts the DUT pin number and DIO channel number associated with that pin. The code for _GetPinInfo is shown below:

Procedure _GetPinInfo(nDutNumber, varDutPin, nDioPin, pnDutPin, psDutPin): Void
--------------------------------------------------------------------------------
nDutNumber: Val Short          !DUT device number
varDutPin: Val Variant         !DUT Pin ("Name", "Number" or valNumber)
nDioPin: Var Short             !DIO Channel number
pnDutPin: Var Short            !Returned DUT pin number
psDutPin: Var String           !Returned DUT pin name
nHandle: Short                 !DIO handle
iPin: Long                     !Pin index counter

{
! Get the DIO session handle
   Dio Get MasterHandle(nHandle)

   If VarType(varDutPin)=vtBstr
   ! The procedure searches the structure array for the "name"
   ! or "number" of the DUT pin passed in by the command,...
      For iPin=0 to m_nDutCount[1]-1
         !  and when "name" is found...
         If LCase(m_astDomain[nDutNumber-1,iPin].Name)=LCase(varDutPin)
            ! the DUT pin number is saved, ...
            pnDutPin=iPin+1
            ! the DUT pin name is saved, ...
            psDutPin=m_astDomain[nDutNumber-1,iPin].Name
            ! the DIO channel number is used for the measurement process
            nDioPin=m_astDomain[nDutNumber-1,iPin].DIO
            ExitLoop ! exit the loop
         ! or when "number" is found...
         ElseIf Val(varDutPin)=(iPin+1)
            ! the DUT pin number is saved, ...
            pnDutPin=iPin+1
            ! the DUT pin name is saved, ...
            psDutPin=m_astDomain[nDutNumber-1,iPin].Name
            ! the DIO channel number is used for the measurement process
            nDioPin=m_astDomain[nDutNumber-1,iPin].DIO
            ExitLoop ! exit the loop
         EndIf
      Next

      ! If the DUT pin "name/number" was not found...
      If iPin=m_nDutCount[1]
         ! generate an error exception and return
         Error 1,"DUT pin name/number \""+varDutPin+"\" not found"
         Return
      EndIf
   Else
      pnDutPin=varDutPin
      ! If the DUT pin number exceeds it's limits...
      If pnDutPin<1 or pnDutPin>m_nDutCount[1]
         ! generate an error exception and return
         Error 1,"DUT pin number "+Str(pnDutPin)+" invalid"
         Return
      EndIf

      ! The DUT pin name is saved, and ...
      psDutPin=m_astDomain[nDutNumber-1,pnDutPin-1].Name
      ! the DIO channel number is used for the measurement process
      nDioPin=m_astDomain[nDutNumber-1,pnDutPin-1].DIO
   EndIf
}

The DIO channel number returned by _GetPinInfo is used for the continuity measurement. The DIO channel is placed in the Force Current mode and the commutating voltages (voltage clamps) of +5V and -2V are applied to the DIO channel to keep the DUT pin voltage to a level that is safe for the DUT. A small negative current (-0.5mA) is applied to the DIO channel, and the resulting voltage is measured. Once the measurement is complete, the DIO channel is returned to dynamic mode (default) and the measured voltage is returned to the calling command. The full ATEasy algorithm is shown below:

Procedure TestContinuity(nDutNumber, varDutPin, pnDutPin, psDutPin): Double
--------------------------------------------------------------------------------
nDutNumber: Val Short          !DUT device number
varDutPin: Val Variant         !DUT Pin ("Name", "Number" or valNumber)
pnDutPin: Var Short            !Returned DUT pin number
psDutPin: Var String           !Returned DUT pin name
nDioPin: Short                 !DIO Channel number
dContinuity: Double            !Continuity voltage measurement
nHandle: Short                 !DIO handle
{
! Get the DIO session handle
Dio Get MasterHandle(nHandle)

_GetPinInfo(nDutNumber,varDutPin,nDioPin,pnDutPin,psDutPin)

! The DIO channel is placed in the Force Current mode and...
Dio Setup Channels Mode PmuForceCurrentMode RangeOfChannels(nHandle,nDioPin,nDioPin)
! commutating voltages (voltage clamps) of +5V and -2V are defined
Dio Setup Channels PMU ForcedCurrentCommutatingVoltage RangeOfChannels(nHandle,nDioPin,nDioPin,5.0,-2.0)
! A small negative current (-0.5mA) is applied to the DIO channel, and...
Dio Setup Channels PMU ForceCurrent RangeOfChannels(nHandle,nDioPin,nDioPin,-0.5,aPmuCurrentRange_n2ma_to_p2ma)

! the resulting voltage is measured
Dio Measure PmuVoltage(nHandle,nDioPin,dContinuity,250)

! The DIO channel is returned to dynamic (default) mode and...
Dio Setup Channels Mode DynamicIo RangeOfChannels(nHandle,nDioPin,nDioPin)

!  the measured voltage is returned to the calling command

Return dContinuity
}

Results

ATEasy automatically evaluates the measurement returned to TestResult against the test’s Min/Max parameters to determine the Pass/Fail status of each continuity measurement, and reports the results of the evaluation to the Test Log (standard output) or Test Executive (ATEasy’s Test Management driver utility). Figure 2 shows the Test Executive output with a DUT open continuity failure for pin 2, and a DUT short continuity failure for pin 9.

Figure 2: ATEasy Test Executive Output with DUT continuity Failures

The ATEasy project files for this article can be downloaded here.

Consolidating Test Resources for Avionics Production Test - Published on 8/30/2021

8/30/2021

Manufacturers of avionics products are constantly challenged to develop, manufacture, and maintain / service a diverse range of avionics products, including aircraft data acquisition and recording systems, navigation / communication solutions and aircraft network systems. These types of products which are deployed on virtually all commercial aircraft in operation today require rigorous functional testing as well as a robust test data collection system to ensure overall system reliability and traceability. Additionally, the long product life cycles for avionics products (typically more than 20 years for service and support) requires that the associated test systems be maintained and supported which can be both technically and financially challenging.

Teledyne Controls manufactures a broad product line of avionics products which include:

Digital Flight data acquisition/management units

Wireless / Quick Access Recorders (WQAR/QAR)

Nav-Com systems

Network File Servers

Network router systems

To address the test requirements associated with these products Teledyne test engineers adopted the PXI platform as the core platform for their manufacturing test solution. Offering a broad variety of instrumentation and providing test engineers with the flexibility to build and easily reconfigure a compact, small footprint test system, Teledyne selected Marvin Test Solutions’ GX7100 PXI chassis, instrumentation and ATEasy® software to provide the basis for their manufacturing test systems.

With over 95 test systems deployed for both production and service applications, Teledyne has been able to address both current and future generation products using a common core system.

[:+[+ateasy+]+:]


Single UUT Modular Acceptance Test Equipment		Teledyne Modular Acceptance Test Equipment with Thermal Chambers

Previous generations of test stations based on custom or proprietary architectures would have taken years to develop, but by selecting a commercial off the shelf (COTS) platform as the core component, Teledyne Controls was able to complete the system design in a few months. And by standardizing on a core platform, Teledyne has been able to leverage the current platform over a 10 year timeframe, supporting over 25 avionics systems, 15 circuit card assemblies, and numerous types of UUTs – demonstrating the robustness and longevity of the platform. Currently there are over 95 test systems deployed for test and maintenance of Teledyne Controls products.

In addition, by standardizing not only on a hardware platform but also on an integrated test executive and test development software platform, the development and deployment of multiple test solutions has resulted in a significant increase in test program development productivity with an equally significant reduction in test program deployment time when compared to previous generation systems. Teledyne’s experience with defining, developing and deploying a common test platform has shown that significant savings can be realized for both development and test maintenance costs.

[:+[+gx7100+]+:]

To learn more about the advantages of a common test platform for avionics production test, a detailed white paper is available:

Download the White Paper

Trendar / Fluke 3050B Digital Subsystem Replacement - Published on 8/18/2021

8/18/2021

I. Introduction
This technical brief offers a notional implementation for replacing the Trendar / Fluke 3050B digital subsystem with a PXI-based, MTS digital subsystem. The suggested implementation only addresses a subset of the Fluke 3050B’s digital test functionality and is based on information obtained from the 3050B Digital / Analog Test System manual, dated February, 1983 (Rev. 1, 2/84).

II. Background
The Fluke 3050B Test System offered automated digital and analog functional test capability for PCB assemblies. Interfacing to the UUT was via a connector adapter which was connected to (4) 156 pin ZIF connectors. Figure 1 below is a picture of the system.

Figure 1: Fluke 3050B System

The 3050B operated in two modes of pass/fail testing – comparison mode and signature mode. Comparison mode relied upon comparing the digital stimulus responses between a known good UUT and the UUT under test. I/O pin states, IC clips applied to the boards, and logic probes were compared step by step. The signature mode utilized only a single board and relied upon pass / fail decisions by comparing CRC (Cyclic Redundancy Check) signatures generated by the I/O pins of the UUT to signatures of a previously tested, known good board.

The 3050B also included fault diagnostics using an environment called ADS, which was a guided probe algorithm that could diagnose faults based on UUT schematic, topology and components. Inputs needed by ADS to perform diagnostics included:

IC type and location file

IC type definition file

Priority node file (optional)

From - to interconnect file

Board edge priority file (optional)

Label file (used for documentation)

The 3050B offered two probes for monitoring / comparing of nodes on the UUT. Probe logic threshold was selectable 1 V, 2 V, 5 V, 7 V or variable (-10 to +10 V). The use of IC clips (16-pin) had similar characteristics except the variable range was 0 to +10 V.

The 3050B digital subsystem’s key features are summarized below:

Maximum of 240 I/O pins, in 32-pin increments; base configuration was 64 pins

Low level driver output less than or equal to 0.7 V @10 mA

High level driver output programmable via jumpers in the connector adapter (see figure 2 for output range)

Driver test rate: 1 MHz, (2 MHz in some modes)

Receiver threshold range: 1.8 V to 3.5 V based on driver voltage level (see figure 3)

Stored sequences: up to 2048 bits

Test length: programmable for 20K, 40K, 100K, 200K, 400K, 1M, 2M, 4M, 10M, 20M, 40M

Tester clock frequency: Programmable in 3 digits from 1 Hz to 9.99 MHz

Figure 2: Output Driver Range

Figure 3: Receiver Threshold Range

Sequence execution included the following capabilities:

Switch any of four pin groups from present mode to Auto Sequence, Stored Sequence, or High Impedance

Change the state of drivers in a pin group in Auto Sequence mode, in accordance with the programmed Auto Sequence algorithm

Change the state of the drivers in pin groups in Stored Sequence mode, in accordance with the programmed Stored Sequence

Enable or disable all receivers

Execute an opcode for a stored sequence as defined in the table below

Opcodes for Stored Sequence

III. Notional 3050B Digital Subsystem Replacement
The notional subsystem replacement is based on MTS’ 6U PXI GX5055 digital I/O card which offers 32 digital I/O channels and a wide (-14 V to +25 V) drive / sense voltage range.

To accommodate 240 pins, the subsystem would consist of (8) GX5055 digital I/O cards, installed in a GX7005 high power, PXI chassis.

This digital subsystem can operate to 50 MHz and features programmable slew rate, which would facilitate matching the 3050B’s driver performance characteristics. In addition, the subsystem features per-pin and per-test step direction control as well as programmable per pin drive / sense levels. All of these features provide the flexibility to facilitate the adaption / migration of a 3050B test program to the proposed digital subsystem.

As noted in Section II, the 3050B supported several test modes, including a comparison and signature mode for pass / fail testing. A summary of possible capabilities and differences based on the GX5055 digital subsystem is detailed below:

[:+[+GX7005C+]+:]

Signature mode, pass/fail only. The use of signature mode requires the calculation of a CRC for the acquired data from the UUT and then comparing to the known good CRC. The GX5055 does not support CRC calculation so this would need to be done post acquisition by the system controller (a PC), provided the CRC calculation method is known.

Comparison mode can be supported, provided the stimulus / response vectors are available from the known good UUTs. The known good test vectors would be applied to the UUT and the response would be captured by the GX5055’s memory. Post-acquisition, the acquired vectors from the UUT would be compared against the known good vectors. The GX5055’s function library includes a function that supports this compare capability. Note that although the 3050B only supported 2K vectors, sequence length could be up to 40M. The GX5055 supports up to a sequence length of 512K, so for long sequences (> 512K), the test and compare process would need to be split up into multiple sequences.

The notional subsystem makes no provision for incorporating a guided probe algorithm for fault diagnosis. A probe can be connected to a spare DIO channel, but development of the probe algorithm would be the responsibility of the end user.

The GX5055 digital subsystem is most aligned with supporting the Stored Sequence mode. The GX5055’s vector depth is much greater than the 3050B’s 2K vectors. However, sequence depth for the GX5055 is limited to 512K. The 3050B supported sequences to 40M. The GX5055’s opcodes are very similar to the 3050B’s which would facilitate re-hosting of Stored Sequences. For large sequences, multiple sequences would need to be loaded and executed as multiple bursts.

IV. Adopting the GX5055 Digital Subsystem for the 3050B Replacement - Considerations
The GX5055 subsystem (Figure 4) can provide the basic digital test capabilities supported by the 3050B.

Figure 4: GX7005 Chassis & Digital Subsystem

Additional issues to be considered as part of this replacement solution include:

Fixtures: Adapter(s) will need to be constructed to adapt the 3050B’s Connector Adapter / test interface to the GX5055’s I/O connectors. Alternatively, new fixtures / cabling would need to be constructed. MTS offers the GX5055 digital subsystem with several different mass termination interfaces supplied by both Virginia Panel and Mac Panel.

Software: A method for migrating the 3050B’s test vectors and associated test program will need to be created. Control of the GX5055 digital subsystem is done via modern text-based languages such as C or ATEasy® with the display / control of test programs via a PC-based controller. Any operator interfaces associated with the 3050B test programs would need to be migrated to the PC-based environment.

3050B Specific Waveforms: The 3050B supported a variety of complex waveforms as well as clocks, gray-code clocks, and eight phase clocks. If the test programs being migrated require these waveforms, they will need to be created by the user as part of the test program migration process. These waveforms are associated with Auto Sequences which were generated by the 3050B’s Auto Sequence Processor.

[:+[+gx5055+]+:]

Pass/Fail Test Modes: As noted in section III, the 3050B supported two modes – comparison mode and signature mode. If implementing signature mode for a program migration effort, the user will need to know the known good CRC signatures as well as having full knowledge of how the CRC signature is calculated.

Guided probe: The digital subsystem is not supplied with any guided probe software. Any diagnostics would need to be developed by the end user.

Cyber Security Features of ATEasy - Published on 8/18/2021

8/18/2021

Introduction

Prevention of security vulnerabilities is increasingly important as new threats and defenses are discovered. In order to support your asset protection, ATEasy includes many security features in compliance with DOD Application Security and Development (ASD) and DISA Security Technical Implementation Guide (STIG). ATEasy is compliant with ASD version 4 release 10 (V4R10) released October 25, 2019 (293 requirements).

For example, the following audit requirements met by ATEasy:

Start/End session/program

User modifications and login/logoff

Inactivity locked timeout

Password policy: term, repeats, disabled accounts, format (# of characters, upper lower/numeric, signs…)

User file protection and read-only setup

Throughout your product's lifecycle, ATEasy provides encryption and a user administration interface to increase application security from conception to operation.

[:+[+ateasy+]+:]

ATEasy User Auditing

Many attack vectors exploit improperly administrator user privileges. To mitigate the risks stemming from poorly defined user rights, rigorous user account management includes auditing. In addition to any enterprise-level solution, ATEasy also features user auditing. When enabled, ATEasy will generate audit records in Windows Event Log for the following events and their event ID number:

Audit Start/Stop - records to ATEasy Windows Application Event Log

ATEasy or Application Start (1010)

ATEasy or Application Exit (1011)

Program Start (1012)

Program End (1013)

Audit User Log In/Off - records to the ATEasy Windows Application Event Log

User Login Succeeded (1020)

User Login Failed (1021)

User Logoff (1022)

User Locked (1023)

User Unlocked (1024)

Audit User Modifications- records to the ATEasy Windows Application Event Log

User Password Change Succeeded (1030)

User Password Change Failed (1031)

User Added (1032)

Used Removed (1033)

User Modified (1034)

User's File Replaced (1035)

User's File Changed (1036)

Auditing establishes self-audits adding to existing security standards and best practices. User action traceability is a key security feature. Figure 1 shows an example of Windows Event Viewer and ATEasy audits. The log provides information security personnel an easy way of tracing user interaction.

Figure 1. ATEasy logs application events, viewed here with Windows Event Viewer.

Building Safe ATEasy Projects

All user data is encrypted by default to prevent unauthorized access. Common application security flaws include revealing too much information about error conditions for example in the form of stack traces, detailed network timeout errors, buffer overflows and database structures. To support secure development through proper error handling, ATEasy has built-in support for example:

Try-Catch blocks to localize the handling of exceptions

OnError() module events to catch all / ease handling of runtime errors

Error statements in user code to generate error conditions allowing centralized or grouped error handling (OnError /Try-Catch)

Procedures to process unhandled exception

Figure 2. Encrypting Executables is Accomplished by Checking Encrypt

Projects can be built into an executable or DLL. Figure 2 shows ATEasy project properties with secure options available. Embedding runtime library can help prevent loading malicious libraries in man-in-the-middle/API-hooking attacks. In particular, when 'Encrypt' is checked the executable or DLL created receives a digital signature with its PCode section encrypted. This feature guards project integrity against file corruption or malicious changes. If the created EXE or DLL file is encrypted, it cannot be read for example using a text viewer. Figure 3 shows File Encryption being enabled for a Program module.

Benefits of project target encryption include:

Maintain executable integrity and prevent hacking or modifying executable (Non-Repudiation)

Prevent reverse engineering and PCode code viewing

Figure 3. An administrator can set passwords for modules to control access

Secure ATEasy Runtime

ATEasy includes features like stack overflow and mismatch checking to maintain project integrity. Buffer overflow protection prevents exploits that utilize malformed input injections. ATEasy implements Control-Flow Integrity to prevent stack smashing and injection of malicious code. Runtime applications are secured and provided with encryption. Binary source code encryption has many benefits. ATEasy verifies files as they are opened which contributes to protection from malicious changes.

The benefits of using password or license serial number protection cannot be reiterated enough. Using access control protects applications from using, viewing, editing and reverse engineering of code by potentially harmful actors. In addition to access control, ATEasy also provides automatic file versioning. Versioning also provides additional recordkeeping capabilities.

ATEasy User Administration, Access Control and Versioning

Access control throughout project lifecycle is paramount for application security. ATEasy includes many features for robust user administration.

Administrator can specify access level and password. Alternatively, ATEasy serial number can be used to grant access based on license. In addition to controlling access, user changes to project files can be subject to versioning. Each version of project files can be labeled and time stamped promoting further tracing of changes and user actions. Figure 4 shows an example project using automatic versioning.

Figure 4. Tracking versions is convenient with periodic auto save enabled.

User interaction can be limited to selecting and running tests with short menus. User login maybe required with ATEasy launch with Use Login Dialogbox. Minimum password length can be enforced as well. ATEasy users can be granted rights as individuals and as group members. Custom groups can be created and user rights can also be set/read in AUser class. These user rights are detailed in figure 5, while figure 6 shows how intuitive enforcing ATEasy information security can be.

Figure 5. Given proper clearance, user rights can be set from Users menu as well as in an instance of AUser class.

Figure 6. Access to the IDE can be made selective based upon group definition.

Test Executive User Administrator, Access Control and Versioning

In addition to ATEasy, Test Executive also contains tools for configuring user rights and access to your application's functions. Administrator can hide/show/enable/disable/rearrange commands, menu items, toolbar & form buttons, and options to handle customization privileges and access to test executive features. An administrator can add and modify available user groups as shown in figure 7, while figure 8 shows a menu for modifying group users.

Figure 7. Group changes can be made

Figure 8. Users can be modified.

Commands available to a Test Executive user can be restricted to based on individual or group settings. Each command can be mapped to custom procedures. For example in figure 9, changing a password is disabled for user group Testers. Much like commands Test Executive's available menus items can be restricted based on user privileges. An example of menu item customization is seen in figure 10, where access and organization of the Testers group menu is considered.

Figure 9. Group specific restrictions can be applied by disallowing functionality for specified parameters

Figure 10. Menu items can be restricted as well.

Application toolbars and options are also available for customization according to user access level. Control of available options can restrict use of for example user being able to delete log files. In figure 11 example, the Test Executive toolbar seen by Supervisors group is being modified.

Figure 11. Setting a custom toolbar for the Supervisor group

Figure 12. Specifying modal user interface for a given group name

Figure 12 shows configuration of the Test Executive touch panel user interface in the case Testers user group. Access to commands linked to form items can be added and removed from user group. Additionally, figures 13 and 14 show more user interface options that can be set for a given user groups and modal and modeless dialog. In figure 13 for example, whether window is shown in full screen can be set. Figure 14 shows some example groups and how their user password minimum requirements can be mandated.

Figure 13. Customizing options for the group Testers

Figure 14. Customizing options for the group Testers

Conclusion

ATEasy and Test Executive provide STIG V4R10 compliant, as well as many other, tools for secure application development. ATEasy applications are deployed across many different platforms and can have a long lifetime, in which case the usefulness of ATEasy built-in application security capabilities will likely only increase with time.

[References]
https://stigviewer.com/stig/application_security_a

White Paper: Overcoming 5G mmWave Semiconductor Production Test Challenges - Published on 7/27/2021

7/27/2021

Beamformer integrated circuits are the key to unlocking the low latency and increased bandwidth performance promised by 5G networks, and they play a critical role in other applications areas as well including radar, imaging and remote sensing. Multiple beamforming devices are integrated into an RF front end as part of the antenna assembly, which is then programmed to form the desired overall radiation pattern. Importantly, the ability to steer the RF signal by shifting the phase of the output is essential for accurate and repeatable signal transmission and reception.

Download the white paper

Adding Custom Commands to ATEasy Test Executive - Published on 7/17/2021

7/17/2021

Overview

ATEasy is a test executive and a rapid application development framework for functional test, Automated Test Equipment, data acquisition, process control, and instrumentation systems, providing all the necessary tools to develop, deploy and maintain software components, as well as a complete and customizable test executive.

Test engineers have several commercial options available to them when choosing the best platform to standardize on for writing test programs. And while there are also commercial test executive development packages available, most are a collection of tools with which engineers can assemble a test executive.

ATEasy comes bundled with a full-featured test executive that runs out-of-the-box with no coding necessary, exploiting ATEasy’s structured applications to dynamically build a user interface tailored to the test processes. And because ATEasy was developed for test engineers, it has many of the processes common to test programs built into the system – like measurement evaluation and data reporting.

[:+[+ATEasy+]+:]

That is not to say that the ATEasy Test Executive is rigid and inflexible when customization is warranted. In fact, since the ATEasy Test Executive was written in native ATEasy language, the full source code to the test executive driver is provided so the user has complete control over adding new functions, or altering the look, feel and functionality of their application.

ATEasy supports easy integration into the test executive of unique user procedures and functions, including user defined menu additions and tool bar images to support those functions. This article will demonstrate the process for adding custom functions, commands, menu’s, forms and tool bars.

Custom Test Executive Procedure

The first step in customizing the test executive is to add code that represents the required functionality. The code could be in the form of a procedure or function, and may include a graphical interface. As a representative example of custom functionality and place-holder for future code development, this example will add a simple procedure called “MySetTemp”. The procedure was added to the System module, and will allow an operator to manually, or programmatically set an ambient temperature that will be recorded in the ATEasy Test Executive data log. Code for the procedure is below:

Procedure MySetTemp(dTempSetting): Void Public ! Sytem.MySetTemp
--------------------------------------------------------------------------------
dTempSetting: [Val] Double = 0
sInput: String
i: Long
{

If ArgMissing(dTempSetting)
dTempSetting = m_dTempSetting
i = InputBox("Set operating temperature","Set Temperature",sInput)

If i = 2 ! Cancel
m_dTempSetting = dTempSetting
Else
m_dTempSetting = Val(sInput)
EndIf

Else
m_dTempSetting = dTempSetting
EndIf

Print "Operating Temperature Set To: "+Str(m_dTempSetting)

}

The procedure will store a temperature to the System module variable “m_dTempSetting”. If the procedure is called from the program thread, and passed a value via the “dTempSetting” parameter, then the variable is updated without user intervention. If the procedure is called without the “dTempSetting” parameter, then a built-in user form will open requesting the operator to enter the temperature. Which ever method is used, the set temperature is stored in the System variable for use by the test executive. Make sure to set the procedure properties to Public and Compile as shown in figure 1.

Figure 1 – MySetTemp Public and Compile properties

Test Executive Data Logging

The System “OnInitProgram” event is used in this example to report the set temperature whenever the test process is initiated. This event is called each time the Program module (which contains the Task/Test list) runs. A simple print statement is used to inform the operator of the previously stored temperature, and because the statement occurs in the System OnInitProgram event, the information is located in the Program header section of the Test Executive log.

Procedure: OnInitProgram(): Void Public ! Syste.OnInitProgram, Occurs when a program has started.
--------------------------------------------------------------------------------
{

Print "Operating Temperature: "+Str(m_dTempSetting)

}

Customizing the Test Executive

Create Command Image
ATEasy’s Test Executive allows custom commands and images to be added to the existing menu, forms and toolbar. The image is a BMP image that will graphically represent the functionality of the added procedure. In this example, a 16 x 16 pixel BMP image was created using the Windows Paint program, and saved as “Thermometer.bmp” - see figure 2. This image will be used when adding the new function to the ATEasy's Test Executive Menu, Form and Toolbar.

Figure 2 – Set Temperature Image

Create New Test Executive Command
A new command must be defined to link the MySetTemp() procedure and the Set Temperature image to the Test Executive. While the application is running and the Test Executive is visible, click on Tools:Customize. The default tab should be "Commands". If it's not, select it. At the bottom of the command list is the "User Defined popup" selection. Click on this and using the "Insert New Command" tool, add a new user defined command as shown in Figure 3:A. Name the command "Set Temperature" (Figure 3:B). Since we will be adding this command to the Test Executive Menu, Form and Toolbar, change the Caption for each of these items to "Set Temperature" (Figure 3:C). Then add the description ""Set operating temperature" to the new command as shown in figure 3:D.

Figure 3 – Create New Test Executive Command

To link the MySetTemp procedure to the newly created command, click in the Procedure field (figure 3:E) and enter the procedure "System.SetMyTemp" )Module.Procedure Name), then click on the check next to the field to accept the entry. If you make a mistake entering the procedure an error message will be dislayed.

To link the image to the command, click on the box next to the Image field to open up a navigation window. Navigate to the folder containing the BMP file previously created, and select the file (figure 3:F). The navigation box will display the image after successfully selecting the BMP image. The last step in defining the new Test Executiv command is to enable it by checking the Enable check box as shown in figure 3:G. When done the Test Executive Customize:Commands dialog should look similar to figure 3.

NOTE: The image navigation will use the absolute path when linking the image. If you intend to deploy your application and cannot guarantee that the installation path will be the same as the development path, you can manually substitute the absolute path with a relative path using this syntax: ".\image.bmp".

Create New Test Executive Menu Function
To add a new Menu item to the Test Executive, while still in the Tools:Customize dialog, click on the "Menu" tab. Expand the "User Defined popup" in the left side of the dialog and select the "Set Temperature" command you just created - Figure 4:A. Expand the "Log" item in the right side of the dialog, and select "Clear" (figure 4:B), then click on "Add" (figure 4:C) to insert the item selected on the left side of the dialog (user defined Set Temperature command), into the position selected on the right side of the dialog, bumping the selected item down on the list. The new item should be visible in the expanded Log function list (figure 4:D). The ordering tools above the right side function list can be used to change the position the functions in the list are displayed in the Test Executive Log Menu (figure 4:E).

Figure 4 – New Test Executive Menu Selection

Create New Test Executive Form Function
Test Executive forms are used when the Test Executive is set to operate in the Modal (Touch Panel) mode. Modal or Modeless operation can be selected from the Tools:Customize Options tab. Using the same process as was used to add a new menu item to the Test Executive, you can add our customer command and image to the Test Executive form.

From the Tools:Customize dialog, select the Forms tab. Expand the "User Defined popup" in the left side of the dialog and select the "Set Temperature" command you just created - Figure 5:A. Select "Log" from the drop-down list at the top of the dialog (figure 5:B). In the Main Buttons area, select "Clear" (Figure 5:C)), then click on "Add" (figure 5:D) to insert the user defined Set Temperature command into the position selected in the Main Button list, bumping the selected item down on the list. The new item should be visible in the expanded list (figure 5:E). The ordering tools above the right side function list can be used to change the position the functions in the list are displayed in the Test Executive Log Form (figure 5:F).

Figure 5 – New Test Executive Form Selection

Create New Test Executive Toolbar Function
To add the new command and image to the Test Executive toolbar, click on the "Toolbar" tab and expand the "User Defined popup" on the left side of the dialog. Select the "Set Temperature" command - Figure 6:A. Click on "Program exit" on the right side of the dialog to select it (figure 6:B), then click on "Add" (figure 6:C) to insert the item into the position selected on the right side of the dialog. The new item should be visible in the expanded Log function list (figure 6:D). The ordering tools can be used to change the position the functions when displayed in the Test Executive Toolbar (figure 6:E).

Figure 6 – New Test Executive Toolbar Selection

Using The New Commands

To use the new function, while the Test Executive is running, you can select it from any of the three Test Executive interface it was linked to, Menus, Forms (when running in Modal mode) or Toolbars. You can also call the function from within a test program. If a temperature parameter is included in the call, then the function executes silently (without operator interaction). If the parameter is omitted, then an operator prompt allows a temperature value to be manually entered, the same as if the function were initiated via the Menu/Form/Toolbar interface - as shown in figure 7.

Figure 7 - InputBox For Manual Temperature Input

Examples of both programming methods are shown below. This code was placed in the Program OnInitTask event, and demonstrates user the input method for Task2, and silent temperature updating for Task 3.

Procedure OnInitTask(): Void Public ! Program.OnInitTask, Occurs when a program task has started.
--------------------------------------------------------------------------------
{
Select Task.Name

Case "Task 2"
System.MySetTemp()
Case "Task 3"
System.MySetTemp(98.6)

EndSelect
}

Examples of using the set temperature function from the Test Executive Menu/Form/Toolbar interfaces are provided below

Figure 8 - Using Set Temperature From The Test Executive Log Menu

Figure 9 - Using Set Temperature From The Test Executive Modal (Touch Panel) Log Form

Figure 10 - Using Set Temperature From The Test Executive Toolbar

Test Executive Data Log

The following is a sample test log documenting the temperature values stored in the m_dTempSetting System module variable. The initial value was set using the toolbar to enter a value of 123 before running the application. When the test is initiated, the System OnInitProgram event is executed, the initial value of 123, stored from the toolbar entry, is displayed. Prior to Task 2 starting, the operator is prompted to enter a new value, and responds by entering the value of 100. This new value is documented before to the Task 2 header. Prior to Task 3 starting, the program automatically updates the m_dTempSetting System variable, and the new value is documented at the beginning of Task 3.

Figure 11 - Test Executive Test Log Output

Summary

This article demonstrates the process for creating user defined functions, and integrating them into the ATEasy Test Executive. The example presented, while simple in concept, can serve as a template for adding more, and more varied functions. It's important to note that the functions can be ported to other ATEasy platforms, but to invoke them, you must either follow the setup process of creating commands and linking them to the Test Executive interface as described here, or, as the setup is saved to the "ATEasy.usr" file, you can copy the .USR file from the initial development system to multiple deployment systems and bypass creating and linking the commands on each deployment system.

Note: When copying the .USR file to a new system, ATEasy will detect the new .USR file and prompt the operator (must be ATEasy administrator) to accept using the new .USR file, or revert back to the .USR file currently in use.

The ATEasy project used to develop this article can be downloaded from the link below. The application was developed using ATEasy 10.0, build 156d
ATEasy Custom Toolbar Example (zip)

How to Support Multiple Languages User Interface in ATEasy - Published on 7/17/2021

7/17/2021

Introduction

This article shows how to create or convert an ATEasy application to support multiple languages user interface providing an application that is more accessible and localized to customers around the world.

Overview

The article provides an example showing how to implement language localization for the following UI elements:

Forms inducing controls, menus

User Messages, prompts and strings

Test Log, including Test Names, Task Names

The main components that were used to create the example provided are:
1. Three modules used in this example as a typical ATEasy application

a. Program module
b. System module
c. Driver module

[:+[+ATEasy+]+:]

2. An ATEasy DLL file for each language to hold the application user interface; 4 DLLs are provided:

a. LanguageUIEnglish.dll, LanguageUIHebrew.dll, LanguageUIGerman.dll, LanguageUIChinese.dll, etc.
b. These DLL files should contain the implementation of the User interface and language based resources.

3. Have a UIlib DLL such that the language DLLs have the same prototype as the UIlib DLL

a. Allows the DLLs to have the same inputs and outputs
b. Allows the program to call in the language DLLs through the UIlib DLL

4. The UI driver can be included with the UIlib library and all of that should be placed inside the system module.

Background

There are two different ways that you can make a multiple language user interface. The first is by replacing the text fields in your form dynamically for each language. However, problems can occur with the font, size, and alignment of the text since each language's text has different attributes. As you can see, the first option can give you many problems, which brings us to the second option. The second option is to make multiple copies of the application in ATEasy DLL files (one file for each language), then calling in the appropriate DLL so it opens up the proper user interface. Implementing DLL files with user interface procedures instead of just replacing the text allows you to more accurately scale the user interface for each language. For this reason, in this article we will be showing you a step by step process of how to complete option two (creating ATEasy DLL files).

Every DLL will have the same DLL interface such that they have the same string functions but the user interface will look different, as seen in figures 1, 2, 3, and 4 below.

Figure 1. Translating test log output to Chinese

Figure 2. Chinese UI form

Figure 3. Translating test log output to German

Figure 4. German UI form

When the program figures out the desired language, it can simply load the proper DLL through LoadLibrary(UILib, “DLL path”). Using DLL files also allows you to have code in a driver and all the DLLs in that driver that can use that code which helps maximize reusable code.

Step by Step Process

1. Create a new driver

a. Name it UI
b. Create the driver that will have all of the DLLs in it

2. Go to events in the UI driver

Figure 5

3. In UI driver create a new form

a. Name it SelectLanguage
b. Gives the user the opportunity to choose which language they want to be displayed

4. In SelectLanguage select the OnLoad() event

Figure 6

5. In SelectLanguage select the OnClick() event

a. By clicking the language, it will call in the proper language DLL

Figure 7:
A- ALabel - name: lblInstructions
B- AComboBox - name: cbSelectLanguage
C- AButton - name: btnOk

6. Go to UI events to OnInitProgram()

Figure 8

7. Go to UI events to OnInitTask()

Figure 9

8. Go to UI events to OnInitTest()

Figure 10

9. Go to your program file and create a new test

a. Name it Display Form

Figure 11

10. Go to UI Procedures and create a new procedure

a. Name it LoadMainForm
b. This procedure is in all the language DLLs too, so by calling in this procedure, the program reads in the UILib DLL and transfers you to the proper DLL file

Figure 12

11. Go to Driver commands and connect procedure LoadMainForm to the commands

a. In ATEasy, when you create a new procedure, it is not a public procedure so by making this procedure into a command you are allowing the entire project to see and use this command. Essentially, you are converting the procedure from a private to a public procedure.

12. Go to UI events to OnEndProgram()

Figure 13

13. Create a new project

a. Name it LanguageUIChinese or whatever language DLL you are making

14. In LanguageUIChinese make a new form

a. Name it MainForm

Figure 14

15. In LanguageUIChinese make a new procedure

a. Name it LoadMainForm

Figure 15

16. In LanguageUIChinese make a new procedure

a. Name it GetTaskTestName

Figure 16

17. In LanguageUIChinese make a new procedure

a. Name it TranslateLogString_OnInit

Figure 17

18. In LanguageUIChinese make a new procedure

a. Name it TranslateLogString_OnInitProgram

Figure 18

19. In LanguageUIChinese make a new procedure

a. Name it TranslateLogString_OnInitTask

Figure 19

20. In LanguageUIChinese make a new procedure

a. Name it TranslateLogString_OnEndProgram

Figure 20

Summary

Introducing a new multiple language user interface in ATEasy increases the availability of an application to more users. Implementing a multiple language user interface through DLL files allows for a more accurate user interface than just changing the text to a different language. Using DLL files allows users to dynamically load the appropriate files during run time which is a response to the increasing trend of making applications more accessible.

Example Files

ATEasy example project files used in this article:

LanguagesUI

How to access the JTAG port on GX3500 and GX3700 series cards - Published on 7/13/2021

7/13/2021

Introduction

While all of MTS's GX3500 & GX3700 series cards are supplied with software panels that allow you to program and interact with the instrument, some users desire access to the built in JTAG port in these devices. Accessing the JTAG signals on these instruments gives users the ability to leverage on-chip debugging tools such as SignalTap II Logic Analyzer.

Required Items

GX3500 or GX3700 series card

10-pin (2 x 5) 0.100”(2.54mm) pitch header (male)

USB Blaster Intel/Altera download cable

Soldering iron (to mount 10-pin header)

Intel/Altera Quartus II v11.0SP1 installed Download Here

[:+[+GX3700+]+:]

Installing the J6 Header

New GX3500/GX3700 series cards ship from the factory without the J6 header installed so the first thing you must do is solder the 10-pin header into J6, position shown below in red.

WARNING: MTS is not responsible if you damage your instrument during this step. Extreme caution should be taken and soldering should only be performed by qualified technicians.

With the 10-pin header placed in the plated-through holes of J6, solder from the backside. Care must be taken not to apply too much heat and consequently reflow nearby surface mounted parts.

Now that you have your 10-pin header soldered into J6, you can now connect the JTAG connector from the USB Blaster (10-pin female connector) to the GX3500/GX3700 and place the card back into the chassis. You must install the JTAG connector from the USB Blaster to the J6 header with pin 1 of the USB Blaster cable oriented towards the rear of the GX3500/GX3700 card, as shown below.

Once you have attached the USB Blaster to the GX3500/GX3700, gently slide the card into the chassis, being careful not to let the USB Blaster ribbon cable bind on the chassis rails as you move it into position. As you will notice, you need to have the slots adjacent to the slot occupied by your GX3500/GX3700 clear so that the USB Blaster can fit in your chassis. Now that the GX3500/GX3700 has been installed into the chassis, connect the USB connector on the USB Blaster to an available chassis USB port and power up the chassis.

Setting Up the USB Blaster Driver

Once Windows has completed booting up, open the Windows Device Manager. Until you specify the proper driver for the USB Blaster, Windows will likely identify it as “Other device” as shown below.

Right click on the USB Blaster, select Update driver and then select Browse my computer for driver software. Now browse to: [Your Altera installation folder]\11.0sp1\quartus\drivers (shown below, using the default installation path) and select Next.

Verifying JTAG Connectivity Using the JTAG Chain Integrity Test

Now that you have assigned the proper driver to the USB Blaster within Windows, you can open Quartus II and set the USB Blaster as the designated JTAG programmer/debugger. This is accomplished by selecting Tools->JTAG Chain Debugger from the main menu tool bar in Quartus II. You will then see the window shown below.

From this window’s menu bar select Edit->Hardware Setup. This will open the Hardware Setup window where you can select the USB Blaster from the Currently selected hardware drop-down list, as shown below.

Once you have selected the USB Blaster as your current hardware, select the Close button and you will be returned to the former JTAG Chain Debugger window. You will notice that the Test JTAG Chain button is now enabled. By selecting this button you can verify that all the solder connections on the J6 header are good and that JTAG connectivity has been established. After testing the JTAG chain you should see a message in the session log stating that the JTAG connection is good, as shown below.

At this point you have established JTAG connectivity with the Cyclone III/Stratix III device on your GX3500/GX3700 card and you are now able to program and debug using many of the Quartus II built in tools. For more information on these tools and their usage please see the links provided below.

Links

Quartus II System Debugging Tools Overview

Signal Tap Logic Analyzer: Intro & Getting Started

SignalTap II Logic Analyzer (Video)

IC Test Socket Contamination - Published on 6/1/2021

6/1/2021

Introduction

One of the most important, if not the most important connection between the TS-900 Semiconductor tester and the DUT is the test socket on the load board.

Because of the nature of this connection, the constant insertion and removal of devices in the socket, it will deteriorate over time and compromise the connection which is critical to the overall integrity of the test. The damage occurs when devices are inserted and removed from the test socket and is caused by metallic residue buildup on the test socket contacts from small particles from the lead plating of the DUT.

These particles are transferred and get embedded on the surface of the test socket contact; these particles become resistive and eventually degrade the connection between the test socket pin and the DUT lead.

Another factor is the wear out of the plating on the test socket contacts themselves. This wear out mechanism happens because of the extreme hardness of the plating on some DUT leads. Repetitive insertions and removal of the DUT will erode the test socket contact plating requiring more and more downward pressure be applied to the DUT to make contact with the test socket, eventually the connection will become intermittent or fail altogether.

[:+[+ts-900e-5g+]+:]

The most common plating processes for IC leads, after the ROHS directive became effective in 2006, are matte tin (Sn) and nickel-palladium-gold (NiPdAu) for leaded and pad packages and tin-silver-copper (SnAgCu) for balls on ball grid array packages.

Matte tin plating is the most widely used lead plating for leaded and pad packages because of its low cost and availability; extensive research has been conducted by the packaging industry, semiconductor manufacturers and test socket manufacturers and the processes for using this type of platting are well understood.

Because matte tin plating develops an oxide layer almost immediately after exposure to air, it is necessary to mechanically break through this oxide to make a good, reliable contact. In older test socket designs, those used to test pre-ROHS tin-lead (SnPb) plated leads, the contacts just presses against DUT lead with little to no mechanical scrubbing action. When this type of socket is new the contacts will penetrate the oxide layer on the tin plated leads; however as the number of parts inserted in the socket increases very small particles from the lead plating will buildup on the surface of the contact (these particles will immediately begin to oxidize and become resistive), and after a number of insertions this residue build up will cause a resistive contact. This resistance is now in series between the DUT and the TS-900 test equipment and will cause intermittent to full contact failure. On devices that draw significant amounts of current, the voltage drop developed across this resistance can cause damage or destruction of the test socket, the load board and the DUT.

Effects of Contamination on Contact Resistance

Effects of Pb-Free Device Plating –Matte Tin (Courtesy Johnstech)

On devices with NiPdAu lead plating, because of the hardness of this plating, the contact degrading mechanism is the wearing out of the plating on the test socket contact surface over time. This exposes the base contact metal and a resistive contact develops because of oxidation. Balls in BGAs will also develop an oxide layer because of the tin in the SnAgCu plating. The pogo pin contacts on BGA sockets will get contaminated with these metallic oxide particles and the contact will also become resistive.

Effects of Pb-Free Device Plating –NiPdAu (Courtesy Johnstech)

New Socket Technologies

New socket technology designs addresses this oxide layer issue by creating contacts that mechanically wipes across the surface of the lead. The socket contacts are plated with a hard metal alloy which will displace the oxide as it slides on the surface of the lead. Some test sockets are manufactured with pins made of solid hard alloy metal; these pins will last longer because as the contact metal wears out, its surface metal stays the same.

New socket technology with movable contacts and force elastometers (Courtesy Johnstech)

Effects of Contact Insertions

Device I/O Surface Oxide Penetration and Removal: SnPb 1, 10 and 50 insertions (Courtesy Johnstech)

Test socket manufacturers recommend that test sockets be cleaned after a certain number of insertions. Each manufacturer has its own cleaning procedure and most sockets can be rebuilt and contacts can be replaced if the they become unusable. Test sockets used in the production test floor should be placed under a preventive maintenance schedule to minimize contact deterioration due to tin oxide buildup and wear. This will maximize your first-time-pass yields and minimizes the amount of product re-test. Taking care of the test sockets will guarantee that they will perform consistently and reliably for a long time.

Test Socket manufacturers and suppliers

Johnstech
Loranger International
JF Technology Berhad
Aries Electronics, Inc
Ironwood Electronics
Emulation Technology, Inc.
Advanced Interconnections
3M Textool
Custom Interconnects

Copyright

All Graphs and Pictures copyright and courtesy of Johnstec

What is HW driver? - Published on 6/1/2021

6/1/2021

MTS HW driver

The HW package - MTS (Marvin Test Solutions) Hardware Access Driver, is used by all MTS instrument drivers and ATEasy to access the PC resources (memory, IO ports, DMA etc), to set/query the PCI/PXI configuration and more.

The HW package includes libraries used to program and create instrument drivers for PCI/cPCI/PXI based instruments, including the PCI Express (PCIe) derivatives. PXI/PCI Explorer , a utility to configure and display PXI/PC based systems, is also included. This utility includes a VISA configuration manager for PXI and PXI express instruments (similar to NI-MAX), and supports MTS and other vendors PXI chassis, controllers and bus expanders.

The MTS HW driver is used by, and installed with all MTS software packages, including ATEasy and all MTS instrument drivers. It is also available as a stand alone package, to download the current HW software click here.

Once installed the HW driver includes the following files:

[:+[+ateasy+]+:]

HwSetup.exe - A command line utility to install, uninstall and check the status of the HW driver

HwTest.exe - A program to test the HW driver and to read/write to I/O ports, memory and to display PCI resources

HwPciExplorer.exe - HW PXI/PCI Explorer Applet, a PXI/PCI based VISA compatible resource manager control panel applet. Used to display the current PXI/PCI devices and to assign slot numbers to device resources. Slots numbers are required to identify a PCI/PXI board when using MTS board driver

HwPciExplorer.cpl and HwPciExplorer64.cpl - 32 and 64 bit PXI/PCI Explorer - Windows Control Applet Panel support

Hw.sys and Hw64.sys - Windows kernel mode device drivers, provides access to I/O ports, memory and PCI resources, installed to the Windows System Drivers directory.

HwDevice.sys and HwDevice64.sys - 32 and 64 bit Windows kernel mode device driver for HW.INF boards, installed to the Windows System Drivers directory

HwPxiExpress.dll and HwPxiExpress64.dll - 32 and 64 bit driver to provide information to MTS Chassis, Controller and Peripheral PXIe devices, installed to the Windows System directory

HwCIns32.dll and HwClins64.dll - Windows Class Installer for HwDevice.sys and HwDevice64.sys

Hw.dll and Hw64.dll - Library with API defined in hw.h, installed in Windows System folder

Hw.h - Include file, to include in your C/C++ project provides functions prototypes to Hw.dll and Hw64.dll files

Hw.lib and Hw64.lib - Import library for C/C++ applications

HwCIns32.dll and HwCIns32.dll - 32 and 64 bit Windows Class Installer for HW

Hw.inf - Driver information files for MTS's PXI/PCI boards. Installed to the Windows System INF directory

Hw.cat - Windows digitally signed catalog file

HW-NI-PAL-PCI.reg - HW-NI-PAL Registration entries file

GX7XXXX.ini - Configuration files used to support Marvin Test Solutions chassis and controllers

Hw.vxd - Windows 9x/Me virtual device driver provides access for memory and PCI resources, installed to the Windows System directory

HwCIns16.dll - Windows 9x/Me Class Installer for HW

HwVdd.dll - VDD for 16 bit application running on 2000-Vista, installed to the Windows System directory

ReadMe.txt - Contains the latest release information about the HW package

HW Library Functions

There are many functions within the HW library that are useful for determining the system configuration. This article discusses the most important procedures, the structHWPCIDEVICE data structure, and provides an examples using the objects listed below for querying the PXI system resources:

HwOpen:
Initializes the HW library this must be called prior to any HW driver functions. This is automatically performed in the ATEasy HW driver (HW.drv), but needs to be explicitly called from other programming languages.

PciGetSlotNumbers([Val] Word wVendorId, [Val] Word wDeviceId, Var Short panSlotNumbers[], Var Word pwDevicesFound):
Returns an array of slot number(s) for the devices with the specified Vendor ID and specified Device ID.

PciGetSlotDevice(Val Long lSlot, Var structHWPCIDEVICE pstPciDev):
Returns the device information for the instrument in the specified slot.

Struct structHWPCIDEVICE:
A data type structure that contains information about devices (instruments) installed in a PXI system. While the procedures above are used to obtain information about a PXI device, it is the structHWPCIDEVICE data structure where that information is stored. Knowing the structure of the data type is key to fully utilizing the HW driver. The full structure provided in the HW driver is provided below for review:

structHWPCIDEVICE: Struct Public
{
    dwVendorId: DWord
    dwDeviceId: DWord
    dwBus: DWord
    stPciSn: structPciSlotNumber
    stPciCfg: strictPciCommonConfig
    aResDesc: structCmPartialResourceDescriptor[8]
    aMemDesc: structHwMemoryDesc[8]
    szId: Char[256]
}

! stPciSn - PCI/PXI slot number (5 low bit: device #, 3 bits: function #, 8 bits: Legacy slot, 16 chassis/slot : 0x203

structPciSlotNumber: Struct Public
{
    dwAsUlong: DWord
}
strictPciCommonConfig: Struct Public
{
    wVendorId: Word
    wDeviceId: Word
    wCommand: Word
    wStatus: Word
    ucRevisionId: Byte
    ucProgIf: Byte
    ucSubClass: Byte
    ucBaseClass: Byte
    ucCacheLineSize: Byte
    ucLatencyTimer: Byte
    ucHeaderType: Byte
    ucBIST: Byte
    stType0: structPciHeaderType0
    dwDeviceSpecific: Byte[192]
}
structPciHeaderType0: Struct Public
{
    adwBaseAddresses: DWord[6]
    dwSubSystem: DWord
    dwSubVendorID: DWord
    dwROMBaseAddress: DWord
    adwReserved2: DWord[2]
    ucInterruptLine: Byte
    ucInterruptPin: Byte
    ucMinimumGrant: Byte
    ucMaxinumLatency: Byte
}
structPxiChassisInfo: Struct Public
{
    dwSize: Long                   ! Fill with sizeof (PXIChassisInfo)
    apcidevBridges: structHWPCIDEVICE[4]    ! Bridges in the chassis
    wChassisModel: Word            ! Chassis model # : i.e. 7010
    wChassisRevision: Word
    dwChassisSerial: DWord
    acUserDefinedData: Char[64]
    wNumberOfSlots: Word           ! Total number of slots in the chassis
}
structCmPartialResourceDescriptor: Struct Public
{
    ucType: Byte
    ucShareDisposition: Byte
    wFlags: Word
    Address1: DWord
    Address2: DWord
    Address3: DWord
}
structHwMemoryDesc: Struct Public
{
    dwPhAddrLow: DWord
    lPhAddrHigh: Long
    dwLength: DWord
    pvVirtualAddress: DWord
}
structHwMemoryDma: Struct Public
{
    ucSize: Byte                   ! Struct Size for Version
    ucBus: Byte                    ! PCI Bus #
    dwLength: DWord                ! Allocation Size
    memdesc: structHwMemoryDesc    ! Returned by HW
    dwDmaAdapter: DWord            ! Returned by HW
}

Using a Device Alias

To demonstrate the utility of the HW driver, let's review a common task confronting anyone writing a program to control PXI test instruments.  When writing a test program, the programmer is always faced with having to identify what instruments are installed in the PXI chassis.  This information is essential to the test program so it knows how to establish a communication link between the host computer (i.e., the test program) and the instruments. Instrument identification can take one of several forms. PXI slot numbers can identify instruments.  Instruments could also be identified by a resource descriptor (VISA) or a board index number.

One traditional method to initialize an instrument would be to use a VISA Resource Descriptor string, for example "PCI4::13::INSTR". ATEasy achieves similar functionality using the nSlot value.  This parameter contains both the Chassis number and the Slot number.  For example, for the nSlot value of 0x108, the hex 0x100 identifies the instrument Chassis as 1 and hex 0x8 identifies the Slot number as 8.

The HW driver also provides a method to create an Alias to an instrument. An alias is a text name that can be assigned to any instrument in a PXI chassis using PXI/PCI Explorer, a PXI resource utility that is installed with the HW package. Using an Alias name for an instrument allows using the instrument without having to identify its specific location in the system. This is useful if an instrument is moved or the system configuration is changed. Since the Alias name identifies the instrument it is no longer location dependent and can simply be remapped using PCI/PXI Explorer to match the existing test programs, and thus avoiding coding changes that might force recertification of a test program. For example to use Alias names to initialize two GX5295s in an ATEasy program the user would simply define the alias using  PXI/PCI Explorer (below), and then use initialization code similar to the example that follows:

Figure 1: Using PXI/PCI Explorer to assign an instrument Alias

lSlot: Long
nStimulusHandle: Short
nResponseHandle: Short

!Using PXI-PCI Explorer Alias to Initalize two GX5295 masters
!Use "Skip On Init" to disable automatic initialization of the GX5295 instruments

!The following procedure uses the HW and GX5295 driver functions,
!Void HwOpen() Automatically called by ATEasy
!Long HwPciGetAliasChassisSlot(sAlias) Returns nSlot used by GXXXInitialize
!Void InitializeMaster(nMasterNumber,nSlot,sVisaResource) Master board Init
!Void GetMasterHandle(pnHandle) Returns the current master handle

!Open the HW driver automatically called by ATEasy
!Hw Initialize()

!Initialization for GX5295 Master 1
lSlot = HW Pci Get AliasChassisSlot("Stimulus") !Gets nSlot value
Dio Initialize Master(1,lSlot,"")
Dio Get MasterHandle(nStimulusHandle)

!Initialization for GX5295 Master 2
lSlot = HW Pci Get AliasChassisSlot("Response") !Gets nSlot value
Dio Initialize Master(2,lSlot,"")
Dio Get MasterHandle(nResponseHandle)

For additional information about using PXI/PCI Explorer, refer to Knowledge Base article Using HW PXI/PCI Explorer Applet. Further details of how to create and use an Alias name is discussed in Knowledge Base article Using an Alias to address PXI instruments.

Instrument Initialization

The process for establishing communication with an instrument is to “Initialize” the instrument. This is done by passing the appropriate identification parameter into an initialization procedure, typically contained in the instrument drivers, and having the procedure return a “handle” that is used as a reference for future communication with that instrument. MTS initialization is performed using the GxXXXInitialize function, where XXX is the mnemonic of the instrument, such as DIO, CNT, DMM, etc. This function can use the device's nSlot parameter, Legacy Slot, VISA Resource Descriptor string or an Alias to Initialize an instrument. This information can be obtained in the PCI/PXI Explorer, or can be obtained programmatically from the structHWPCIDEVICE listed above.

For example, to initialize the GX5295 located in nSlot 0x108 as referenced above, the user can initialize the instrument using Dio Initialize Master(1, 0x108). The device handle can be queried using the ATEasy command Dio Get Master Handle(pnHandle).

The instrument initialization process is very similar to that of opening a file, and using the returned “file handle” for subsequent reading or writing to a file.

[:+[+gx5295+]+:]

Identification of instruments can be done at program design time by hard-coding the instrument identification into the test program, or at run time by querying the system resources and dynamically initializing instruments using the information returned by the system query. To use procedures contained in HW.DLL to query the system resources and identify installed instruments at run time, the HW HwOpen() procedure must be called prior to calling any of the other procedures in the HW driver. In the ATEasy HW driver, this initialization is automatically performed when the ATEasy application runs.

Once the HW driver has been initialized, the PciGetSlotNumbers() procedure returns an array of PXI slot numbers that contain instruments matching the search criteria – often the Vendor ID and/or the Device ID. The device information is contained in the structure structHWPCIDEVICE (listed above). If, for example, you wanted to know how many GX5295 dynamic digital instruments were installed in a PXI chassis, what are their slot numbers, and the firmware revision of each of those instruments, you could use the following code:

Word wVendorId : Word =0x16E2 ! Marvin Tests Solutions Vendor ID
wDeviceId=0x5295 : Word  ! GX5295 Device ID
panSlotNumbers : Short[32] ! Array of slot numbers found
Word pwDevicesFound: Word ! Number of slots matching the Vendor and Device ID’s
pstPciDev: structHWPCIDEVICE
sDeviceInfo : String
i : Long

!HwOpen() Is performed automatically using ATEasy
!Open the HW driver automatically called by ATEasy
!Hw Initialize()

PciGetSlotNumbers(wVendorId, wDeviceId, panSlotNumbers, pwDevicesFound)
If pwDevicesFound<>0
  For i=0 to pwDevicesFound-1
    PciGetSlotDevice(panSlotNumbers[i], pstPciDev)
    sDeviceInfo= pstPciDev.szId
    Print "Slot "+Format(panSlotNumbers[i],"00")+" Firmware: "+Mid(sDeviceInfo,Pos("SUBSYS_",sDeviceInfo)+7,4)
  Next
EndIf

After the slot number for an instrument is obtained, it would be a simple matter to initialize the instrument by calling the instrument's Initialize() procedures and passing the slot number obtained by scanning the PXI system using the example above. Another method of identifying a PXI system's configuration is using the PciGetSlotDevice(). This procedure returns the device information for the instrument in the specified slot. PciGetSlotDevice() can be used in a polling scheme to identify what, if any, instruments are installed in each slot of a PXI chassis, or in all slots in a multi-chassis configuration.

Device Settings

The Device Settings are as shown in PCI/PXI Explorer,

Figure 2: Device Settings

To view the Device Settings, expand the folder under the desired instrument. This folder displays the Bus, Device, Function, Device ID, Vendor ID and the memory allocated for the module. These parameters can help determine if the module has had the correct resources allocated during the boot process. For example, if neither of the Memory parameters is showing that memory has been allocated for the instrument, then the module was not allocated memory resources on system boot-up, which could indicate that the instrument drivers need to be installed. Typically, this is done prior to installing the hardware and allows these resources to be allocated when the computer/Windows boots. The Device Settings are informational only and are not editable by the user.

The Device Settings information can be obtained programmatically using HW driver functions such as PciGetSlotDevice. The PciGetSlotDevice function can be used to obtain information on all devices in a system and allow the user to write driver functions using the information contained in the HWPCIDEVICE structure. The following is an ATEasy procedure that displays the Device Settings of all devices found in the chassis.

Slot: Long
nCntr: Short
stPciDevice: structHWPCIDEVICE

!DisplayDeviceInfo
!This example demonstrates using the HW driver library function HwPciGetSlotDevice
!to obtain PCI/PXI device configuration of each slot of a system. The variable
!stPciDevice is defined as a HWPCIDEVICE structure. The for-next loop prints
!the information found in each populated slot

Log.PlainText=True
ClearLog()

HW Initialize()             ! Must be called before any HW call
HW Pci AssignDeviceSlot()   ! Assign slots to all devices

for lSlot=0 to HW_MAX_SLOTS-1
    HW Pci Get SlotDevice(lSlot, stPciDevice) ! Get the device in the specified slot
    if stPciDevice.dwVendorId<>0              ! if populated slot, print the device info
       append "    Slot ";lSlot;" - Bus ";stPciDevice.dwBus;", Device ";\
              stPciDevice.stPciSn.dwAsUlong and 0x1F;\
              ", Function ";(stPciDevice.stPciSn.dwAsUlong shr 5) and 0x7
       append "     - VendorID 0x";ucase(str(stPciDevice.stPciCfg.wVendorId, 16));\
              ", SubVendorID 0x";ucase(Str(stPciDevice.stPciCfg.stType0.dwSubVendorID, 16))
       append "     - DeviceID 0x";ucase(str(stPciDevice.stPciCfg.wDeviceId, 16));\
              ", SubSystem 0x";ucase(Str(stPciDevice.stPciCfg.stType0.dwSubSystem, 16))

       for nCntr=0 to 7
           select stPciDevice.aResDesc[nCntr].ucType
           case 1
              append "     - Port:      0x";\
                     ucase(Str(stPciDevice.aResDesc[nCntr].Address1, 16));\
                     " Length 0x";ucase(str(stPciDevice.aResDesc[nCntr].Address3, 16))
           case 2
              append "     - Interrupt: 0x";\
                     ucase(Str(stPciDevice.aResDesc[nCntr].Address1, 16))
           case 3
              append "     - Memory:    0x";\
                     ucase(Str(stPciDevice.aResDesc[nCntr].Address1, 16));\
                     " Length 0x";ucase(str(stPciDevice.aResDesc[nCntr].Address3, 16))
           endselect
       next
    endif
next

Conclusion

The HW driver, coupled with the PCI/PXI Explorer Applet, provides the user a powerful toolset to not only obtain system information, but can be used to automate identification and initialization of the instrumentation contained in the test system. For additional information about how to use the HW driver and the PCI/PXI Explorer Applet, review the HW programming example installed with ATEasy (Hw.prj) located in the ATEasy driver directory and the files installed the Program Files\Marvin Test Solutions\HW. In addition refer to the following knowledge base articles: Using HW PXI/PCI Explorer Applet, Scanning a PXI system to learn about system resources and Using an Alias to address PXI instruments.

Adding TCP/IP-based LAN buffer Peek and Flush to ATEasy WinSock Functions - Published on 6/1/2021

6/1/2021

Introduction

In order to assert more control in LAN data exchange, you may find it useful to peek at the available buffer data.

Peeking doesn't empty the buffer as with the WsReceive ATEasy function. To maintain communication, you will eventually need to flush a buffer.

This article discusses how to use Windows Sockets 2 API in ATEasy combined with ATEasy internal WinSock functions.

The example shows how to set up a simple client-server connection to send, receive, peek and flush TCP/IP data.

For more information on using DLLs, see ATEasy Help. In the example we use Ws2_32.dll and the API defined in Winsock2.h. See the recv function as detailed here: MSDN: recv function

[:+[+ateasy+]+:]

Creating a Server Socket and Connecting to the Client

You can create simple server and client sockets with ATEasy internal library WinSock functions. In this example the client and the server will run on the same machine and communicate with each other. You can also use the internal library to resolve the server IPv4 address to its handle to bind to the created server socket. Lastly, the server socket is set to listen and a separate thread for the client is created.

! Create a server socket
hServerSocket=WsCreate(aWsTcpIp, 0)

! Bind to for example localhost --> TCP socket 127.0.0.1:10
lStatus=WsBind(hServerSocket, 10, WsGetNameAddress("127.0.0.1"))

! Place socket to listen
lStatus=WsListen(hServerSocket)

! New thread to connect client and send test data
CreateThread(ClientConnectAndSend, 1)

Figure 1. Server socket creation, binding and setting to listen at example address "127.0.0.1:10". Client thread creation.

Creating a Client Socket and Connecting to the Server

The example uses a separate thread for the client. In the client's thread, a client socket is created and connected to the server. After connection, data packet "42\x0" with a null byte terminator is sent to the server.

! Client socket created
hClientSocket=WsCreate(aWsTcpIp, 0)

! Connect client to server
WsConnect(hClientSocket, 10, WsGetNameAddress("127.0.0.1"), lTimeout)

! Send data
lStatus=WsSend(hClientSocket, lTimeout,,"42\x0")
m_bSent=True

Figure 2. Client socket creation, connection and sending bytes to server

Creating a Client Socket and Connecting to the Server and Sending Data

Once the incoming client connection is accepted and data received, a null-terminated peek buffer is initialized with 1 kB of null bytes. The peeked data will be used to Pass/Fail the example's test. Note that ATEasy socket handle are the same as Windows socket handle and can be interchanged.

! Accept incoming hServerSocket connection
hPipe=WsAccept(hServerSocket, 10)

! Wait until data is sent
if hPipe>0
   while m_bSent=False
   endwhile
else
   TestStatus=ERR
   ExitTest
endif
! Allocate 1 kB for sPacket
sPacket=Dupl("\x0",1024)

! Peek (recv with MSG_PEEK flag) buffer data - not receiving data
lStatus=recv(hPipe,sPacket, 1024, MSG_PEEK)
if lStatus<>3 OR sPacket<>"42"
   TestStatus=FAIL
endif

TestResult=sPacket

Figure 3. Accepting client connection and its sent data. Peeking the buffer with recv does not flush sent data from client.

Server Peeking and Receiving the Data

Once the data is peeked, the sent data can be received and flushed. Flushing can be done by receiving a byte of data at a time until none are available. One last peek is done to confirm no more data is available.

! Receive data
lStatus=WsReceive(hPipe, 1, ,sPacket, len(sPacket))
if lStatus<>2 OR sPacket<>"42"
   TestStatus=FAIL
endif

! Ensure buffer is empty - 1 byte at a time
while lStatus>0
   lStatus=WsReceive(hPipe, 1, ,sPacket, 1)
endwhile

! Peek (recv with MSG_PEEK flag) buffer data to ensure it has been emptied
lStatus=recv(hPipe,sPacket, 1024, MSG_PEEK)
if sPacket<>""
   TestStatus=FAIL
endif

Figure 4. Once more ATEasy WinSock module is used to receive data. A peek is performed to confirm buffer is void of data

Conclusion

ATEasy provides an intuitive interface for conducting WinSock communication. Peeking and flushing sockets can be done with importing Windows Sockets 2 DLL Ws2_32.dll by using the Winsock2 header per above mentioned MSDN. Recv and Recvfrom functions can be used to peek and flush sockets efficiently in ATEasy.

Example Files

ATEasy example project files used in this article:

LanBufferPeekFlush

TS-900 Load Board Design Considerations - Published on 6/1/2021

6/1/2021

TS-900 Load Board Design Considerations

The load board used to interface the device under test (DUT) to the instruments in the TS-900 Semiconductor Test System is a critical component in the overall test system performance.

The careful consideration of its design will allow consistent and repeatable test results increasing first pass yields and minimizing false failures, reducing the need for retesting failed devices and increasing test throughput.

Designing the load board might look like a routine task that can be accomplished easily, however with new technologies and increasingly complex devices to be tested, there are many more issues to be considered when developing the design.

Some factors that need to be considered early are board layout, parts placement, power planes and grounding. These factors all help minimize crosstalk, noise and current leakage issue and improve the electrical, signal performance and integrity.

[:+[+ts-900+]+:]

TS-900 Load Board

The Device Under Test (DUT)

The first critical component in the design of the load board design is the DUT itself. Understand its characteristics; is it mixed signal, analog only or digital only? What are its power supply needs, single or multiple (analog and digital) supplies, ground pins – how many? In mixed signal devices the ground pins are usually separated into analog and digital grounds.

Also important are clock requirements: single or multi clock; does the device requires operating with a crystal (internal oscillator), does it have a PLL (Phase Lock Loop) – what components are needed for the PLL to operate?

In mixed signal and analog devices there might be outputs with high source impedance that requires buffering to prevent loading of the signal during operation. Also some inputs might require special signal conditioning for the DUT to operate correctly. Are there needs for pull-up or pull-down resistors, bypass capacitors, filtering?
On devices with high power requirements, power dissipation will need to be addressed. Power supply requirements are critical and decoupling capacitors are essential for their operation.

All of these issues require careful planning for the external components positioning, including relays to allow for connection and disconnection of components and instruments during testing. Understanding these requirements is critical for the load board lay out to maximize performance, signal integrity and minimize noise generation and crosstalk.

Test Socket

One of the most important components on the load board is the DUT socket. Its selection is critical to the overall performance of the load board and ultimately the test system. There are many different types of sockets from different manufacturers and selection will depend on several factors like: package type, frequency of operation, cost, contact type, contact material, DUT power requirements, temperature of operation, etc. The emphasis here is for reliability, the socket will be used tens of thousands if not hundreds of thousands of times, and it is the weakest link on the tester set up. During operation contacts are compressed and subject to wear, if used for temperature testing it sees extreme temperature variations, and debris and particles accumulates on its contacts after many insertions and removal of the DUT.

These and other factors create an environment where the socket will begin to deteriorate causing intermittent contact failures and over time it will eventually fail. One option that should be investigated when selecting the socket is whether the different socket components (contactors, springs, housing) can be replaced in case of damage, this will allow you to repair a socket and keep maintenance costs down. Careful consideration to the selection of the DUT socket will help you minimize the impact of the socket on the overall reliability of the test system.

Load Board Design

When it comes to high speed digital devices the ideal characteristic impedance for the load board should be 50 ohms. When laying out the high speed signal traces maintaining 50 ohm impedance will increase the bandwidth of the signals and prevent mismatching. A practical rule to remember is that it takes about an inch of trace for every nanosecond of signal rise time, so for a 2 nanosecond rise time signal a trace greater than 2 inches must be considered to be a transmission line and should be treated as controlled impedance trace.

A typical load board will have a minimum of 4 layers (see Fig. 1), high speed parallel signals and high speed clocks should be laid out first and should be as straight as possible from the source to the DUT pins; also try to reduce parallel trace runs, the longer they run side by side the more the propensity to have crosstalk between them. A good rule to follow is to have two times the width of the trace when routing signals close to each other. Signal traces should be equal length to minimize skew between signals, try to avoid running the signals through vias or minimize them as much as possible, they create impedance mismatches and degrade the signal integrity.

Other things to avoid during layout are sharp 90 deg. angle corners in high speed traces, turn traces using two 45 deg corners; this will lower noise generation and improve signal integrity.

If there is space available a highly effective technique for reducing crosstalk is to separate high speed signal traces (like high speed clock lines, reset or strobe signals) that run parallel to each other with a ground trace between them. This ground trace should be tied to the digital ground plane with vias at each end and at regular intervals, the closer the ground vias are to each other the lower the impedance of the ground trace, effectively creating a shield around the signal trace. If differential, high speed clock signals are involved, they should be routed together as a pairs with a ground trace between them and between other signals.
Sometimes there are components that are needed for the operation of the DUT such as crystals for internal oscillators or more specific the loop capacitor for an internal PLL. These components are external to the DUT and should be placed as close to the pins they belong to as possible. Since they might be susceptible to noise pickup, they could be shielded using a guard ring trace around these components.

A side effect of adding required components to the DUT (like pull-up or pull-down resistors, capacitors, etc) is how are you are going to test for the parameters on these pins when these components are connected to the DUT. Connecting instruments like source meters or DMMs to these pins will require a relay to disconnect these components during parameter measurements; a SPDT relay contact per pin and per component will allow you to connect and disconnect the instrument and component during tests and operation. The relay common (C) terminal should be connected to the DUT pin; the normally closed (NC) terminal should be connected to the component while the instrument will be connected to the normally open (NO) terminal. Typical relays used should be small signal relays with low capacitance and high signal bandwidth like the Coto 2200 series, Omron G6K series, NEC Tokin UA2/UB2 series, Panasonic GQ (AGQ) series etc.

Load Board Layout

Typically, when laying out the traces for high speed signals, is better not to introduce stubs. These stubs act like antennas, they create impedance mismatch and degrade performance by either generating or picking up noise. Also, it is usually not a good layout rule to take off and route a signal perpendicular from a trace to connect it to a component, pin or trace, maintain the physical trace continuity from beginning to end.

Power supply pin decoupling capacitors should be placed as close to the supply pin as possible using quality ceramic surface mount capacitors; DUT ground pins should be connected directly to the ground plane, avoid running a ground trace from a via to the DUT ground pin; this also applies to the ground connections for bypass capacitors. The rule here is to keep ground connections short.

Whenever possible power supply traces to the DUT pins should be wider than normal, 2x to 3x wider; this lowers the impedance to the power supply and improves current carrying capability.

On a mixed signal device, the analog and digital power planes should be split (see Fig. 2) to separate the noise generating digital domain from the noise sensitive analog domain. Lay out analog signals on top of the analog power plane and digital signals on top of the digital power plane, this will maintain the return signal currents on top of its corresponding power plane minimizing noise coupling and generation.

It is important to understand that even with low speed mixed signal devices, with today’s fast digital circuitry it is the fast edge rates (rise and fall) and not the frequency of the signal that are the cause of noise generation.

When dealing with sensitive analog pins is important to keep this digital noise away from them. Noise immunity from this digital noise is achieved by separating the digital signals away from the analog traces during the layout process. PCB traces that carry analog signals to high impedance analog inputs should be completely separated from running next to digital traces to prevent noise coupling. If, because layout constrains, the two types of signals must be close to each other then isolating the analog trace with ground traces between them would improve noise immunity considerably.

Power Supplies and Ground Planes

During lay out of a mixed signal load board any component, including buffers, op amps, analog power supply pins that are part of the analog portion of the DUT should be connected to the analog supply power plane. Any digital supply pin and any digital circuit or components should be connected to the digital supply power plane; do not mix components from the two different power planes. The digital output pins generate fast current transients every time their outputs toggle creating noise that couples to the power lane, you want to keep these transient away from the analog power supply plane and prevent the injecting noise into the analog circuitry.

Decoupling capacitors, typically up to 100 KHz use electrolytic caps, from 100 KHz to about 10 to 15 MHz use 0.1uf, from 15 MHz to 100 MHz use 0.01uf and above 100 MHz a combination of 0.001uf with the PCB power and ground planes would be good a compromise; use good quality capacitors, Tantalum for the electrolytic caps and specially the ceramic caps should be surface mount. When decoupling the power supply pins on both analog and digital supply pins, place the caps as close the pins as possible and the cap’s ground connection should be directly to ground, avoid connecting to ground through a trace and a via. On high power devices include a quality tantalum capacitor in parallel with the ceramic capacitor to supply the current demand for the device.

On a four layer board, the two internal layers are usually the power and ground layers while the two outside layers are used for signal routing. The power planes for a mixed signal device load board should be split between an analog supply plane and a digital supply plane (see Fig.2). It is necessary that at least one layer of the load board be dedicated to a solid ground plane. Source Power Supply ground connections (both analog and digital supply grounds) to the ground plane or planes should be made at one point or location.

The following figure shows the typical arrangement of the load board layers. When more than 4 layers are needed, add alternate ground and signal planes on the bottom of the load board. All the ground planes should be connected together to the power supply grounds with heavy, low impedance connections.

The signal routing for the digital traces and any digital signal or component should be routed over the digital power plane on the top signal layer, while any analog signal traces or analog components should be routed over the analog power plane on the top signal layer.

The reason for routing analog signals and digital signals on top of their corresponding power planes has to do with the return paths the currents take on the PCB. Any time a signal travels down a PCB trace a corresponding return current is generated. The path this return current takes is mostly dependent on the resistance (takes the path of least resistance) of the PCB plane for DC and low frequency signals, in this case they literally go in a straight line from source to load and back. As the frequency of the signal increases (around 1 MHz and above) the path the return current takes is mostly concentrated under the original signal trace (takes the path of less inductance), this is called the “proximity effect” and it follows the trace as it is laid out on the PCB. In reality the process is somewhat more complicated than this and includes several variables that affect it, but in general and what concern us here are the current return paths especially for digital signals.

For any digital signal that is routed on the top layer and crosses the power planes split line, you should include locations to add capacitors between each power plane and ground close to where the signal crosses the power planes. These capacitors allow for the return currents, which flow on the plane adjacent to the trace, to pass across the power planes close to where the signal crosses the power plane split (see Fig. 3). The reason for two capacitors is to minimize the possibility of coupling digital noise between the two planes.

Sometimes this might not be necessary because there may be a short return current path that somewhere we cannot see. So, it is generally good to lay out your board for use of these capacitors, and then test for differences in signal integrity with and without these capacitors in place.

The bottom layer signal routing does not need to follow this restriction since the ground plane is next to the signal layer providing a return path for the currents and shielding any noise from the power planes. Keeping the correct signal routing above their respective power plane will minimize the current loops that degrade signal integrity.

Use separate power sources for each power supply plane. Use a linear output power supply for the analog supply because mixed signal devices do not behave well with the high frequency supply noise generated by switching supplies.

Sometimes you have to deal with a high output impedance analog pin that have to drive external circuitry, in this situation it necessary to buffer the output signal using an op-amp (with low input bias currents) to be able to drive the circuitry without unnecessarily loading the signal down; if an op-amp is used, a relay might need to be added between the DUT pin and the op-amp to allow parametric testing of the DUT pin.

Other DUT Testing Equipment

At some point it might be necessary to connect the TS-900 tester to either a wafer prober or a packaged part device handler. In this case a new load board will be designed with connectors for the wire harnesses used to connect the tester to the equipment. The wire harness should be built for high frequency, with 50 ohms impedance coaxial wires and connectors to maximize signal integrity and minimize noise pick up.

You should apply the same mixed signal design criteria when designing a load board for mixed signal device testing in a handler or prober as you would for a normal load board. The same separation of the power planes should apply here. Keeping the digital and analog signals separate in the wire harness will allow you to route the signals at the connector location into separate power planes.

Unless there is a direct docking between the TS-900 and the handler, a DUT interface card for the handler will have to be designed to accommodate the wire harness connectors, any critical external components and the handler contactor needed to test the DUT.

[:+[+ts-900e-5g+]+:]

Conclusions

Use a solid, single layer ground plane. Do not split the ground plane. Use the thickest cooper metal planes as feasible. It reduces inductance and resistance to connections.

Split the power planes; keep all power planes in the same board layer. There should be a power plane for the analog circuitry and a power plane for the digital circuits.

Locate all analog components and traces over the analog power plane and all digital components and traces over their respective digital power plane.

Trace width should remain constant throughout the length of the trace.

Use separate power sources for each plane. It is best to use a linear voltage regulator for the analog power source because analog and mixed signal devices do not behave well with the high frequency supply noise produced by switching supplies.

Signal that cross the split between power planes should include locations to add capacitors between each power plane and ground. Locate these capacitors very close to the signal lines and the power plane split. Add these capacitors if during test, the signal generates unwanted noise.

If the DUT has multiple ground pins, connect all of them to the ground plane. The same is applicable to the + or - power supply pins; each supply pin needs to be connected to its appropriate supply plane and decoupled with capacitors to ground.

Decoupling capacitors should be positioned next to the power supply pins and connected directly to the ground plane. A good rule is to use high quality ceramic, surface mount, capacitors, 0.1uf when frequencies involved are below 10 MHz, 0.01uf frequencies are above 10 MHz and 0.001uf for 100 MHz and above; for High Current devices add a quality Tantalum capacitor in parallel with the ceramic capacitor.

If, because of layout constraints, you are running analog and digital signals parallel to each other, try to separate them with a ground trace; tie this ground trace at both ends and at multiple points in between to the ground plane to shield the signals.

Use vias only when absolutely necessary. Avoid the use of vias when routing high frequency signals.

The distance between traces running in parallel should be equal to two trace widths when routing signals close to each other.

Always follow the currents. We are dealing with circuits here and the current always flows from a source to the load and then back via a return path. Keeping track of where the current flows and how it flows is essential in making the load board work well.

How to modify the ATEasy Test Log output - Published on 6/1/2021

6/1/2021

This article covers the following Log file subjects:

How to set the Log format to HTML or Text

How to modify the ATEasy Log strings

How to change the TestLog Company Logo

How to change the position of the TestLog Company Logo

How to add additional information to the TestLog

Note:
An ATEasy application (Q200188.zip) that demonstrates how to adjust the various TestLog settings, shown here, can be downloaded by clicking on this link Q200188.zip

[:+[+ateasy+]+:]

Setting the ATEasy Log Format

The ATEasy Log format can be set to either HTML or Text as follows:

In the ATEasy Menu go to the Tools..Options. In the Log tab check the "Use the HTML format as default" box to set the output to HTML. If the box is not checked the output will be Text mode.

In the Test Executive similar example exist in the Options, Customize or Users forms.

The format can also be changed at runtime by setting the PlainText property of the internal variable Log. The PlainText property can be used to set a value that determines whether the log file will be displayed and opened as either text or HTML. It can also be used to check if the log file is set to HTML or Text mode. See ALog control, PlainText and "Log Window, Using the Log, TestLog, and DebugLog Internal Variables" in ATEasy Help for more information:

Example

!Adding the following statement to the System.OnInitSystem() event
!sets the log format to plain text
Log.PlainText=True

How to modify ATEasy Log strings

The following example shows how to remove the Signature line from the ATEasy TestLog output. Similiar approaches can be used to modify/remove other log string components. Note: The code shown in this example is given in the ModifyTestLogFooter() System procedure in the accompanying ATEasy application.

The following example is written around three ATEasy procedures
1) GetLogString()
2) Replace()
3) SetLogString()

1) GetLogString(): While ATEasy is executing Event procedures GetLogString() retrieves the current Log string. The contents of the Log string for the different Event procedures are shown below. See ATEasy Help for more information.

Module Event	GetLogString() returns
OnInitSystem	The application top header includes the company logo
OnInitProgram / Program.OnInit	The serial number and the start time.
OnInitTask	The task header.
OnEndTest	The test log line (MIN/MAX, RESULT, etc.), including the test table header if required.
OnEndProgram / Program.OnEnd	The stopped time, elapsed time, UUT status, Signature

2) Replace(): Replace() returns a string in which a specified substring has been replaced with another substring. See ATEasy Help for more information.

3) SetLogString(): This procedure is used to set the next log string used by ATEasy. Setting the log string inside a test will cause ATEasy to output the string after the OnEndTest event is called. See ATEasy Help for more information.

As you can see from Item1 above, to modify the Signature line the following code will need to be added to the System.OnEndProgram() event or if the Test Excutive driver is being used it will need to be added to the beginning of the TestExec.OnEndProgram() event:

Example

s:string! String used to store the Log string
sSub:string! String used to store the line to be removed

s=GetLogString()            ! Get the current log string
if Log.PlainText=TRUE then  ! Check to see which log format is being used
   !If the log format is Plain Text then remove this line
   sSub="Signature    : ...................."
else
   !If the log format is HTML then remove this line
   sSub="Signature       "align=left>: __________________________________"
endif
s=Replace(s, sSub,"",,,True)! Remove the string sSub from the original log string
SetLogString(s)             ! Set the new log string

How to change the TestLog Company Logo

Note: See ChangeCompanyLogo() System procedure in the accompanying ATEasy application

There are two ways of replacing the company logo:

The quick solution is to save your company logo to the same size as the built in image (103x44) and copy it to C:\Program Files\ATEasy\CompanyLogo.gif.

Alternatively, you can change the default Company Logo file location. To do this you will need to change the HTML header that is output to the test log after OnInitSystem is called. You can do that by calling GetLogString(), modifying the return string with your own file location and then calling SetLogString().
To view the original string you can right click on your log window and select View Source. Then look for CompanyLogo.gif, you will need to modify the table around it.

Notes:

1) If your company logo file is larger than 103x44 you will have to change the Right and Left Width values to adjust the location of the logo
2) If you are using the Test Exec you will need to use the following command to set the string (instead of Get/SetLogString):

TestExec Log Set InitialString()

Example:

s        :string  ! String used to store the Log string
sSub       :string  ! String used to store the line to be removed
sFileLoc  :string  ! String used to store new Logo image file location

s=GetLogString()            ! Get the current log string
sSub="C:\\Program Files\\ATEasy\\CompanyLogo.gif" !This is the default Logo image file location
s=Replace(s, sSub,sFileLoc,,,True)   ! Add in the new Logo location
SetLogString(s)             ! Set the new log string

How to change the position of the TestLog Company Logo

Note: See ChangeCompanyLogo() System procedure in the accompanying ATEasy application.
As before you will need to change the HTML header that is output to the test log after OnInitSystem is called. You can do that by calling GetLogString(), modifying the return string with your new settings and then calling SetLogString(). To view the original string you can right click on your log window and select View Source. Then look for your company logo image filename, you will need to modify the table arround it.
The logo can be shifted horizontally adjusting the LEFT and RIGHT Width settings and by using the HSPACE attribute.

Example:

s       :string  ! String used to store the Log string
sSub      :string  ! String used to store the line to be removed
sNewStr:string  ! String used to store new Logo position

s=GetLogString()            ! Get the current log string
sSub=": " \
           ""
sNewStr=":"  \
          ""
s=Replace(s, sSub,sNewStr,,,True)! Add in the new Logo position in the Test Log
SetLogString(s)             ! Set the new log string

How to insert additional information to the TestLog

Additional information can be added to the TestLog by using the Append() procedure. This statement appends a message to the log string that ATEasy generates. For example, running an Append statement from a test will print its message after test results instead of ahead of them. See ATEasy Help for more information.

Example:

DMM Measure (TestResult)
if (TestResult Append "Result too low - check circuit X"
elseif (TestResult>Test.max)
Append "Result too high - check circuit Y"
endif

Programming GX1110 for AM and FM Modulation - Published on 6/1/2021

6/1/2021

Introduction: The GX1110 is a 100 MHz, single-channel PXI Arbitrary Waveform Generator (AWG) that can also operate as a function generator with Direct Digital Synthesis (DDS) of the clocking resource. Built-in waveforms are available for use with both the DDS or AWG modes of operation and include Sine, Triangle, Ramp, Noise, Gaussian pulse and Sinx/x.

The GX1110 can apply either Amplitude Modulation (AM) or Frequency Modulation (FM) to the carrier waveform using either an internal modulation source or an external modulation signal.

This article demonstrates how to program the GX1110 to generate AM and FM signals using an internal modulation source. The modulating signal has three parameters that define its characteristics.

For AM, those parameters are the modulation frequency, the modulation amplitude and the modulation waveform.

For FM, the parameters are modulation frequency, deviation and modulation waveform.

[:+[+gx1110+]+:]

Specifications for the modulation parameters are:

Modulation Parameters:

Source: Internal or External
Frequency: 0 Hz - 20 KHz
AM Amplitude: 0% - 100%
FM Deviation: 0% - 100%
Waveform: Sine, Square, Triangle, Ramp Up, Ramp Down, Noise

Program Examples: The following ‘C’ code sets the GX1110 to generate a
100.0 KHz carrier signal with a 5.0V amplitude, and defines the modulation to be FM, 16.0 KHz modulation frequency and a 20.0 KHz frequency deviation. The resulting waveform is shown in figure 1.

// Initialize the GX1110 in slot #6
GtWaveInitialize(6,&nHandle,&nStatus);
// Reset the GX1110
GtWaveReset(nHandle,&nStatus);
// Set the GX1110 to Function Generator mode
GtWaveSetOperationMode(nHandle,GTWAVE_OPERATING_MODE_FUNC,&nStatus);
// Set output to 5.0V, Enabled, Sine Wave, 100.0 KHz Frequency
GtWaveSetAmplitude(nHandle,GTWAVE_CHANNEL_A,5.0,&nStatus);
GtWaveSetOutputState(nHandle,GTWAVE_CHANNEL_A,True,&nStatus);
GtWaveFuncSetWaveform(nHandle,GTWAVE_CHANNEL_A,GTWAVE_WAVEFORM_SINE,&nStatus);
GtWaveFuncSetFrequency(nHandle,GTWAVE_CHANNEL_A,1.0E5,&nStatus);
// Set FM modulation source to internal
GtWaveFuncGetFmSource(nHandle,GTWAVE_CHANNEL_A,GTWAVE_FUNC_FM_SOURCE_INTERNAL, &nStatus)
// Set modulation to FM Sine Wave, 16 KHz Modulation, 20.0 KHz Deviation
GtWaveFuncSetFmWaveform(nHandle,GTWAVE_CHANNEL_A,GTWAVE_WAVEFORM_SINE,&nStatus);
GtWaveFuncSetFmFrequency(nHandle,GTWAVE_CHANNEL_A,16.0E3,&nStatus);
GtWaveFuncSetFmDeviation(nHandle,GTWAVE_CHANNEL_A,20.0E3,&nStatus);
// Enable FM modulation
GtWaveFuncSetFmState(nHandle,GTWAVE_CHANNEL_A,True,&nStatus);
// Set the GX1110 to Run state
GtWaveRun(nHandle,GTWAVE_CHANNEL_A,&nStatus);

Figure 1: Frequency Modulation Waveform

The following ‘C’ code sets the GX1110 to generate a 1.4 KHz carrier signal with a 5.0V amplitude, and defines the modulation to be AM, 50.0 Hz modulation frequency and 100% modulation level. The resulting waveform is shown in figure 2.

// Initialize the GX1110 in slot #6
GtWaveInitialize(6,&nHandle,&nStatus);
// Reset the GX1110
GtWaveReset(nHandle,&nStatus);
// Set the GX1110 to Function Generator mode
GtWaveSetOperationMode(nHandle,GTWAVE_OPERATING_MODE_FUNC,&nStatus);
// Set output to 5.0V, Enabled, Sine Wave, 1.4 KHz Frequency
GtWaveSetAmplitude(nHandle,GTWAVE_CHANNEL_A,5.0,&nStatus);
GtWaveSetOutputState(nHandle,GTWAVE_CHANNEL_A,True,&nStatus);
GtWaveFuncSetWaveform(nHandle,GTWAVE_CHANNEL_A,GTWAVE_WAVEFORM_SINE,&nStatus);
GtWaveFuncSetFrequency(nHandle,GTWAVE_CHANNEL_A, 1.4E3,&nStatus);
// Set modulation to AM Sine Wave, 50 Hz Modulation, 100% Amplitude
GtWaveFuncSetFmWaveform(nHandle,GTWAVE_CHANNEL_A,GTWAVE_WAVEFORM_SINE,&nStatus);
GtWaveFuncSetFmFrequency(nHandle,GTWAVE_CHANNEL_A,50,&nStatus);
GtWaveFuncSetFmDeviation(nHandle,GTWAVE_CHANNEL_A,20.0E3,&nStatus);
// Enable FM modulation
GtWaveFuncSetFmState(nHandle,GTWAVE_CHANNEL_A,True,&nStatus);
// Set the GX1110 to Run state
GtWaveRun(nHandle,GTWAVE_CHANNEL_A,&nStatus);

Figure 2: Amplitude Modulation Waveform

How to use Microsoft Visual Studio to debug a DLL function called from ATEasy - Published on 6/1/2021

6/1/2021

ATEasy is capable of interfacing with and calling external libraries such as DLL, .NET assemblies and ActiveX components.

Sometimes it is necessary and useful to be able to debug and step into the code that resides in the external library. The procedure described here demonstrates debugging a C/C++ DLL debugged in Visual Studio 2005 . A similar approach can be done to debug ActiveX or .NET assembly and other development environments than Visual Studio (for example LabWindows /CVi).

Follow these steps to debug your DLL using Visual Studio:

1. Compile your DLL project within Visual Studio C++ in Debug mode.

2. Set the Visual Studio DLL project debug Command to ATEasy (ATEasy.exe) and the Working Directory to the ATEasy directory path (by default:
C:\Program Files\ATEasy\):

[:+[+ateasy+]+:]

3. Place a breakpoint in the DLL source in the function ATEasy will call .

4. Begin a debug session from within Visual Studio. This should result in ATEasy being started by visual studio debugger:

5. Make sure your ATEasy module library points to the debug version of the DLL file:

6. In ATEasy, run the DLL function using DoIt or Start:

7. The Visual Studio IDE should be paused when the breakpoint set earlier is reached. The debugger can now be used to step through the code:

8. You can confirm that the correct DLL is loaded by going to Debug | Windows | Modules from the Visual Studio file menu:

Using the GX5296 to Emulate the SPI Bus - Published on 6/1/2021

6/1/2021

Introduction

The use of digital test instruments for emulating common serial bus protocols can provide benefits over dedicated bus test products and often presents a trade-off between functionality, flexibility and cost. For example, a dedicated test instrument solution can offer more extensive test capabilities such as protocol support for controlling and analyzing traffic between a bus controller and a device under test.

However, a dynamic digital solution using the GX5296 can offer the flexibility to adapt to nonstandard line rates and timing as well as supporting other digital test needs such as multi-site test capability, analog testing and the ability to test the connectivity of the Device Under Test (DUT) to the test system. Ultimately, the goal is to identify those instances where the clever or novel application of a digital test tool is appropriate and provides tangible benefits.

This paper presents an overview of how the rich feature set of the GX5296 dynamic digital I/O instrument can be used to support SPI serial bus interfaces. By using this dynamic test solution, users can potentially realize a lower cost compact test system solution with similar capabilities of the “Big Iron” test systems of the past, along with providing a common user control interface and expandability for future requirements.

[:+[+gx5296+]+:]

The Serial Peripheral Interface (SPI) bus is a synchronous serial communications interface specification used for short distance communication. Refer to the block diagram shown in Figure 1. SPI devices communicate in full duplex mode and use a master-slave configuration. Multiple slaves can be selected by using individual slave select lines. The basic SPI bus specifies four logic signals:

• SCLK : Serial Clock (output from master)
• MOSI : Master Output, Slave Input (output from master)
• MISO : Master Input, Slave Output (output from slave)
• SS : Slave Select (Active low, output from master)

Figure 1: SPI Bus Block Diagram

Refer to Figure 2, the SPI bus master configures the clock polarity and clock phase with respect to the data. These are referred to as CPOL for the polarity setting and CPHA for the clock transition setting. The following example illustrates how the rich feature set of the GX5296 can be set up to test a SPI bus in any configuration. For our example the GX5296 is configured to simulate a master testing a slave in a CPOL=0 and CPHA=0 configuration.

Figure 2: Clock Polarity and Phase Timing Diagram

GX5296 Using GtDio6x Software
The GX5296 is supplied with Dio6xEasy - graphical vector development / waveform display tools, GtDio6x-FIT - File Import toolkit (optional) as well as a virtual instrument panel - GtDio6x-Panel, 32 / 64-bit DLL driver libraries, and documentation. The GtDio6x virtual panel can be used to interactively control and monitor the instrument from a window that displays the instrument’s current settings and status. In addition, various interface files provide access to the instrument’s function library for programming tools and languages such as ATEasy, C/C++, Microsoft Visual Basic®, Delphi, and LabVIEW.

Our example focuses on using the GtDio6x-Panel (software virtual panel) launched from the desktop, or by selecting the program from Windows Start menu. It is recommended that most of the GX5296 setup be performed using the panel and saved to a file. This provides the simplest method to set up and or reuse test conditions.

DIO to UUT Connections
The GX5296 DIO connections to the unit under test (UUT) are as follows: channel 0 is connected to the SCLK pin, channel 1 is connected to the master out (MOSI) pin, channel 2 is connected to the slave input (MISO) pin and channel 3 is connected to the slave select (SS_L) pin.

Channels Setup
As CPOL and CPHA are set to zero, SCLK is a positive edge clock and data is captured on the clock's positive transition. To achieve the positive edge clock required for this example, the SCLK channel is set to the Return To One data format. If CPOL is set to one SCLK would be a negative edge clock and therefore the channel would need to be set to the Return To Zero data format. All other channels are set to the “No Return” data format, as these pins will not need to change within the timing period.

Before beginning the instrument setup, reset the GX5296 instrument by pressing the reset button on the panel. To configure the GX5296 channels select the channels page. Refer to Figure 3 below and make the following settings. After each selection has been made, press the Apply Settings button.

Set the Channel Mode of channels 0 thru 3 to Dynamic I/O
Set the Channel Mode of all other channels to Disabled
Set the Capture Mode of each active channel to Window Open Edge
Set the Data Format of channel 0 to Return To One
Set the Data Format of all other active channels to No Return
Set the Phase and Window settings of channel 0 to Step TSet0
Set the Phase and Window settings of all other active channels to Step TSet1
Configure the Drive and Sense logic levels for each channel

Figure 3: Configuring GX5296 Channels

System Clock Setup
The data rate used in this example is 25MHz. In order to achieve the maximum timing flexibility the T0 Clock Period should be set to the lowest practical setting and the Clocks Per Vector (CPV) multiplier set to achieve the desired timing period. For our example this means that the T0 Clock Period should be set to 10ns and the Clocks Per Vector (CPV) should be set to 4 (10 * 4 = 40ns or 25MHz). Refer to Figure 4 and set the T0 Clock Period to 10ns and the Clocks per Vector (CPV) to 4, then press the Set button. Note that the total timing period can be varied during the burst on a per step basis by changing the CPV value. The T0 Clock value is fixed for the entire burst.

Figure 4: Clock and Clocks Per Vector (CPV) Configuration

Timing Setup
To recap, we have now configured the GX5296 as follows:
Total period timing set is to 40ns (10ns * 4)
SCLK DIO channel is set to use Phase Step TSet0 with Return To One format
SSL, MISO and MOSI channels are set to use Phase Step TSet1 with No Return formatting
All Channels are set to use Window 0
In the Channel setup, each channel is assigned to one of four Phases (0-3) and four Windows (0-3). The Phases setting in the Timing Setup determines when the Drive signal will be asserted and or returned (denied) during the timing cycle. The Window setting determines when the Sensing open and close window will occur. The TSets Page is used to display the 64 Timing Set groups. Refer to timing diagram in Figure 5, SCLK transitions from a low to a high at 50% of the cycle. To achieve this clock period, Phase Assert0 must be set to 0ns and Phase Return0 to 20ns. Since data formatting for this channel is set to Return To One, this will generate the desired clock frequency as long as the vectors for this channel are set to output a low. The SS, MISO and MOSI channels are set to No Return formatting. These channels are valid at beginning of the period and remain constant during the timing cycle so Phase Assert1 is set to 0ns. Phase Return1 is not used but needs to be set to some value greater than the Phase 1 Assert, say 20ns.

Figure 5: SPI Bus Timing

To enter the Timing Set Editor, select the TSets page. Refer to figure 6, and set the Phase and Window of TSet Index 0 to the following values and then press the Write button.
• Set Phase Assert0 to 0.00
• Set Phase Return0 to 20.00
• Set Window Open0 to 30.00
• Set Window Close0 to 40.00
• Set Phase Assert1 to 0.00
• Set Phase Return1 to 20.00
• Set Window Open1 to 20.00
• Set Window Close1 to 40.00

Figure 6: Timing Set Editor

Step and Vector Creation
A Step is a group of vectors with a defined starting address and vector count. If desired, a Step can use the same set, a subset, or a unique set of vectors. Each vector defines the drive and sense states at the defined timing set period. Each step can select a unique CPV value, Timing Set Index (0-63), Record Memory mode, Phase Trigger Source and Step Trigger control.

Select the Steps page and refer to Figure 7. By default, the GtDio6x driver defines step 0. There are four icons used to Create, Delete, Move Up or Move Down a step. To modify the step's parameters, simply select the step by clicking on it. Our example requires two steps: Step 0 set to 50 Vectors and Step 1 set to 1 vector. Add a second step by pressing the Create New Step icon. Select Step 0 and set the Vector Count to 50 and the Address to 0, followed by the set button. Select Step 1 and set the Vector Count to 1 and the Address to 50, followed by the Set button. Our example requires that the Clocks Per Vector setting for both Step 0 and 1 be set to 4. As the CPV setting has already been set for step 0, select step 1 and change the CPV setting to 4 and press the Set button. Since our demo only uses 1 timing set group, ensure that step 0 and step 1 Timing Step Indexes are both set to zero.

Figure 7: Step Editing

The Phase Trigger Source has two selections: “System Clock” and “Vector Clock”. The “System Clock” selection sets the selected Phase timing to the T0 Period. The “Vector Clock” selection sets the selected Phase to the System T0 Clock times the CPV setting. Note this selection can be made on a per Step basis. Refer to figure 8. If a pin is set to return to zero using a T0 setting of 8ns with 5 Clocks per vector (CPV) using “System Clock”, the pin can be set up to generate a clock of 8ns, or 125MHz. This “System Clock” pin would then generate five 8ns Clocks per 40ns timing period. Another pin using “Vector Clock” can only be set up to produce one transition per the 40ns timing period. Our example requires that both Phase 0 and Phase 1 be set to “Vector Clock”. Phase 2 and Phase 3 are not used. Perform this setting for both Step 0 and Step 1.

Figure 8: System and Vector Clock Definition

Refer to figure 9 on the Steps page, there are four record modes that are set up on a per step basis. If the vector response is known then the record mode should most likely be set to Real Time Compare Error. Using the Real Time Compare Error (Recording) mode, a burst will automatically return a pass/fail status. If however, as in our example, the application calls out to read back and analyze a response from the DUT, then the mode should be set to Response (recording). To make this selection, select each Step and select Response (recording) from the pull down menu.

Figure 9: Record Mode Selection

Any Step can be set up to perform a jump or goto subroutine. This feature can be used unconditionally or can be set up to jump, or not jump, on a specified condition. A jump can be set up to jump back to its own or any other step. There are also sixteen loop counters available to use in a jump condition. Loop counters can be nested. Our example does not require the use of Jumps or Subroutines. Ensure that the Step Control is set to “None” for both steps. The last step needs to be defined to tell the sequencer engine where to end the burst. In our Demo example, we have two steps. The first step is 50 vectors to send and receive data from the SPI bus. The second step is used as a Standby sequence step. Refer to Figure 10, at the completion of a digital sequence run the GX5296 will execute one of two Run Completion Modes - Standby or Idle. If Standby is selected the sequencer will continuously run the first vector of the indicated Run Completion Step. If Idle is selected the sequencer will continuously run the selected Idle Step. For our example, select Step 0 and make sure the “Last Step” check box is checked. Set the Sequencer Run Completion Mode to Standby and the Run Completion Step to 1.

Figure 10: Run Completion Mode Selection

Vector Editor Example
Vectors can be programmed manually or by importing a number of different simulation sources such as WGL, STIL and ATP file formats. Note that the simulation file importing requires an optional FIT licence. To edit Vectors manually select the step to edit and press the Edit button, or double click on the Step. Refer to figure 11 for an example of manual vector editing. Each channel for Vectors within the step is set to an Opcode to indicate the Drive and Sense state.

Figure 11: Manual Vector Editing

Saving the GX5296 setup
A unique feature of the GtDio6x driver and panel allows all GX5296 settings to be saved into a file that can be retrieved at anytime. To save the GX5296 settings press File from the top menu and select Save. When prompted select a directory and enter a filename. Press the Okay button when finished. This greatly simplifies programming as the state of the GX5296 can be easily reprogrammed by simply loading a file from the panel, or by loading the file programmatically as in the following ATEasy example,
sFile = GetDir(aGetDirCurrent)
sFile = sFile+"\\DioFiles\\"+"SpiBusExample.dio6x"
DIO File Load(sFile,0,0,0,0)

Running the GX5296
To run the GX5296, perform the following: from the panel depress the “Reset Seq.” button, select the run completion step and set it to 1, then press the “Run” button.

Reading Record Memory
Record memory can be read by pressing the “Edit Vector” button on the Steps page of the GtDio6x panel, or can be read programmatically using the function GtDio6xReadRecordMemory. The GtDio6xReadRecordMemory function can be setup to read the results of any number of pins. In our example, the GtDio6xReadRecordMemory would be used to read the results of the MOSI line. This data can then be modified and written back to the GX5296 MISO line using the GtDio6xWriteVectorMemory function.

Conclusion
While a dedicated test instrument can offer more targeted test capabilities for serial bus interfaces, a solution built around a dynamic digital test instrument, such as the GX5296, can offer flexibility that is unmatched when compared to a dedicated bus test tool. These features include the flexibility to adapt to multiple bus environments, adapt to changing test conditions, support nonstandard protocols (data rates, timing, message sizes…) and provide synchronization for external equipment to time-specific bus events. As the instrument also provides a full featured PMU per pin, analog and connectivity tests can also be easily integrated. A dynamic digital PXI solution can also reduce the footprint of the test system and reduce the test equipment learning curve as the test engineer is working with one instrument and learning one programming language. As can be easily seen, support for multiple serial buses with the single dynamic digital test solution can also be realized. Using a multipurpose instrument means that the test engineer needs to interface with only one vendor should technical support be required. Finally, significant cost savings can be realized since a variety of different bus protocols can be supported without incurring incremental hardware investment each time a new bus protocol is added to a test setup. Ultimately, the goal is to identify those instances where the clever or novel application of a dynamic digital test tool is appropriate and provides tangible benefits in time, cost, flexibility and effective utilization of resources.

[:+[+gtdio6x-fit+]+:]

Comparing C/C++, C#, VB and ATEasy Basic Data Types - Published on 5/27/2021

5/27/2021

Data type reference table

The following table describes ATEasy equivalent data types when calling procedures defined in other programming languages such as C/C++. The table also shows the suggested ATEasy data types used when importing C/C++ header file to ATEasy; these suggestions are offered using the ATEasy Ambiguous C Type Dialog (see ATEasy on-line help for more information):

C/C++	C#.NET	VB.NET	ATEasy	Description
signed char	sbyte	ByVal SByte	Val Char	Signed 8-bit integer
signed char *	sbyte *	ByRef SByte	Val String, Var String, Val Char[ ], Var Char[ ]	Pointer to a single or an array of signed 8-bit integer characters
unsigned char	byte	ByVal Byte	Val Byte	Unsigned 8-bit integer
unsigned char *	byte *	ByRef Byte	Val Byte, Var Byte[ ], Val Byte[ ]	Pointer to a single or an array of unsigned 8-bit integer
bool	bool	ByVal Boolean	Val Bool	Boolean data type (True <>0/False 0), True is usually -1 but in C data type BOOL is 1
bool *	bool *	ByRef Boolean	Var Bool, Var Bool[ ], Val Bool[ ]	Pointer to a single or an array of boolean data type (True/False)
signed short int	short	ByVal Short	Val Short	Signed 16-bit integer
signed short int *	short *	ByRef Short	Var Short, Var Short[ ], Val Short[ ]	Pointer to a single or an array of signed 16-bit integer
unsigned short int	ushort	ByVal UShort	Val Word	Unsigned 16-bit integer
unsigned short int *	ushort *	ByRef UShort	Var Word, Var Word[ ], Val Word[ ]	Pointer to single or an array of unsigned 16-bit integer
wchar_t	char	ByVal Char	Val WChar	Unicode 16-bit integer
wchar_t *	char *	ByRef Char	Var WChar, Val BString, Var BString, Val WChar[ ], Var WChar[ ]	Pointer to single or an array of Unicode 16-bit integer
signed int	int	ByVal Integer	Val Long	Signed 32-bit integer
signed int *	int *	ByRef Integer	Var Long, Var Long[ ], Val Long[ ]	Pointer to single or an array of signed 32-bit integer
unsigned int	uint	ByVal UInteger	Val DWord	Unsigned 32-bit integer
Var DWord, Var DWord[ ], Val DWord[ ]	unsigned int *	uint *	ByRef UInteger	Pointer to a single or an array unsigned 32-bit integer
float	float	ByVal Single	Val Float	32-bit floating-point (single precision)
float *	float *	ByRef Single	Var Float, Var Float[ ], Val Float[ ]	Pointer to a single or an array of 32-bit floating-point
double	double	ByVal Double	Val Double	64-bit floating-point (double precision)
double *	double *	ByRef Double	Var Double, Var Double[ ], Val Double[ ]	Pointer to a single or an array of 64-bit floating-point
char[ ]	sbyte[ ]	ByVal Byte ( )	Val String, ValChar[ ], Var Char[ ]	String of NULL terminated ASCII characters
char[ ] *		ByRef Byte ( )	Val String, Var String	Pointer to string of NULL terminated ASCII characters
wchar_t[ ]	string	ByVal String	Val BString, Val WChar[ ], Var WChar[ ]	String of Unicode characters
VARIANT	object	ByVal Object	Val Variant	Dynamically-changeable data type
int	int	ByVal Integer	Val Procedure	Holds the address of a procedure, 32 bit
IUnknown . IDispatch	object	ByVal Object	Val Object	COM/NET object, stored in a 32-bit address for the COM interface

Using Val and Var Parameters

ATEasy function parameters can be either Val or Var.

Val: The parameter is passed 'by value'. A local variable is made from the supplied argument. Any changes made to a Val parameter within ATEasy will not affect the original variable.

Var: The parameter is passed 'by reference'. The parameter is a reference to the supplied argument. Any changes made to a Var parameter within ATEasy will be made to the original variable.

[:+[+ateasy+]+:]

Using MemoryCopy() to get/set variable values

The ATEasy MemoryCopy() internal procedure can be used in ATEasy to copy variables values into ATEasy using the variable's memory address and size.

For instance, in this C++ DLL procedure a char array is created. The function returns the location of the first element in the array (plAddress) and the array's size (plSize):

void StringTest(int *plAddress, int *plSize)
{
    static char szExample[]="Test String ABC123";
    *plAddress=(int)&szExample[0];
    *plSize=strlen(szExample);
}

The ATEasy procedure shown below calls the C++ DLL procedure, retrieving the address and size data and then uses that information to construct its own variable using MemoryCopy. In this case, a string is the most appropriate variable. But this technique could be used for other basic and / or user-defined variables.

Procedure MemoryCopyTest(): String Public
--------------------------------------------------------------------------------
sTest: String
lSize: Long
lAddress: Long
{
    StringTest(lAddress, lSize)
    SetLen(sTest, lSize)
    MemoryCopy(&sTest, lAddress, lSize)
    return sTest
}

Related Material

Knowledge Base: Passing Array between ATEasy and .NET

Metal-Oxide (MOX) Gas Sensor Testing - Published on 5/27/2021

5/27/2021

Background

The application of MEMS technology has allowed Metal Oxide (MOX) Gas Sensors to be mass-produced at the wafer level with silicon wafer manufacturing offering cost reduction and scalability to large volumes. These gas sensor devices are suitable for precise measurement of Carbon Monoxide (CO) and a wide range of Volatile Organic Compounds (VOCs) such as Ethanol, Acetone and Toluene. Applications for these sensors, which are largely driven by health and safety considerations, include environmental monitoring, biological research, industrial control, portable breathalyzers and home air monitoring systems. The adoption of MEMS technology for MOX gas sensors has resulted in greatly reduced manufacturing costs. However, each of these sensors must also be tested, which presents a unique set of challenges when compared to the manufacturing and testing of typical semiconductor devices. This application note discusses how a semiconductor manufacturer of Gas Sensors employed a focused test solution that provided the required accuracy, accommodated very large site counts, and matched the over-all throughput performance of high performance semiconductor test systems at a much lower cost.

What is a MOX Gas Sensor?

The MOX Gas Sensor is a MEMS device (Micro-Electro-Mechanical System) fabricated as a multi-chip module (MCM).  The basic components of the MCM are the micro-controller ASIC, pre-tested on the wafer, and the sensor, the object of this test application.  These components are placed on a common substrate and a lid is placed over the components with a small hole or mesh in the lid that allows gas into the sensor.

The sensor consists of a small heating element housed beneath a thin membrane coated with a proprietary metal-oxide material.  The MOX material is a variable resistor that responds to chemicals in the gas it is exposed to.  The MOX can be formulated to respond differently to certain types or classes of gas, called the target gas.  In an environment of “clean” air, the MOX resistance can be several MOhms.  When heated, and in the presence of the target gas, the resistance of the MOX material drops significantly, down to several tens of KOhms.  When the application of heat is removed, and/or the test gas is eliminated, the MOX resistance returns to its previous value.

With the application of controlled heat, measuring the resistance of the MOX coating in the presence of clean air, and then measuring the resistance of the MOX coating in the presence of air with a controlled amount of the target gas (measured in Parts per Million), the ratio of the two measurements can be used to calibrate the device.  In actual operation, the calibrated MOX resistance measurement is indicative of the density of the target gas in the environment.
Control of the sensor heater and MOX measurements, as well as device register read/write, are performed by the controller ASIC, which is in turn controlled by the test system over an I²C interface.  The I²C interface is a four-wire bus consisting of the two-wire I²C bus (SCL and SDA), an interrupt signal and a reset signal.  Figure 1 details the components that comprise the MOX Sensor MCM device.

Figure 1: MOX Gas Sensor MCM

Test System Requirements

To test these devices, the test system needed to have the following capabilities and attributes:

The time to test/calibrate a MOX sensor can be several tens of minutes. This long “dwell” time is required due to the need to “soak” the sensor(s) with clean air and the target gas. Clearly, using a large, high performance semiconductor tester, which is effectively sitting idle for many minutes during the gas soak time, is not a productive use of that expensive resource. The solution had to have a low initial capital cost.

Test throughput is still important. With long dwell times, it was essential that the system support very large parallel test capability so the soak time can be amortized across many devices.

The DUT load board had to reside in an enclosed environment where concentrations of gas could be precisely controlled. This precluded the typical practice of using handlers to load and unload devices, resulting in the requirement for manual insertion and removal of the devices. Consequently, a means for an operator to visually identify passing and failing components for manual binning was required.

Once the desired soak time had been reached, all measurements needed to be completed in less than one second to avoid skewing of the results due to disparate soak times.

As the component was a new design, the system needed to be expandable, so the test capacity could grow as production volumes increased.

The devices arrive for package test after the wafer-level ASIC test is completed, with common I²C slave addresses for all devices. The system needed the ability to isolate the I²C bus to each device, eliminating the need to modify the slave address for testing. Since the load board involved manual insertion of the DUT, a test method was needed to verify correct component insertion prior to initiating the lengthy test process. A simple contact test achieved this, so the system needed to provide PMU/pin capability.

Implementation

Architecture
The architecture selected was a hybrid PXI-based system consisting of a mixture of PXI instruments and external instruments controlled over USB. Note, the use of the word hybrid in this circumstance does not mean PXI Express hybrid – the PXI instruments are all standard PXI-1. In this context, hybrid means the combination of PXI and non-PXI instruments.

Power
The operating current of the device in normal, or idle, states was very low, but during measurements, experiments showed that, when the sensor heater was activated, inrush current per device could be quite high. To support a large multi-site configuration (up to 512 devices), PXI power solutions were deemed inadequate, so external Keysight E36313A power supplies were selected.

Digital Instrument
An obvious implementation is to use a dedicated digital instrument for each device being tested. This would meet the requirement to isolate the I²C bus for each device, but the cost for such a “brute force” approach would exceed the overall system budget. So a switched, or multiplexed, digital interface implementation was devised whereby each DUT would communicate over a dedicated I²C bus, minimizing the digital instrumentation resources. The instrument of choice, based on cost, channel density and ease of use, was the Marvin Test Solutions GX5295 digital I/O card.

With 32 channels per slot, per-pin PMU, deep pattern memory and a robust API function set, the GX5295 could test eight devices in parallel without slave address conflict issues. An 8:1 multiplexing scheme allowed one GX5295 to test 64 devices in groups of eight at a time, again avoiding slave address conflicts. This approach allowed one inexpensive GX5295 to measure a full 64-site load board in well under the allocated time budget. And, since the GX5295 supports synchronous multi-instrument expansion, the time to make measurements on 512 devices is the same as the time to measure 64.

[:+[+gx5295+]+:]

System expansion is simply a matter of adding extra GX5295s, load boards, chambers and ITA cables, up to a maximum of 8 total (512 DUTs).

Load Board
Load board density was set to 64 devices (Figure 2). For reasons explained above, this provided a natural granularity for system expansion. To simplify the system/DUT interface, the mux switching devices were placed on the load board, eliminating external switching and the associated cables, while still maintaining good signal integrity.

Figure 2: Load Board

The load board includes 64 tri-color LEDs for visually indicating Pass/Fail status of each DUT. The LED power includes a battery backup so the visual Pass/Fail state is retained even when the load board is removed from the system – which was necessary for the operator to manually remove and bin the devices. A charging circuit on the load board keeps the battery topped-off while tests are running.

Since the I²C interface is an open-collector bus, it requires external pull-up resistors for operation. These resistors interfere with the PMU contact test for determining proper DUT insertion in their sockets – the current through the pull-up resistors would swamp the ESD diode measurements. Consequently, a Vcc controlled pull-up relay was included to isolate the pull-up resistors from Vcc when making the contact measurements (Figure 3).

Figure 3: Pull-up Isolation

Load Board Control
An inexpensive MTS GX5733 static digital I/O module was used to control all of the load board functions (I²C mux, tri-color LEDs and Vcc pull-up isolation relay).  A special driver was developed that simplifies load board control.

PXI Chassis
The PXI chassis selected was the MTS GX7305 high-power chassis.  The chassis provides 20 PXI-1 (non-express) slots – one for the MXI controller and 19 for instrumentation.  The chassis exceeds the PXI minimum specifications for power delivery and cooling capacity, and includes functions for monitoring backplane voltages and slot temperatures.

Interface Test Adapter (ITA)
A dedicated ITA was designed for the GX7305’s hinged front panel, allowing for simple, clean cabling between the test system resources and the load boards.  Cables from both the PXI instruments and the external E36313A power supplies mate to connectors on the back side of the ITA, which are hidden from view when the hinged panel is closed.  Cables to the load board, Mass Flow Controllers and exhaust valves connect to the front of the ITA (Figure 4).

Figure 4: Interface Test Adapter

Figure 5 details a block diagram of the test system’s resources and associated ITA.

Figure 5: System Block Diagram

Gas Control
To facilitate precise control of gas exposure to the DUT, an enclosed environment (chamber) was designed to house the load board and restrict the test gas to a confined space. The gas is introduced to the chamber via Mass Flow Controllers (MFCs) that meter Clean-Dry Air, Humidified Air and the Test Gas, allowing them to be mixed in precise quantities to achieve the desired gas densities (measured in Parts per Million). A separate MFC is also provided for each chamber to meter the mixed gas to the enclosed chamber in a controlled volume. Control of the MFCs is performed using the auxiliary PMU channels on the GX5295’s J3 connector.

Exhaust valves are used to evacuate the test gas from the load board chamber after the tests are complete. The exhaust valves are solenoid operated, powered by one of the E36313A power supplies, and controlled via 12 V switching relays located on the ITA.

Software
The software used to control the system is ATEasy®, v10.  Software control was written to facilitate easy expansion of the system as well.  ATEasy supports multi-threading applications.  For each GX5295/load board/chamber, ATEasy instantiates a separate thread for processing measurements and generating data logging reports.  The ATEasy test application queries the number of GX5295s installed in the system (one GX5295 for each 64-site load board), then dynamically allocates a thread for each.  Processes common to all threads, such as initiating the digital test patterns that are run in parallel for each load board, are facilitated using thread synchronization.

Included in the ATEasy application are drivers for the GX5295s, GX5733, Keysight power supplies and GX7305 chassis monitoring, as well as an Excel spreadsheet driver for managing the data logging.  There is a MOX driver, built on top of the GX5733 static digital instrument, for simplified control of the load board.

Included in the delivered package are tools for high-level creation of I²C bus patterns, concatenation and loading of I²C bus sequences, as well as downloading captured I²C bus traffic for diagnostics and analysis.  Data logging to an Excel spreadsheet facilitates the use of all of the high-level data analysis tools of Excel, such as graphs, filters and application of formulas to the acquired measurements.

[:+[+ateasy+]+:]

Communication to the DUT is done over an I²C bus. As mentioned above, each device is preconfigured with an identical I²C slave address. Were all of the DUTs to reside on the same I²C bus, it would be necessary to reprogram each device with a unique slave address prior to testing to avoid bus conflicts, and then re-program the slave address to the default value for delivery to the customer. Using a dedicated bus per device allows all communication to occur using the default address, saving time and money, and avoiding potential human error. A single GX5295 with 32 I/O channels can communicate across eight I²C busses simultaneously without concern for address conflicts.

The I²C test patterns were generated using a simple utility written in ATEasy (Figure 6). Bus commands are constructed using a drop down menu of pre-defined bus commands for reading and writing to a device’s registers. An idle command is also available to allow insertion of dead-time between commands that require it, or to serve as a visual separation in the data patterns for debugging purposes.

2C User Interface Utility" title="I²C User Interface Utility" border='0' >

Figure 6 : I²C User Interface Utility

Based on the requirements of the test processes, a sequence of commands are generated for a single device. Then using DIOEasy (Figure 7), a tool for generating and diagnosing GX5295 digital test patterns, the single (four-wire) bus control is copied to the remaining seven busses supported by the GX5295. Each test process is written as series of stand-alone pattern sequences so they can be concatenated together in any order desired.

Figure 7 : I²C Pattern Editing using the DIOEasy Tool

An offline utility is included in the ATEasy application that performs this concatenation, generating one large test file that is quickly loaded to the test hardware during initialization of the system. To aid in debugging and diagnostics, a text file is generated identifying the order of the loaded tests, their initial vector address, and the pattern size of each pattern sequence.

Lock NVM, :Start 0, :Size 204, :Length 1632
Unlock NVM, :Start 2656, :Size 204, :Length 1632
Dut Poll, :Start 5312, :Size 207, :Length 1656
Dut Status, :Start 7992, :Size 207, :Length 1656
Start Sequence, :Start 10672, :Size 204, :Length 1632
Pre-Init 3, :Start 13328, :Size 240, :Length 1920
Pre-Init 5, :Start 16272, :Size 204, :Length 1632
Pre-Init 7, :Start 18928, :Size 204, :Length 1632
Pre-Init 12, :Start 21584, :Size 1908, :Length 15264
Pre-Init 14, :Start 37872, :Size 1363, :Length 10904
Pre-Init 16, :Start 49800, :Size 240, :Length 1920

The state of each pin is recorded during test execution. At the completion of the test, the actual bus traffic (commands and DUT responses) can be uploaded from the hardware to DIOEasy, allowing the user to evaluate and/or document I²C bus communication.

Test Process

Continuity
The per-pin PMU function available with each GX5295 I/O channel is used to source a small current through each of the DUT’s ESD diodes, and the resulting voltage drop across the diodes is measured to determine if the DUT is correctly installed in its socket.  Prior to doing this, the pull-up isolation relay needs to be enabled so current flow through the I²C pull-up resistors does not corrupt the continuity measurement.  Devices are binned according to their pass/fail status.  Future test evaluation is bypassed for any device having a “Failed” bin status.

Sensor Initialization
Prior to exposing the DUT to a test gas and measuring the MOX resistance, the sensor must be initialized.  The Initialization reads relevant NVM (Non-Volatile Memory) data and stores it for future data correlation. It also dynamically calculates minimum and maximum permissible MOX resistance values for each DUT, based on the stored Heater Resistance and the current chamber temperature. These values are stored for future use.  The Gas Test will use these values when determining good/bad devices.

Gas Measurement
The Gas Measurement test is the heart of the MOX Gas Sensor production test.  Once initialized, all devices in all chambers are exposed to a controlled mixture of “Clean/Dry Air” (CDA), “Humidified Air” (running CDA through a bubbler - BBL) and the “Test Gas”. The gas mixtures are precisely controlled (in PPM) using programmable Mass Flow Controllers.  Each of the three MFCs is controlled by the application of 0 V – 5 V, representing 0% to 100% of the rated flow, respectively.  A fourth MFC is included for each chamber/load board. The MFC control voltages are provided by the auxiliary PMU channels on the J3 connector of the GX5295s.

During the Gas Test, the concentration of the test gas, and the exposure time for each specific concentration, is defined by a “Soak List”.  The soak list contains set points for the three gasses, and the duration to hold that concentration before moving to the next set point in the list.  At the end of the defined time period, a MOX measurement is taken, compared against the MOX min/max values previously calculated, and recorded.  Binning is set accordingly.

To simplify the application of the soak parameters, a form (Figure 8) was created in ATEasy that allows an engineer to create the soak list using a GUI. Set points can be added, inserted, modified and deleted. During execution, the GUI highlights where in the list the test process is, providing the operator an indication of how long the test has run, and how long until completion.

Figure 8 : GUI Soak List

An optional parameter that can be enabled when running the soak list is to make intermediate MOX measurements – measurements between the soak list set points.  This provides additional characterization data of the MOX operation by logging additional measurements during the lengthy test process.  The options for data logging are “Off”, measurements only at the set points, and “2”, “4”, “6” measurements/minute.  Intermediate measurements are saved to the Excel data log file, but are not used in evaluation of pass/fail status.

Pre-Initialization
The devices arrive from the contract manufacturer (CM) with some information already stored in the device’s Non-Volatile Memory (NVM), such as the Product ID, a correlation Tracking Number, Heater Resistance and the ambient temperature the resistance was measured at, Slave Address, etc.  The pre-initialization test allows an engineer to overwrite the NVM with new data.  This is not a normal test process used during production.  Instead, it is used to allow an engineer to run characterization tests on the device with complete control over all DUT parameters.

Sensor Aging
The Sensor Aging test is also not part of the normal production test.  It is used to characterize the MOX under simulated aging processes.  The aging test runs CDA to the part with an extended heater temperature, for a user-defined number of one minute cycles.  Analysis data is collected during this process, and at the conclusion of the aging test, a normal Gas Test is run and the MOX characteristics recorded.

DUT Polling
When running the Gas Test, the Sensor Aging test, and other test processes, the DUT is programmed with a test sequence table with the processes executed and controlled by the micro controller.  During this sequence table execution, the DUT registers are not available for access, except for a polling register.  The polling register is updated during the table sequence execution and can be queried by the test system to determine if the sequence table is done, or if the current table in the sequence is executing.  Since polling is required for several of the MOX tests (every process that utilizes sequence tables), it is implemented as a subroutine that can be called when needed.  The time that it takes to execute the sequence table can vary depending on the test requirement – number of steps in the table and delay parameters per step.  To provide the operator with status of the sequence execution, an Elapsed Time form (Figure 9) was created to provide visual feedback of the time remaining to complete the sequence table.

Figure 9 : Elapsed Time Form

DUT Status
Like DUT Polling, the DUT Status is queried by multiple test processes, and is implemented as a subroutine.  The status indicates the health of the DUT – specifically, if a Power On Reset has occurred recently.  The POR bit is set whenever power to the device is interrupted, or if a Reset is initiated.  Reading the POR state resets the bit.  Many of the tests will not function correctly, or are considered invalid, if a POR is indicated.

Chamber Characterization
One of the most challenging aspects associated with proving the efficacy of the test system, was characterizing the distribution of the test gasses in the chamber (Figure 10).  The initial concept was to introduce the gasses at the four corners of the load board, assuming that, over time, the gas would mix and be distributed evenly within the chamber.  But tests proved that the gas would not reach a homogenous concentration within the chamber in the time limit defined by the soak list.  Increasing the flow rate of the test gasses, and extending the soak time, were both considered as a remedy for this shortcoming, but in the end were deemed too expensive in gas utilization and test throughput, respectively.

Extensive experimentation, later substantiated by fluid modeling, demonstrated that a modified manifold approach produced near ideal gas distribution.  The gas was introduced at four points into a low-volume manifold located directly above the DUT sockets.  Pin-holes in the manifold above each socket deliver a concentrated stream of the test gasses directly to each device.  The end result was near optimal performance utilizing a minimum amount of test gas, without adversely affecting test throughput.  The chamber design will be modified to incorporate these findings into the production systems.

Figure 10 : Device Gas Manifold

Summary

In conclusion, each of the criteria for the test system was met, or exceeded.

The solution had to have a low initial capital cost. Based on the PXI form factor, a creative hardware and software implementation resulted in a capital cost at well under 1/5 of the cost of a conventional semiconductor test system.

The system needed to support very large parallel test capability. Site count can be expanded from 64 sites to 512 sites, in 64 site increments. At these capacities, a 35 minute test cycle still results in a throughput rating of just over 4 seconds per device. Further optimization of the test code, gas flow rate, soak times and pass/fail parameter optimization will drive the test time per device even lower.

A means for an operator to visually identify and manually bin passing and failing components was required. Test status LEDs with battery backup provides the operator with a visual indication of DUT site pass/fail (Figure 11).

Figure 11 : DUT Board with LED Indicators for Pass/Fail Status

All measurements needed to be completed in less than one second. The time to measure the MOX resistance for 64 sites was measured at less than 800 mS. Due to the parallel operation of the GX5295 digital test instrument, extending the site count to 512 will not appreciably increase the measurement time.

The system needed to be expandable. Site count can be expanded from 64 sites to 512 sites in 64 site increments.

Isolate the I²C bus to each device. Each DUT socket has an isolated I²C bus for programming and reading/writing register, accessed as an 8 x 8 matrix (8 groups of 8 DUT’s).

Provide PMU/pin capability. The GX5295 architecture comes standard with a PMU per pin capability, plus four additional PMUs for general purpose use. The PMUs provided an easy method to perform a contact test and the additional PMUs were dedicated to MFC control, helping to lower the system cost by eliminating extra hardware.

The specialized requirements associated with the testing of MOX gas sensors presented unique challenges. In particular, the large test “dwell” time required by these devices demanded a different kind of test solution – one that could be easily scaled to support very large parallel test capabilities with test assets that were significantly lower in cost than the traditional “big iron” ATE solution. As detailed above, a PXI-based solution based on off-the-shelf hardware and software provided the optimal solution – achieving both high throughput and very moderate cost.

Translating STIL, WGL, VCD, EVCD and Teradyne ATP files to DIO/DIO6x Files - Published on 5/6/2021

5/6/2021

Introduction

The Marvin Test Solutions FIT (File Import Toolkit) option is a simulation file translator that engineers can use to easily import STIL, WGL, VCD, EVCD simulation and Teradyne ATP files to Marvin’s compressed digital file format. The FIT converter is available as a separate option for both families of digital I/O products GtDio6x (GX5296, GX5960 Series) and DIOEasy (GX5290 series). Since the features and operation associated with the two options are virtually identical, this article refers to both options as FIT. Both DioEasy and Dio6xEasy coupled with the -FIT option create a comprehensive tool-set for users to translate, view and debug digital test vectors on the user’s desktop or on a Marvin Test Solutions test system. The following article explains the simple process to convert a file.

Licensing the FIT converter

FIT is launched from DioEasy/DioEasy6x by selecting File->File Import from DioEasy/Dio6xEasy, if no license is installed you will be prompted to enter a license string. The license string can be obtained via the MTS support portal (Magic), by creating an incident, providing the FIT Serial number and the Computer ID displayed at the bottom of the License Setup dialog as shown here:

[:+[+gx5296+]+:]

Figure 1 – DioEasy-FIT License Setup

The FIT Window

The following controls are displayed on the FIT window:

Import File
May be entered manually or by pressing the Browse (...) button to browse for the file name to import and convert.

Output DIO File
This file name will be automatically filled in with same name as the Import file with a DIO/DIO6x file extension. The Output file can be any valid file name or file path.

Signals TAB
Once the conversion file name has been entered the Signals Tab of the FIT converter will look similar to the display in Figure 2. The Signal names, UUT Direction and the Bidirectional Control are determined by the selected file. The DIO Channels are assigned automatically. All columns can be easily edited with drop-down choices.

Figure 2 – DioEasy-Fit Main Page

Profile TAB
The Profile Tab provides a simple method to edit signals and also provides a means to change variables or options that will affect the outcome of the conversion. Signals can be copied and pasted from and to the profile tab. This provides a simple method to change the digital channel used, signal name or the UUT Direction. Comments can also be added when followed by a '#'.

As shown below digital channels can be easily re-sequenced, the UUT direction can change or an unused signal can be removed by removing the DIO channel associated with the signal. Once a Profile has been edited it can be saved for use in future conversions. To save a profile, enter the profile name in the Import Profiles drop list then press the Save Profile to File button. See Import Profiles file name selection in Figure 2.

The figure below depicts removed channels, channel re-sequencing, and signal renaming using the file import toolkit.

[Signals]
        0        cen_I :    Input;         # Re-sequenced digital channels
        3        cen_O :    Output;
        2        wen_I :    Input;
        1        wen_O :    Output;
        7        oen_I :    Input;
        8        oen_O :    Output;
                 bhen_I :   Input;         # Removed unused signal
        4        bhen_O :   Output;
        5        blen_I :   Input;
        6        blen_O :   Output;
        9        a0_I :     Input;
       10        a0_O :     Output;
[End]

File Conversion

Marvin Test Solutions' DioEasy-FIT converter will import any STIL, WGL, VCD, EVCD simulation or Teradyne ATP files. The conversion process is the same regardless of the file type. Use the following steps below to import a file.

Select the file to import, make sure to select the File type.

If necessary enter the target digital file name and path (.dio or .dio6x).

Make any necessary changes to the profile or select a saved profile to use for the conversion.

Select the board type to use for the target file.

Click on Import to begin importing the file.

[:+[+GtDio6x-FIT+]+:]

Once the import process has started, FIT will switch to the Status tab. The Status tab will show the progress of the conversion and will display any errors encountered. At the completion of a successful conversion the status tab will look similar to the display shown in Figure 3. For additional information regarding DioEasy-FIT refer to the DioSoftware or the GtDio6x User Guides.

Figure 3 – DioEasy-FIT Conversion Status

Proper Termination of High-Speed Digital Signals - Published on 5/6/2021

5/6/2021

When interfacing to any digital logic source, it is important to provide quality signals to the device under test (DUT). And the key to providing quality signals is to treat the interconnecting cables between the digital source and the digital receiver as a transmission line requiring proper termination. This termination can take the form of impedance matching and Impedance bridging.

Impedance matching is the design practice of setting the input impedance (Z_L) of an electrical load equal to the fixed output impedance (Z_S) of the signal source to which it is connected, usually in order to maximize the power transfer and minimize reflections from the load¹, while Impedance Bridging maximizes transfer of a voltage signal to the load². When the output impedance of a device is connected to the input impedance of another device, it is a bridging connection if the second device does not appreciably load the previous device².

[:+[+dioeasy+]+:]

For many electrical systems, simple wires and cables are adequate connection schemes, but for high-speed digital signals, this is not the case. The fast edge rates of these signals contain frequency components that are much faster that the data rate of the signals. And it is edge speed, not data rate or clock frequency that is the critical parameter. As the edge rate of the signal approaches the round-trip propagation delay of the signal through the cable, the cable begins to behave as a transmission line. A good rule-of-thumb in determining the propagation delay of a cable is to use 1nS per foot cable length. In figure 1, if the cable length (L) were 1 foot, then a digital signal with a 2nS edge rate would require that the cable be terminated with a load of Z ohms.

Figure 1 – Unterminated Transmission Line

There are many methods for terminating a transmission line. While some use active components, like diodes, this article will focus on the more common method of using resistors. For instance, a common TTL transmission environment is 100 ohms. Impedances of 50-75 ohms are also used, but have a disadvantage that the termination resistors would place a large load on the digital driver. This is best to avoid, especially for "weak" drive devices. The simplest way to terminate a 100 ohm transmission line would be to place a resistor at the end or the cable (Figure 2) where R_L is equal to Z Ohms.

Figure 2 – Terminated Transmission Line

This termination scheme, while simple, places an added load on the driver. In keeping with the above example, if the drive voltage were 5V, and R_L is 100 ohms, then the termination load is 5Volts/100Ohms=50mA. This is beyond what many TTL devices can accommodate. One way to address this loading is to use a higher impedance cable. Simply changing your transmission environment to 125 ohms would lower the termination loading to 40mA – still high, but lower than the previous example. An advantage of this method of termination is the ability to handle multiple fanouts. Each fanout stub would have their own termination resistors, but the fanout network would multiply the termination loading.

To address the loading drawback, parallel termination can be used. Terminating the transmission line requires that the termination load be referenced to a power plane. While the ground plane is typically considered the termination reference, the V_CC power plane can also be used (Figure 3). The resistors R_PU (Pull-Up) and R_PD (Pull-Down), while technically not in parallel, for the purposes of transmission line termination, are in parallel with each other. The resulting termination value is calculated using Ohms Law: R_L=(R_PU x R_PD) / (R_PU + R_PD). If Z were 125 ohms, then using R_PU and R_PD with values of 180 ohms and 390 ohms, respectively, would result in a Thévenin equivalent termination of 123 ohms. The load on the driver, when outputting a 4V logic “1”, would only be around 10mA – well within the range of most TTL devices.

Figure 3 – Parallel Terminated Transmission Line

The GX5292 has 330/390 parallel termination built in and are user selectable in groups of eight channels using on-board relays. This termination is intended to provide proper termination of UUT driven signals, but has minimal affect of signals driver by the GX5292. The termination can be enabled programatically, or using the Group Termination controls on the DioEasy Panel's I/O Channel Settings tab. The GX5055 and GX5960 also provide on-board termination, however, they are controlled per pin, and includes the ability to source and sink current.

Figure 4 – DioEasy Panel - Group Termination Controls

A little overshoot is not harmful to your system. In fact, many designs under-terminate a signal on purpose to achieve some overshoot and undershoot. This guarantees a clean transition through the UUT input thresholds so you don't linger in the hysteresis range of the receiver. It will also reduce termination loading further. Under-termination produces some ringing in the signal at the receiver (figure 4), but so long as the negative "bounce" does not drop below the input-high threshold of your receiver (Vih), there is no negative affect. As a general rule, if the ringing is not affecting your UUT's operation, then it may not be a problem and you can ignore it. A 220/330 ohm termination network would provide 132 ohm termination; slightly under-terminating a 125 ohm transmission line and producing minor ringing on the signal.

Figure 5 – Minor ringing in a digital signal

Digital signal are often part of a bi-directional bus, and it is typically a requirement that when a bi-directional line is tristated, the bus will “float” to a known level. A 125 ohm termination resistor to ground or V_CC will guarantee that a tristated bus would be pulled to ground or to V_CC, respectively. Parallel termination can allow a bus that is in an undriven state to float to a predetermined value. For example, 180/390 ohm parallel termination will force a tristated signal to about 46% of V_CC, or about 2.3V for V_CC equal to 5V.

Source termination is an example of Impedance Bridging termination. As mentioned previously, impedance bridging maximizes transfer of a voltage signal to the load. Since most IC’s have a very high input impedance, large drive currents are not required to transmit a signal, so long as the voltage levels comply with the V_IL and V_IH parameters. Source termination places a resistor in series with the driver, with the source resistance value (R_S) equal to the characteristic impedance of the transmission line (Figure 5). The resistor (R_S Ohms), in series with the transmission line (Z Ohms) will appear as a voltage divider. When R_S Ohms equals Z Ohms, the instantaneous voltage on the transmission line will be 50% of the voltage provided by the driver.

Figure 6 – Impedance Bridging Source Termination

The 50% amplitude wave propagates down the transmission line until it sees the large mismatch at the unterminated receiver.  Source termination relies on the large mismatch to reflect 100% (ideally) of the signal back into the transmission line – in effect, instantly doubling the voltage at the receiver from 50% of the drive voltage to 100%.  Since there is very little power transferred to the receiver - remember, source termination is impedance bridging, not impedance matching, the voltage level remains nearly equal to the drive voltage.  The reflected wave propagates back down the transmission line, where the source termination resistor absorbs it.

There are a couple of caveats to using this termination scheme.  First, if you were to look at the signal on the transmission line side of the source termination resistor, you would see a very poor digital signal.  The signal would rise to 50% of the driver voltage, remain at this level for 2x the propagation delay of the cable (approximately 1nS/ft), and then complete the transition to 100% of the drive voltage, producing a stair-step transition.  However, we are not concerned with the signal integrity at the source.  The receiver sees a clean 100% signal transition, which is what is important in digital signal transmission.

The other disadvantage of source termination is that it works best for a single receiver.  Additional receivers on the bus will be unterminated stubs.  When the source terminated signal reaches a stub, the 50% amplitude signal is divided in half again, producing a 25% amplitude signal (assuming the stub matches the impedance of the transmission line).  Now the 100% reflection at the receiver produces a 50% amplitude transition (assuming a single stub), and the reflected wave when it reaches the transmission line will be split between propagating back down the transmission line, and propagating to the other stub.  With multiple receivers on a source terminated transmission line, instead of seeing clean transitions at the receiver, you get a transition with steps and added ringing caused by multiple reflections bouncing every which-way.  If the length of all of the stubs is very short, then the perturbations in the edge transitions will be minimal, and the signal quality might be adequate.  But with source termination, as the unterminated stub lengths increase, edge transition quality for all receivers decreases.

One final caution about using source termination.  Providing both source and load termination on the same signal, while resulting in a very reliable signal, will also limit the amplitude to half of what it would otherwise be.  As illustrated in figure 6, double termination creates a voltage divider at the receiver.  The current across R_S and R_L is equal, and assuming the values of R_S and R_L are equal, the voltage at the receiver is 50% of the source voltage, rather than the full source voltage.

Figure 7 – Double Terminated Signal

The voltage drop from double termination can be compensated for if the source driver has programmable outputs with a range at least double the desired logic level. The GX528x and GX529x series digital instruments available from Geotest (except the GX5295) all have programmable output levels in the range of 0V to 3.6V. The GX5295 has a programmable range of -2V to +7V and the GX5055 and GX5960 have programmable output levels in the range of –10V to +15V.

Terminating a Differential transmission line requires placing a resistor of the same value as the characteristic impedance of the cable, across the differential signals (figure 8). The termination can be on either or both ends of the transmission line, depending on the application requirements. Cables are generally rated for their characteristic impedance based on the type of cable. For example, the GT95022 cable supplied with Geotest DIO instruments is a SCSI Fast cable, and as SCSI is a differential transmission standard, the cable impedance is specified as a differential Impedance of 124 ohms, ± 10 Ohms. When used in a single-ended application, then the impedance is half the rated differential impedance.

[:+[+GX5295+]+:]

Figure 8 – Differential Termination

To facilitate easy connection of Geotest dynamic digital instruments, Geotest has optional breakout adapters, the GT95014 and GT95015, which provide 34 x 2 rows of male pins on a 0.1” spacing. This is compatible with a 68-pin IDC type connector. These adapters accommodate single-ended or differential signals, respectively, and provide sockets for termination resistors on the board. Documentation for these adapters can be found here (GT95014**) and here (GT95015).

Figure 9 - GT95014 & GT95015 Breakout Adapters

In summary, to guarantee good signal quality in a digital environment, it is important to understand when termination is required (as the edge speed of the signal transition approaches the round-trip delay time of the signal through the interface cable), the different methods of terminating a transmission line (source termination, single load termination and parallel load termination), and the advantages and disadvantages of each.

^{1. Wikipedia - http://en.wikipedia.org/wiki/Impedance_matching
2. Wikipedia - http://en.wikipedia.org/wiki/Impedance_bridging}

Translating Waveform Generation Language Files (WGL) to Marvin Test Solutions DIO File Format - Published on 5/6/2021

5/6/2021

Defining WGL

The Waveform Generation Language (WGL) is a data description language supported by Test Systems Strategies Inc. A WGL file uses an ASCII representation of the digital waveform data, so can be edited using any text editor. WGL is also an intermediate file format used by the semiconductor industry for converting digital test patterns from a logic simulator to tester hardware, and back again.

Test information is represented in a WGL file using a structured, free form language with small, specialized structural blocks contained within larger, more generalized blocks. A full discussion of the WGL language and syntax is beyond the scope of this article, but can be found in the TDS Languages Guide, Version 2007.1, published by Test Systems Strategies, Inc. The benefit of WGL is that any digital instrument or tester that is capable of reading or writing test patterns using the WGL language, has a link to any simulation tool that also supports WGL, either directly between the simulator and tester hardware, or indirectly through other translators or filters.

[:+[+dioeasy+]+:]

To illustrate the Marvin Test Solutions Digital I/O (DIO) WGL import filter, a Simple WGL file was manually generated. Note, this is not a typical WGL file as many of the structural blocks are excluded for clarity. But it does serve as a good primer into the WGL file structure and facilitates demonstrating the process for importing WGL files into the Marvin Test Solutions DIO format.

A Simple WGL File

Waveform Sample

  Signal
    Stim00   : input;
    Stim01   : input;
    Stim02   : input;
    Stim03   : input;
    Stim04   : input;
    Stim05   : input;
    Stim06   : input;
    Stim07   : input;
    Stim08   : input;
    Stim09   : input;
    Stim10   : input;
    Stim11   : input;
    Stim12   : input;
    Stim13   : input;
    Stim14   : input;
    Stim15   : input;
    Resp00   : output;
    Resp01   : output;
    Resp02   : output;
    Resp03   : output;
    Resp04   : output;
    Resp05   : output;
    Resp06   : output;
    Resp07   : output;
    Resp08   : output;
    Resp09   : output;
    Resp10   : output;
    Resp11   : output;
    Resp12   : output;
    Resp13   : output;
    Resp14   : output;
    Resp15   : output;
  End

  Timeplate Match_0 Period 100nS
    Stim00   := input[0pS:S];
    Stim01   := input[0pS:S];
    Stim02   := input[0pS:S];
    Stim03   := input[0pS:S];
    Stim04   := input[0pS:S];
    Stim05   := input[0pS:S];
    Stim06   := input[0pS:S];
    Stim07   := input[0pS:S];
    Stim08   := input[0pS:S];
    Stim09   := input[0pS:S];
    Stim10   := input[0pS:S];
    Stim11   := input[0pS:S];
    Stim12   := input[0pS:S];
    Stim13   := input[0pS:S];
    Stim14   := input[0pS:S];
    Stim15   := input[0pS:S];
    Resp00   := output[0pS:Q];
    Resp01   := output[0pS:Q];
    Resp02   := output[0pS:Q];
    Resp03   := output[0pS:Q];
    Resp04   := output[0pS:Q];
    Resp05   := output[0pS:Q];
    Resp06   := output[0pS:Q];
    Resp07   := output[0pS:Q];
    Resp08   := output[0pS:Q];
    Resp09   := output[0pS:Q];
    Resp10   := output[0pS:Q];
    Resp11   := output[0pS:Q];
    Resp12   := output[0pS:Q];
    Resp13   := output[0pS:Q];
    Resp14   := output[0pS:Q];
    Resp15   := output[0pS:Q];
  End

  Pattern Loopback (Stim00,Stim01,Stim02,Stim03,Stim04,Stim05,Stim06,Stim07,Stim08,Stim09,Stim10,
                    Stim11,Stim12,Stim13,Stim14,Stim15,Resp00,Resp01,Resp02,Resp03,Resp04,Resp05,
                    Resp06,Resp07,Resp08,Resp09,Resp10,Resp11,Resp12,Resp13,Resp14,Resp15)

    {Start Vectors}
    Loop 32
      Vector(+, Match_0) := [1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0];
      Vector(+, Match_0) := [0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0];
      Vector(+, Match_0) := [1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0];
    End

    Repeat 4
      {End Vectors}
      Vector(+, Match_0) := [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0];
    End
  End
End

The keyword Waveform denotes the beginning of a waveform block called Sample.  Within the Waveform block are several sub-blocks; the first is a sub-block denoted by the keyword Signal.  This block defines the signal names and types.  The point of reference for the signal types is the UUT, meaning that all the Input signals (Stim Names) are input to the UUT, and all Output signals (Resp  signal names) are output from the UUT.  WGL defines other signal types that are not used in this example.

The Timeplate keyword defines the beginning of the block structure called Match_0, where signal timing is defined.  It also defines the period of the Match_0 timing set to be 100nS – a 10 MHz data rate.  All of the Stim signals are defined as being active at the beginning of the test cycle (0pS), and the driven data pattern will be substituted (:S) by the value in the signals associated bit position within Pattern block (discussed later).  All of the Resp signals are defined as being active at the beginning of the test cycle (0pS), and the compare data pattern will be substituted (:Q) by the value in the signals associated bit position within Pattern block.

The Pattern block called Loopback first defines the bit ordering for the subsequent data patterns.  The ordering is LSB first, so Stim00 is the LSB data position, and the drive state is be represented by the left-most bit value in the vector field.  Bit ordering continues with Resp15 being the MSB, with the compare state being represented by the right-most bit value in the vector field.

The Vector field defines the substitute I/O patterns for the :S and :Q signals defined in the Match_0 Timeplate, and stipulating the Match_0 timeplate specifies the timing parameters to use.  In WGL, each vector has the capability of using different timing parameters, although that is not the case in our simple example.  The data pattern for the Stimulus pins and Response pins is a Walking 1 pattern from the LSB word to the MSB word, providing a 16-bit loop back pattern (16 LSB Stimulus pins to 16 MSB Response pins).  The pattern is entered once, but looped 32 times, as denoted by the Loop keyword.  The final four vectors are a repeat of the last vector, which contains all 0’s for both the Stimulus and Response signals, as indicated by the Repeat keyword.

Each sub-block structure is terminated by the End keyword, and the text contained in the curly-braces {} indicated text labels that are included as labels in the resulting DIO file.

WGL can represent simple Stimulus/Record digital test patterns, as well as more complex Stimulus/Response patterns that incorporate Real-Time compare functionality.  Since several Marvin Test Solutions DIO products support both functions, this article will demonstrate importing the sample WGL file both ways.

Activating DIOEasy-FIT - WGL Import Toolkit

The Marvin Test Solutions WGL import utility is a licensed product of Marvin Test Solutions , Inc. Once purchased, the File Import Translator license (FIT) can be activated by entering a unique license string for the system. The license string is based on the Computer ID of the host system where the license will be installed, and can be found from DIOEasy by clicking on Help\About DIOEasy\Setup License, and selecting Setup License (see figure 1).

Figure 1: File Import Translator License Setup

The computer ID is the 10 digit code displayed at the bottom of the DIOEasy License Setup dialog - "XXXX YYYY ZZ" in figure 2. To obtain the FIT license, open a Magic incident, request an FIT license, and provide the sales order number of your FIT purchase and the Computer ID. You will receive a license that is unique to the system whose ID you provided. Enter the license string in the "License String/File" text box and click on "OK".

Figure 2: Computer ID Code

The Marvin Test Solutions WGL import utility is supported using DIOEasy, Marvin Test Solutions' interactive digital development tool set, and from GtDio32.dll API, a Dynamic Link Library of DIO software functions. The full list of these DIO functions and their syntax and uses can be found in the "DioSoftwareProgRef.PDF" document. This document is included with the GtDio.Exe driver installation package available from the Marvin Test Solutions web page:

http://www.marvintest.com/Downloads.aspx?prodId=16&search=package

The DioFileImportWgl Function

One of the functions included in the GtDio32.Dll is DioFileImportWgl(). This function is an import utility for reading WGL formated digital test patterns and converting them into a Marvin Test Solutions DIO formatted file. The file can be loaded to the instrument, opened for viewing and editing using DIOEasy, or opened under program control so digital pattern data can be accessed from within a test program. The syntax for this function, and an example of it’s usage are provided below:

DioFileImportWgl (pszSourceWglFile, pszDestDioFile, nConversionMode, nBoardType, pdMaxFrequncy, pdwMaxSteps, pszError, nErrMaxLen, pnStatus)

Parameters:

Name	Type	Comments
pszSourceWglFile	PCSTR	Source file
pszDestDioFile	PCSTR	Target DIO file name
nConversionMode	SHORT	Conversion mode: 0 DIO_FILE_WGL_TO_DIO: Standard DIO file. 1 DIO_FILE_WGL_TO_DIO_RTC: Real Time Compare DIO file
nBoardType	SHORT	Sets the target supported DIO board type: 0x55 DIO_BOARD_TYPE_GX5055 – Gx5055 DIO board type. 0x70 DIO_BOARD_TYPE_GX5290 - Gx5290 DIO board type. 0x75 DIO_BOARD_TYPE_GX5290E - Gc5290 Express DIO board type. 0x7A DIO_BOARD_TYPE_GX5295 - Gc5295 board type.
pdMaxFrequncy	PDOUBLE	0 for the WGL importer to use the best vector clock frequency, otherwise overwrites the vector max frequency.
pdwMaxSteps	PDWORD	The maximum number of steps to convert.
pszError	PSTR	Buffer to contain the returned error string.
nErrMaxLen	SHORT	Size of the buffer to contain the error string.
pnStatus	PSHORT	Returned status: 0 on success, negative number on failure.

Importing WGL In DIOEasy

To import a WGL file into a DIOEasy digital file, click on File from the menu bar, and select Import WGL File. A dialog will pop up prompting you to select the source WGL file, and the destination DIO file (figure 3). In addition to specifying the source and destinations files, you must also select the target DIO instrument from the drop-down list (see the nBoardType parameter above), and whether to use the default values for the test frequency (data rate) and file size. When importing a WGL file, the import filter will determine the optimal timing to use based on the capabilities of the DIO instrument selected, and set the clock rate accordingly.

Figure 3: DIOEasy WGL Import Dialog

One final selection is whether to translate the WGL patterns for stimulus/record operations with Post Process compare, or to translate the WGL patterns for Real-Time compare. Real-Time compare has the advantage of performing a hardware comparison of the UUT response against a pre-loaded expected response. Since the compare process is done in hardware, and at the speed the digital engine is operating at, pass/fail results are instantaneous, whereas, post-process compare requires software to read the recorded information from the DIO hardware, and compare each step against a reference file that contains the expected UUT response. The WGL import filter supports both test methodologies, as do selected Marvin Test Solutions digital instruments.

Once the import process completes, a new DIO file is created and automatically loaded to DIOEasy. The file can be viewed and edited, the same as any other DIO file, and the test file can be loaded to the DIO hardware for execution. Figure 4 shows a portion of the translated Simple.WGL file.

Figure 4: Translated Simple.WGL Digital Test Patterns

Timing Translation

A common concern when porting digital test from the simulation environment to hardware is how timing parameters are interpreted. A simulator can generate process with picosecond timing resolution. This is far beyond the capability of the actual hardware test system to implement. The WGL import filter will try to fit the timing parameters into the capabilities of the hardware by adjusting the clock frequency to accommodate the minimum phase resolution between the signals. This is done by dividing the WGL test cycle time by the minimum phase difference between the various signals. For example, if you had a WGL file with a cycle time of 1uS (1 MHz data rate), but there was a setup parameter of 10nS between a clock and data channel, the importer would calculate a new data rate for the hardware that meets both criteria. In this example, the digital hardware would run at 100 MHz, providing the 10nS phase resolution. This translates to more digital test vectors loaded into the hardware than the native WGL file represents. In this case, 1uS period / 10nS resolution results in 10:1 pattern depth on the digital tester. So, if the WGL pattern file were initially 1M vectors, the pattern file loaded to the hardware would be 10M vectors.

[:+[+GX5295+]+:]

In some cases, the simulated phase resolution exceeds the capability of the tester, so the WGL importer maintains a proportional relationship between the signals. For example, assume the cycle time is 50nS and some of the channels in that cycle change on 5nS phases (200 MHz resolution). The WGL importer determines that one WGL cycle will require ten DIO cycles (50nS period / 5nS resolution). Assuming the hardware is the GX5292, the minimum cycle timing for this instrument is 10nS (100 MHz maximum frequency), so the pattern data rate would be set to 100 MHz, but you would maintain the 10:1 pattern ratio to keep the phase relationships proportional to the original WGL pattern ( (50nS period / 5nS resolution) = (100nS period / 10nS resolution) ).

Multisite Digital Test System Design - Published on 3/9/2021

3/9/2021

Introduction

Semiconductor digital tests, especially digital test programs converted from simulation files such as STIL, WGL, VCD, EVCD or ATP, are often required to be expanded into multiple DUT test sites. This article discusses the system hardware and software requirements to perform multi-site testing using the GtDio6x product line and ATEasy®, to provide a cost effective solution.

Digital Design Considerations

When designing a multi-site test program the tradeoffs between cost and performance may not be completely understood. After evaluating the performance and capability of the GX5296 or the GX5964 series of dynamic digital instruments, it may be logical to assume that the large number of channels of a single GtDio6x board should be capable of providing a multi-site digital test solution. While this solution is possible, it cannot yield the performance of a system that uses a digital resource or board per DUT test site.

Domain Per Site Solution

Marvin Test Solutions recommends that multi-site test systems be designed such that each DUT test site uses its own digital domain, as shown in Figure 1. This solution provides the fastest multi-site test performance, as each DUT test site can be run independently.

Figure 1 – Multi-Domain Solution Block Diagram

Using this configuration, all digital resources are available for each DUT test site. The test status of each DUT test site can be instantly identified by reading the Real Time Compare (RTC) error status register. In addition, the system can be designed such that each DUT test site will use the same digital test file and test program. DUT test sites can be can easily be expanded by adding additional digital domains. Using ATEasy® a multi-threaded test program can easily be created to perform this testing.

Table 1 – The relative merits of the Multi-Domain Solution

Single Domain Solution

A multi-site digital test system designed using a single digital domain as shown in Figure 2 has several disadvantages. First, each test site can no longer use the same digital file. This solution will require a separate application to create the additional test sites from the original digital file. This additional application would need to copy the original channel and vector data to all of the new DUT test sites.

Figure 2 – Single Domain Solution Block Diagram

This also requires a much more complicated test program to determine DUT test site status. As with the multi-board solution if the RTC error status register is zero then all DUT test sites pass. But when a failure occurs, the status of each DUT test site cannot be determined by simply reading the RTC error status register. The DUT test status must be determined by reading the RTC Error Address and or the record memories.

[:+
The record memory alone could be read and evaluated to determine the status of all DUT sites, but as the sizes of most of these digital tests are very large, the approach is not practical as it would consume too much test time.

The RTC Error address memory contains the failing vector addresses up to 1K failures. The record memory for each of these addresses can then read to determine the failing DUT site(s). As each entry indicates a failing location time is not wasted reading large sections of record memory to determine the test failures. Unless the number of failures is less than 1k or all DUTs have failed as indicated above, the status of all DUTs cannot be determined. In this case the test program must disable the failing test sites and rerun the digital test until the status of all DUT test sites are known. The GtDio6x series of digital instruments provides a method to abort the test sequence if a failure is detected; this feature can save test time when a failure occurs.
[+GX5296+]+:]

Table 2 – The relative merits of the Single-Domain Solution

Summary

The following table compares the two solutions:

Multisite in a Single Domain Solution Single Site Per Domain Solution
Programming is required to Create Digital Test File Automatic Generation of Digital Test File
Reduced number of PXI Slots and Boards More Slots/Digital Test Boards
Lower Hardware Cost Higher Hardware Cost
Slower Deployment Faster Deployment
Requires complicated programming to find the faulty DUT Better Diagnostics
Lower Test Yield Maximum Test Yield

Table 3 – Pros and Cons of Single vs. Multiple Domain Solutions

Conclusion

Unless the space (PXI slots) in the semiconductor test system is at premium, a multi-site test system should always be designed using one digital domain for each DUT test site. The upfront costs of adding the additional hardware will pay large dividends, guarantying the fastest possible test times and simplifying test programming. Careful consideration of these capabilities is paramount in the design of a multi-site digital test system.

Using External Events with the GX5296 and GX5960 Products - Published on 10/8/2020

10/8/2020

Introduction

It is often a requirement of a digital instrument to wait for a specific event to synchronize data transfers, handshake to a device under test (DUT) or to trigger on a specific event. The digital sequencer of the GX5296/GX5960 series of digital instruments provides capabilities such as conditional / unconditional jump, subroutine jump, or looping. Additionally, the sequencer has the ability to trigger on and or handshake with external signals in order to synchronize with a DUT. The trigger sources for these triggers include the Auxiliary channels as well as up to 32 digital channels. This article focuses on explaining the usage and set up the various triggers available in this series of high speed digital (DIO) products using the GtDio6x panel and ATEasy examples to program the instrument.

Trigger Logic

The Test Logic block of the digital sequencer as shown in Figure 1 is controlled by the state of the auxiliary (AUX) Inputs and or the Error / Channel Test signal (ERR/CH TEST). The Error / Channel Test or Channel Compare 0 signal is controlled by the state of the digital channels. These trigger mechanisms can direct sequencer operations such as Start, Stop, Halt, Pause and Resume as well as conditional looping from a number of input sources.

Figure 1 - DIO Block Diagram

Trigger Sources

Trigger sources are provided by the Auxiliary Channels, PXI Triggers 0-7 and Channel Compare 0. The GX5296 provides 4 and the GX5961 provides 12 Auxiliary channels. The eight PXI triggers an be generated by multiple instruments in the PXI chassis or the PXI system controller. The Channel Compare 0 trigger resource is the result of the state of any number of digital channels on the Master DIO board in the domain. Channel Compare 0 becomes true when the DIO channel states matches the Channel Compare programmed state. The Channel Test also includes mask to remove unwanted channels from the comparison. Any Trigger Input Source can be programmed to be level or edge sensitive and or can be inverted. Triggers can only be sourced from the Master DIO of a domain of channels.

GtDio6x Panel Trigger Page

The GtDio6x panel Trigger page as shown in Figure 2 allows the user to view or configure external events to control the state of the digital sequence engine. The available Trigger Logic includes multiple Pause, Resume and Jump commands as well as basic sequencer operations such as Run, Stop or Halt. The sources for these triggers can be programmed to become level or edge sensitive and can be inverted. Some of the trigger logic signals have a reset mode that can allow the trigger to occur only once or multiple times during a burst.

Figure 2 - DIO Trigger Page Run Trigger

Run and Stop Triggers

To configure a Run trigger simply select the Run trigger to in the trigger logic field. Select the trigger source such as Auxiliary 0, Level/Edge type to Rising Edge, signal Inversion to False. Press the Set button to apply theses settings. Figure 2 shows the Run trigger set to run the sequencer when Auxiliary channel 0 transitions from a low to a high logic level. Note that the Run trigger does not include a reset mode. The configuration of all triggers can be saved and or loaded using a Dio6x file. This configuration and the Stop trigger can be programmed in ATEasy as follows,

!ATEasy Run and Stop Trigger Examples
!Run Trigger example
Dio Set Trigger Run(adio6xTriggerSourcePXI0,False,adio6xTriggerOnRisingEdge)
!Stop trigger example
Dio Set Trigger Stop(adio6xTriggerSourcePXI0,False,adio6xTriggerOnFallingEdge)

Halt Trigger using Channel Compare 0

There are four channel compare triggers as shown in Figure 3. Only Channel Compare 0 can be used as an input trigger source. Each channel of the master in the domain can be used in a Channel Compare. The Channel Compare also provides a mask register to remove channels from the comparison. Each bit of the Expected and Mask values represent a channel.

When using the GX5296 a channel is "Masked Out" when the mask value of that channel is a logic 1. When using the GX5960 series a channel is "Masked Out" when the mask value of that channel is a logic 0. Channel Compare 0 becomes true when the digital channels state matches the state of the non masked expected value. This example is using the GX5296, the Channel Compare is set to 0x1234 and the mask value is set to 0xFFFF0000. In this case the GX5296 has been programmed to execute in an endless loop waiting for the channels to match the expected value of 0x1234 to halt the sequence. All other channels are ignored.

Figure 3 - Halt Trigger using Channel Compare 0

!AtEasy Halt Trigger example using Channel Compare 0
dwExpectData=0x1234
dwMaskData=0xFFFF0000
!Setup Channel Compare
Dio Set Sequencer ChannelsCompareTrigger(adio6xChannelsCompareTrigge0, dwExpectData,dwMaskData)
!Setup Halt trigger
Dio Set Trigger Halt(adio6xTriggerSourceChannelCompare0, False, adio6xTriggerOnHighLevel, adio6xHaltTriggerResetStartEndStep)

Jump Triggers

Using a Jump trigger allows a digital pattern to be repeated until an external event occurs. The trigger state is tested at the end of the step. Care must be used when using this trigger as if the trigger it can create and endless loop if the trigger condition is always present or the step will only run once if the trigger state is not matched. This trigger requires settings on both the Steps page and the trigger page. Refer to figure 4, go to the Steps page and select the where the jump is to occur. In this case Step 2, set the Step Control to Jump then perform the following selections,

Set the Loop Counter to 0

The jump Condition to Jump Trigger 0 True

Select the GoTo to Step 2

Uncheck the Continuous Loop radio button

Select a loop count 1

Finally go to the Trigger page and select Jump Trigger 0. Select the trigger source to PXI Trigger 3, the Level/Edge to High level and press the Set button.

Figure 4 - Configuring a Jump Trigger

!ATEasy Jump Trigger Example
lStep=2
lNextStep=2
lLoopCount=1
lLoopCounter=0
!Set Step Control
Dio Set Step Control(lStep,adio6xControlActionJump,lNextStep,adio6xControlConditionJumpTrigger0_True,lLoopCount,lLoopCounter,0)
!Set Jump trigger
Dio Set Trigger Jump(adio6xJumpTrigger0,adio6xTriggerSourcePXI3, False, adio6xTriggerOnRisingEdge, adio6xJumpTriggerResetStartEndStep)

Pause Resume Triggers

Pause Resume triggers offer a method to pause the sequencer to wait for an external event to occur. Unlike the Jump trigger the Pause trigger stops the execution of the sequencer and waits for an external event to Resume the additional digital sequences. Care must be taken when using this trigger as if the resume trigger event never occurs the sequencer will never resume from the pause state.

Refer to Figure 5, in this case it is known that PXI trigger 0 will be low prior to the start of the burst, this meets the pause trigger condition. The sequencer will resume when the PXI trigger 0 transitions from a low to a high state. To configure the Pause Resume triggers first go to the Steps page and select Step 0. Select the Pause trigger to Pause: Pause Trigger 0=True, Resume: Pause Resume Trigger 0=False. Then go to the Trigger page and select Pause Trigger 0. Set the trigger source to PXI Trigger 0, the Level Edge to Low level and press the set button. Finally select Resume Trigger 0 and set the trigger source to PXI Trigger 0, the Level/Edge to Rising Edge and press the set button.

Figure 5 - Pause Resume Trigger

!ATEasy Pause Resume Example
lStep=0
!Set Step pause resume trigger
Dio Set Step PauseTriggerResume(lStep,adio6xPauseTrigger0True_ResumePauseTrigger0False,adio6xResumeDisabled)
!Set Pause Trigger
Dio Set Trigger Pause(adio6xPauseTrigger0,adio6xTriggerSourcePXI0,False,adio6xTriggerOnLowLevel, adio6xTriggerResetStepStartResume)
!Set PauseResume Trigger
Dio Set Trigger PauseResume(adio6xResumeTrigger0,adio6xTriggerSourcePXI0,False,adio6xTriggerOnRisingEdge)

Conclusion

The GtDio6x series of digital instruments provides a robust set of trigger resources that can be used to control the digital instrument. For more information regarding the GtDio6x panel or for specific trigger settings refer to the GtDio6x User's guide. For further information on your specific instrument refer to the GX5296 or GX5960 User's Guides.

Countering Cybersecurity and Counterfeit Material Threats in Test Systems - Published on 10/16/2019

10/16/2019

Automatic test systems designed to validate the performance of military and aerospace products have always been held to a higher standard; moreover, emerging threats to data security and instrumentation integrity continue to raise this bar. Engineers are faced with growing pressure to not only ensure that the unit under test (UUT) meets all design criteria, but that it remains safe from malicious attacks aimed at gaining access to test parameters or results, controlling of test sequences and functionality, downloading malware, or impacting functionality by way of counterfeit parts installed in instrumentation.

Originally presented at AUTOTESTCON 2019.

Download the white paper

White Paper: Solving Functional Test Obsolescence - Published on 10/10/2019

10/10/2019

Electronic functional test equipment obsolescence challenges military, aerospace, and manufacturing test engineers who must support mission-critical electronics with lifecycles measured in decades. The lack of available OEM support for legacy Automated Test Equipment (ATE) systems compels users to consider either replacing or upgrading high-performance legacy ATE systems. Yet, the perception that replacing or upgrading obsolete systems is very expensive, extremely difficult, and / or sacrifices functionality prevents users from adopting either solution.

Marvin Test Systems’ PXI-based test system offers the features and capabilities needed to support both legacy and next generation factory and depot test needs. Key features and capabilities of the GENASYS platform’ include:

A high performance, PXI-based, digital subsystem for both legacy and next generation digital test needs

Configurable, commercial off the shelf (COTS) digital, analog, and switching software components

Comprehensive test program migration tools supporting legacy L200 / L300 test systems

To learn more about how the GENASYS platform can solve functional test obsolescence, click here.

Presentation: User Programmable FPGAs for ATE - Trends and Applications - Published on 9/12/2019

9/12/2019

User Programmable FPGAs for ATE - Trends and Applications

User-programmable FPGAs can address a range of analog and digital test needs.

This presentation will provide an overview of current trends and applications for FPGAs in automated test systems, with a focus on the advantages of employing industry standard design tools, hardware and interfaces to configure a new test instrument or a legacy replacement solution.

Originally presented at IEEE AUTOTESTCON 2019.

Download the presentation

The PXI Standard – A Summary of Updates and Enhancements to the PXI Specifications - Published on 9/5/2019

9/5/2019

Since its first release in 1998, the PXI standard has been continually upgraded, taking advantage of the ever evolving capabilities of card modular architectures. The specification, which was initially based on the PCI standard, has been continually updated as both hardware and software technologies / standards have evolved over time. And as summarized in this paper, the latest updates to the PXI specification demonstrate how the standard is focused on addressing the latest technologies and capabilities via its high performance and compact card modular architecture.

Originally presented at AUTOTESTCON 2019.

Download the white paper

Addressing ATE Instrument Obsolescence with Form / Fit / Function Compatible Solutions – A Case Study - Published on 9/5/2019

9/5/2019

The availability of form, fit, function (FFF) replacement instrument solutions offers a viable path for extending the life cycle of automatic test systems and preserving the investment in associated test programs. And for those applications where a significantly large number of active TPSs are involved, the FFF approach offers the only real viable solution. By employing a FFF replacement solution, test system maintainers are able to extend the life cycle of ATE and the associated test program sets as well as improve performance and reliability of both the ATE and the test programs.

Originally presented at AUTOTESTCON 2019.

Download the white paper

White Paper: Modernizing Military Flightline Test Sets With the MTS-207 - Published on 5/24/2019

5/24/2019

This paper describes how the USAF's 309th Software Maintenance Group (SMXG) at Hill Air Force Base developed the PATS (Portable Automated Test Set)-70 which supports the testing of various A-10/C systems on the flightline. Based on Marvin Test Solutions' MTS-207, a state-of-the-art, ruggedized, portable PXI-based platform designed for flightline, back shop, and airborne applications, the MTS-207 provided the USAF with the necessary flexibility to add a specific test instrumentation, such as GX6315 and GX2065 PXI cards for supporting the A-10/C's specific flightline test needs .

To learn more about the PATS-70 test set, click here.

White Paper: Leveraging Industry Standards for User Programmable FPGA Instrumentation - Published on 9/25/2018

9/25/2018

Field Programmable Gate Arrays (FPGAs) are used extensively in today’s electronic assemblies and test engineers are also choosing to incorporate FPGA-based instrumentation as part of their functional test solutions. Today there are a variety of user-programmable FPGA-based instruments available to test engineers which can be used to support a wide range of applications and interfaces. These instruments employ a range of programming tools and architectures. However, to ensure maximum flexibility and long-term / organic support for test systems and applications, both the suppliers and end-users of these instruments need to focus on employing industry standards.

Download the white paper

White Paper: Next Generation Armament Test Solutions for the Flightline - Published on 9/25/2018

9/25/2018

Smart weapon systems are now common place within the U.S. Armed Forces community and among U.S. allies. And to ensure mission success, maintainers need to confirm that all of these systems are mission ready or Full Mission Capable (FMC). Gone are the days of simply checking for the absence of stray voltage and the presence of firing signals by using an Armament Circuits Pre-Load Test Set (ACPTS), commonly referred to as a “beer can”. Today’s sophisticated weapon systems need to support not only legacy test needs but also advanced systems by providing multiple measurement and stimulus channels as well as incorporating communication busses such as MMSI, MIL-STD-1760, Ethernet, CAN Bus, and more. The challenges faced by developers and customers alike lie with the difficulty to incorporate these capabilities into a handheld package to help minimize the “footprint of test”.

There are some advanced solutions available today that can address not only the current generation of legacy and smart weapons but also have the flexibility to address future armament test needs on the flightline. Building on the current generation of “smart” beercans, the next generation solution for flightline test offers maintainers the ability to perform advanced test and diagnosis on the flightline - simplifying maintenance logistics while increasing performance and reducing test and maintenance time.

Download the white paper

Presentation: User Programmable FPGA PXI Instrumentation for Functional Test – Applications and Best Practices - Published on 9/20/2018

9/20/2018

User Programmable FPGA PXI Instrumentation for Functional Test – Applications and Best Practices

Field Programmable Gate Arrays are used extensively in today’s electronic assemblies and test engineers are also choosing to incorporate FPGA – based instrumentation as part of their functional test solutions.

This presentation will provide an overview of how user-programmable, FPGA-based PXI instrumentation, when combined with commercially available IP (Intellectual Property) or custom logic cores, can provide cost-effective, flexible test instrumentation solutions which can potentially support multiple applications and a range of interfaces using a single, FPGA-based instrument. In addition, the presentation will discuss “best practices” associated with the design and programming of FPGAs in order to ensure success and maintainability for a user – defined FPGA instrument.

Originally presented at PXI China 2018.

Download the presentation

White Paper: Metal-Oxide (MOX) Gas Sensor Testing - Published on 6/4/2018

6/4/2018

The application of MEMS technology has allowed Metal Oxide (MOX) Gas Sensors to be mass-produced at the wafer level with silicon wafer manufacturing offering cost reduction and scalability to large volumes.

This white paper discusses how a semiconductor manufacturer of Gas Sensors employed a focused test solution that provided the required accuracy, accommodated very large site counts, and matched the over-all throughput performance of high performance semiconductor test systems at a much lower cost.

Download the white paper

Active Power Management for Digital Functional Test Systems - Published on 12/18/2017

12/18/2017

Digital functional test systems have been part of the test landscape for over 40 years. The earliest test systems employed simple, static digital test capabilities. However, as the performance and complexity of these digital devices, modules, and systems evolved, the digital test instrumentation advanced as well. In particular, the on-going advancements associated with device toggle rates have placed a corresponding demand for ever-higher performance on the test instrumentation and systems, with today’s high-end semiconductor test systems offering multi-GHz test capabilities with attendant high power dissipation.

For military-aerospace applications, digital functional test has always presented a unique set of requirements and challenges. Unlike the test requirements associated with high-end device test, M-A applications are primarily focused on supporting module and system level test. Consequently, “bleeding edge” digital test performance is not required; however, a broad range of test flexibility and capability is required. The test systems and associated digital subsystems are tasked with supporting a broad portfolio of both legacy and current generation electronic assemblies, since these test systems are being used to service products in the field as well as test new generation products in the factory. More specifically, test systems deployed in the field (such as the VIPER/T shown in Figure 1) have the added constraints of both size and power dissipation – with the requirement that these systems be portable and exhibit high reliability.

Figure 1: VIPER/T Test System

The digital subsystem’s capabilities associated with these types of systems include:

Support vector rates of at least 50 MHz with timing per pin, multiple time sets and a flexible sequencer.

Offer a compact footprint and modular architecture, supporting up to 512 channels within a single chassis.

Offer a wide programmable drive / sense voltage range, which allows support for both legacy applications as well as current technologies.

Flexible architecture providing per pin programmability – maximizing flexibility for a wide range of applications.

Managing the power requirements and power dissipation associated with these digital subsystems is a key requirement to achieving high reliability. Modern digital subsystems employ two major components - a high performance ASIC or FPGA which provides all of the digital logic, timing, and sequence control; and a monolithic pin electronics (PE) device(s) which interfaces to the digital logic and provides the programmable levels to the UUT or device under test (Figure 2).

Figure 2: Digital Subsystem Architecture

Historically, pin electronics for digital subsystems have relied upon custom designs – some discrete, some hybrid and some full custom. However, today there are commercial vendors producing a range of pin electronic products for both semiconductor and board level test applications that offer a high level of integration and channel density. These devices are a key enabler to achieving ever higher channel densities, which also brings with it the on-going challenge of managing power dissipation and power consumption.

Today’s digital subsystems are based on open architecture, card modular platforms such as the VXI and PXI standard, with PXI being the dominant platform. And to accommodate many of the necessary features and capabilities associated with supporting M-A applications, PXI’s 6U form factor offers added PCB real estate and flexibility with regard to the use of additional power supplies, beyond the standard PXI supplies. However, power management is still a primary concern for these digital subsystems. Consider the following:

For a wide voltage swing, high slew rate configuration, power requirements per channel can be 2.5 W or more, with a 32 channel board requiring 80 watts just for the pin electronics.

A multi-board digital system, with all channels operating in a high voltage mode (25 V range) can require over 1200 W of power for a 512 channel system.

Total input power for a digital subsystem can easily exceed 2 KW for a high channel count system.

As previously noted, today’s digital subsystem architectures are comprised of pin electronics and a digital ASIC or FPGA and as indicated above, the PEs are responsible for a significant portion of a digital subsystem’s power dissipation. Clearly, there is the opportunity to manage overall system power dissipation by actively managing the configuration and operating conditions associated with the PE devices.

Modern monolithic pin electronics employ two voltage rails, VH (or VCC) and VL (or VEE), which support the programmable input and output voltage levels and interface to the unit under test. These rails require a wide voltage range (-18 V to +29 V), and are the primary source of high power dissipation within the system. Consequently, by actively managing the PE devices’ operating conditions based on specific test needs, total average power and dissipation can be reduced. Incorporating programmable power supplies into the system for VL and VH and tightly controlling them by software, based on an application’s specific drive / sense levels, offers the ability to manage overall power dissipation. Under software control, active power management can be accomplished in the following ways:

Operation with optimal rail voltages - The quiescent power dissipation for pin electronics is VL+VH times the quiescent current. However, the instrument output’s programmable levels Voh and Vol for a specific application may not be close to the VH and VL rails, with quiescent power dissipation being high regardless of the programmed Voh and Vol levels if the maximum voltages are applied to the VH and VL device rails. However, by programmatically lowering the VH and VL voltage levels such that just enough head room is required for a specific application, power dissipation can be significantly reduced. Consider the case where the programmable output level range is -10 V to +15 V. The VH voltage needs to be around 20 V and the VL voltage needs to be around -15 V to provide head room for the pin electronics circuits. If an application requires Voh=5V and Vol=0V, VH can be programmed down to 10V and VL to -5V. In this case, the pin electronics’ power dissipation will be reduced by more than 50%. By actively managing the VH and VL power supply voltages, power dissipation can be minimized, resulting in lower operating temperatures and increased reliability.

The design of PE devices also allows for the device’s output section to be powered down without affecting the digital state of the device. This feature is extremely useful when one considers that the active duty cycle or burst time for running active digital patterns is very low. Consequently, by incorporating an “intelligent” or “smart” instrument driver that manages the digital subsystem’s power supplies, average power consumption (and power dissipation) can be reduced by over 50%.

Adjustable / programmable slew rate and device bias current also provide the means to actively manage overall digital subsystem power dissipation. For those applications that require a high voltage swing, high slew rate is typically not required. Consequently, the PEs can be programmed via the instrument driver for optimum slew rate and bias levels based on specific test needs. A range of over 2 to 1 is available for managing power dissipation.

To prove out the effectiveness of the “active power” management implementation, an existing test program that employed a VXI-based digital test system was converted to execute on a 6U PXI digital subsystem (Figure 3) that employs an active power management implementation.

Figure 3: PXI Digital Subsystem

Compared to the legacy VXI-based digital subsystem, the PXI system demonstrated over a 50% reduction in power consumption under idle conditions - translating into lower operational costs, lower internal operating temperatures, and increased overall system reliability and up time. By leveraging the features and capabilities found in modern digital pin electronics in conjunction with use of “smart” instrument drivers, an active power management implementation can be realized that minimizes power dissipation without sacrificing system performance.

Using Visual Indicators (LEDs) in ITAs - Published on 11/13/2017

11/13/2017

MTS has developed a CCA that serves as a general purpose indicator board.

Attached are the schematics 3999-402-00-Aa-SCH.PDF and the assembly drawings 3999-402-00_Assembly Drawings.pdf. The mechanical engineers have a template of the board so they can design an ITA front panel after you tell them which indicator the design uses of the available ones.

There are 4 AC indicators (LD7 – LD10), supporting ITAs that use a three phase input (Neutral is common for them) and / or a single phase. Those inputs are rectified and designed to be ON for inputs of about 115VAC (most probably will be ON for a much lower voltage too).

There are 2 DC indicators for the 5-40V range (LD1 - LD2). When the associated jumper connects positions 1 and 2 the range is 5-20V, when connecting 2-3 the range is 6-40V.

There are 4 DC indicators for the 6-80V range (LD3 – LD6). When the associated jumper connects positions 1 and 2 the range is 8-80V, when connecting 2-3 the range is 6-40V.

Keep in mind that the DC inputs have an input capacitor and the AC inputs have a 270K input resistor. This means that Safe To Turn On or Isolation tests may be impacted.

White Paper: Implementing Digital Interfaces with User Programmable FPGAs - Published on 9/22/2017

9/22/2017

The electronics test engineer is constantly challenged by a myriad of digital interfaces. Military, Space, Communications, and Automotive electronics all utilize both industry standard and custom digital interfaces. Many of these interfaces are supported with test instrumentation that is dedicated to a specific interface or alternatively, a cycle-based, general purpose digital I/O instrument may be employed. Using dedicated test instrumentation can be very costly and general purpose digital I/O instrumentation can offer only a partial solution as well as requiring substantial programming / debugging, with either solution ultimately driving up the cost of test. A user-programmable FPGA-based solution can offer a cost-effective, alternative solution for supporting digital interfaces and specifically, serial interfaces.

Download the white paper

Using Subversion (SVN) Source Control From ATEasy - Published on 6/27/2017

6/27/2017

How to Use Tortoise SVN With ATEasy

1. Download and install TortoiseSVN (x86 or x64 depending on your system) from SourceForge.net. Make sure Command line client tools are installed.

Figure 1: Install TortoiseSVN and make sure the command line client tools are installed.

2. Using Windows explorer, create a folder to host the repository (local or server). Right click the newly created folder and select TortoiseSVN and select Create Repository Here. Click on Create folder structure.

Figure 2: Creating a TortoiseSVN repository.

3. Open ATEasy, select Tools, Options, then the Source Control tab. In the drop-down box select Subversion. Make sure the executable is correct; if not, locate the file and update the Executable field. Click Close and confirm your selection.

Figure 3: Select the TortoiseSVN executable.

4. Open a workspace and select the project you wish to add to the source control repository. Right click on the Project from the workspace window and select Add:

Figure 4: Add your project to the Source Control Repository.

5. In the Add Files to Source Control dialog do the following:

Type in the Repository Root (server or local folder where you created the repository).

Type in the Subfolder - usually the project name where the added files will be stored in the repository.

Type in the Working Copy Folder - the root folder for your local files where the project resides. Note that all of the Added files should be located below this root folder.

Check the files that you want to add. Note not to select files that reside in a folder outside of the working folder.

Figure 5: Add Files to Source Control.

Next, click OK to add the files. You will get the following message if TestExec Subfolder in the repository does not exist.

Figure 6: Subfolder if the repository does not exist.

Click Yes to add the files to the repository and put them under source control (shown in Cyan color in the workspace window). The files are also checked off as shown here:

Figure 7: Files under source control have check marks.

Note: The Log window's Source Control tab will show all the commands invoked by ATEasy that perform the operation (Add Files in this case). This log can also be used to troubleshoot the operation in case of issues due to a wrong command line configuration set by the Options dialog or wrong parameters invoked by ATEasy. The command reply is also visible. The Log window is color coded so that commands invoked by ATEasy show in blue, replies from the source control tool show in green, and error replies show in red.

Figure 8: The Log window Source Control tab.

Note: The information about the repository and the local working folder is saved in the ATEasy Workspace file used when you added the file to the source control repository.

6. You can check the latest status of the file in the source control repository using the Source Control > Show Properties command.

Figure 9: Source Control File Properties.

7. To add the other files that reside under the Drivers folder, repeat steps 4 and 5. Select the Profile and the Test Exec drivers and add them to the repository under the Drivers subfolder and C:\Program Files\ATEasy 9.0\Drivers working folder.

Figure 10: Add the Other Files that reside under the Drivers folder.

At this point all the project files are added and checked off as shown here:

Figure 11: All project files are added and checked off.

8. You now can make changes to the files , save them, and when ready, re-check the files in. For example, change the TestExec1.prg and check it in. You can also add a comment to describe the changes made as shown here:

Figure 12: Check In.

9. You can open the Source Control History dialog and see all the file revisions that were checked in, including the revision number, the user, the date and the comment:

Figure 13: Source Control History.

You can select the revision you need and then click on Get to copy that revision to add to a selected folder:

Figure 14: Get a copy of a revision.

Use Open to open that revision in ATEasy, View Text to view the revision in text mode, and Diff to show the difference between the revision and the version you have selected as shown here:

Figure 15: Use Diff to show the difference between the revision and the version you have.

10. The Get Files operation is useful when you no longer have the files locally and you want to retrieve them from source control. To get files from the repository, right click and go to Source Control > Get Files.

Figure 16: Get Files from Source Control.

How to Convert C++ Driver Example to LabWindows/CVI - Published on 4/26/2017

4/26/2017

Introduction

This Knowledge base will give guidance on how to convert Marvin Test Solutions C++ Driver Example to LabWindows/CVI. Since CVI is based on C and not C++ we need to convert some types from C++ to C.

Steps to Convert Examples

Step 1: Create LabWindows/CVI Project

Create the LabWindows/CVI project in the Examples\LabWindows\ folder. Save it at GxXXXExampleC.

Step 2: Copy Example files to the LabWindows folder

Copy GxXXX.h, GxXXX.lib and GxXXXExample.cpp files into the newly created folder. Rename the .CPP file to .C as LabWindows only works with C files.

Step 3: Insert the Example files into the LabWindows/CVI project.

Insert GxXXX.h, GxXXX.lib and GxXXXExample.c files into the newly created project.

Step 4: Modify the GxXXX.h file.

In the GxXXX.h file there is a piece of code that needs to be modified.

The original code looks like:

After the change is made:

Step 5: Modify the GxXXXExample.c code to account for C++ to C changes.

The following changes need to be made to the C file to account for the change in language from C++ to C.

false needs to changed to FALSE

true needs to be changed to TRUE

new needs to be changed with malloc

Example:
padwDataWr = new DWORD[dwDmaByteCount];
becomes
padwDataWr = (DWORD *) malloc(sizeof(DWORD) * dwDmaByteCount);

delete[] needs to be converted to free

Example:
delete [] padwWr;
becomes
free(padwDataWr);

atoi() needs to be converted to (BYTE)atoi()

Example:
atoi(szParameter);
becomes
(BYTE)atoi(szParameter)

Conclusion

To convert a C++ example to LabWindows/CVI can be done, but there are some challenges that need to be met. When converting your own C++ code to LabWindows, be aware of any language specific changes that need to be made.

Download LabWindows/CVI Example showing converting the C++ provided with GXFPGA driver converted to C.

Migrating from ATEasy 2.x to ATEasy 9.0 - Published on 4/25/2017

4/25/2017

To begin migrating your ATEasy 2 project to the new ATEasy:

1. Installing ATEasy

Install the new version of ATEasy with Migration Files. This installation choice has DLLs that will be used in the conversion step.

You can choose to install the Migration Files by:

Selecting Install.

Selecting the ATEasy 2.x Migration Files option in the Custom Install. If you have already installed ATEasy just rerun the installation and choose Modify and check the ATEasy 2.x Migration Files.

Figure 1: Installing Migration Files

The ATEasy Setup will copy three Migration Files:

ATEasy2_32.dll: This file is used for loading and converting ATEasy 2 files into the new ATEasy file format.

ATEZUser32.dll: This file is used if your existing ATEasy 2 system makes use of the USER driver (ATEZUser.drv).

ATEZUser.drv: This file is a new ATEasy driver file replacing the ATEZUSER.ins used by system files in ATEasy 2. It provides procedures to create user interface elements used in ATEasy 2 applications

2. Creating a New Project

Create a new project using the File, New.. menu command. That project will become the Active Project (shows in bold in the workspace window).

Figure 2: Creating a New Project

Figure 3: The new Project is shown in bold in the Workspace View

3. Save the New Project

Save the project file by clicking File, Save. We recommend to save all application files (.prg, .sys, .drv, .prj. wsp) that were migrated or created to a single and new application folder.

4. Adding System File

Open and add the ATEasy 2 system file (.CFG file) into the new ATEasy project using the File, Open... menu command. Make sure Add to Project is checked in the File Open dialog.

Figure 4: ATEasy 2 .CFG file is added into the ATEasy project

During the process of converting the system file the ATEasy 2 driver files (.INS) that are configured to your old system will be also converted. If ATEasy cannot find the INS file you'll be prompt to enter a new path for them. You will also be prompted to replace any 16 bit DLLs that were used by the old driver files to 32 bit DLLs. ATEasy will scan your system and driver file code and make changes during the conversion.

Figure 5: ATEasy 2 .INS files are migrated during CFG file migration.

Figure 6: ATEasy System File after migration.

5. Adding a TestExecutive

If you need a test executive user interface to your application insert the TestExec.drv and Profile.drv (Profile driver must be inserted before the Test executive).

Figure 7: Inserting TestExec after Migration of the System file is complete.

Figure 8: ATEasy System File after TestExec is inserted.

6. Inserting Programs

Insert your ATEasy 2 program (.PRG) files into the new ATEasy project (similar to step #3) . ATEasy will scan your program code and make changes during the conversion.

Figure 9: Inserting an ATEasy Program(PRG) File.

Figure 10: Choosing an ATEasy Program(PRG) File.

Figure 11: Program shown in the Workspace view inside the newly created Project.

If you have not saved the files up until now this would be a good time to do Save All. This will make sure that all the migration is saved. The old ATEasy 2 files will not be changed. Since the Program files keep the same file extension, the file name should be changed or saved in a different location.

Figure 12: Saving the Migrated Program file to another name.

Finally there is the workspace to save. In ATEasy 2 these did not exist, but this is where you can link many ATEasy projects together. You can choose not to have a workspace and add the project to an empty workspace every time you want to work with it, but it is beneficial to have all your projects in one easy to reach location.

Figure 13: Saving the Workspace to link many Projects together.

Downloads

If you would like to see the files that were imported, the example is available for download.

If you would like to read more information about ATEasy migration and what has been changed in the new ATEasy continue to the sections below.

What's New in ATEasy from version 2.x

New ATEasy Features	ATEasy 2 Features
Windows 9x, or newer user interface incorporating all of the GUI capabilities and design features of these advanced operating systems.	Windows 3.1 user interface.
A 32-bit application written using the Win32 programming model and object-oriented techniques.	A 16-bit application.
An event-driven programming language using properties, methods and events to aid in ease of use and functionality.	A declarative programming language.
Support for OLE Automation, for interaction with other OLE-compliant applications such as Microsoft Excel.	N/A
Integration of the various "editors" of ATEasy 2 into a coherent and unified menu structure.	Specialized "editors" for different areas of the program.
Forms are now built into ATEasy, and use events to respond to user action.	Only dialog boxes can be constructed.

Code Changes

1. Converting Basic Data Types to 'C' like data types.
Basic data types have been renamed in the new version to correspond with 'C'-like data types. Their size and functionality remain the same. When you do programming in the new ATEasy, you will have to use the renamed data types.

ATEasy 2	ATEasy 9
byte	char
int	short
long	long
float	double

2. Restructuring Driver and System Commands
Driver and System commands have been restructured in the new version.

Commands in ATEasy 2 were divided into four types: Analog, Digital, Instrument and Special.

If you created a command in ATEasy 2 under Instrument or Special, it can be used in the new ATEasy as is.

If you created a command in ATEasy 2 under Analog or Digital, the syntax of that command looked like:

Set XXX Function VDC

where XXX was the name of the driver.

In the new ATEasy, the syntax for commands is:

XXX Set Function VDC

where XXX is the name of the driver.

The new ATEasy will convert commands used in tests and procedures to the correct syntax when converting, but the System Driver must be loaded in order for the conversion to take place.

3. Filename Extensions have changed

ATEasy 2	ATEasy 9
.INS files	.DRV files (driver files)
CFG files	.SYS files (system files)
.PRG files	.PRG files (program files)

4. LST Files are no longer supported
The new ATEasy does not support the loading of .LST (ASCII text format program) files. Use ATEasy 2 to load these files and convert them to .PRG files before converting the .PRG files to the new ATEasy.

5. 16-bit DLL's are no longer supported
The new ATEasy does not support 16-bit DLLs. If your .INS driver (with the exception of ATEZUSER) uses a 16-bit DLL, you will have to replace it with a 32-bit DLL. If you have the source code for the 16-bit DLL, recompile it as a 32-bit DLL. If you do not have the source code, contact the vendor who supplied the 16-DLL to obtain a 32-bit version. Below is the warning box you get when you try to load and convert an .INS driver based on a 16-bit DLL.

6. Dialog Box(DLG) files are now supported through ATEZUSER
The new ATEasy supports .DLG (dialog box) files through the ATEZUSER driver; they can be used as is. However, it is recommended that you consider converting your .DLG files to ATEasy 9 Forms, as Forms offer much more flexibility plus event-based programming. (This conversion is not a file format conversion; you will have to rework your dialog boxes manually.)

7. String RIGHT function functions differently
The RIGHT string function in the new ATEasy differs from the RIGHT function in ATEasy 2.

The RIGHT function in ATEasy 2 programs will be changed to the MID function with one parameter when a program is converted to the new ATEasy.

When MID has only one parameter, it functions the same as RIGHT.

Mid (sSTR, iBYTES)

where iBytes is the number of bytes from the right that will be returned. With this syntax:

Mid ("abc",2) = "bc"

Note: Many of the new ATEasy library functions have been modified to accept additional optional parameters. However, these functions remain compatible with their ATEasy 2 equivalents.

8. Subroutines have been replaced by Events.

ATEasy 2 subroutines have been replaced by the use of Events in the new ATEasy. The following table describes the ATEasy 2 subroutines and the corresponding new ATEasy event. Click on any event for a syntax description and an example of its use.

During the process of converting ATEasy 2 files to the new ATEasy files, the new ATEasy converts each ATEasy 2 subroutine in each module into a corresponding event. For example, if the Driver module contained an _AbortProgram subroutine, the new ATEasy would convert it to an OnAbort event residing in the Driver module. For more information on conversion, see Converting ATEasy 2 Files.

ATEasy 2 Subroutine	ATEasy 3 Corresponding Event
_AbortProgram	System OnAbort Event Program OnAbort Event Driver OnAbort Event
_EndProgram	System OnEndProgram Event Driver OnEndProgram Event
_EndTask	System OnEndTask Event Program OnEndTask Event Driver OnEnd Task Event
_EndTest	System OnEndTest Event Program OnEndTest Event Driver OnEndTest Event
_ErrorProgram	System OnError Event Program OnError Event Driver OnError Event
_InitProgram	Driver OnInitProgram Event System OnInitProgram Event
_InitTask	System OnInitTask Event Program OnInitTask Event Driver OnInitTask Event
_InitTest	System OnInitTest Event Program OnInitTest Event Driver OnInitTest Event
_ResetProgram	Program OnReset Event
_ResetDriver	Driver OnReset Event
_ResetSystem	System OnReset Event

9. Run statement has changed
The Run statement argument for a string expression has changed in the new ATEasy. The syntax is:

Run program-specifier

One change is that in the new ATEasy, the program-specifier can be a string or object expression. In ATEasy 2, the program-specifier could only be a string expression.

Another change is that when a string expression is passed as an argument in the new ATEasy, the string expression can contain a program shortcut name or a program filename. In ATEasy 2, when a string expression was passed as an argument, it contained only a filename.

10. TestRefResult was removed and replaced with TestResult
TestRefResult variable which was used to store Ref-X/2 test result was deleted. You need to use the TestResult variable instead. The migration will convert all preferences.

White Paper: Presentation: Leveraging the PXI Modular Architecture for Semiconductor ATE Platforms - Published on 11/29/2016

11/29/2016

Leveraging the PXI Modular Architecture for ATE Platforms

The PXI platform presents a flexible, innovative, cost-effective alternative to big-iron ATE systems for semiconductor test. Marvin Test Solutions offers a range of advanced, PXI-based test system configurations for digital, mixed-signal and RF test applications.

Originally presented at International Test Conference 2016.

Download the presentation

Combat Helicopters and Armament Test - Published on 11/15/2016

11/15/2016

In the decades since it made its debut on the battlefields of the mid-20th Century, the helicopter has come into its own as a nimble, responsive platform capable of performing a variety of missions over widely divergent terrain. Supporting these aircraft presents unique challenges for the military services.

Download the white paper

White Paper: Using IEEE 1149.1-2013 (JTAG) with ATEasy - Published on 11/10/2016

11/10/2016

ATEasy® is a flexible integrated Test Executive development environment for board and system- level test. This white paper provides an overview of how ATEasy can be used to support JTAG/IEEE 1149.1 based instrument control, programming and test.

Download the white paper

White Paper: Legacy Test Systems - Replace or Maintain - Published on 9/21/2016

9/21/2016

Test platforms age, the components within the test systems degrade, become obsolete and wear out over time. Manufacturing companies must continuously evaluate the expected lifespan of their test equipment and determine the risk and tradeoffs associated with replacing the equipment vs. maintaining the equipment. Both industry and government entities continually struggle with how to best evaluate and address the issues of aging test equipment and systems. This paper reviews the various options available to test engineers when faced with replacing or maintaining a test system.

Download the white paper

White Paper: Modernizing Legacy Automated Test Systems for DoD Depots - Published on 6/28/2016

6/28/2016

Department of defense (DoD) maintenance depots face a growing challenge regarding legacy Automated Test Systems (ATS). These systems, which are critical to ensuring mission success, are increasingly difficult to maintain and repair as well as being costly to modernize or replace. According to the General Accounting Office, the DoD has estimated that they will spend billions of dollars to modernize their ATS inventory, much of which was acquired in the 1970s and 1980s [1]. One of the maintenance depots is Tobyhanna Army Depot (TYAD) and is in a similar situation with its legacy test systems. The aging testers at TYAD are becoming increasingly out of date and more difficult to support. When the testers do not work properly, maintenance can suffer and readiness can be adversely affected. This paper reviews the requirements and issues associated with depot ATS equipment and will present a technical strategy for the modernization of ATS at TYAD.

Download the white paper

Solution Spotlight: Cost Effective Functional Test Solutions with ATEasy - Published on 6/16/2016

6/16/2016

Solution Spotlight: Cost Effective Functional Test Solutions with ATEasy®

From Test Connections Newsletter - December 2015

Test engineers are looking for more time efficient & cost effective functional test solutions for modern electronics. To achieve this, many are exploring the use of low cost equipment and/or alternative test strategies, such as eliminating ICT/Flying-probe test and instead, using simpler test methods including AOI and functional test work-flows. True time and cost savings however, do not come from just using low cost equipment or eliminating tests; there are many considerations to realize a cost effective test solution.

In-house designed test systems often 'hide' the true time and cost of developing & maintaining the hardware, software, & mechanics associated with a test system within the company’s overhead expenses. The cost of test escapes and field failures, not to mention customer satisfaction, can often get 'buried’ deep in a company's general operating costs. The most effective “total cost solution” often comes from using high quality equipment, and a standardized, reconfigurable and reusable test platform.

One of the most important considerations when designing or selecting a test system is to choose the right software platform. Using a powerful and standardized software platform is the ideal goal, which offers the following key benefits:

Reduced training time & costs

Accelerated implementation of test programs because of standardization and the ability to re-use code

Improved efficiency of test engineering resources by having a common programming / toolset environment

Reduced test program maintenance and support costs

For functional test systems, the software platform should include the following features and capabilities:

A focus on automated functional test

A simple and easy to use coding language, structured coding environment and intelligent code completion to speed the overall coding process

Easy code maintenance & re-use

Backward compatibility with previous versions of the test program tool set

Support for various communication protocols

Extensive driver support for various instruments and a simple method for implementing new drivers

Support for existing customer test code including graphical programming languages such as LabView. .

A configurable and feature rich test executive.

Expert support and training

Just as the software platform described above offers key features and benefits for functional test, the associated test system hardware needs to be highly integrated, flexible, reconfigurable and reusable, allowing its use on multiple projects within a company. Test engineers must also consider the test system’s mechanics at the outset. All too often this is an afterthought and the downfall of many a test system. A good test system interface solution should allow easy, quick, short, and reliable interconnection to the UUT while at the same time being easily reconfigurable and reusable.

Eiger Design GmbH, has recently introduced the J-Testr, a new, highly integrated, flexible & modular functional test system which includes the ATEasy® Lite software platform and offers the features and capabilities detailed above. J-Testr's compact size, versatility and safety features make it applicable for functional test applications ranging from commercial and industrial to military. In particular, the J-testr offers a simplified tester / UUT interface, by employing a special dual plugging mechanism and a simple interposer design for connecting test system resources to the UUT.

The J-Testr, provides a full range of peripheral stimulation cards which are all controlled via the ATEasy® Lite software and offer advanced test and safety features required for efficient, safe and quick testing of modern UUTs. The ATEasy® Lite product is designed specifically for OEM suppliers of functional test systems, offering a cost effective and full-featured test development and test executive environment that supports OEM specific instrumentation. With ATEasy® Lite, functional test suppliers can offer a robust, cost-effective, commercial software platform that supports their test system specific hardware as well as an additional “external” instrument.

When combining ATEasy® Lite's features with systems such as the J-Testr, test engineers can considerably reduce their 'true' functional test system implementation and support costs, as well as realizing moderate acquisition costs.

Solution Spotlight: Replacing Legacy Instrumentation with Form/Fit/Function (FFF) Instrumentation - Published on 6/7/2016

6/7/2016

Replacing Legacy Instrumentation with Form/Fit/Function (FFF) Instrumentation

From Test Connections Newsletter - June 2015

Military, aerospace and even commercial products require support equipment for production and maintenance. One important type of support equipment is functional Automated Test Equipment (ATE). When a dedicated test system fails and is not available, there is usually an immediate impact on the product it supports. It can be a monetary impact or even worse, readiness impact. Legacy ATE systems are being pushed into extended service, beyond the service years for which they were originally intended, and as they age, the downtime increases. Instrument obsolescence is one of the major reasons for test system down time. If a system resource fails, it must be repaired or replaced. If the instrument is no longer produced (i.e. obsolete), then other, less traditional remedies must be employed.

Preserving Investment

Over a test system’s life span, significant costs can accrue. ATE costs start with the initial investment for designing, building and developing Test Program Sets (TPSs). However, after the initial cost of ATE deployment, test system costs will continue to accrue due to the on-going investment in test programs, fixtures, etc. And over time, the major investment component will become the test programs which increases exponentially, as the number of programs are added to a system.

Cost of TPS Relative to ATE Capital Cost

Additionally, as the ATE matures, maintenance costs will increase due to ageing and obsolescence issues. Consequently, to preserve the investment in the test system and associated test programs, identifying “drop – in” or form, fit, function replacement solutions for obsolescence issues can offer a cost-effective solution.

Replacement Options

Stockpiling Spares
Stockpiling of spare instruments is one way to mitigate system down time and maintenance issues. The spare instruments may be procured as part of the initial investment, during the ATE life span or as a life time buy when the notice of end of life is received. With the typical life span for commercial instrumentation being 5-7 years, but with test systems in use for 20 or more years, this strategy is routinely employed by test system maintainers. However; this is only a short-term solution, particularly when dealing with system life cycles of 20+ years since at some point, the spares will be depleted.

Ongoing Maintenance and Repair
On-going maintenance and repair of the obsolete instrument may be an option. However, the problem with this approach is the ever-increasing cost and time to repair as well as obtaining components which may become obsolete. Even if some systems are reserved for cannibalization, the source of instruments and parts will eventually be exhausted - resulting in a short-term solution at best.

Used Instruments
A tempting solution is to find an instrument replacement on the secondary market. Many test equipment distributors offer used instruments and depending on the age of the instrument (how long it has been out of production), there is a good chance of finding the instrument on the secondary market. However, even if the equipment is in pristine condition, this is still a short term solution to the long term problem of support and maintenance since eventually, this source will be exhausted.

TPS Migration / COTS Instrument with Adapter
A long-term solution can be the migration of the test program to a new, up-to-date test system.
However, this approach can be very expensive; especially if a large number of TPS’ are involved and particularly if new fixtures are also part of the conversion process. Consequently, the high cost associated with a complete test program re-host strategy usually precludes TPS migration to a new test platform. What is a more likely scenario is to selectively replace those instruments that are obsolete with a new COTS instrument which can offer comparable functionality and performance. However, software functionality will not be compatible, requiring a software driver wrapper or adapter. Identifying a COTS functional replacement should be done with care. The candidate instrument’s specification should be scrutinized closely to verify that all the features used in the ATE are compatible, all the levels and ranges are covered, and all required inputs and outputs exist. An important issue that must be addressed is the improved performance of the new instrument. Newer instruments will, in most cases, have much faster or better performance than the obsolete instrument which will typically lead to TPS failures. For example, if a DMM with a reading rate of 100 readings per second is being replaced by a new DMM with a reading rate of 1000 readings per second, it may be necessary to add delays to the test program.

In most cases the new instrument is not compatible with the legacy command set and translation/adaption is required. The translation should replicate the legacy instrument’s commands as well as the instrument’s response. Comprehensive functionality also needs to include any self-test functionality that the legacy instrument may have offered, since overall compatibility must address not only test program functionality, but also any system self-test functionality which may incorporate individual instrument self-test functionality. Instrument adaption can be accomplished in one of two ways:

Software conversion layer or wrapper: With addition of a software wrapper to the instrument’s driver, the replacement instrument will be compatible with the legacy instrument’s commands and TPSs should be able to use the new instrument with virtually no changes. Of course once installed, the legacy instrument cannot be used any more. However, like all software development tasks, there is also some risk involved and in many cases, changes to the test program may be required, necessitating revalidation of the complete test program - incurring additional time and expense.

Hardware adapter or Translation Module Adapter (TMA): A TMA is a stand-alone unit that connects between the system controller and the replacement instrument. The TMA has its own processor and uses two ports; one to communicate with the system controller and one to communicate with the replacement instrument. Special firmware needs to be developed to accept the legacy commands from the controller and translate them to the new instrument’ commands. Like its software counterpart, once a hardware adapter is implemented, TPSs should be able to use the new instrument with virtually no changes but unlike the software adapter, the legacy instrument can still be used simply by bypassing the TMA. Hardware adapters face similar obstacles as their software counterparts. There is some risk involved with firmware development and communication response time can create timing issues, necessitating test program revisions - requiring TPS revalidation.

Form, Fit Function (FFF) Instrument Replacement - A Superior Solution

FFF instrument replacement offers a superior solution for replacing out of production, legacy instrumentation. A modern, COTS instrument with an integral communication interface adapter offers a drop in replacement that is functionally, electrically, and mechanically equivalent to the legacy instrument, preserving the initial investment in the ATE and associated TPS’. Key features and benefits associated with an FFF solution include:

Preservation of existing test programs. Great care is taken replicate the legacy instrument’s functionality, allowing system self-test and test programs to execute with no changes - eliminating the time and costs associated with re-verification.

Flexibility to use both the legacy instrument and replacement instrument

Ability to replicate “un-documented” behavior of a legacy instrument - which can be a key feature for performing accurate TPS execution since a TPS may use undocumented functions as a “feature” requiring the replacement instrument to behave the same.

FFF Replacement: GP1612 for HP8112

As shown in the chart below, the FFF solution when compared to all other alternatives, offers key advantages for those users looking to replace legacy instrumentation as well as preserving their investment in ATE and TPS.

Marvin Test Solutions' GP15xx and GP16xx instrumentation offers 100% form-fit-function drop in replacements for a broad range of GPIB pulse, arbitrary waveform and function generators that were manufactured by Wavetek and Hewlett-Packard.

Obsolete Product	Manufacturer	MTS Model Number
HP8160A	Hewlett Packard	GP1552AH
HP8112	Hewlett Packard	GP1612H
HP8116	Hewlett Packard	GP1616H
HP8165A	Hewlett Packard	GP1665H
175	Wavetek	GP1650W
178	Wavetek	GP1665W
859	Wavetek	GP1552AW

White Paper: PXI-Based, Advanced Switching Architecture for Functional Test - Published on 5/24/2016

5/24/2016

Virtually all ATE systems employ a switching subsystem in order to route test system resources to multiple test points on the UUT. The challenge for any switching subsystem is multi-dimensional and involves many considerations / trade-offs including footprint, performance, flexibility, maintainability, and reliability. Additionally, if the application needs to address legacy test needs, there can be the additional challenge to support not only current and future switching requirements, but also legacy test requirements. Many of today’s functional test systems employ the PXI architecture which offers modularity and flexibility. However when combining switching and instrumentation, test engineers can be challenged to create a system that combines all of the switching and instrumentation capabilities in one compact platform.

Download the white paper

Solution Spotlight: Expanding Digital Test Capabilities with a Multi-Site Test Feature - Published on 5/16/2016

5/16/2016

Solution Spotlight: Expanding Digital Test Capabilities with a Multi-Site Test Feature

From Test Connections Newsletter - September 2015

Figure 1: GX5295

Today’s semiconductor vendors are increasingly moving to open architecture, PXI –based solutions to provide them with cost effective, compact footprint, and flexible test solutions. MEMS suppliers in particular, are looking to PXI-based solutions as being well-suited for addressing their need for cost effective test solutions.

MTS was approached by a major supplier of MEMS devices to help with addressing their requirement to test multiple, low pin count devices using Marvin Test Solutions’ GX5295 digital instrument. Supporting 32 digital channels, with PMU per pin capability, the customer needed to support the testing of 8 devices, using a single GX5295 for their multi-site test configuration. The customer’s key requirements included the following:

Using the GX5295’s Real-Time Compare function, log the first failure on each channel if/when they occur. The failed channel is correlated to specific site failures.

For future failure analysis, record the test pattern step where each channel’s first-failure occurred.

Suppress all further real-time compare operations for a channel, after the first failure.

Enable or disable first-failure logging on a channel-by-channel basis.

Support complete test execution, without pause or interruption, regardless of the number of channel failures.

Report all failed channels with a single register read, avoiding the time-consuming operation of up-loading and post processing the full pattern buffer to identify failed channels.

Maintain existing real-time compare capability.

Support the LabVIEW programming environment

With the requirements defined, MTS’ engineering group enhanced the GX5295's features with an updated firmware, driver and software package to meet all of the objectives outlined above. These new features included the following enhancements:

Channel error latch with a feed-back loop to the real-time compare mask circuit.

Selection logic to enable the Record-First-Failure (RFF) mode or the standard Real-Time Compare mode (RTC).

A Channel-Disable register to globally and selectively disable real-time compare per channel when operating in the RFF mode.

New API functions added to the GX5295 DLL to control the new RFF features

An upgraded GtDio Panel application which provides interactive control and display of results for the RFF functions

LabVIEW wrappers for the new RFF functions which were added to the GX5295’s DLL.

Implementation

In normal operation, the RTC Error Memory will record up to 1K of errors, including address locations. However, for applications that require support for multi-site testing ( and recording of errors on each channel), what is needed is additional control logic that will record only the first failure for each channel, preventing the possibility of overflowing the 1K of error memory if multiple errors occur on a single channel. The block diagram below details the normal RTC operation and the enhanced RFF mode of operation. With the modified GX5295 firmware, both the RTC and RFF features are supported by the module with the mode of operation being a software selection.

Figure 2: RTC and RTF Modes

On-Site Evaluation & Deployment

The new capabilities were delivered to the customer for beta testing, and installed on a development station in their test lab.  The GX5295 supports firmware upgrades in the field by loading the new firmware to the target hardware via the PXI bus. An updated DLL, DioEasy application and updated LabVIEW drivers were also installed on-site.

Initial checkout was done using the DioEasy application and involved loading the GX5295 with test patterns that would guarantee multiple RTC errors across many channels, using a simple loopback cable to inter-connect channels.  The original RTC functionality was first demonstrated and verified, proving that the changes did not affect the base-line functionality of the GX5295.  Then, the RFF mode was enabled, and the test results verified that only the first failure (and failing vector address) for a channel was recorded in the GX5295 error memory.  Subsequent errors for the channel were ignored.  At the conclusion of the test, the DioEasy display correctly indicated all known failing channels.

Once the new capabilities were demonstrated, the process was repeated with the customer’s Devices Under Test (DUT’s).  The GX5295 executed a 20M-vector scan test on twelve devices simultaneously.  With a 1K error memory, the un-enhanced GX5295 would over-run the error memory if one site were bad, forcing a cumbersome coding exercise to monitor the error memory, and when full, save the error information, clear the error memory, and continue the test.  At the conclusion of the test, the saved error data had to be integrated and correlated to the failed DUT site(s). With the RFF mode enabled, the tests were again executed and it was verified that only the first failure for a channel was recorded in the GX5295’s error memory.  Failures were also induced on several sites, and in each circumstance, the GX5295 correctly identified the failing sites – in a single pass and without an error memory over-run.

The customer’s LabVIEW control program was then modified to add the new functions for setting up and controlling the RFF capabilities and a single “Read Error” VI was placed in parallel with the LabVIEW code that was managing the data collection and correlation to identify failed sites.  When executed, the modified code executed as expected and correctly identified all of the failed sites.  The end result was that the multi-site test ran faster by eliminating a significant piece of code that was used to manage error collection, reducing a lengthy, iterative process of running, flushing error memory, and restarting the test.  In addition, test functionality was improved in that any known bad sites could be excluded from the test simply by writing a value to the Channel Disable Register that would mask the channel associated with that site, eliminating the need to fill a 20M-vector pattern (in this instance) with the equivalent mask pattern. With the enhanced GX5295, MTS was able to deliver a test solution that meets all of the customer’s stated requirements and provides a drop-in upgrade path for those customers using the GX5295 for multi-site semiconductor testing.

PXI chassis configuration is lost every time the system is powered up. - Published on 5/16/2016

5/16/2016

Problem: Every time my test system boots up, the Marvin Test Solutions PXI chassis configuration that is stored in the PXISYS.ini file gets replaced with an empty file with no configuration data. This forces us to create a new PXISYS.ini file with the correct configuration data each time the system is re-booted.

Solution:
This problem is caused by National Instruments Measurement and Automation Explorer overwriting the Marvin Test Solutions slot description file upon rebooting. If you have NI Measurement and Automation Explorer (NI-MAX) installed, and it is version 4.0 or later, then your configuration file is being overwritten by NI-MAX and NI-VISA . To correct this problem you need perform one of the following procedures:

1. Download and install the latest HW (v4.9.1 or above). Many of Marvin Test Solutions drivers and products release after April 2016 contains the new HW. The new HW perform the registry fix (described in 2 below) automatically .

2. Modify the Windows registry by applying a registry patch to disable NI-VISA from doing this. The process is as follows:

Create a text file called "DisableBootPxiSysGeneration.reg" and copy/paste the following text to the file:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWARENational InstrumentsNI-PXIRM]
"DisableBootPxiSysGeneration"=dword:00000001
Save the file (in text format).
Double click the file to apply the registry change.
Use PXI/PCI Explorer to verify or assign instruments to the appropriate chassis slot.
Cycle power and verify that the chassis configuration and instrument slots are preserved.

Solution Spotlight: Field and Flightline Testing of MIL-STD-1760 Systems - Published on 5/10/2016

5/10/2016

Field and Flightline Testing of MIL-STD-1760 Systems

From Test Connections Newsletter - March 2015

MIL-STD-1760 defines the electrical interface between the aircraft and the Carriage Stores as well as the mechanical and communication protocol aspects of the interface.

The intent of MIL-STD-1760 (also known as just "1760") was to simplify the integration of new weapons onto existing platforms. Prior to the introduction of 1760, the integration cost of a new weapon system was over $100 million dollars (in 1980 dollars). With 1760, integration costs shrank to under $25 million which was a significant improvement.

As with all good inventions, there’s always a "but" and 1760 was no exception. Most field and flight-line test sets for armament were deployed over three decades ago and as such, were not suitable to test the "smart" interface of MIL-STD-1760. And unlike legacy systems, the aircraft is expecting to have a carriage store present in order to keep the interface active. Immediately after powering up the 1760 interface, the aircraft sends a MIL-STD-1553 transmission that can be translated to "who’s out there".

The aircraft is expecting an answer within 150 mSec and this response needs to include the identification of the Carriage Store or at least a message that says "I’m busy". In case of the "busy" message, the aircraft expects the identification response within 500 mSec of power up.  If there’s no response from the carriage store, the aircraft shuts down the interface and it is no longer powered or operating.

Legacy field and flight-line test sets cannot communicate with the aircraft as they do not include the ability to test a 1760 interface. As a result, they can only perform some limited testing of the interface during the first 150 mSec after power up. However,  since they can’t even respond with an "I’m busy" answer, the interface will be shut down 150 mSec after power is applied and from that point forward, the test set is testing a dormant interface. Since one of the main functions of flight-line armament test sets is to check for stray voltage and functionality, it is clear that neither can be achieved unless the aircraft "believes" that there’s a real 1760 carriage store present and active.

In order to effectively test the interface, the test set not only needs to support the MIL-STD-1760 interface but it also needs to be able to identify itself as a real carriage store that will be recognized by the aircraft as part of its standard configuration. Since this is not easily achieved, many users revert to the use of the real carriage store when testing is needed although using a real carriage store as a test set has its complications too.  Stores such as JDAM cannot just be connected to the interface. Because the store’s Inertial Measurement Unit (IMU) needs to be aligned, the store will need to move before it can be aligned prior to testing the interface. This means that the aircraft needs to be taxied around the base until such alignment is achieved which also means that a pilot is now needed to run the test. Obviously, having a pilot taxi the aircraft around the air base to test the 1760 interface is not a preferred method although it is being used occasionally. Alternatively, maintainers have attempted to use other tools, such as a ruggedized laptop with a MIL-STD-1553 interface configured as a weapon. However, this solution is also inadequate since it does not support the testing of power, analog, or discrete signals associated with the 1760 interface.

Full featured and complete testing of the 1760 interface is key to ensuring mission readiness. Recognizing this need for a next generation flight-line test solution, Marvin Test Solutions (MTS) developed the MTS-3060 SmartCan. As a universal flight line armament test set the SmartCan is capable of testing all legacy and "smart" interfaces used on military aircraft.

Most military aircraft today are capable of carrying JDAM and for that reason, MTS elected to implement JDAM support with the SmartCan. Upon power up, the SmartCan will identify itself as a JDAM and test the entire interface while the aircraft is communicating with the "JDAM". Additionally, since some wing stations (such as the wingtip) cannot be used with JDAM, MTS also implemented support for testing the AIM-120 AMRAAM interface. With the SmartCan, the aircraft does not need to be moved anywhere and the 1760 interface can be tested thoroughly without moving the aircraft.

The compact and handheld MTS-3060 SmartCan™ operates from four commercial AA batteries and weighs less than 2 Kg, making it ideal for flight-line test applications. With its full-featured MIL-STD-1553 interface, the SmartCan can support the testing of virtually any "smart weapon" interface including JDAM and AIM-120. Additionally, it can load / test AC and DC power lines, provide video for testing the 1760’s analog signals, and check for the functionality and presence of stray voltage on the Release Consent line.

Solution Spotlight: Advanced Digital Testing Using PXI Instrumentation - Published on 5/6/2016

5/6/2016

Solution Spotlight: Advanced Digital Testing Using PXI Instrumentation

From Test Connections Newsletter - March 2016

Device Under Test

The target device was a WiFi IC, with 802.11n and Bluetooth capabilities. Upon reviewing the target IC specifications, a set of resource requirements to test the IC were identified and matched to instruments available in the PXI form-factor. The Device Under Test (DUT) required four power supplies, and the power supplies had to be sequenced in a specific order when powering up the DUT. Further, while the IDD for the DUT was very low, when the DUT was initialized, the inrush current could exceed 1A on one of the supplies. The power requirement mandated that programmable power supplies be used, and that the 1A of in-rush current be accommodated.

On initial power-up, the DUT is in a low-power idle state whereby communication is possible. There are two communication ports on the DUT: a JTAG port and a Scan port. The JTAG port is used to configure and initialize the DUT, and perform an initial structural test of the IO. The Scan port is used to configure the DUT for operation and complete the structural IO test. Additional functional tests are also implemented using the Scan port to control the DUT.

Since the DUT was already being tested on an UltraFlex system, the DUT had a proven set of test patterns that were available for reuse with the PXI system. Marvin Test Solutions’ file conversion tools were available to convert the ATP files to hardware specific patterns, with the digital test instrumentation meeting the speed, channel density, pattern depth, and timing capabilities required to accurately represent the ATP pattern file parameters.

Test System

A means to interface to the DUT was required in order to substitute for the IC handler associated with the UltraFlex system. Dedicated DUT boards were designed and cabled to the instrumentation for the demonstration system. The DUT board design was modularized to accommodate easy expansion of the number of test sites and demonstrate multi-site test capabilities.

Figure 1: Test System

The system design as shown consisted of a GX7100B PXI 3U/6U Combo Smart Chassis. A combination of 3U and 6U PXI slots was required to accommodate the two GX7400A programmable power supplies. Each GX7400A provides two 150W programmable power supplies in three 6U slots.

Four GX5296 PXI modules were chosen as the digital test instruments for the DUT. The GX5296 provides 32 IO channels per card with full PMU per channel capabilities, 64M pattern depth, 125 MHz clock rates, 1nS edge timing resolution, timing per pin, and real-time compare of DUT response data.

Using MTS’ GtDio6x-FIT file translation tools, the digital test patterns were translated from the UltraFlex ATP pattern files, and formatted so that the patterns for each DUT would reside on two GX5296 instruments. Expanding the capabilities from testing one DUT to two DUT’s was simply a matter of adding a second set of GX5296 instruments, and cabling from those modules to a second DUT test board.

The software to control loading the translated ATP test patterns, running the analog contact tests, executing the test patterns and reporting test results to the operator was written using the ATEasy® development environment, and the test execution was controlled using the integrated Test Executive GUI. Demonstrations were also written using LabVIEW and TestStand to show the overall versatility of using open architecture hardware and software tools for semiconductor test applications.

Figure 2: GX5296

To learn more about PXI - Based Semiconductor Test Systems: Advanced Test Capabilities and Features, download our white paper.

What is the screw thread for the Marvin Test Solutions switching product's DB78 connector - Published on 5/6/2016

5/6/2016

Solution:

Geotest switching cards use a Positronic DB78 connector. This connector has a jackscrew for fastening a harness or cable. What is the jack-screw thread spec? It is 4-40 thread.

Calling Marvin Test Solutions DLL functions from a C# Visual Studio .NET Project - Published on 5/6/2016

5/6/2016

All Marvin Test Solutions driver packages such as GxPS, GxSW, etc. come with a Windows DLL that can be called from a user created Windows application. Each driver package also includes examples and interface files (.vb and .h) for Visual Basic and C/C++ projects.

Before referencing such a DLL in a C# .NET project, a few steps must be taken to bridge the gap between the Unmanaged code in the DLL and the Managed code in the .NET project.

This can be accomplished by using a concept called Marshaling where unmanaged data types are converted to managed .NET CLR (Common Language Run-time) data types. Each .NET datatype has a default unmanaged data type that the CLR will use to marshal data back and forth between managed code and a unmanaged function. As an example, the C# data type string has a default unamnaged data type of LPTSTR. Note that the default marshaled datatype can be changed in the C# code. The figure below illustrates the relationship between the .NET classes and the Marvin Test Solutions DLL. Generally, the application class will reference function prototypes that are defined in a marshalling class which actually links to the DLL functions.

Follow these steps to use the DLL from C#:

1. Create a new .cs file (GxFpga.cs in this example) to contain a class that will import and define all the functions and constants in a Marvin Test Solutions DLL. This class should be contained in a namespace that will later be referenced in your main program with a "using" statement.

Use the DllImport attritube within your C# code, to specify the name of the DLL that needs to be loaded.

Use the static and extern C# keywords to declare a function prototype and name for the imported DLL function along with the correct parameter datatypes.

Use the ref keyword to delcare pointer parameters (data passed by reference) and the MarshalAs keyword to change the default marshaled datatype.

In this example the GxFpgaInitialize, GxFpgaGetDriverSummary and GxFpgaWriteMemory C functions along with some constants, will be imported into a C# .NET project:

GxFpgaInitialize (SHORT nSlot, PSHORT pnHandle, PSHORT pnStatus);
GxFpgaGetDriverSummary (PSTR pszSummary , SHORT nSummaryMaxLen, PDWORD pdwVersion, PSHORT pnStatus);
GxFpgaWriteMemory(SHORT nHandle, DWORD dwOffset, PVOID pvData, DWORD dwSize, PSHORT pnStatus);

#define GXFPGA_LOAD_TARGET_VOLATILE 0
#define GXFPGA_LOAD_TARGET_EEPROM 1

The following is an example of the above header file converted to c# declaration:

//GxFpga.cs

using System;
using System.Runtime.InteropServices;
using System.Text;

namespace GxFpgaNamspace
{
    class GxFpga
    {

        [DllImport("GxFpga.dll")]
        public static extern void GxFpgaInitialize(short nSlot, ref short pnHandle, ref short pnStatus);
        [DllImport("GxFpga.dll")]
        public static extern void GxFpgaGetDriverSummary([MarshalAs(UnmanagedType.LPStr)] StringBuilder sSummary, short nMaxLength, ref long pdwVersion, ref short pnStatus);
        [DllImport("GxFpga.dll")]
        public static extern void GxFpgaWriteMemory(short nHandle, UInt32 dwOffset, UInt32[] pvData, UInt32 dwSize, ref short pnStatus);
        [DllImport("GxFpga.dll")]
        public static extern void GxFpgaReadMemory(short nHandle, UInt32 dwOffset, UInt32[] pvData, UInt32 dwSize, ref short pnStatus);
        [DllImport("GxFpga.dll")]
        public static extern void GxFpgaReset(short nHandle, ref short pnStatus);

         // … more functions and definitions here

        public const short GXFPGA_LOAD_TARGET_VOLATILE = 0;

        public const short GXFPGA_LOAD_TARGET_EEPROM = 1;

        // … more definitions here

    }

}

Note that in the example above, [MarshalAs(UnmanagedType.LPStr)] was used to override the default marshaled datatype of LPTSTR (Unicode). The default marshaled datatype for the .NET data types short and long work correctly and do not need to be modified. The StringBuilder class should be used for passing strings by reference as shown in the GxFpgaGetDriverSummary function prototype above.

2. Add the .cs file created above to your C# .NET Project.

3. Include the marshalling class created in step 1, within your main project code with a "using" statement. Then call the imported DLL functions.

//Program.cs

using System;
using System.Runtime.InteropServices;
using System.Text;
using GxFpgaNamspace;

class GxFpgaExample
{
    static void Main(string[] args)
    {
        short nHandle = 0, nStatus = 0;
        long dwVersion = 0;
        UInt32[] adwReadData;
        UInt32[] adwWriteData;
        UInt32 i;
        StringBuilder sSummary = new StringBuilder(256);

        adwReadData = new UInt32[10];
        adwWriteData = new UInt32[10];

        for(i=0; i<10; i++)
            adwWriteData[i] = i+2;

        GxFpga.GxFpgaInitialize(35, ref nHandle, ref nStatus);

        GxFpga.GxFpgaGetDriverSummary(sSummary, 256, ref dwVersion, ref nStatus);

        GxFpga.GxFpgaReset(nHandle, ref nStatus);

        GxFpga.GxFpgaWriteMemory(nHandle, 0, adwWriteData, 4*10, ref nStatus);

        GxFpga.GxFpgaReadMemory(nHandle, 0, adwReadData, 4*10, ref nStatus);

    }
}

Note that the ref keyword is also used when passing non-string parameters by reference. The StringBuilder class is used so that the buffer can be allocated before passing it to the GxFpgaGetDriverSummary. String would not work in this case because it is immutable.

PXI Addressing Using Marvin Test Solutions and VISA based Drivers - Published on 5/6/2016

5/6/2016

To initialize a VISA based PXI drivers, you call viOpen(.., resource, …_) function passing resource string as an address that can be one of the following:

Canonical resource name – “PXI::15::INSTR” PXI bus 0 device 15, or using slot numbers “PXI::CHASSIS1::SLOT3::INSTR” –In this case, when you move the board to another slot in the chassis you need to specify different string and change the application.

Alias Name– “DMM1” – DMM1 need to be defined in the VISA resource manager (usually NI-MAX) Alias Editor and assigned to physical PXI address – In this case, when you move the board to another slot in the chassis you need to open the VISA resource manager and change the alias to point to the new slot – no change to the application is required.

Marvin Test Solutions drivers for PXI instruments are supplied with HW - Geotest Hardware Access Driver. These drivers works in two modes, using VISA or using HW:

Using VISA – Using the Geotest driver GxxxInitializeVisa( … ,sResource, …) function - Allow you to initialize using resource string or alias as in VISA : “PXI::15::INSTR” or “DMM1”) – Using an alias will allow moving of the card without changing the address (you need to change using the VISA resource manager Alias Editor).

Using HW – the Geotest driver GxxxxInitialize(.., nSlot, …) function – You can specify the nSlot parameter in two ways: logical number (legacy slot, for example 3) or physical slot number: chassis*256+slot - 0x103 for chassis 1 slot 3. If you use the logical slot number (3) when you move the board from slot 3 to 4 – You can reassign 4 to 3 logical number using the Marvin Test Solutions PCI/PXI Explorer applet and the app will work with no changes. HW also support alias name, you can set alias name using PXI Explorer and use a HW function to convert the “DMM1” alias as entered in PXI Explorer applet to nSlot to allow using names instead of addresses.

The following are the HW v3.2 functions used to map between alias and physical PXI/PCI address as defined in hw.h:

// returns the VISA resource for the specified alias
INT  HwPciGetAliasVisaResource(PCSTR pszAlias, PSTR pszResource);

// returns the chassis slot for the specified alias (Chassis*256+Slot)
INT  HwPciGetAliasChassisSlot(PCSTR pszAlias);

// returns the legacy slot for the specified alias
INT  HwPciGetAliasLegacySlot(PCSTR pszAlias);

In ATEasy, you configure PXI driver address from the driver shortcut property page. Newer ATEasy drivers (for example GX2200.drv) supports the same type of initialization of the instrument: using VISA or using HW. If you intend to use VISA, set the VISAResource driver parameter to a resource string or alias. If you intend to use HW, set the Slot parameter to legacy or slot number (you can also call the HwPciGetAliasChassisSlot if you intend to use alias).

Notes:

Marvin Test Solutions drivers that were release with HW v1.x or v2.x do not support VISA

Alias mapping is provided with HW 3.2 and above

What is the mating connector for the Marvin Test Solutions DIO products - Published on 5/6/2016

5/6/2016

The Marvin Test Solutions DIO cards use 68-pin female VHDCI connector with a shielded, double pin row receptacle. The mating connector is the Honda HDRA-E68MA+ (or equivalent). The plastic shell part number is HDRA-E68LGKPE.

For more information check the Honda Web Site.

Connector Image and Information

Importing Teradyne* DTB files to the Marvin Test Solutions GX5960 Digital Subsystem - Published on 5/6/2016

5/6/2016

Teradyne^TM* users who have already developed digital test programs for the Teradyne^TM* platform in the form of Digital Test Binary (DTB) files can convert them to XML files and then import them using Marvin Test Solutions' GtDio6x Software Front Panel.

The process of importing the DTB files consists of the following steps:

Exporting the DTB files to XML

The Teradyne^TM* software front panel can be used to export a DTB file to XML format, allowing for a transparent and readable representation of the digital test data.

Creating a Domain to describe the GX5960 (GX5961/GX5964) Digital Subsystem

A Domain is a group of adjacent GX5960 PXI cards that are synchronized across the PXI backplane using a common set of timing signals. Several cards can be added to a domain in order to achieve a pin count that matches or exceeds the pin count requirement by the original .DTB file.

The GX5960 series is comprised of two individual, stand alone PXI cards, the GX5961 and the GX5964. The GX5961 has 16 I/O channels and additional connectors for auxiliary channels, high voltage pins, and an external probe connection. The GX5964 has 32 I/O channels. More information can be found at: GX5960. Depending on the needs of the end user (channel and feature requirements), one or more of these cards can be used to describe the digital subsystem. Using the GtDio6x Software Front Panel, a Domain can be set up in the domain tab as shown here:

Importing and executing the XML file for the Marvin Test Solutions Gx5960 Digital Subsystem

The XML file can be imported into the GX5960 Digital Subsystem by way of a C API function call that is part of the Marvin Test Solutions Driver DLL. The function prototype of this function is as follows:

VOID WINAPI GtDio6xExecuteDigitalTest(SHORT nHandle, LPCSTR szXMLFile, PLONG palPinRemapping, LONG lPinRemappingArraySize, PSHORT pnTestResult, PLONG plStatus)

The array parameter palPinRemapping allows the end user to create a mapping between the DTB specified channel numbering and the physical channels that make up the Gx5960 Digital Subsystem Domain.

The indices of the array represent the physical channels of the domain and the values of each element represent the corresponding mapped pins from the DTB derived XML file. The following graphic shows this relationship:

The GtDio6xExecuteDigitalTest function will load the digital sub system with the pattern data, timing sets, and channel settings as specified in the DTB derived XML file and execute the digital burst.

Querying the Subsystem for error count and location

Once sequencer execution has started, its status can be polled by calling GtDio6xQuerySequencerStatus. Once execution has finished (or during execution), the user can query the instrument for a real time error count. The instrument also has a 1024 deep real time error memory that stores the pattern location of the first 1024 errors that have occurred. The error memory can be accessed by calling GtDio6xQueryErrorAddress. Finally, the error record memory can be accessed which stores a per channel and pin pass/fail result that mirrors the pattern data memory. The record memory can be accessed by calling GtDio6xQueryRecordData.

Saving configuration to a native Marvin Test Solutions XML file

Once the digital subsystem has been loaded with the DTB derived XML file, the configuration can be edited and saved in a Marvin Test Solutions native XML file format for later use by calling GtDio6xFileSaveConfiguration and GtDio6xFileLoadConfiguration.

* Teradyne is trademark of Teradyne, Inc.

How to configure NI-MAX version 4.1 and above to recognize a Marvin Test Solutions chassis. - Published on 5/6/2016

5/6/2016

Solution:

Note: HW v3.0 and above automated the process described below. You can configure the chassis from the HW PXI/PCI Explorer applet that can be found the Windows Control Panel using the Scan for New Devices and clicking on the Save button.

Download and install the GxChassis package, found in the download section of the Geotest website. Once this package is installed, all the chassis INI files can be found at the following path: C:Program Files\Marvin Test Solutions\GxChassis\INI Files\.

In NI Measurement & Automation Explorer (NI-MAX), right click on "PXI System" and select "Show PXI Buses". Typically, multiple buses will be shown, and the chassis may be associated with any one of these buses (depending on chassis type).

Starting from the first bus listed, right click and select "Identify as a PXI Chassis". Then choose "other chassis" and select the Geotest .INI file that corresponds to your chassis.

In case of an error message ("This chassis has been identified but is not described in the pxisys.ini for this system") right click on "PXI System" and select "Delete All Identifications".

Repeat steps 1 through 3 listed above, using the next bus in sequence, until NI-MAX properly identifies the correct Geotest chassis.

Right click on "PXI System" again, and deselect (uncheck) "Show PXI Buses".

You will now be able to view and configure your chassis and its resources, using NI Measurement & Automation Explorer (NI-MAX) 4.1+.

Integrating Verifide's Data Storage and Analysis Tools with ATEasy - Published on 3/21/2016

3/21/2016

ATEasy provides the ability to easily log test data which can then be analyzed to identify failure rates, yields, and pass/ fail trends. The use of 3rd party data analysis tools can greatly simplify this process compared to using conventional IT solutions which are deficient in several key areas:

1. File based data systems although simple, do not provide data management, search, or querying capabilities.
2. Database systems allow querying but are not flexible, require database administrator skills and effort, and can perform poorly
3. Basic data management methods do not readily support the extraction of trends and metrics from test data
4. Tools like Excel provide basic charts but no interactivity or ability to drill down
5. Dedicated reporting tools are expensive, not flexible, and often require coding to integrate

Organizations many times, are left to build their own data management infrastructure and applications, specifically for their own system and data requirements. And while this approach may meet their needs, such systems are not scalable and useable across multiple devices or production lines. A better solution is to consider a test data management tool that can be easily integrated with test software such as ATEasy. Verifide PASS is a a test management platform that can provide you with extensive capabilities for analyzing your test data.

Designed with these requirements in mind, Verifide allows you to keep your tests in ATEasy while easily adding comprehensive data management and analysis tools to your existing systems.

Figure 1:The PASS software fits around your existing ATEasy tests

The PASS software by Verifide is a complete test platform that provides a comprehensive test infrastructure, data management and visualization tools, including the following capabilities:

1. The ability to store rich data such as tables, arrays, and images.
2. The power to search, access, and analyze test data locally or from a remote computer or via a web application
3. Requires no database design or administration because the database is built dynamically as data is stored
4. Visualize data and identify trends and drill down into raw data for troubleshooting/analysis
5. Compare/overlay test data and plots
6. Generate reports from tests with no code

The PASS software is a highly modular and scalable architecture. With the PASS platform, there is no database setup and you can continue to use the same framework and applications to manage data for any and all of your test systems. You can use it on one computer, or deploy through secure corporate IT firewalls with hundreds of users.
With the event-driven architecture of ATEasy, the integration of the PASS data management system into your existing test systems is easily done. By simply adding the driver, your test results will be pushed to the database and the PASS applications will allow you to view trend data as well as generate reports.
For a more hands-on demonstration of how to integrate the software and use the data analysis tools, you can view ATEasy integration video at:
https://player.vimeo.com/video/157803873

Note: The example below assumes that the ATEasy software development platform is already installed.

Step 1: Install the PASS software

Go to http://www.verifide.com/web/ateasy.html to register and get a download of the 30 day trial software.
You will be sent a download link and installation guide to complete the installation. The example is available here for download.

Step 2: Add the driver to your ATEasy System.

First add the driver to the project by navigating to the $(InstallDir)\Samples\ATEasy\ folder and selecting the PASSDriver.drv file
This will load the driver with defaults and import all needed libraries automatically

Figure 2: The driver will be added to the project

Figure 3: Select the driver file to add to the System

Step 3: Configure any options using driver parameters

The PASS Driver allows you to configure options and override the default settings. Right click on the [PASSDriver in the System\Drivers and choose Properties, then go to the Misc tab to set these options.
By default, the driver is ENABLED, Test data and Program summary record are stored to the Database, and PASS run-time services are disabled (for events/alarms/services) so you can get started without requiring any additional applications to be started/stopped.
If you wish to disable the driver entirely, set the ALL_OFF parameter to 1
Data is stored by default to a Database named ATData. If you wish to store to another Database, set the DB_NAME parameter in the driver settings, or use one of the available driver commands to set it.

Figure 4: The driver has various options that you can control

Step 4: Run your tests.

By default, data storage is enabled and you should not need to do anything. The PASS driver will key off of the ATEasy event-driven mechanism and store the data automatically (You do not need to do any DB or parameter setup upfront)
If you choose to store additional data, in addition to the TestResult, such as arrays, images, etc. then you can use the commands in the driver to do so. You can also use the driver to log activity or debug data for later analysis.

[Figure 5: The driver has commands to add data, log messages, and configure options

Figure 6: The driver commands can be used to add additional results to the test record or to log information messages to the log

Step 4: Consuming the data

Once the results have been stored, you can view them using the PASS Vision application. This can be located in Start->All Programs->Verifide->Applications->Vision
When the application opens up, you will be asked to login. The default, Readonly, account is vguest and does not have a password, so leave it blank.

Figure 7: The vguest account does not need a password to read data from the database

This will bring up a Dashboard and show you all the existing databases and a quick snapshot of the test volume etc. If you wish to learn more, you can play around with the DEMO database to explore the full capabilities of the PASS data platform.

Figure 8: The dashboard shows all the current databases and allows the user to choose what analysis to perform

Viewing test results

To view past results by time or test name etc, first select the database name, then click on the Query button in the Dashboard. This will bring up a list of previous results. Clicking on a result will allow you to view the raw data and/or report for the test

Figure 9: The PASS reporting framework allows you to create custom templates with charts, tables, images etc.

With the PASS data management, you automatically get the ability to observe data trends across runs. To perform a trend, select a database from the dashboard and click on the Trend button.
Here, you will first select a test or tests whose results you want to analyze for trends. Then select the data items such as TestResult to trend. To define the data set, you need to then perform a query – the easiest way to do this is using the Quick Query button at the top.

Figure 10: The Trend application allows selection of result fields to create a trend table

Clicking on the Load button will mine all the data items from the results available and present it to you in a table. You can then further analyze the data visually using the chart button at the bottom of the table.

Figure 11: The trend table shows tabulated result values based on your query

From the trend table, if you click the Chart icon at the bottom of the page, then it will bring up a chart viewer for you to see all your test results plotted in a trend line.

Figure 12: The trend table values can be plotted and you can zoom in and export the chart as well.

Metrics

Metrics are important to viewing your overall test process and volumes. PASS provides this feature out-of-the-box with customizable pivot tables and analytics. For more information, please visit our main website to watch our product intro videos, or refer to our comprehensive help file.

Figure 13: Metrics allow you to view process information and statistics

Summary

Using Verifide with ATEasy offers a complete test solution. Verifide provides the tools you need across your testing process- from data analysis to data storage, including monitoring and execution requirements.

Learn more at http://www.verifide.com.

White Paper: Leveraging Open Architecture, Modular Test Platforms for ATE - Published on 11/30/2015

11/30/2015

Card modular archtectures and specifically the PXI architecture offer a compelling alternative to closed, "big iron" ATE systems for semiconductor test.
This presentation provides an overview of market factors impacting the semiconductor ATE business and describes how advanced PXI instrumentation and systems are addressing current and future semiconductor test needs. The next generation of PXI digital instrumentation offers the capabilities and test features normally only found in proprietary ATE semiconductor systems. With advent of these new, advanced digital subsystems, PXI–based semiconductor test solutions such as MTS' TS-900, can now offer a broader range of test capabilities and features for digital, mixed-signal and RF test applications.

Download the presentation

White Paper: PXI-Based, High Performance, High Density Switching Architecture - Published on 11/30/2015

11/30/2015

Virtually all ATE systems employ a switching subsystem in order to route test system resources to multiple test points on the UUT. The challenge for any switching subsystem is multi-dimensional and involves many considerations / trade-offs including footprint, performance, flexibility, maintainability, and reliability. Additionally, if the application needs to address legacy test needs, there can be the additional challenge to support not only current and future switching requirements, but also legacy test requirements. This paper reviews current switching architectures employed today and discusses the benefits / limitations of current COTS offerings. The paper also reviews the switching requirements associated with addressing high complexity / high performance functional test applications and how the development and implementation of a PXI-based switching architecture can meet these requirements.

Download the white paper

White Paper: PXI–Based Semiconductor Test Systems: Advanced Test Capabilities and Features - Published on 10/13/2015

10/13/2015

The next generation of PXI digital instrumentation offers the capabilities and test features normally only found in proprietary ATE semiconductor systems. With the advent of these new, advanced digital subsystems, PXI–based semiconductor test solutions such as the TS-900, can now offer a broader range of test capabilities and features for digital, mixed-signal and RF test applications. Offering comparable features and performance to proprietary or “big iron” ATE, today’s PXI systems offer compelling test solutions for verification, focused production, and failure analysis applications. With a wide offering of software tools, an intuitive software development / test executive environment (ATEasy), and the open architecture of PXI, PXI platforms like the TS-900 offer a cost effective, performance ATE solution.

Download white paper

Source Control using ATEasy - Published on 9/3/2015

9/3/2015

Overview

In this example we demonstrate how to setup source control for a project in ATEasy 9.0 using Git source control. Features include the ability able to add, check in/out files, view history and check differences between repository history files.

Download and Install Git

Download and install Git from the Git website: http://git-scm.com/downloads. The Git GUI can be used to view your files and edits with a broad spectrum of applications, but we will focus on using Git for ATEasy source control.

Creating Workspace

We will open ATEasy and create a new workspace called SourceControlExample.wsp. You can place the workspace within your own projects folder, in a folder on your desktop or in some other folder.

Adding Project to Workspace

Instead of creating our own project we will use one that already exists. We use the Forms project and program located in the ATEasy Examples folder (on x64 machine C:\Program Files(x86)\ATEasy 9.0\Examples\). Copy the Forms.prj and Forms.prg to your project folder located in the SourceControlExample.wsp.

Click File->Open and Forms.prj in your folder. This will open the project and program file in your workspace.

Figure 1 : Open Forms Project in SourceControlExample Workspace

Setting up Source Control Options

To setup Source Control in ATEasy click Tools->Options. Go to the Source Control tab and choose what type of Source Control you are using. In this example we are using Git. Choose where the source control client executable (.exe) file is located.

Figure 2 : ATEasy Source Control Options

Adding Files to Source Control

Each ATEasy file in the workspace can have the following icons in addition to the blue color indicating that the file belongs to source control:

file checked out by the current user
file checked out by others
file checked out by multiple users

Click on the Forms project to select it. We will now add the Files to Source Control, creating a saved base before we make any changes. Click File->Source Control->Add

Figure 3 : Initial addition of files to Source Control

Figure 4 : Add Forms Project and Program to the Source Control

After the window above pops up select both the .PRJ and .PRG files and add a comment to the commit. The comment will allow you easily distinguish commits from each other. Try to use short phrases that describe what changes you made to the files. Finally click OK and the Source Control Log will pop up and show the Git commands that are being called to commit the files to your source control.

The Workspace window in ATEasy changes after a Check In is made.

Figure 5 : Workspace After Source Control Check In

Viewing Repository Path of a File

The repository path can be viewed by opening the properties of a file in ATEasy and going to the Source Control tab. In this example we went to the Forms.prg properties.

Figure 6 : Source Control Properties

Making and Committing Changes to Source Control

We will make a change so we can see how the history and differences work. In the forms program, open and maximize the Forms so we can view all the forms that are available. Now highlight over a few forms, delete and save.

Now to commit the changes we have made, click File->Source Control->Check In…

Figure 7 : Check In Updated File to Source Control

Since we only changed the program only check the Forms.prg. Add a comment to distinguish it from other changes we may have made. Click OK to commit the change into the Source Control.

Figure 8 : Update Source Control with Program

Viewing Source Control History

To view the Source Control History, click to highlight the file you want to check then click File->Source Control->Show History…

Figure 9 : Source Control History

In the Source Control History window you can view all the commits you have made. Information about the user is displayed, the time they committed the change and the description of the change are all displayed.

Display Source Control Differences

To show the differences between the original file and the current file, highlight over the first commit on the bottom and click Diff…

Figure 10 : Difference in Original and Current program files.

To jump through the differences in the files, click the down arrow. The left side shows the current file and right side shows the file in the source control. As you can see the form was deleted from the original file.

Using ATEasy Procedure Data Type to Dynamically Call Commands and Procedures - Published on 9/3/2015

9/3/2015

The ATEasy Procedure data type allow users to programmatically link to procedures and commands, enabling the user to:

Call procedures or commands using a string that hold their name

Dynamically call commands of different driver Instances

Create scalable drivers

Procedure Data Type Basics

The ATEasy procedure data type is a pointer to a procedure. To assign data to a procedure variable you use the procedure name or procedure name string. For example, if proc is a variable of data type Procedure, the following code shows the use of the variable:

! proc: Procedure  ! declare a variable in variables

proc=GetLogString  ! assigns the internal library function GetLogString() pointer to proc variable
Print proc()       ! will call the GetLogString and will print the current log string

proc=System._Reset ! assigns System _Reset() procedure pointer to proc variable
proc()             ! will call the _Reset() procedure

proc=Abs           ! assigns the internal function Abs pointer to proc variable
print proc(-5)     ! calls Abs with a parameter of -5, this will print 5 to the log

When referencing a command with a procedure variable, the command statement is enclosed in quotes:

proc="TestExec Log Clear" ! assigns the command 'TestExec Log Clear()' pointer to a procedure
proc() ! will clear the Test Executive's log

Procedure variables can also be assigned to string variables in case any string manipulation needs to be done:

! proc: Procedure
! s:String

proc="TestExec Log Append"
s=proc
s=s+" Message"
proc=s
proc("My note") ! calls TestExec Log Append Message("My Note")

Using Procedures Variable to Call Multiple Module Instances

ATEasy supports multi UUT testing so that a single test program can be written to support testing of many devices in parallel or sequential modes. To achieve this functionality, we need to dynamically select to which Driver Shortcut to direct the commands. In a recent application, a user has 16 data bus transceivers which the user tests by sending and receiving messages from the PC. The communication with the UUTs is modeled with the UUT ATEasy driver and 16 instances of the driver are placed in the ATEasy System which the handles UUT1 through UUT16.

Since the same Program will be used for all 16 UUTs, the TPS must somehow differentiate between the various instruments. Using the internal AApp class UutIndex property to differentiate between the UUT that the program talks to. This property returns the current instance of the UUT that is running. With some procedural code in the Program module, the programmer can reference the proper driver instance as shown here:

Procedure UutMessageSend(sMessage): Void
--------------------------------------------------------------------------------
  sMessage: Val String
  proc: Procedure
{
  proc="UUT"+Str(App.UutIndex+1)+" Message Send"
  proc(sMessage)
}

For this test case, the programmer uses ATEasy's Multiple UUT testing mode and specifies parallel testing of 16 UUTs. When the application is run, 16 instances of the program and driver are created by ATEasy and executed at the same time. The instances are automatically assigned an AppIndex of 0 to 15. When UutMessageSend() is called from the Program module, the command dynamically created is "UUT1 Message Send(sMessage)" to "UUT16 Message Send(sMessage)".

Arrays of Procedures

Another approach to the solving the problem of dynamically directing commands to various UUTs is to assemble a collection of procedure pointers into an array and use the UutIndex to differentiate between them.

! i: Long
! aprocUutMessageSend: Procedure[1] ! declare array of procedure

! Resize the procedure array
redim aprocUutMessageSend[App.UutCount]
! Loading the procedure array
for i=0 to App.UutCount-1
aprocUutMessageSend[i]="UUT"+Str(i+1)+" Message Send"
next

The procedure array is loaded once during application initialization. After the array is loaded, it can be called from within the Program module with a single call:

aprocReferences[App.UutIndex](sMessage)

Common Errors

Procedure Scope
Referenced procedures must be in scope. If it is not, you will receive the following JIT compiler error.

If you link a System procedure to a procedure variable in the Program module, the System procedure must be set to public.

Procedure Not Compiled
If you assign a command to a procedure variable using quotation marks the reference will not be noticed and compiled when the application is built.

This issue can be resolved by checking the Compile checkbox in the Properties window for the procedure. Checking the Compile checkbox ensures that the procedure will be compiled, even if it is not used by your application.

White Paper: PXI-Based, Functional Test Solutions for Legacy and Next Generation Test Requirements - Published on 7/2/2015

7/2/2015

Mission critical, high value electronic products require comprehensive functional testing prior to final shipment or deployment. In addition there are many products in use today that have lifecycles extending into decades, creating a challenge for test organizations that must support these products. The lack of available OEM support for legacy Automated Test Equipment (ATE) systems compels users to consider either replacing or upgrading high-performance legacy ATE systems. Marvin Test Solutions’ PXI-based, GENASYS platform offers the features and capabilities needed to support both legacy and next generation factory and depot test needs.

Read the white papers to learn more about the GENASYS platform’s key features including:

A high performance, modular , switching subsystem that addresses both legacy and future test needs

A high performance digital subsystem for both legacy and next generation digital test needs

Configurable, commercial off the shelf (COTS) digital, analog, and switching software components including migration tools for addressing legacy test applications

Download white paper

White Paper: Bridging the Warfighting Armament Test Gap - Published on 6/26/2015

6/26/2015

Over the years, modern fighter aircraft have received numerous upgrades to their avionics and armament systems. From the F-35 to the A-10, all of the aircraft now possess “smart” (Mil-STD 1553 and 1760) weapons technology and enhancements to legacy weapons. Today’s armament systems do not resemble the systems TAC, now called Air Combat Command (ACC), deployed almost four decades ago. Yet, maintainers are still required to use the same or similar ACPTS (Armament Circuits Pre-load Test Sets) combined with big box test equipment to verify that these sophisticated armament and munitions systems are Full Mission Capable (FMC). Additionally, this combination of box testers and ACPTS equipment doesn't deliver the capabilities needed to support today’s Smart weapons.The advanced Smart armament and munitions employed today, combined with obsolete or inadequate test equipment deployed on the flight line, has created an armament test gap because of the inability of today’s O-Level testers to provide the necessary tools to test and maintain armament and munitions. The armament test gap represents major maintenance and readiness issues for maintainers and operators alike due to the necessity of having to implement of a multitude of workarounds on the flight line.

Having identified the armament test gap in legacy 4th and 5th generation aircraft several years ago, Marvin Test Solutions has developed, qualified, and successfully deployed the MTS-3060 SmartCan™ universal O-level tester across legacy aircraft and is planning to do the same for 5th generation aircraft. Despite maintaining the small footprint of a ACPTS, the MTS-3060 SmartCan™ bridges the armament test gap by combining all of the capabilities of the ACPTS and
provides maintainers with the necessary tools to adequately test and troubleshoot today’s aircraft loaded with legacy and smart weapons.

To read more about how the MTS-3060 is bridging the armament test gap, click here.

Upgrading PXI Instrument Firmware - Published on 6/18/2015

6/18/2015

Overview

Often, capabilities of PXI instrumentation is enhanced over the life of the product. Sometimes those enhancements are as a result of changes or improvements to the instrument drivers and/or controlling software. But many times those improvements are in the form of new hardware capabilities via the instrument firmware. The firmware may fix bugs that were identified after the product was delivered, or may introduce altogether new capabilities. In these cases, it is preferred that the new firmware be updated, or flashed, in the field, rather than returning the instrument to the factory. This minimizes down time associated with shipping to and from the factory, and allows immediate feedback as to the effectiveness of the upgrade.

Instruments produced by Marvin Test Solutions support field upgrades to the firmware, and from time-to-time, new firmware is released for Marvin Test Solutions (MTS) products. This document explains how to flash the firmware in the field for those MTS instruments that support this capability. The process for flashing firmware on MTS instruments is essentially the same from product-to-product, so this document will use the GX5292 Digital IO (DIO) instrument as a representative example for how to flash firmware for all MTS instruments.

Upgrading Firmware

Step 1: Request the new firmware file from Marvin Test Solutions. The best method to do so is to open a Magic support ticket, accessible from the Marvin Test Solution’s web page under the “Support” link (Figure 1, below), and request the firmware file. Using Magic requires an MTS User Account. It is free to sign up and requires only some basic information so we know who you are and how to contact you for support follow-up.

Figure 1: Magic support link

Step 2: Launch the instrument's virtual panel. For the GX5292, this is the DIO Panel (Figure 2, below), which is included in the instrument’s software installation package.

Figure 2: GX5292 instrument panel

Step 3: Initialize the instrument by selecting the hardware you wish to initialize. For the GX5292, click on the “Configuration” tab located at the top of the instrument panel, and enter your instrument list. This may be a single instrument (Figure 3, below), or multiple instruments configured as a Master/Slave domain. If necessary, you may need to select the instance of the instrument you want to initialize. For the GX5292, and most other MTS products, you specify the instrument by its PXI slot number. Click on the Initialize button.

Figure 3: Initializing the instrument

Step 4: Once the instrument is initialized, click on the About tab. The About page displays useful information about the instrument, such as the driver revision, the instrument serial number (some instruments do not include this information), the firmware revision, and the Upgrade Firmware button (Figure 4). Click on the Upgrade Firmware button. Using the navigation window, select the firmware file that was provided to you. Before committing to the upgrade, you will be provided a final opportunity to cancel the firmware upgrade process (Figure 5). Click on Yes to continue with the firmware upgrade.

Figure 4: The "About" page

Figure 5: Update Firmware confirmation

During the firmware upgrade process, the status of the upgrade (erasing old firmware, programming new firmware and verifying new firmware) will be displayed (Figure 6). It is very important that the process not be interrupted or chassis power removed during the upgrade process – especially after the old firmware has been erased. It is possible that the instrument would be left without a valid firmware installed, rendering the instrument useless. If this were to happen, then the instrument can be returned to the MTS factory in Irvine, California, where a new firmware image can be installed on the instrument. Request an RMA via your Magic incident.

Figure 6: Firmware update status

At the conclusion of the firmware upgrade, a message will be displayed indicating that the firmware upgrade was successful (Figure 7).

Figure 7: Firmware update completed

Step 5: At this time, the instrument EEPROM has been upgraded and contains the new firmware image, but the instrument FPGA still retains the logic represented by the old firmware, which was loaded during the chassis power up sequence. To begin using the new firmware, it is necessary to run the PXI chassis through a full power cycle. Shut down all open applications, and then shut down the Windows OS. If the PXI chassis is still running after Windows terminates, cycle chassis power to OFF. Allow the chassis to remain off for several seconds to provide sufficient time for all backplane power voltages to dissipate, and then cycle the chassis and the host PC power to ON.

On older Windows OS’s, you may receive a New Hardware Found message. This is normal as the Windows registry retains the old firmware key. Follow the normal new hardware found installation procedure to update the registry with the new firmware information. Run the instrument virtual panel and initialize the instrument as before. The About tab should now indicate the new firmware version.

At this point, the instrument is ready to use with the new firmware functionality.

White Paper: Addressing Legacy ATE System Requirements with PXI - Published on 11/24/2014

11/24/2014

Beginning in the late 1960s, proprietary ATE systems were deployed by a wide range of customers for the functional test and verification of high value, mission critical products including board & box level avionics, depot level test & repair of armament and avionics electronics, and communications / satellite subsystems. These test systems are now obsolete, however the products (and their derivatives) originally tested on these platforms are still in use and need to be maintained. Consequently, there is an on-going need to either maintain these obsolete systems or migrate the applications and the legacy system’s capabilities to a modern test platform. Read the white paper to learn how the PXI architecture, and associated instrumentation and software can provide the basis for a modern functional test platform that can effectively support both legacy ATE functionality as well as future functional test needs.

Download white paper

White Paper: A Portable, Engineering-Design Partnership to Replace Obsolete Test Systems - Published on 11/24/2014

11/24/2014

Based on Marvin Test Solutions' MTS-207 COTS platform, a state-of-the-art, ruggedized, portable PXI-based test system designed for flightline, back shop, and airborne applications; the MTS-207 provided the USAF with the necessary flexibility to add specific test instrumentation to support the A-10/C's flightline test needs. Read the white paper to learn more about the benefits of this COTS platform including:

Accelerated time to market

Proven capabilities for flightline test

Modular and expandable for future applications

Download white paper

White Paper: Incorporating Optical Test Capabilities into a Depot Test Platform - Published on 6/25/2014

6/25/2014

Abstract

This paper reviews how an existing test platform that supports a variety of missile launcher systems; LAU 7, LAU 88, LAU 117, LAU 127, LAU 128, and LAU 129, was modified to address support for Paveway laser guided bomb kits. Specifically, support for the Paveway system required the addition of an optical test bench as well as adding additional simulation and test capabilities to accurately simulate laser targets and to measure laser detection signals. The modular design of the existing TS-217 test system afforded test engineers the ability to augment the existing test platform such that both LRU and SRU level test capabilities were part of the complete solution. Additionally, by incorporating an innovative optical bench with a solid-state target, a complete functional simulation of the weapon was achievable including testing of operational limits.

The paper details the updates incorporated into the test system which were needed to provide a test solution that offers full functional verification of the weapon. Additionally, a review of the optical bench implementation is discussed including the incorporation of a novel solid state target simulation system.

Download white paper

White Paper: Upgrading Alstom BTE Functional Test Systems with PXI - Published on 6/9/2014

6/9/2014

This technical brief provides an overview of how SNCF railway in France was able to update their current Alstom BTE (Bench Test Equipment) platforms to PXI.

SNCF maintains a wide range of electronic assemblies which are part of the Alstom train sets operated by SNCF. The BTE platform incorporated Geotest’s (now Marvin Test Solutions) GTXI systems and was deployed in world-wide locations. These test sets, which are now over 15 years old, have reached end of life, requiring railway operators to look at upgrade solutions that can be used to continue servicing Alstom’s AGATE (Advanced Generic Alstom Transport Electronics) family of electronic control units. Marvin Test Solutions (MTS) worked with Accelonix, an integrator in Paris, France to upgrade and convert SNCF's existing GTXI systems and ATEasy programs to MTS’ GX7100 PXI platform.

The resulting upgrades provided SNCF with greatly improved test performance and maintainability. Key benefits included:

Up to 60% test time reduction

Simple program conversion and retention of existing user interface by leveraging ATEasy’s backward compatibility

A modern test platform (PXI) architecture, providing a cost effective extension of the test system’s life cycle

To read more about this solution download our test solutions technical brief.

How do I force a Task or a Test to run in ATEasy Test Executive? - Published on 4/17/2014

4/17/2014

The ATEasy Test Executive provides a way for users to check and uncheck a Task or a Test by clicking on the Tests pane check boxes. The Tests pane displays a tree control (TreeView) nodes that represents a Program, Task or Test. This article describes how to check and disable a TreeView node to force a Task or a Test to run and to prevent the user from un-checking the node.

The example assumes you are running a program with a task ID "SystemBIT" and we want to prevent users from un-checking it. The code can be placed in Program.OnInit():

1. Define a program variable:

node: MSComctlLib.Node

2. Insert the following cod to the Program.OnInit() event:

! force task with an id of "SystemBit" to run, prevent the user from un-checking it
! find the node for SystemBIT, replace this name with your task ID
node=TestExec.m_frmMain.FindNode(Program, Program.Tests("SystemBIT"))
! check the node
TestExec.CheckTreeNode(node)
! prevent the user from un-checking it
TestExec.SetNodeData(node, ateNodeFieldDisable, True)

Using an XML File to Load Test Parameters to an ATEasy Program - Published on 4/16/2014

4/16/2014

This example reads a XML file and stores the new parameters in the program test objects. The parameters which will be updated by the XML file are grouped into a Test node and the specific test which will be updated is identified by an ID attribute. Each child node that is grouped within a Test node can be used to update a Test properties. For instance:

   3
   3.6
   3.3

This XML Test node, when used with the XMLTestParameters.drv, will update the the Test whose ID properties equals "PS1". It will update the Test's Min, Max and Tag properties with 3, 3.6, and 3.3 respectively.

Using the Example

The code to read the XML file and apply the parameters reside in the XMLTestParameters.drv driver. The XMLTestParameters driver utilizes the XML.drv, a general purpose XML file reader. This driver uses the functionality of Microsoft's System.Xml namespace, documentation here. Functionality includes the ability to create, open, read and write XML files. Additional methods and properties can be added by the user to expand the driver functionality.

To use the driver:
1. Insert the XMLTestParameters.drv to your system
2. Insert the XML.drv to your system
3. To load the parameters to your program use the following code:

if not XMLTESTS ReadTestParametersFile(GetDir(0)+"\\TestParameters.xml")
abort
endif

This code typically resides in Program.OnInit() event.

Example Code

The XMLTestParameters.drv export one command / procedure that is used to load the parameters:

--------------------------------------------------------------------------------
Procedure ReadTestParametersFile(sFile): Bool
--------------------------------------------------------------------------------
sFile: Val String
sProperty: String
sTest: String
s: String
enNodeType: Long
{
  ! open the test properties file
  try
    XML Reader Open(sFile)
  catch else
    MsgBox("Unable to open XML File: '"+sFile+"'")
    return False
  endtry

  !Iterate through the open XML file
  while (XML Reader Next())
    enNodeType=XML Reader Get NodeType()
    select enNodeType
    Case XmlNodeType.Element
      ! Keep track of the element that the user is on.
      s = XML Reader Get Name()
      if s="Test"
        !If the element is a new test, store the ID attribute
        sTest=XML Reader Get Attribute("ID")
      else
        !Store the name of the element as a property
        sProperty=s
      endif
    Case XmlNodeType.Text
      !If the node is text, it is a value that should be updated
      !use the Test ID and property name to decide where to assign the value
      select sProperty
      case "min"
        Program.Tests(sTest).Min=Val(XML Reader Get Value())
      case "max"
        Program.Tests(sTest).Max=Val(XML Reader Get Value())
      case "tag"
        Program.Tests(sTest).Tag=XML Reader Get Value()
      case else
        !More customization can be here
      endselect
    EndSelect
  EndWhile
  XML Reader Close()
  return True
}

Where to Go From Here

This example only allows you to update a Min/Max type tests properties. If the ability to update the properties of another test type were needed, the code within the sProperty case statement would need to be updated. To add the ability to set the ValuePlus and ValueMinus property of a Tolerance type test, the user would need to add a 'case "valueplus"' and a 'case "valueminus"'.

Download the Example and the XML drivers: Click Here

Using MATLAB from ATEasy - Published on 4/16/2014

4/16/2014

Installing MathWorks MATLAB® will also install an ActiveX control “Matlab Application Type Library” that can be used to write and retrieve variables from environments other than the MATLAB command window, such as ATEasy. An ATEasy driver (MATLAB.drv) has been created as a wrapper for this interoperability tool to perform the majority of the overhead of starting and communicating with the MATLAB utility. This allows you to reuse existing test application code in ATEasy projects with only a few lines of code.

Manipulating the MATLAB Command Window

Upon launching the ATEasy, the MATLAB driver will open a MATLAB command window that will open and run in the background until the termination of the ATEasy Application. If your project requires direct interaction with the command window, there are two ATEasy commands for command window manipulation:

MATLAB Window Maximize(): Maximizes command window and brings it to the front.
MATLAB Window Minimize(): Minimizes the command window.

Send Instructions to the MATLAB Command Window

Text-based instructions can be sent to the MATLAB window from ATEasy using the Execute command.

MATLAB Execute (sCommand, psResponse)

Where sCommand is the string sent to the MATLAB window and psResponse is MATLAB’s response.
For instance, the following code in MATLAB:

>> a=1

a =
1

>> b=3*a

b =
3

Can be executed in ATEasy with the following commands:

MATLAB Execute(“a=1”, sResponse1)
MATLAB Execute(“b=3*a”, sResponse2)

Example Code

The following code with pass the integers 3 and 5 to the ExpTwo function in ExpTwo.m and return back the value to the TestResult variable.

dwLength : DWord ! The length of the directory string name
sCommand : String ! The command that is sent to the command window
s : String ! The response from the command window

dwLength=GetShortPathNameA(GetDir(0), NULL, 0)
dwLength=GetShortPathNameA(GetDir(0), sCommand, dwLength) ! HPVEE requires short file names 8.3 use Windows API to retrieve it
sCommand="cd "+sCommand
MATLAB Execute(sCommand, s)
sCommand="result=ExpTwo(3,5)"
MATLAB Execute(sCommand, s)
MATLAB Get Variable("result", TestResult)

ATEasy Project and Example

ATEasy and MATLAB Example

Calling Agilent VEE UserFunctions from ATEasy - Published on 4/16/2014

4/16/2014

Installing Agilent VEE will allow the installation of an ActiveX automation server that can be used to run UserFunction from environments other than the VEE development environment, such as ATEasy and Visual Studio. An ATEasy driver (VEE.drv) has been created as a wrapper providing an interoperability tool that can perform the majority of the overhead associated with starting and communicating with the VEE Run-time. This allows you to reuse existing test application code in ATEasy projects with the addition of only a few lines of code.

Example VEE library

For example, we have “VEE_ATEasyExample.vee” which contains three UserFunctions:

AddTwo: Adds two numbers and outputs the sum (a+b=result)

ExpTwo: Outputs the first input raised to the power of the second input (a^b=result)

MultiplyTwo: Multiplies two numbers and outputs the product (a*b=result)

Image 1: VEE Project Navigator

Flow of data

To call a VEE function from ATEasy, you would implement the following prototype:

VEE Call (sLibFile, sUserFunction, inputs, outputs)

The sLibFile defines the .VEE file that contains the target UserFunction, sUserFunction specifies the VEE function that will be executed, and the inputs and outputs represent the input and output terminals as arrays of variants.

Image 2: Flow of data between ATEasy and VEE

Example Code

The following code will pass the integers 3 and 5 to the AddTwo function in the VEE_ATEasyExample.vee and should assign the value {8} back to the outputs variable.

sLibFile : String   ! Contains the path to the VEE file
sUserFunction : String   ! Contains the name of the VEE UserFunction
avrInputs : Variant[2]   ! The input parameters, where 2 is the number of parameters passed to the VEE function
vrOutputs : Variant      ! The returned output parameters array stored to a variant

sLibFile=GetDir(0)+"\\VEE_ATEasyExample.vee" ! vee in current directory
sUserFunction="AddTwo"   ! VEE function name
avrInputs={3,5}          ! input parameters
VEE Call(sLibFile, sUserFunction, aVarInputs, vrOutputs)
TestResult=vrOutputs[0]  ! store returned value

ATEasy Project and Example

ATEasy and VEE Example

Consume a web service in ATEasy - Published on 4/16/2014

4/16/2014

In this article, we will be consuming the CDYNE free weather service. We will be using the following resources:

Weather Service WIKI
Weather service Specification Sheet

Use WSDL.exe to generate the source code for the proxy class in one of the Visual Studio languages.

WSDL is a tool provided by Microsoft for the generation of Web Services proxy classes. The help file for the tool is located here.

The weather service specification sheet provides us with a listing of functions and parameters as well as the location of the WSDL formatted files. Type the following into your command prompt to generate the proxy class code in Visual Basic and save the output to "C:\Temp\myProxyClass.vb".

>WSDL /L:VB /O:C:\Temp\myProxyClass.vb HTTP://wsf.cdyne.com/WeatherWS/Weather.asmx?wsdl

Use Visual Studio to generate a .Net assembly from the source code.

Launch Visual Studio and create a class library project and import the code generated by WSDL.exe. User Project | Add Reference to add System.Web.Services to your project. Build the project and locate the compiled library.

Download Visual Basic project

Import the .NET library into ATEasy.

Create a new ATEasy application and a new driver. Rename the new driver to WeatherSvc. Import the .NET library into the new driver. For convenience, you can also move the DLL file into the ATEasy application directory.

Instantiate the proxy class with ATEasy.

Create a driver procedure GetWeather(). This procedure will allow us to retrieve the city, state and current temperature for the provided zip code.

Procedure GetWeather(zipcode, temperature, state, city): Void
--------------------------------------------------------------------------------
zipcode: Val BString
temperature: Var BString
state: Var BString
city: Var BString
WeatherReturn: WeatherProxyClass.WeatherReturn
weather: WeatherProxyClass.Weather
{
weather=new WeatherProxyClass.Weather()
WeatherReturn=weather.GetCityWeatherByZIP(zipcode)
city=WeatherReturn.City
state=WeatherReturn.State
temperature=WeatherReturn.Temperature
}

Create a command tree within your driver to link to this procedure. Attach this procedure to the "Driver Get Weather" command.

To test this, create a series of variables and tests in the program module.

weatherCity: BString
weatherState: BString
weatherTemperature: BString

Task 1 : "Perform Weather Operations"
--------------------------------------------------------------------------------
Id = Perform_Weather_Operations

Test 1.1 : "Request information"
--------------------------------------------------------------------------------
Id = Request_information
Type = Other
{
WeatherSvc Get Weather("92614", weatherTemperature, weatherState, weatherCity)
}

Test 1.2 : "Check City"
--------------------------------------------------------------------------------
Id = Check_City
Type = String
String = "Irvine"
{
TestResult=weatherCity
}

Test 1.3 : "Check State"
--------------------------------------------------------------------------------
Id = Check_State
Type = String
String = "CA"
{
TestResult=weatherState
}

Test 1.4 : "Check Temp"
--------------------------------------------------------------------------------
Id = Check_Temp
Unit = "Fahrenheit"
Type = MinMax
Min = 30
Max = 120
{
TestResult=Val(weatherTemperature)
}

Download ATEasy project

Capturing channels simultaneously with the GX2472 Digitizer - Published on 4/16/2014

4/16/2014

The GX2472 is a dual differential channel, 14-bit digitizer offering a 70 MS/s ADC and 512K of memory. Each of the GX2472's differential channels has its own amplifier, filters, ADC and capture memory allowing for simultaneous waveform capture.

The following procedure demonstrates how to achieve simultaneous digitization using psuedocode. For more details, there are example projects at the end of the article. For more information, refer to the Gx2472 User's Guide.

Procedure to Achieve Simultaneous Digitization

Setup channel parameters for each channel

Arm both channels for triggering

Wait for GX2472 to finish data capture

Read device memory

Breakdown of Procedure

Each channel saves its own parameters independently. The first step is to setup each channel's parameters. This is done by sequentially setting each channel to active, unlocking the channel to allow changes and configuring that channels parameters. In the psuedocode below, both channel's parameters will be identical.

For ChannelNumber = 1 to 2
    SetActiveChannel(ChannelNumber)
    UnlockChannel()
    SetClockSource(...)
    SetRange(...)
    SetTriggerLevel(...)
    SetDCOffset(...)
Next

After parameters have been set, lock the channels to initiate a capture. Each channel has it's own configurable trigger criteria. After a channel is locked, it awaits a trigger to begin data capture. Each channel has it's own trigger settings and can be connected to a different stimulus. Therefore, it is possible for one channel to trigger and begin capture while the other channel does not trigger and simply remains in the armed state. The psuedocode below demonstrates locking both channels to arm for triggering.

For ChannelNumber = 1 to 2
SetActiveChannel(ChannelNumber)
LockChannel() ! Locks access to the controller and allows channel to begin capture
Next

Now, the controller must wait for the channels to complete their data capture. This is done by repeatedly checking the status of the GX2472 to see if both channels have completed. A timeout condition should also exist in case one or both channels do not trigger and thereby never complete their data capture. The pseudocode demonstrates such a loop:

Repeat
GetTestStatus()
Until (TestComplete or TimeOut)

Finally, each channel must transfer its capture memory back to the controller. Again, we must loop through each channel, reading the memory back sequentially. The psuedocode below shows this:

For ChannelNumber = 1 to 2
    SetActiveChannel(ChannelNumber)
    UnlockChannel() ! Allows memory to be accessed by controller
    ReadADCResults(Array[ChannelNumber])
Next

Sample Projects and Examples

The sample projects below contain working code that sets both channels for capturing a 50,000 sample waveform:

ATEasy example can be downloaded here.

Microsoft Visual C++ 2005 example can be downloaded here.

Real-Time Digital IO Compare Example - Published on 4/16/2014

4/16/2014

In this tutorial, we will be running a PXI Digital IO GX5292 board in real-time compare mode through DIOEasy and examining some of its functionality.

Create the pattern we will use in DIOEasy as follows:

1. Open DIOEasy.

2. Create a new file with the following settings:

File Type: DIO (DIOEasy File Menu)
Board Type: GX5290 (DIOEasy File Properties - General tab)
Num. Of Boards: 1 (DIOEasy File Properties - General tab)
Num. Of Steps: 1024 (DIOEasy File Properties - General tab)
Operating Mode: Real Time Compare (DIOEasy File Properties - General tab)
Clock Delay (ns): 0.00 (DIOEasy File Properties - Setup tab)
Strobe Delay (ns): 0.00 (DIOEasy File Properties - Setup tab)

3. Set Channels 0 through 15 to output

Select Channel 0 through Channel 15
From the menu bar, select Fill -> Direction…
Click Output

4. Fill Channels 0 through 15 with a walking one pattern

While Channels 0 through 15 are still highlighted, select Fill -> Shift / Rotate…
In the dialog that pops up, change the Type from ‘Shift’ to ‘Rotate’
Click Overwrite!

5. Create the expected pattern for Channel 16 through 31

Select Channel 16 through 31.
From the menu bar, select Fill -> Shift / Rotate…
In the dialog that pops up, change the Type from ‘Shift’ to ‘Rotate’
Click Overwrite!

6. Add HALT command to the end of the pattern

Click on the last step of your pattern (step 1023)
Hit Alt+Enter to open the command properties window.
Change the command for this step from NOP to HALT

7. Insert error in Channel 0

Click Channel 0 to highlight the entire channel
From the menu bar, select Fill -> Value…
Select to fill the channel with all 0s and click Overwrite!

8. Save this file as “RTCError.dio”

The image above depicts the DIO file created. When executed, it will output a walking one pattern on J1 channels 0 through 15 while reading J1 channels 16 through 31 as input. Externally, the first sixteen channels will need to be wired to the second sixteen channels (channel 0 wired to channel 16, channel 1 wired to channel 17, and so on) to achieve a loopback. We are expecting to see the same walking one pattern on channels 16 through 31 as we output on channels 0 through 15. Since we want to observe some errors, we have intentionally set all steps in channel 0 to LOW. This will generate 64 errors (1 error every 16 steps).

Run the Pattern using GTDIO Panel:

1. Launch the GTDIO Panel from DIOEasy using the shortcut (F10).

2. Initialize the driver for the board.

3. Load and run the RTCError.dio pattern

Change the vector from 'File' to 'Window' and click 'Execute'
After the pattern is loaded to the DIO, click 'Arm!', then click 'Trig!'

4. View the resultant pattern.

Change the vector from 'Load' to 'Show' and click 'Execute'
In the dialog box that pops up, select the option 'Load into New Window'

A result pattern will be loaded into DIOEasy. Whenever discrepancies are found between the expected results and the actual results, the column containing the error will be shaded as shown below:

Masking / Unmasking:

If there is a channel or number of steps that you do not want to check for errors, the real time compare input mask can be used to enable/disable the compare engine.

1. Mask steps 0 through 15

Highlight steps 0 through 15.
From the menu bar, select Fill -> Real Time Compare Input Mask
Click Mask On

2. Run the Pattern using the GTDIO Panel

In the result pattern below, you can see that the error that was masked does not appear shaded because it was not analyzed.

Real Time Compare Error Logging Modes

When your DIO is operating in Real Time Compare mode, you can set stop conditions. In DIOEasy, hit CTRL+R or use the menu bar to open the File-> Properties dialog window. Click on the Real Time Compare tab. By default, it is set up to not stop for any special condition. By changing the 'Failures count:' to 10 and clicking Set, we indicate that the pattern should stop running if ten errors are encountered during execution. You can use this properties window to set the DIO to stop execution if a certain data value is encountered or when the program counter reaches a specified value.

How to Repeat a test multiple times - Published on 4/16/2014

4/16/2014

In ATEasy, there are many ways to display the results of tests. The following example demonstrates how to measure and display the results of similar measurements in a single test loop rather than several individual tests. For example, we already have a test that calls an instrument to make a measurement. We want to measure and display the results eight times.

To achieve this goal, we are going to create a test to make a measurement. After we take a measuremet we call the RepeatTest() procedure to repeat the test times as required. Finally, we will create a variable to track the number of iterations in a driver public variable m_nTestIteration (initialized to -1).

The test to repeat and make the measurements will be:

DMM Measure(TestResult)
RepeatTest(8) ! add this line at the end of every test that need to be repeated

The procedure to loop would be:

Procedure RepeatTest(nNumberOfIterations) : Void
nNumberOfIterations: Val Short
{
if m_nTestIteration=-1
m_nTestIteration=nNumberOfIterations! start count
endif

m_nTestIteration=m_nTestIteration-1

if m_nCurrentTest=0
return ! we are done
endif

Test EndEvents Test ! repeat this test
}

Create the module variable:

m_nTestIteration: Short = -1

The result shows that the test 1.1 ran 8 times, taking different measurements each time.

From the picture, we can see that the tests numbers were all identical: “001, no matter what iteration was it. Another problem is that if the last iteration of the test has a PASS status, the program status will show as PASS no matter if one of the test iteration failed. We can add code to include the test iteration in the test number by revising the RepeatTest procedure:

Procedure RepeatTest(nNumberOfIterations) : Void
nNumberOfIterations: Val Short
s: String
i: Short
{
if m_nTestIteration=-1
     m_nTestIteration=nNumberOfIterations! start count
endif

m_nTestIteration=m_nTestIteration-1

! display test number - test iteration to the log
s=GetLogString(aLogStringCalcTestStatus)
i=pos(Format(test.Index+1, "000"), s)
SetLogString(Left(s, i)+Format(test.Index+1,"000") + "." + str(nNumberOfIterations-m_nTestIteration) + mid(s, i+len(Format(test.Index+1, "000"))))

! if one test failed fail the program
if TestStatus=FAIL
    program.Status=FAIL
endif

if m_nTestIteration=0
    return    ! we are done
endif

Test EndEvents Test ! repeat this test
}

The ATEasy driver which contains the RepeatTest procedure can be downloaded here.

How to print a HTML or TEXT file from within an ATEasy application - Published on 4/16/2014

4/16/2014

One method of printing a HTML file from within an ATEasy application is to use the ALog control. This can be done as follows:

1. Create a form and uncheck the form Visible property.
2. Place an ALog control in the form and set it's PlainText property to False for HTML or True for text file printing.
3. Create a public procedure with one parameter that contains the location and name of the HTML file to be printed.
4. The procedure should load the form in Modeless mode, set the logPrint.LocationURL to the HTML file location, call logPrint.PrintLog and then return.

The example that accompanies this KB article is called Q200180.zip. In the example the form used to print the HTML file is called PrintHTMLForm. The public procedure used to call the form and print the file is called PrintHTML(). The same code can be used to print TEXT (log) files. The procedure code is as follows:

PrintHTML(sFile)
  {
! Declare a PrintHTMLForm form variable called frmPrintHTML

Load frmPrintHTML, False, 0  !Load the PrintHTML form
DoEvents()   !Process all pending operations
frmPrintHTML.logPrint.LocationURL=sFile  !Set the URL of the file to be printed

!Wait for the file to be loaded
while frmPrintHTML.logPrint.ReadyState <> alogReadyStateComplete
  DoEvents()
endwhile

frmPrintHTML.logPrint.PrintLog()  !Print the file
Unload frmPrintHTML
frmPrintHTML= Nothing
  }

For more information about how to select a printer for printing refer to Q000090

How to create a "system modal" form similar to ATEasy 2.x dialogs - Published on 4/16/2014

4/16/2014

Solution:

The System modal dialog style (DS_SYSMODAL) was dropped as it is no longer supported in Win32. According to MSDN documentation:

This style is obsolete and is included for compatibility with 16-bit versions of Windows. If you specify this style, the system creates the dialog box with the WS_EX_TOPMOST style. This style does not prevent the user from accessing other windows on the desktop. Do not combine this style with the DS_CONTROL style.

You can still make a window top-most by using the following USER32.DLL function, in the Form OnLoad event:

SetWindowPos(Form.hWnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOSIZE or SWP_NOMOVE)

Where the parameters are prototype as follows:

DLL User32
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
File = User32.dll

DLL Types
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

DLL Procedures
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Procedure SetWindowPos(hwnd, hwndInsertAfter, x, y, cx, cy, uFlags): Bool
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

hwnd: Val AHandle
hwndInsertAfter: Val AHandle
x: Val Long
y: Val Long
cx: Val Long
cy: Val Long
uFlags: Val DWord

DLL Constants
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
HWND_TOPMOST: AHandle Const = -1
SWP_NOSIZE: Long Const = 1
SWP_NOMOVE: Long Const = 2
SWP_NOZORDER: Long Const = 4

Sample files are available: Q200054.zip

Regenerating Program Tasks and Tests IDs - Published on 4/16/2014

4/16/2014

Solution:

ATEasy will try to leave the Test or Task IDs intact after renaming them. The reason is that an external file or code may reference the ID; changing the ID name will break the code.

If you don't have any external reference to the Task or Test IDs, and you would like to generate IDs that are similar to the Task/Test name, you can use the attached utility.

To use the utility, open the link below to access the ATEasy utility files (ProgramIds.prj, ProgramIds.sys and ProgramIds.drv) and copy the files to a folder. Open the project file (ProgramIds.prj) in ATEasy and from the Run menu select Start.

Select the program source file that you wish to convert (language.pgt in this example) and type a new program name that will contain the new program with the new Ids (language-new.pgt). Click on the Convert button.

Files for this Article: Q200053.zip

Using ATEasy and DSI Software to Run and Analyze Test Programs - Published on 1/13/2014

1/13/2014

ATEasy Test programs can be converted to an ATML Test Descriptions file. The eXpress environment imports the ATML Test Descriptions file and enables the user to perform their System Diagnostics, Prognostics Health Management and Testability evaluations and use any other features which are made available through eXpress. At the conclusion of the diagnostics creation, eXpress generates DiagML files which are utilized by the eXpress Run-Time Authoring Tool which can enable us to analyze faults through DSI Workbench by monitoring a ATML Test Results file or through the ATEasy Fault Analysis tool by creating a Conditions file which can be used with the embedded ATEasy Test Executive.

Interoperable data formats in ATEasy and DSI software

DSI eXpress and ATEasy Integration (Part I)

The video demonstrates the interaction where DSI Workbench monitors first a passing Test Results file and then a failing Test Results file. The failures are generated using hardware on the MTS TS-710 test system and a custom UUT that has been modeled in eXpress to take advantage of the ability to highlight components on a real image of the UUT.
http://www.youtube.com/watch?v=XBn1VMO2oBI
Link to video

DSI eXpress and ATEasy Integration (Part 2)

The video demonstrates the interaction where the eXpress Run-Time Authoring Tool generates a conditions file which is used natively by the ATEasy Test Executive. The Diagnostic Study in eXpress is examined to describe how a constellation of passing and failing test results allows the software to fault a specific component and creates a DiagML file. Then the eXpress Run-Time Authoring Tool is used to generate the conditions file. Within the ATEasy Test Executive, the previously created file is opened and used to analyze the test results and fault a component based on the study created in eXpress.
http://www.youtube.com/watch?v=t0iv78TW78I
Link to video

More Information on the Software

ATEasy - A test executive and rapid application development framework for ATE.

eXpress - Software diagnostic engineering tools that encompass diagnostics, testability, prognostics and systems engineering.

eXpress Run-Time Authoring Tool - Takes eXpress diagnostic design data and integration and deployment of Systems Diagnostic and Prognostic designs within real-world troubleshooting environments such DSI Workbench and ATEasy.

DSI Workbench - Allows for publication of diagnostics within production and maintenance troubleshooting environments. Will facilitate the integration of diagnostic design views, engineering views, photos and videos within an integrated environment.

White Paper: The MTS-3060 SmartCan - The Next Generation in Armament Test Solutions - Published on 1/2/2014

1/2/2014

This paper provides an overview of the MTS-3060 SmartCan™ which offers next generation, O-level test capabilities for alternate mission equipment (AME) and other aircraft systems. Delivering new and advanced flightline test capabilities, it supports the testing of suspension and AME systems including pylons, launchers, bomb racks, and pods. The MTS-3060 SmartCan™ is a high-performance hand-held device with the shape of a "beercan", and provides advanced test capabilities that are unavailable in other O-level test products. Unlike any other beercan testers, the MTS-3060 provides measurement, loading and stimuli functions that are typically only associated with large O-level testers, such as the SERD-75501. With multiple measurement and load channels, dedicated and continuous squib circuit monitoring, audio and video simulation, and MIL-STD-1760 support, the MTS-3060 SmartCan™ can support a range of aircraft platforms including the F-15, F-16, TA-50, F-5, and F-22 as well as any "smart" or legacy armament system.

To learn more about the MTS-3060 SmartCan, click here.

White Paper: Commercial Off the Shelf (COTS) Based, Flightline Test Solutions - Published on 11/22/2013

11/22/2013

The flight-line test sets discussed in this paper are all based on a common core PXI (Compact PCI Extensions for Instrumentation). The platform includes a 14-slot PXI backplane. PXI is a modular card, rugged standard which can be used to achieve reliable performance under harsh operating conditions. Industry
standard PXI includes two form factors: 3U and 6U. While 3U is the more popular of the two and most PXI instrumentation is available in this form factor, many products including high-density switching and high performance digital are only available in the 6U form factor. Additionally, the PXI standard maintains full interoperability between 6U and 3U, allowing any 3U PXI module to be installed into any 6U PXI slot. For these reasons, the PXI core platform employed by these test sets offers both 6U and 3U PXI slots. Since 2004, PXI-based flight-line test solutions have been supporting a wide range of aircraft including the F-16, F-15, TA-50, FA-50, A-10, and MC-130.

To learn more about COTS Based, Flightline Test Solutions, click here.

White Paper: Integration of Software Technologies into a Test System - Published on 6/20/2013

6/20/2013

ATE systems can require the incorporation of a range of software tools and components. This presentation provides an overview of these different software tools and how ATEasy can be used to simplify the process of incorporating various application development environments as well as 3rd party software applications such Excel, XML and databases.

Download the presentation

White Paper: Addressing Semiconductor Test with PXI - Published on 6/17/2013

6/17/2013

Recent advancements in PXI (Compact PCI Extensions for Instrumentation) digital, analog and RF test products and systems now makes it possible for test engineers to address a range of ATE device test needs with the PXI platform. In particular, PXI digital products that offer tester per-pin features including a parametric measurement unit (PMU) per-pin architecture as well as PXI test systems that incorporate these features are now offering ATE semiconductor test capabilities with high value and performance. In addition, these PXI test systems, such as Marvin Test Solutions' TS-900 are providing test engineers cost-effective ATE that can be used for failure analysis, prototype device verification, and pilot / early production runs – allowing the “big iron” ATE to be focused on the volume production test applications while providing engineering test groups ATE features in a compact and configurable platform.

Download the white paper

Using ICEasy's Shmoo Plot Tool with ATEasy - Published on 6/11/2013

6/11/2013

Shmoo plots can be useful for graphically representing test results obtained when characterizing a part using two test variables.

When testing a device, one may want to know how a device will operate over a range of test parameters such as supply voltage and clock frequency. By varying the parameters while performing a functional test on the device, it is possible to characterize the device for a range of operating conditions. By plotting the test parameters and indicating a pass / fail condition in green or red for each test condition, the resulting two dimensional plot will graphically show the area over which the device operates or fails.

ATEasy v9 supports two dimensional Shmoo plotting using the AChart control within a Form. The Shmoo plot capability is used extensively with the TS-900 Semiconductor Test System for characterizing a device for a given range of operating conditions.

The following figure is an example of a Shmoo plot generated in ATEasy that represents the test results based on a sweep of the VCC and operating frequencies for a digital part:

In order to use the Shmoo Plot within a form, follow these steps:

1. Create a Form within ATEasy

2. Select the AChart control and draw the chart on to the Form

3. Right click on the newly placed AChart control, and select Properties.

4. Select the "Control" tab and select "Shmoo" from the "Style" combo box.

The Shmoo plot is one of several styles that can be selected for an AChart Control.

5. Select the "Ticks" tab and configure the Major and Minor intervals for the X and Y axis.

The minor interval sets the resolution of the axis.

6. Select the "Axes" tab and configure the X and Y axis names and scales (min/max)

The "Axes" tab contains the minimum and maximum value for each of the axis. Each axis represents a variable that is being sweeped. The axis range (min/max) in conjunction with the Minor tick interval, determines the number of steps for a given axis. In this example, the X-axis (Frequency) has a range of 1-26 Mhz with a minor interval of 1 resulting in 26 steps for the sweep across the X-axis

7. Call the SetData member of the AChart control to set the measurement and Pass/Fail results for the Shmoo Plot.

Shmoo data is represented by an X axis value, a Y axis value, and the corresponding Test Result Boolean value. In this example, the X axis represents VCC and the Y axis represents the Frequency.

Each cell of data can be entered, one at a time, using the following call (the chart control is called "cht1" in this example):
cht1.SetData(0, dVcc, dFrequency,,,False, bTestResult)

bTestResult contains the Pass/Fail result of a functional test that was run with a particular value of VCC and VOH.

Note: This article uses a pre-release version of ATEasy 9.

White Paper: Where’s The Beer? A Paradigm Shift in Flight-Line Armament Testing - Published on 12/12/2012

12/12/2012

Abstract

Prior to loading live weapons on an aircraft, maintainers are required to verify that no stray voltage is present and that the firing signals are functioning properly. In the Air Force world, this is done with a small, battery-operated tester called an Armament Circuits Pre-Load Test Set (ACPTS), commonly referred to as a “beercan” due to its shape and size. The typical beercan is a rudimentary test set with few capabilities and limited performance. The beercan’s function is to verify that there is no stray voltage on the critical firing lines (squibs), and to verify the presence of firing signals including magnitude and timing during a valid launch procedure. The typical beercan only has one or two measurement channels, necessitating the manual switching of various adapters to enable testing of multiple signals. The typical beercans also lack the ability to emulate weapon signals, precluding any effective “smart” weapons testing by beercans.

A new breed of beercans has been recently introduced to address this deficiency by improving the test capabilities of the beercan, thus eliminating the flight-line testers and simplifying the maintenance logistics while increasing performance and reducing test and maintenance time. This paper discusses the requirements of flight-line armament testers and introduces a universal beercan - the SmartCan which offers capabilities previously unavailable for the flight-line.

Download white paper

White Paper: Incorporating Advanced Instrumentation Capabilities into a PXI DMM - Published on 12/12/2012

12/12/2012

Abstract

The use of card modular instrumentation for ATE systems offers test engineers many benefits - including lower acquisition costs, a more compact system footprint, and higher performance when compared to "box based" ATE architecture. In particular, upgrading to the PXI architecture can decrease both the physical and budgetary footprints, while still meeting the overall test requirements. However, for T&M instrument suppliers, incorporating the features and capabilities associated with advanced instrumentation into the PXI form-factor can present several design challenges, particularly in the areas of volume / real estate, noise, power consumption, and measurement stability. Additionally, these demanding requirements can be further challenged when the instrument is required to operate beyond the "normal" temperature range associated with commercial instrumentation.

This paper discusses the requirements and techniques used to develop a PXI-based, high performance DMM. A review of the required performance parameters is presented along with an analysis of the alternative design methods employed in order to achieve the necessary performance capabilities without compromising the overall capabilities of the hardware. Areas covered in this paper include a discussion of design techniques which includes the use of multi-function circuitry to reduce overall volume requirements, the conversion of purely analog circuitry into a mixed signal format to reduce volume and power requirements, minimizing power supply noise when replacing a mains-based power supply with isolated and non-isolated DC/DC circuitry and the requirement to operate over an extended temperature range. Additionally, a review of the overall mechanical design with attention to the need to accommodate the noise and airflow considerations associated with the PXI architecture is discussed.

Download the white paper

Using the DAQ Function of the GX2065 - Published on 7/23/2012

7/23/2012

The GX2065 is a 3U DMM and DAQ. The DAQ is capable of capturing up to 8192 Voltage or Current measurements to memory.

The DAQ function uses a 3Mhz sampling clock and a clock divider with a maximum value of 255, allowing a range of sampling frequencies (3Mhz to 11.76Khz).

Follow these steps to capture samples using the DAQ:

1. Set desired function by calling GxDmmSetFunction, and passing in VAC_AC, VAC_DC, IAC_AC, or IAC_DC (Voltage or Current). The function must be one of four "AC" functions in order to use the DAQ.

2. Set desired range by calling GxDmmSetRange

3. Call GxDmmSetACClockDivider and pass in the clock divider value (1 to 256).

4. Call GxDmmSetTriggerMode and pass in GXDMM_TRIGGER_ARRAY along with the number of samples you would like to capture (1 to 8192). This will initiate the capture process

5. Monitor the status of the capture by calling GxDmmGetReadArrayStatus. This function will return the finished state of the capture and the number of samples currently captured.

6. When the capture process has completed, call GxDmmReadArray to retrieve the samples. The function will return an array of samples as well as an array of time stamps. Each sample is accompanied by a time stamp in nano seconds.

The following is C example code to capture 1000 samples of voltage at a sampling rate of 1.5Mhz:

SHORT nHandle, nStatus;

//Measurement array
DOUBLE adMeasurements[1000];

//64 Bit Time Stamps
DDWORD addwTimeStamps[1000];

BOOL bFinished=FALSE;

//Initialize DMM
GxDmmInitialize(nSlot, &nHandle, &nStatus);

//Set Function to AC, AC coupled for DAQ functionality
GxDmmSetFunction(nHandle, GXDMM_FUNCTION_VAC_AC_CPL, &nStatus);

//Set Range to 10 Volts
GxDmmSetRange(nHandle, GXDMM_RANGE_10V, &nStatus);

//Divide DAQ 3Mhz clock by 2 to get 1.5Mhz sampling clock
GxDmmSetACClockDivider(nHandle, 2, &nStatus);

//Start capture of 1000 samples
GxDmmSetTriggerMode(nHandle, GXDMM_TRIGGER_ARRAY, 1000, &nStatus);

//Wait until capture complete
while(!bFinished)
GxDmmGetReadArrayStatus(nHandle, &bFinished, &dwSampleCount, &nStatus);

//Read back measurements and timestamps
GxDmmReadArray(nHandle, adMeasurements, addwTimeStamps, 1000, &nStatus);

PMU Functionality with the GX5960 Series - Published on 5/7/2012

5/7/2012

The Gx5960 Series of Digital I/O devices include the ability to configure each of its I/O channels to operate in either dynamic or PMU mode. This article focuses on the PMU mode.

Each digital channel includes a parametric measurement unit (PMU) which can be used to characterize and measure a digital pin’s DC characteristics. The PMU can be configured for force current, measure voltage, or force voltage, measure current. The PMU’s range of operation is listed below:

Force voltage range: -10 volts to +15 volts (plus vMid Voltage)

Force current range: +/- 25 mA FS or +/- 200 mA

Measure voltage range: -10 volts to +15 volts (plus vMid Voltage)

Measure current range: +/- 25 mA FS or +/- 200 mA

API Functions

The following are the API calls required to set up the instrument for PMU operation:

VOID WINAPI GtDio6xSetChannelMode(SHORT nHandle, LONG lChannelListArraySize, PLONG palChannelListArray, SHORT nMode, PSHORT pnStatus);

VOID WINAPI GtDio6xSetChannelForcedVoltage(SHORT nHandle, LONG lChannelListArraySize, PLONG palChannelListArray, DOUBLE dVoltage, SHORT nCurrentRange, DWORD dwSetupMode, DOUBLE dMaxCurrent, PSHORT pnStatus);

VOID WINAPI GtDio6xSetChannelForcedCurrentCommutatingVoltage(SHORT nHandle, LONG lChannelListArraySize, PLONG palChannelListArray, DOUBLE dVComHi, DOUBLE dVComLo, PSHORT pnStatus);

Note that the voltage clamps only apply for forced current operation up to 24mA. If this current is exceeded, the voltage clamps are no longer effective.

Example Code

The following C code performs the following:
1. Set Channel 0 Mode to PMU Force Current
2. Set Channel 0 PMU Force Current Voltage clamps to +5V and -5V
3. Set Channel 0 to Force 10mA in 25mA range
4. Measure the output current
5. Set Channel 0 Mode to PMU Force Voltage
6. Set Channel 0 to Force 12V with the current range set to 25mA
7. Measure the output voltage

//Use channel 0
alChannelListArray[0]=0; //Use channel 0
GtDio6xInitialize(1, &nHandle, &nStatus);
GtDio6xSetChannelConnect(nHandle, 1, alChannelListArray, TRUE, &nStatus);
//Set Channel Mode to PMU Force Current
GtDio6xSetChannelMode(nHandle, 1, alChannelListArray, GTDIO6X_CHANNEL_MODE_PMU_FORCE_CURRENT, &nStatus);
//Set Clamping voltages to +5V and -5V
GtDio6xSetChannelForcedCurrentCommutatingVoltage(nHandle, 1, alChannelListArray, 5, -5, &nStatus);
//Force 10 mA in 25mA range
GtDio6xSetChannelForcedCurrent(nHandle, 1, alChannelListArray, 10, GTDIO6X_PMU_CURRENT_RANGE_N25MA_TO_P25MA, &nStatus);
//Measure the current output
GtDio6xMeasure(nHandle, 0, GTDIO6X_MEASURE_OUTPUT_CURRENT, &dMeasurement, 1, 0, 0, &nStatus);

//Set Channel Mode to PMU Force Voltage
GtDio6xSetChannelMode(nHandle, 1, alChannelListArray, GTDIO6X_CHANNEL_MODE_PMU_FORCE_VOLTAGE, &nStatus);
//Force 12 Volts
GtDio6xSetChannelForcedVoltage(nHandle, 1, alChannelListArray, 12.0, GTDIO6X_PMU_CURRENT_RANGE_N25MA_TO_P25MA, GTDIO6X_PMU_FV_SETUP_DEFAULT, 20, &nStatus);
//Measure the voltage output
GtDio6xMeasure(nHandle, 0, GTDIO6X_MEASURE_IO_VOLTAGE, &dMeasurement, 1, 0, 0, &nStatus);

More information on the GX5960 series can be found on the Geotest website.

Look at the following articles for more information about PMU and related applications: PMU White Paper , Semiconductor Testing with GX5295 PMU

White Paper: Next Generation Test System Architectures for Depot and O-Level Test - Published on 3/1/2012

3/1/2012

Abstract:
For over 30 years, ATE has been a key resource and tool for the maintenance and repair of electronic systems, subsystems and board level assemblies deployed on a wide range of military-aerospace systems. ATE has been relied upon to maintain and support electronic assemblies for avionics, weapons systems, and communication systems. In addition, repair logistics and the “up-time” demands for these systems have resulted in the need for repair / support strategies that shorten the repair loop. For the US Marine Corp, the need to minimize this repair loop is acute and has resulted in the adoption of a maintenance / repair strategy that employs Depot – level test capabilities which can also be deployed at the field or O-level.

This paper discusses how a PXI-based architecture which employs the GX5960 subsystem can provide the basis for replacing a Teradyne VXI M9 digital test solution. The successful development and implementation of software tool set for migrating M9 or LASAR-based test programs is also presented. The resulting solution offers a downsized test platform that supports legacy test programs while offering portability and performance at a significantly lower cost for both Depot and O-level test needs.

Download the complete white paper

Using Interrupts with the GX3500 and GX3700/GX3700e FPGA Instruments - Published on 8/12/2011

8/12/2011

Interrupts are widely used as a means for hardware to handshake and syncronize with software in order to signal the completion of a hardware process or the need for a change in software execution. The Gx3500 and Gx3700 User FPGA boards both support this feature by exposing a dedicated hardware interrupt pin to the FPGA designer, and three API functions in software for interrupt management and set up.

Before getting started with Interrupts follow these steps:

Verify that the GX3500 has the lastest firmware. The Interface FPGA, which contains the core firmware for the device, must be upgraded to version B003 or greater. This can be done by initializing the GX3500 from within the software front panel, clickong on the About Tab, clicking on Upgrade Firmware, and then browsing to the appropriate firmware file (.RPD file extension).

Verify that the latest GXFPGA software package has been installed (Version 1.2 or greater).

Software

The user can select to handle a hardware interrupt in one of two ways:

Assign a callback function to be invoked (in a new threadd) whenever an interrupt occurs (GxFpgaSetEvent)

Block (Wait) until an interrupt occurs or timeout (GxFpgaWaitOnEvent)

The software API functions that interface with the hardware generated interrupt are:

GxFpgaSetEvent

GxFpgaSetEvent(SHORT nHandle, SHORT nEventType, BOOL bEnable, Gt_EventCallback procCallback, PVOID pvUserData, PSHORT pnStatus)

This function is used to enable the capture of interrupt events and set up the callback interrupt handler.
nEventType: The type of event to capture. Currently this value must be set to GT_EVENT_INTERRUPT
bEnable: A boolean flag to enable or disable interrupt generation
procCallBack: A call back function (function pointer) can be passed to the procCallback parameter
pvUserData: A pointer to user data (scalar or structured data) that will be passed to the callback function when an interrupt occurs

Note: The callback function (passed into procCallback) must match the following prototype where GxFpgaCallBack can be any name:

GxFpgaCallBack(SHORT nHandle, SHORT nEventType, PVOID pvUserData)

GxFpgaWaitOnEvent

GxFpgaWaitOnEvent(SHORT nHandle, SHORT nEventType, LONG lTimeout, PSHORT pnStatus)

This function blocks program execution and waits for an interrupt to occur.
nEventType: The type of event to capture. Currently this value must be set to GT_EVENT_INTERRUPT
lTimeout: A timeout value (in terms of mS) to determine how long to wait for an interrupt before continuing the program

GxFpgaDiscardEvents

GxFpgaDiscardEvents(SHORT nHandle, SHORT nEventType, PSHORT pnStatus)

This function discards all pending interrupt requests.
nEventType: The type of event to capture. Currently this value must be set to GT_EVENT_INTERRUPT

Hardware

When creating an FPGA design, use the IRQ pin (as assigned in the pin planner) to generate a hardware interrupt. An interrupt is generated when the IRQ pin is driven from a logic low to a logic high state (Rising Edge).

Example

The GXFPGA driver contains an example that shows how to program the card interrupt. See the The GxFpgaExampleC.cpp and the GxFpgaExampleIRQx250ms.rpd in the Examples\C folder. In the example an interrupt is generated every 250 mSec.

Using the Gx5960 Pattern Test Flags to Qualify real time compare errors - Published on 6/7/2011

6/7/2011

The Gx5960 series DIO boards are able to perform real time conditonal branching/halting and recording when a compare error has been detected from a particular data pattern. Each data pattern contains two flags to help qualify any errors generated. The qualification (by way of Pattern Test Flags) allows the sequencer to determine if a particular pattern's error can cause a branch/halt and if it will be recorded in the EAM (Error Address Memory) or not.

Pattern Test Flags

Conditional Error Enable Flag: Each data pattern contains a Conditional Enable (CONDEN) flag that is used by the Conditional Logic to determine if a real time compare result generated by a particular data pattern will be used within a conditional error statement.
A list of conditional error statements are:

Halting on error (or NOT error)

Jumping on error (or NOT error)

Go subroutine on error (or NOT error)

Looping on error (or NOT error)

Burst Error Enable Flag: Each data pattern also contains a Burst Error Enable (BERREN) flag that is used by the Error Address Memory to determine if an error generated by a particular data pattern will be recorded or not.

Note that the Error Address Memory stores up to 1024 real time compare error addresses. The Burst Error Enable flag does not have any effect on the Record Memory.

Either flag (CONDEN, or BERREN) can be set, or no flags set at all on a per data pattern basis.

The API function used to configure the pattern test is as follows:

VOID WINAPI GtDio6xSetPatternTestEnable (SHORT nHandle, LONG lPatternOffset, SHORT nEnable, PSHORT pnStatus)

After selecting the sequence step using the GtDio6xSelectSequenceStep function, this function can be called to apply a pattern test flag to a particular data pattern.

The possible values of nEnable are as follows:

GTDIO6X_STE_NONE - No Flags are enabled for the data pattern

GTDIO6X_STE_COND - Only the CONDEN flag is enabled for the data pattern

GTDIO6X_STE_BURST - Only the BERREN flag is enabled for the data pattern

GTDIO6X_STE_BOTH - Both, CONDEN and BERREN flags are enabled for the data pattern

Sequencer Basis Settings

The sequencer uses the following three settings to determine if the Pattern Test Flags (CONDEN and BERREN) will be used or not:

Error Count Basis - Selection of the signal used for counting real time compare errors by the EAM

Local - Unqualified (all), locally generated real time compare errors will be used in the EAM Error Count

Local BERREN - Only qualified (with the BERREN flag enabled) locally generated real time compare errors will be used in the EAM Error Count

Domain - Unqualified (all), domain wide real time compare errors will be used in the EAM Error Count

Domain BERREN - Only qualified (with the BERREN flag enabled) domain wide real time compare errors will be used in the EAM Error Count

Error Address Basis - Selection of the signal used to generate a real time compare error pattern/sequence address for use by the EAM

Local - Unqualified (all), locally generated real time compare errors will be recorded in the EAM

Local BERREN - Only qualified (with the BERREN flag enabled) locally generated real time compare errors will be recorded in the EAM

Domain - Unqualified (all), domain wide real time compare errors will be recorded in the EAM

Domain BERREN - Only qualified (with the BERREN flag enabled) domain wide real time compare errors will be recorded in the EAM

Pass/Fail Basis - Selection of the signal used by the Conditional Logic to perform an action on a rela time compare error.

Local - Unqualified (all), locally generated real time compare errors will be used by the Conditional Logic

Local CONDEN - Only qualified (with the CONDEN flag enabled) locally generated real time compare errors will be used by the Conditional Logic

Domain - Unqualified (all), domain wide real time compare errors will be used by the Conditional Logic

Domain CONDEN - Only qualified (with the CONDEN flag enabled) domain wide real time compare errors will be used by the Conditional Logic

The API Function used to configure the Error Count Basis and Error Address Basis is as follows:

VOID WINAPI GtDio6xSetErrorParameters (SHORT nHandle, SHORT nErrorCountBasis, SHORT nErrorAddressBasis, PSHORT pnStatus)

The API Function used to configure the Pass/Fail Basis is as follows:

VOID WINAPI GtDio6xSetPassFailParameters (SHORT nHandle, SHORT nPassFailBasis, SHORT nPassValidMode, PSHORT pnStatus)

Consult the Function Reference for more information on these functions.

The following diagram explains the concepts described above:

Using GX5295 Level Comparators for Fast Go/NoGo Production Tests - Published on 5/13/2011

5/13/2011

Introduction
In the semiconductor production test world, the maxim “Throughput is King” is as true today as when the term was coined decades ago.  The underlying assumption is that the test “adequately” evaluates the operation and functionality of the UUT.  Special emphasis is given to the word "Adequate" because the typical practice is to perform a robust, comprehensive functional test and characterization for design verification, and then perform a subset of those tests on the production line.  Once a design has been verified, it is usually not necessary to functionally test every aspect of each device, or fully characterize the AC and/or DC parameters of each device during the production test cycle.  An adequate subset of the functional and parametric tests are selected such that, if the UUT passes these tests, you have high confidence that the component will function correctly in its intended application.

Limit Testing
By limiting the number and scope of the tests performed, test time can be significantly reduced.  And, as “time is money”, reducing test time can save money, improve production yields, and directly impact the profitability of a device in the market.  But limiting the number and scope of tests performed during production is not the only way to reduce test time.  Limit testing can also be an effective time saver that will improve yield without sacrificing quality.  Limit testing is the practice of testing only to a minimum or maximum value to validate device parameters.  For example, if a device is specified to provide a minimum 2.5V output under a specified load, it is not necessary to test the device to 2.6V.  Nor is it necessary to actually measure the output voltage.  So long as the device meets the minimum output threshold (or limit), it is considered within specification.

Testing to a specific limit or threshold, rather than measuring an actual value, can improve test time by utilizing comparators for the limit test, rather than making a measurement.  The output of a comparator provides an instantaneous pass/fail indication of whether the parameter meets the minimum (or maximum) allowable value for the parameter being measured.  A measurement is not only slower than using a comparator, but requires that the measured value be evaluated against the pass/fail criteria.  Typically this evaluation is performed in software, which is slower than a hardware comparison.

GX5295 Limit Testing
The GX5295, from Geotest - Marvin Test Systems, Inc., supports both methodologies.  It has a full-function Parametric Measurement Unit (PMU) per pin, capable of forcing voltage or current, and measuring current or voltage, respectively.  It also provides a dual-threshold comparator for each pin with minimum and maximum thresholds that can be used to validate whether or not a DC parameter meets an acceptable limit.  By providing a dual-threshold comparator per pin, the GX5295 can be programmed with a unique minimum AND maximum limit for EACH pin, and then simply select for each pin which comparator output to use for a limit test.  The output of the comparator is binary, “0” or “1”, “pass” or “fail”, “good” or “bad”.  No measurement is performed, no evaluation of the measured value is needed.  Compliance for the parameter is known immediately.  Further, comparators can run at the maximum rate of the GX5295 and has minimal impact on throughput.

A block diagram for one GX5295 channel input is shown below.  Each channel can be independently configured to operate in Digital I/O mode (DIO) or Parametric Measurement Unit mode (PMU).  The DIO mode is useful for performing standard digital functional test; supporting both Digital Stimulus/Response and Digital Real-Time compare.  The PMU mode is useful for making DC measurements or validating DC limits.

In PMU mode, the GX5295 can force a voltage or a current on each channel, and then measure the respective current or voltage. The measured property can also be passed to the PMU comparators to be used in limit testing. Since each channel has fully independent control over the high and low limit values for it's comparator, as well as the force property and value, a complete DC validation of all input pin thresholds and output pin levels can be performed in a single measurement cycle. For bidirectional channels, two cycles would be required. Features and specifications for the GX5295 PMU are provided in the Table below:

Parametric Measurement Unit (PMU) Specifications:


Number of PMUs	32, one per data channel
	4, one per auxiliar channel (for timing / control functions)
Modes:	Force voltage, measure current
	Forcecurrent, measure voltage
Force Voltage Range:	-1 volts to +6 volts
Force Accuracy:	+/- 25 mV
Force Voltage Resolution:	16 bits
Force Current Range:	+/- 32 mA FS, +/- 8 mA, +/- 2 mA, +/- 512 uA, +/- 128 uA, +/- 32 uA, +/- 8 uA, +/- 2 uA FS
Force / Measure Current Accuracy:	+/ 160 uA, 32 mA range
	+/- 40 uA, 8 mA range
	+/- 10 uA , 2 mA range
	+/- 2.56 uA, 512 uA range
	+/- 640 nA, 128 uA range
	+/- 160 nA 32 uA range
	+/- 40 nA, 8 uA range
	+/- 10 nA, 2 uA range
Measure Voltage Range:	-2 volts to +7 volts
Measure Voltage Accuracy:	+/- 5 mV
High & Low Voltage Clamps:	VCLo: -2 to +5 V
	VCHi: 0 to +7 V
Voltage Clamp Accuracy:	+/- 100 mV

The DLL API functions for utilizing the GX5295 PMU functions are:

DioGetChannelMode()
DioGetInputLoadCurrent()
DioGetInputLoadCommutatingVoltage()
DioGetInputLoadState()
DioMeasure()
DioPmuGetComparatorsSource()
DioPmuGetComparatorsStates()
DioPmuGetComparatorsValues()
DioPmuGetComparisonBooleanResult()
DioPmuGetComparisonResults()
DioPmuGetForcedCurrent()
DioPmuGetForcedCurrentCommutatingVoltage()
DioPmuGetForcedVoltage()
DioPmuSetupComparatorsSource()
DioPmuSetupComparatorsValues()
DioPmuSetupForcedCurrent()
DioPmuSetupForcedCurrentCommutatingVoltage()
DioPmuSetupForcedVoltage()
DioSetupChannelMode()
DioSetupInputLoadCurrent()
DioSetupInputLoadCommutatingVoltage()
DioSetupInputLoadState()

Example
A example test setup and code for validating the output drive levels of a UUT are provided below. The UUT is a 10-bit full adder. There are 20 input signals mapped to GX5295 channels 0:19; Ain[0:9] and Bin[10:19]. There are 11 output signals, 10 bits for the sum and one bit for the carry. these signals are mapped to GX5295 channels 20:30.

Example ATEasy Code for limit testing UUT outputs:

! Define DIO output as force voltage (drive UUT inputs)
Dio Setup Channels Mode PmuForceVoltageMode RangeOfChannels(nHandle,0,19)
! Set default voltage to 0V for DIO outputs - logic '0' for UUT Ain and Bin inputs
Dio Setup Channels PMU ForceVoltage RangeOfChannels(nHandle,0,19,0,1,0,1)

! Define DIO inputs as force current mode (load UUT outputs)
Dio Setup Channels Mode PmuForceCurrentMode RangeOfChannels(nHandle,20,30)
! Set force current to 1mA load using the 2mA range
Dio Setup Channels PMU ForceCurrent RangeOfChannels(nHandle,20,30,1,2)
! Set high/low commutating voltage to +3.5V and -1V, respectively
Dio Setup Channels PMU ForcedCurrentCommutatingVoltage RangeOfChannels(nHandle,20,30,3.5,-1)

! Set channels 20 - 30 for comparator mode (limit testing)
Dio Setup Channels PMU ComparatorsSource RangeOfChannels(nHandle,20,30,aPmuComparatorsSourceIoVoltage)
! Define High/Low input comparator limits to 1.5V/0.5V, respectively
Dio Setup Channels PMU ComparatorsValues RangeOfChannels(nHandle,20,30,1.5,0.5)

! Apply logic '0' (0V) to UUT Ain inputs (Bin is also '0') - force UUT sum outputs to '0'
Dio Setup Channels PMU ForceVoltage RangeOfChannels(nHandle,0,9,0,1,0,1)
! Return high/low comparator results in arrays adwHighStates and adwLowStates
Dio Get Channels PMU ComparatorsStates(nHandle,False,adwHighStates,adwLowStates)

! Apply logic '1' (3.0V) to UUT Ain inputs (Bin inputs are '0') - force UUT sum outputs to '1'
Dio Setup Channels PMU ForceVoltage RangeOfChannels(nHandle,0,9,3,1,0,1)
! Return high/low comparator results in arrays adwHighStates and adwLowStates
Dio Get Channels PMU ComparatorsStates(nHandle,False,adwHighStates,adwLowStates)

Summary
Using comparator-based limit testing improves test throughput for DC parametric tests by streamlining the procedure for validating DC parameters of the UUT, without sacrificing quality or coverage.

Error while using online help books: 'Navigation to the webpage was canceled' - Published on 5/11/2011

5/11/2011

When attempting to open a Microsoft Compiled HTML Help CHM file via a link on a website, you may encounter a message stating 'Navigation to the webpage was canceled'

Windows security update 896358 prevents the opening of CHM files from non-trusted locations. Specifically, when attempting to open a CHM by clicking a link from a website, the file is downloaded to your computer's local Internet cache. Although this file location is local to your machine, the directory is designated as Internet zone which is not by default an "Trusted" zone. By default, only the Local Machine (URL Security Zone 0) is trusted and therefore only CHM files downloaded and saved on the machine's local hard disks are accessible.

Workaround: Changing your max allowed zone

MaxAllowedZone	URL Security Zones Allowed
0	Local Machine zone: Content that exists on the local computer.
1	Local Intranet zone: Content located on an organizations local intranet. Also includes local machine zone.
2	Trusted Sites zone: Content located on web sites that are considered more reputable or trustworthy than other sites on the Internet. The user designated these sites manually by adding the URLs of these trusted Web sites to this zone. Also includes local machine and intranet zone.
3	Internet zone: Content located on web sites that are not designated as either trusted sites or restricted sites. Also includes zones 0 through 2.
4	Restricted sites zone: Content located on web sites that are considered less reputable or trustworthy than other sites on the Internet. The user designates these sites manually by adding the URLs of these distrusted sites to this zone. Also includes all other zones.

You can perform a registry edit to enable zones beyond the local machine zone. Copy this code below into a text editor and save as EnableCHM.reg; right-clicking and selecting Merge will merge these changes to the registry, enabling the running of .chm files opened from the Internet zone:

REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000003

The will enable the running of .chm files from any site on the Internet except those listed within your computer's restricted sites. Copy the code below into a text editor and save as DisableChm.reg; right-clicking and selecting Merge will disable the running .chm files, except when opened from the local system, which is the most restrictive setting possible:

REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000000

Note: IT personnel should be consulted before making registry changes.

Workaround: Running the CHM from the local machine

Choose to right-click and save the CHM file to your computer.

If the file doesn't open from your local machine, it may still have a flag incidicating that the file originated from another computer.

1. Right-click and open the Properties of the CHM file.
2. Click 'Unblock' at the bottom of the Properties Dialog window.
3. Retry opening the file.

How to assign a Processor Core for an ATEasy thread or process - Published on 4/7/2011

4/7/2011

As multi core processors become more prevalent, software developers can take advantage of the additional performance benefits by writing code that implement multiple threads to accomplish tasks in parallel. ATEasy fully supports multithreading technology and provides a set of API functions that easily allow a user to create, terminate and manage threads.

This article describes two such API function that can be defined in your ATEasy application from the Windows API to manage the processor affinity property of a thread or process. Setting the processor affinity will lock a thread or process into using a particular CPU Core, bypassing the Windows scheduler.

The following describe the function prototypes:

BOOL WINAPI SetProcessAffinityMask( __in HANDLE hProcess, __in DWORD_PTR dwProcessAffinityMask)

DWORD_PTR WINAPI SetThreadAffinityMask(__in HANDLE hThread, __in DWORD_PTR dwThreadAffinityMask)

These functions are defined in kernel32.dll. In order to use them in ATEasy, kernel32.dll library must be inserted into an ATEasy Program, System, or Driver and the above functions defined.

For each function, the first parameter can be defined as Val AHandle and the second parameter can be defined as Val DWord in ATEasy. The return type can be defined as DWORD.

Pass -1 to the hProcess parameter to configure the main ATEasy process.

Pass the return value from the ATEasy functions CreateThread or GetCurrentThread to hThread to configure a specific thread.

dwProcessAffinityMask and dwThreadAffinityMask are bit-wise masks that indicate which core will be selected.

More information can be found at the following links:
SetProcessAffinityMask
SetThreadAffinityMask

Guidelines for designing a custom GX3500 expansion board - Published on 12/16/2010

12/16/2010

Introduction

A unique feature of the GX3500 FPGA card is that it can accommodate an expansion card assembly that can be used to customize the interface to the UUT. This eliminates cumbersome and physically difficult to integrate external boards from the test system.

The custom expansion interface is contained on a mezzanine board that sits piggyback on the GX3500 FPGA PCB (figure 1). The expansion board provides approximately 105 cm² on each the front and back sides (figure 2), and obtains power from the GX3500.

Figure 1: GX3500 with Expansion Board

Figure 2: GX3500 Expansion Board Design Area

Software controlled relays control whether the 160 FPGA signals are routed directly to the GX3500 front panel connectors, or whether the I/O signals are intercepted from the FPGA and routed through the expansion board. The relays can be controlled using the API function GxFpgaSetExpansionBoardBypass(), or using the GX3500 Soft Panel (figure 3).

Figure 3: Expansion Board Bypass Control

High Speed Terminal Strips, manufactured by Samtec, are use to provide power to the expansion board, and bring the signals on and off the board (figure 4). The middle bar of the connector is used for ground and power connections to the expansion board, while the outer pins provide access to the I/O signals (figure 5).

Figure 4: Expansion Connectors

Figure 5: Power Connections

Design Guidelines

When designing an expansion interface for the GX3500, consideration must be given to the following:

Board Area: Maximum board surface area is about 200 cm².

Component Height: Maximum component height is 8mm, with some areas on the board reduced to a maximum component height of 5mm.

Power Requirements: The GX3500 expansion connectors provide multiple power voltages to the expansion board. Provide adequate decoupling and filter capacitors and do not exceed the maximum power budget for the voltages:

5V, 4.0A
+12V, 0.5A
-12V, 0.5A
1.2V, 1.0A
2.5V, 0.5A
3.3V, 4.0A

Cooling: Make certain the air flow is not blocked to higher power components.

Termination: Provide proper trace impedance and, if necessary, termination for high-speed signals and signals with fast edge rates.

A full GX3500 Expansion Board Design Guide is included in the GX3500 User Guide.

White Paper: An FPGA–Based Solution for Testing Legacy Video Displays - Published on 11/30/2010

11/30/2010

Systems deployed in the last century used CRT monitors to display information to a technician or operator. These monitors were based on analog video transmission standards such RS170, NTSC (National Television Standards Council), PAL (Phase Alternating Line) and other similar standards. Today, with the widespread use of DVI and HDMI digital video, it is rare to find CRT monitors in commercial use. But they are still widely used in older deployed systems.
This paper is a case study based on the requirement for a PXI-based instrument that can generate simple color bar signals in NTSC and PAL formats to support the Mini-Samson/Katlanit Remote Controlled Weapon Station. By integrating an off-the-shelf PXI FPGA card (GX3500), with an intellectual property (IP) core available in the public domain and a handful of commercially available support components, a cost effective solution was developed which supports the generation of both analog and digital video signals for testing CRT and LCD monitors.

Download the white paper

Using Simple Network Management Protocol (SNMP) in ATEasy 8.0 - Published on 11/22/2010

11/22/2010

SNMP (Simple Network Management Protocol) is a networking protocol used to monitor and control network-attached devices such as adapters, routers, switches, workstations, and servers. To use SNMP to communicate with a device, the device must both support SNMP and have SNMP enabled. The primary functions that can be performed through SNMP are device identification, device property querying and device configuration. Since SNMP can be integrated with ATEasy, a technician using ATEasy can automate the testing of SNMP-enabled devices.

In this guide, we will discuss two ways to utilize SNMP within ATEasy:

Using 3rd party software

Using the WinSNMP API with the ATEasy SNMP.drv driver

Using 3rd party software

There are a few open-source SNMP Managers available to utilize for basic testing. This example will demonstrate using Net-SNMP. When installed, Net-SNMP adds command-line executables such as the SNMPGET, SNMPGETNEXT, and SNMPSET functions for OID querying, SNMPWALK for device location, and SNMPSTATUS and SNMPNETSTAT for device status information. Only a couple of these features will be used in the article for demonstration. The complete list of features is available on the Net-SNMP webpage.

The example below demonstrates calling the executable SNMPGet to query an OID for information and saving the results to a text file.

Procedure SNMPGet(): Void
--------------------------------------------------------------------------------
    sAgent: String
    sSaveFile: String
    sOID: String
    sCommunity: String
{
    sCommunity = "public"
    sAgent = "127.0.0.1" ! Local Host
    ! Object Identifier Descriptor for the device we're talking with
    sOID = "sysDescr.0"
    sSaveFile = "snmpgetresults.txt"

    ! Calls device SNMP and saves results to text file
    WinExec("SNMPGET -v 1 -c " + sCommunity + " " + sAgent + " " + sOID + " > " \
        + sSaveFile)

    ! display results
    WinExec("notepad " + sSaveFile) ! Opens text file for viewing the SNMPGET results
}

In the first WinExec command an OID, sysDescr.0, is requested from the local host and saved into "snmpgetresults.txt". The second WinExec command opens that file so the data can be viewed.

The SNMPGet procedure can be modified to use the other Net-SNMP features, such as SNMPNETSTAT which gives us the assignment of an agent's TCP and UDP ports.

Using the ATEasy v8.0 WinSNMP Driver

Another way to communicate with a target agent using SNMP protocol is to directly access the WinSNMP API provided with Microsoft Windows. The implementation is simplified through use of the WinSNMP ATEasy driver, which is available in ATEasy v8.0 and above. The driver also lists the procedure to install and configure the WinSNMP service required when using the Windows driver.

In the ATEasy implementation of WinSNMP, an SNMPGET call can request and retrieve the value of an Object Identifier in a single command, as shown here:

! Request the System Contact from the agent
TestResult = SNMP Function Get("1.3.6.1.2.1.1.5.0")

With the ATEasy Driver included in the project, the preceding line of code acquires the System Contact octet string and assigns it back to the TestResult variable for use in ATEasy.

Similarly, the included function "SNMP Function Walk(...)" can be used to traverse a system and returns back all of the nodes between the start and stop OID specified.

!Return the data stored at all OIDs between 1.3.6.1.2.1 and 1.3.6.1.2.1.6.0
TestResult = SNMP Function Walk("1.3.6.1.2.1", "1.3.6.1.2.1.1.6.0")

Example results of an SNMP Walk:

1.3.6.1.2.1 = NULL: 0
1.3.6.1.2.1.1.1.0 = STRING: Hardware: x86 Family 15 Model 4 Stepping 7 AT/AT COMPATIBLE
1.3.6.1.2.1.1.3.0 = TIMETICKS: 52335668
1.3.6.1.2.1.1.4.0 = STRING: Victor Brode
1.3.6.1.2.1.1.6.0 = STRING: My CTS box

Summary

This demonstration of features just barely scratches the surface of the utility that SNMP provides. A complete listing of the WinSNMP ATEasy driver is available in ATEasy v8.0 and above. Hopefully, if your project is required to automate SNMP communication, this article has given you a good idea where to start.

White Paper: Implementing a High Performance Digital Subsystem Using the PXI Architecture - Published on 10/14/2010

10/14/2010

Abstract
High Performance digital subsystems have been developed over the years using a variety of proprietary and industry standard architectures such as GPIB and VXI. With the availability of high performance / high density FPGAs and analog electronics, the implementation of high performance digital functional test subsystems has now become a reality using the PXI architecture. The smaller form factor of PXI, which offers users the ability to down size and deploy very cost effective, performance digital subsystems, has also presented some unique challenges for instrument design teams developing these high performance digital subsystems. This paper discusses some major considerations and challenges when implementing high performance digital instrumentation based on the PXI architecture.

Download the complete white paper

Activating the Multi-User Features of ATEasy's Test Executive - Published on 9/27/2010

9/27/2010

The Test Executive driver included with ATEasy provides a multi-user environment. Within, a user with administrator rights can create user groups and user accounts. User group such as  Testers, Supervisors, Administrators can be assigned a customized set of command menus, toolbars, options and different levels of privileges.  This article with cover activating these features and configuring user groups within the test executive.

The TestExec.drv ATEasy software driver includes integrated support for multi-user features which are turned off by default.  To activate these features, you only need to enter the location of your users file (.USR) into the TestExec Driver Shortcut parameters page.  The parameter UsersFile, which is empty by default, can be changed to the absolute or relative location of a file i.e. 'C:\Windows\System32\Ateasy.usr'

Ideally, a Users file would be located on a network drive where it would be accessible by all of the ATEasy developers and testers within an organization, but write access could be controlled and given to project administrators.  For the purposes of this demo, which can be done locally, it is sufficient to use a user file that is stored locally.

Configuring the user groups within your Test Executive

Now that the multi-user features have been enabled, you will be prompted with a User Login Dialog when you attempt to start your program.  If you are using the multi-user features for the first time, you will need to log in with one of the user file's administrator accounts to configure each user's privileges.

To begin configuring your user groups, log in as an administrator.  If you are using the user file located at 'C:\Windows\System32\Ateasy.usr' and you have never changed the password on this file, the default administrator account user name is Administrator.  Leave the password blank and hit OK to log in.

Once logged in as Administrator with multi-user features enabled, you should have a new menu bar item: Tools | Users...
This is your portal for configuring users groups.  Clicking this item will allow you access the Test Executive's Users Dialog.

The Users Dialog is where access levels, UI configuration, and Test Executive customization is handled in multi-user mode.  Layouts and privileges are differentiated for your users. The User Dialog window has eight pages, all of which are documented in the Test Executive help.

Users Dialog: Groups Page

By default, you are provided with three User Groups with which to organize your ATEasy users.  When the Test Executive activates a User file for the first time, it will automatically create three default user groups with their own set of command menus, toolbars, and options.

Administrators - Has all of the functions available in a Test Executive that is not using the multi-user feature.  Also has ability to configure the user file from within the Test Executive.

Supervisors - Same rights and default layout as the Administrator account, but does not have the ability to access the Users dialog.

Testers -  This user group was designed to allow selection of program / profile, execution of that selection and test log archiving.

Each individual user must be placed into one of these User Groups before they can access the Test Executive.  Alternatively, a custom User Group can be created and assigned to a user.  The Groups page is where user groups can be created / modified / deleted.

Users Dialog: Users Page

The Users Page allows the administrator to see all of the users associated with the current USR file. Users can be added and deleted here, passwords can be changed, and users can be assigned to user groups. Also, one user can be selected as a default user, allowing automatic login when the test program is started. The default user account can not have a password, however.

The rest of the pages in the Users Dialog deal with configuring each user groups layout. The details of these pages are covered in the Test Executive help under the keywords "Users Dialog".

Example

The following example will demonstrate using the administrator account to configure the layout of the tester account. The tester account, by default, has only Continuous and Task By Task run conditions available. We will be adding the Test By Test mode.

Start an ATEasy project and include the TestExec software driver. Make sure the UsersFile parameter is set to the ATEasy.usr file in your Window's System folder.

Open the Users Dialog (Tools | Users...)

Click the Toolbar tab.

Click the drop-down box labeled Group: and change the active user group to Testers.

In the available commands box, click the plus icon by Conditions... to expand the list.

Locate and click on the item Test By Test. Click it and click the Add -> button to add the item to the active toolbar for Testers.

We have added the button to the toolbar, but it is not enabled yet.

Click the Commands tab.

Click the drop-down box labeled User Group: and change the active user group to Testers.

In the available commands box, click the plus icon by Conditions... to expand the list.

Click the item Test By Test and click the Enable checkbox to enable this item.

Click OK.

If you use Tools | Change User... to log into your Tester account, you will notice that the Task By Task option has been added to the toolbar. In this manner, other items can be added and removed from the ToolBar. The process is very similar for menu items as well.

Executing and communicating with Perl or TCL scripts from ATEasy v8.0 using the Standard I/O Process Driver - Published on 8/12/2010

8/12/2010

ATEasy v8.0 supports calling, controlling and communicating with Windows console applications. This allows test engineers leverage existing script code written in languages such as TCL, Perl, PHP and use the script from their tests.

This article describes the simple process involved in calling a TCL and Perl script from ATEasy. The example code involves with using the ATEasy Standard I/O Process Driver StdIoProcess.drv. The example scripts will wait for ATEasy to send data via the standard I/O and then will respond by echoing this data back to ATEasy. Similar techniques can be used to control any Windows command line utilities.

The ATEasy StdIoProcess driver allows a user to call console based executable, pass arguments,monitor the process’s standard output and send data to the process via its standard input.

Note that the following software components are required to get started:

Microsoft .NET Framework

Installation of an script interpreter

A script interpreter executable that can take the filename of the script to be run from its first command line argument.

The first example calls a TCL script. This example is using the ActiveTCL interpreter which was installed in the C:\tcl folder. The script will accept two numeric values and output the sum of those two values:

puts "TCL Script Started"
gets stdin x
gets stdin y
set result "The Sum is: "
append result [expr $x+$y]
puts $result

Here is the ATEasy code using the StdIoProcess driver. ATEasy pass in two numbers 4 and 5 and read back the result as calculated by the RCL script:

sTclPath="C:\\tcl\\bin\\tclsh85.exe"
StdIoProcess Execute(sTclPath, "\""+sExamplePath+"StdIoProcessAdd.tcl\"", "4\r\n5\r\n", True)
s=StdIOProcess Get StdOutput()
if StdIOProcess Get ExitCode()<>0
TestStatus=FAIL
endif
if val(right(s, 3))<>9
TestStatus=FAIL
endif

Similar to the TCL interpreter, the Perl interpreter installed from Strawberry Perl can be used. In the following example we run StdIoProcessAdd.pl, passing two numbers 45 and 9 and getting back the sum as shown here:

! add two numbers using PERL
StdIoProcess Execute(sPerlPath, "\""+sExamplePath+"StdIoProcessAdd.pl\"", , False)
StdIoProcess Write("45")
StdIoProcess Write("9")
StdIoProcess Read(s, True)
TestResult=val(s)

The contents of the perl script TestScript.pl is the following:

print "Perl Script Started";
$x = ;
$y = ;
print $x+$y;

The referenced files are included in ATEasy v8.0 and above (see StdIoProcess.prj example). The example also contains example of executing the Windows command prompt (CMD.EXE). Here is the ATEasy form that is provided with the example:

Importing non-standard Function Panel (.fp) drivers into ATEasy - Published on 7/8/2010

7/8/2010

Introduction

ATEasy allow you to use VXI Plug&Play drivers (sometimes refer to as IVI-C driver) created by instrument vendors. These instrument drivers support various interface types such as GPIB, VXI , Serial, PXI, USB, LXI or PCI based board and more. The function panel driver (FP) has a .fp file extension and can be imported to ATEasy using the Insert, Import FP File (*.fp) command. Once the driver is imported you will need to save it to ATEasy driver (.drv or .drt file). The process of importing the FP driver is described in the ATEasy on-line help (see "Using VXI Plug&Play Function Panel Drivers" topic).

You can obtain and download a Function Panel driver from the instrument manufacturer web site. Most vendors also register their driver at the IVI Foundation web site IVI Foundation website under the Driver Registry section. Some vendor such as Agilent or National Instruments carry also third party instruments drivers.

Driver Prerequistes:

The IVI-C driver specification describe a standard for Initialize, and error handling functions which must exist in the FP driver. The ATEasy Import command will search for these functions and generate special ATEasy code to intialize and handle errors in the imported driver. The following functions are searched by the Import command:

Initialize function should have the following format:

PREFIX_init(sResourceName, bIDQuery, bResetDevice, m_session)

Error Message function should have the following format:

PREFIX_error_message(m_session, lStatusCode, psMessage)

The prefix begins with a two-character vendor code, followed by characters that uniquely identify the instrument driver. The following is an example of the Initialize function for the Pickering System 40 PXI cards:

pipx40_init(sResourceName, bIDQuery, bResetDevice, m_session)

Importing Non-Standard FP Drivers

The ATEasy Import Wizard will search the FP driver for the required Initialize and Error Message functions. If these functions do not exist in the FP driver, ATEasy will display messages listing the missing function(s) and ask the driver developer to select the appropiate function from the displayed FP function list (see example below).

Figure 1: "Unable to find Standard Function" message from the ATEasy Import Wizard

If the appropiate function does not exist in the displayed listing, ATEasy will create a function wrapper with no source code so the developer can include the source code at a later time manually. The following are examples of the Initialize and CheckError functions after the ATEasy Import process, showing the required FP driver functions implementation:

Procedure Initialize(sResourceName, bIDQuery, bResetDevice) : Void
! Create the following variables
!    sResourceName: [Val] ViRsrc
!    bIDQuery: [Val] ViBoolean = 0  !Specifies if the card is to be queried
!            to confirm it's ID when it is opened. This action is implicit in the
!            driver's operation so the value of this control is ignored.
!    bResetDevice: [Val] ViBoolean = 0 ! Specifies if the card is to be reset
!            when it is opened. This action is obligatory for all cards so the
!            value of this control is ignored.

{
    if ArgMissing(sResourceName)
       sResourceName=Driver.Parameters("ResourceName")
       if sResourceName=""
          error -1001, "Unable to initialize.\nDriver Shortcut parameters must "                "be configured from its Misc property page"
       endif
    endif

    if ArgMissing(bIDQuery)
       bIDQuery=Driver.Parameters("IdQuery")
    endif

    if ArgMissing(bResetDevice)
       bResetDevice=Driver.Parameters("ResetOnInit")
    endif
    ! Required FP driver function is highlighted below
    CheckError(pipx40_init(sResourceName, bIDQuery, bResetDevice, m_session) )
}

Procedure CheckError(iStatus) : Void
!   Create the following variables:
!       iStatus: Val ViStatus
!       sError: String: 1024
{
    m_lLastError=iStatus
    if iStatus <> VI_SUCCESS then
       ! Required FP driver function is highlighted below
       pipx40_error_message(m_session, iStatus, sError)
       error iStatus, sError ! generate exception
    endif
}

White Paper: GX52xx - PXI Digital I/O Cards - Clock and Strobe Delay Operation - Published on 5/20/2010

5/20/2010

Abstract

The Gx528x and Gx529x dynamic Digital I/O (DIO) product families have very robust timing features that provide the user with the flexibility to align signals between the DIO and the Unit Under Test (UUT). The clock signal is used to output test vectors, and the strobe signal samples data into the DIO’s record memory. The basic architecture provides six coarse delays in 4 ns steps. In addition, a fine resolution delay (vernier) is available which provides a 0ns to 3ns delay in 250ps steps. Together, these elements provide delays in the range of 0ns to 27ns, with 250ps resolution. Read more...

Download the complete white paper

How to call ATEasy procedures dynamically based on Test and Task names - Published on 5/19/2010

5/19/2010

Sometimes it is useful to call a procedure with a function pointer. One example would be calling a unique procedure for each Test defined in a Program based on the Test and Task name of the current Test being executed. A procedure pointer can be used instead of hard coding a call to each procedure, thereby simplifying the code and allowing more tests to be added without code modification.

The following steps should be followed:

Create procedures for each test defined in the program. In this example, the procedure names must be the Task name followed with the underscore character, appended to the Test name follwed by “_Init”. This naming template can be changed by modifying the first line of code in step 3.

Define a variable in the OnInitTest() event named proc of type Procedure. This will act as the function pointer.

Insert the following code in the OnInitTest() event.

proc=Task.Name+"_"+Test.Name+"_Init" !Assign the procedure pointer a procedure
if(proc)         !Check to make sure the procedure actually exists
     proc()      !Execute procedure
else
     print "proc is not valid!"
     !error handling code
endif

White Paper: ATEasy - Deployment Across the Organization - Published on 5/19/2010

5/19/2010

Abstract

ATEasy’s modular structure lends itself to the distribution of ATEasy development activities among different skills sets, allowing organizations to better control the development and deployment of ATEasy. The modular structure promotes achieving of code reuse, better manageability and increased efficiency.

Because driver files, the test executive (which is an ATEasy driver as well), and the systems files can be reusable components between systems or shared by programs, they should be standardize to achieve better reusability. To achieve standardization, organizations should define and allocate specific job responsibilities to enforce and create a streamlined process of managing the development and deployment. By assigning personnel with responsibilities to the various aspects of ATEasy module development, organizations can achieve much higher efficiency and code reusability.

Download the complete white paper

PXI Express Standard - Published on 4/30/2010

4/30/2010

What is PXI Express?

The PXI Express (PXI-5) standard was created by the PXI Systems Alliance to integrate PCI Express advances into the PXI standard to improve performance attainable in modular instrumentation and automation systems such as those utilized by automated test developers and technicians. The PXI-Express standard brings with it several improvements but still provides a high degree of compatibility with the PXI-1 standard and compatibility with industry-standard software and operating systems. For more information on the PXI-1 standard, please follow the link to this article: What is PXI?.

Instead of a shared parallel bus, PXI Express uses multiple point-to-point serial connections (“lanes”) for instrument communication. Each lane consists of a pair of lines: one transmitting and one receiving, each able to transfer data independently allowing unimpeded bidirectional communication. A single-lane connection (‘x1’ or ‘by 1') has a bandwidth of 250 Mbytes/sec/direction. The lanes are assigned to the instruments by a matrix switch and can routed to provide one or more instruments with additional bandwidth. In this manner, devices with a higher bandwidth requirement can be allocated more resources. The PXI Express standard also incorporates a 100 MHz differential system clock that is phase-aligned with the existing 10 MHz PXI system clock and can work in conjunction with the 33MHz PCI system clock. Additional features include signaling to ensure that modules using system clocks or clock divisions are synchronized and point-to-point differential triggering. A PXI Express controller utilizes the same operating system and driver model as PXI. This ensures that the test designer can reuse existing code and software with the newer PXI Express system.

Slots

A PXI Express chassis can have five slot types:

PXI Express System Slot: slot 1 shown above

PXI Express Peripheral Slot: slot 5 shown above

PXI Express System Timing Slot: slot 4 shown above

PXI Peripheral (PXI-1) Slot: slots 2 and 6 through 9 shown above

PXI Hybrid Slot: slot 3 shown above

The PXI Express System Slot is the leftmost PXI slot, designated by a filled triangle labeled '1'.  This slot will accept a system module in the form of an embedded controller or a PXI Express Bus Expander.  An embedded controller is a single-board computer which comes with traditional components such as processor, memory, network and video cards, and I/O ports such as keyboard, mouse, and USB.  A PXI Express Bus Expander kit allows remote control of the PXI Chassis and its hardware by another computer.  The kit consists of a PXI-Express interface card which goes in the System Slot, a PCI-Express card which is installed into the desktop or plugged into the laptop, and an interface cable.  If the System Module's functionality is integrated into the chassis and none is required, then the PXI System Slot will not be present on the chassis and the peripheral slot numbering will begin with '2'.  Additionally, if a system module does not fit into a single slot, the PXI Express standard requires that the System Module expand to the left in slot-wide increments defined as controller expansion slots.

The System Timing Slot is intended to be used by a PXI Express System Timing Module.  A System Timing Module provides individual triggers to all other PXI Express Peripheral modules and allows replacement of the system reference clock.  The System Timing Module replaces the Star Trigger Module as the timing and synchronization provider for the rest of the peripheral modules. The star trigger connection points defined in PXI-1 are still retained as well as the ability to replace the system reference clock with it's own, more accurate reference clock.  If a system timing module is not required, the system timing slot can be used can by a PXI Express Peripheral.

The PXI Express standard specifies that there may be slots that support PXI board as defined by the PXI Hardware Specification.  These peripheral slots are referred to as PXI-1 slots.  Communication with the controller is supported via an included, shared PCI bus.

Finally, there are two hybrid slots that can be used with PXI Express instruments or with legacy PXI instruments that are hybrid slot compatible.

PXI-1 peripheral modules have a J1 and J2 interface to connect to the backplane.  To make these instruments hybrid slot compatible, the card’s J2 interface must be removed and replaced with an XJ4 interface.  The resulting interface is compatible with PXI Express chassis hybrid slots but will still work in traditional PXI-1 slots.  Since removing the lower portion of the J2 interface will remove the access to the local bus, this modification should not be done on some instruments.

What is PXI? - Published on 3/30/2010

3/30/2010

The PXI Standard

The PXI standard is defined by the PXI Systems Alliance and was developed in response to the needs of test systems developers and users who required a new platform that is high-performance, functional, reliable, compact, yet easy to integrate and use. By leveraging off of the PCI, CompactPCI and VXI standards, PXI brings together the right technologies for PC-based test and measurement, instrumentation, and industrial automation. Further, since PXI is a PC-based platform, it maintains software compatibility with industry-standard personal computers, as well as all PC-based operating systems, software tools, and instrument drivers. Not only is PXI fully compatible with existing operating systems and software, it is fully compatible with the Virtual Instrument Software Architecture (VISA) standard that was created by the VXIplug&play Systems Alliance. VISA is used to locate PXI resources as well as communicate with PXI, serial interface, VXI, and GPIB peripheral modules and is supported by test development software packages such as ATEasy™, LabVIEW™, LabWindows/CVI™ and Agilent VEE™.
The PCI bus is a 33/66MHz 32/64bit bus that offers peak data transfer rates of 132 Mbytes/s (32-bit, 33MHz) and 528 Mbytes/s (64-bit, 66 MHz). PXI expands upon the PCI bus by using the rugged form factor of CPCI and then adding triggering, local buses and system clock capabilities. The result is a standard that incorporates all of the benefits of PCI and cPCI in an architecture that supports these standards’ mechanical, electrical and software features. Also because interoperability between CompactPCI and PXI is a feature of the PXI Standard, both instrument types can reside in the same PXI system without any conflict - offering users a broad selection of both 3U and 6U cPCI modules in addition to the PXI instrument offerings.

PXI Express leverages the electrical features defined by the widely adopted PCI Express specification for data movement. All PXI Express modules comply with the CompactPCI Express specification, which combines the PCI Express electrical specification with rugged euro card mechanical packaging and high performance differential connectors. This allows measurement and automation Systems based on PXI Express to have a data throughput of up to 4 GBytes/sec in each direction. PXI Express also offers two-way interoperability with CompactPCI Express products. For more information on PXI Express go to the following article on the PXI Express Standard.

PXI Instrument architecture:

PXI instruments are available in two form factors: 3U (100 by 160 mm, or 3.94 by 6.3 in.) and 6U (233.35 by 160 mm, or 9.19 by 6.3 in.). These two form factors are shown below.

Figure 1: PXI 3U/6U Instrument Form Factors

3U PXI instruments have two rear connectors named J1 and J2. J1 is used to carry the 32-bit PCI local bus signals. J2 is used to carry the signals for 64-bit PCI transfers and the PXI signals for implementing the local bus, star trigger signals and trigger bus signals. These signals are described later in this article. Connectors J3/J4/and J5 are undefined for 6U PXI modules but may be used for special applications.
6U system controller modules and system slots may use P3/J3, P4/J4, P5/J5 for rear I/O purposes.

Note: 3U instruments can reside in 6U slots when used with a 3U-to-6U Panel adapter similar to the Geotest GX97005 panel adapter shown below.

Figure 2: Geotest GX97005 PXI 3U-to-6U Panel Adapter mounted on a 3U PXI/cPCI instrument

PXI Hardware Architecture Overview

A PXI system consists of three main components:
  1) The chassis
  2) The system controller
  3) Peripheral instrumentation

Figure 3: GX7300 20-slot 3U PXI chassis

PXI Chassis and Backplane Information:

The main components of a PXI chassis are:
  1) The System Controller
  2) The Star Trigger Controller
  3) The Chassis Backplane

Per the PXI Standard, the System controller will always reside in Slot 1 and the Star Trigger Controller, if required, is always located in Slot 2. The chassis backplane contains the PCI Bus, the Star Trigger Bus, a PXI Trigger Bus, PCI-PCI Bridge devices and the 10MHz System Reference Clock.
       In a typical 20-Slot PXI chassis layout, slot number 1 is dedicated for an embedded or remote controller. Slot 2 can be used by a PXI Star Trigger Controller or by a PXI/cPCI instrument. Slots 3 through 15 supports the PXI Star Trigger and Slots 16-20 accommodate PXI or cPCI instruments without the Star Trigger.

Figure 4: PXI Chassis architecture

Figure 5: GX7000A 20-slot 6U PXI chassis

System Controllers

The System Controller is always located in the first slot on the left-hand side of the chassis and is available in two configurations: Embedded controllers and Remote Controller Interface Kits:

Embedded controllers are basically a PC on a card and can run on a number of different Operating Systems, for example Windows and Linux. As they remove the need for any external control they are ideal for portable applications and applications that require “single box” solutions. In cases where the embedded controller requires more than one slot the PXI Standard allows for additional controller expansion slots to the left of the controller slot. In this way instrument slots are not used by the controller.

Embedded controllers come in two form factor, Single slot controllers and Multi-slot controllers:

Single-slot embedded controllers are one PXI slot wide and do not require any controller expansion slots. They support multiple peripherals and I/O interfaces through the controller’s front panel and the chassis rear I/O panel. Connection to the DVD-RW drive, hard drive and chassis rear I/O connectors is via the controller’s internal I/O interface. As some of these controller cards have a flash drive port option, where the flash-drive port is built onto the controller card, they can be operated from a flash-drive without the need for a hard drive. All Geotest embedded system controllers adhere to the PXI and cPCI specifications and are PICMG 2.0 Rev. 3.0 compliant.

Figure 6: GX7924 6U and GX7934 3U PXI Single-Slot Embedded Controllers

Multi-slot embedded controllers operate the same as single-slot controllers but differ in that all the PC components, for example the hard-drive, are built onto the controller card and all the external connectors, for example Ethernet, USB, etc.., are available on the front faceplate. As these components and connectors require extra space, these controllers can occupy up to three slots (a system slot plus two controller expansion slots).

Figure 7: Typical Multi-Slot Embedded Controller

Remote Controller Interface Kits (also referred to as Bus Expansion Kits) are used in cases where the user wants to control a slave PXI chassis using an external PC, laptop or a Master PXI chassis. The interface kit consists of a pair of cards, one that plugs into the PC/Laptop or the Master PXI Chassis and another that goes in the system slot of the slave PXI chassis. The cards are then linked via copper or fiber-optic cable. For more information on the various PXI bus expansion options please see the following article on PXI Bus expander configurations

Figure 8: External PC controlling a slave PXI chassis with a MXI-4 Remote Controller Kit

Figure 9: Master PXI chassis controlling a Slave PXI chassis

Star Trigger Controller

The Star Trigger (ST) Controller, if required, will always reside in Slot 2. This slot has dedicated trigger lines that can be used to synchronize up to 13 Peripheral PXI instruments that reside in the 13 consecutive slots to the right of the controller. It does this by utilizing backplane traces that are of equal length, providing for a skew of less than 1nSec between slots. If a Star Trigger Controller is not required, any PXI or cPCI instrument can be used in this slot.
For example, in the Geotest GX73xx and GX70xx 20-slot chassis’s Slots 2 through 15 support the Star Trigger while slots 16 through 20 accommodate PXI or cPCI instruments without the Star Trigger.

PXI Bus Segments

The PXI Standard allows for up to eight slots per 33MHz segment (one system slot and seven peripheral slots). Multiple segments can be connected together using a PCI-PCI bridge device. The PCI-PCI bridge presents one PCI load on each of the bus segments that it links together.
A typical 20-slot PXI chassis is divided to three bus segments (see Figure 8 below), each connected by a PCI-PCI Bridge device. The left bus segment supports the System Slot, the Star Trigger Slot and 5 more peripheral slots (Slot 3 to 7). The second segment supports slots 8 to 13. The third segment supports slots 14 to 20.

PXI Local Bus

The PXI local bus is a daisy-chained bus connecting peripheral slots in the same bus segment. Each local bus consists of 13 user-defined lines that can be used to pass analog or digital signals between two adjacent modules or provide a high-speed side-band digital communication path that does not affect the PXI bandwidth. Local bus signals can support voltages from 0 to 42V DC and up to 200 mA DC current for any local bus line. The local bus lines for the leftmost peripheral slot of a PXI back plane (slot 2) are used for the star trigger facilities. Figure 8 schematically shows a complete PXI system including the local buses.

Figure 10: PXI Local Bus Segments

PXI Trigger Bus

The eight PXI bused trigger lines can be used in a variety of ways. For example, triggers can be used to synchronize the operation of several different PXI peripheral modules. In other applications, one module can control carefully timed sequences of operations performed by other modules in the system. Triggers may be passed from one module to another, allowing precisely timed responses to asynchronous external events that are being monitored or controlled. The number of triggers that a particular application requires varies with the complexity and number of events involved.
The PXI trigger bus provides connectivity only within a single bus segment.which maintains the high performance characteristics of the trigger bus and allows the partitioning of instruments into logical groups as show in Figure 9. However, logical connections between bridge segment for the trigger bus are permitted, allowing communication between bridge segments. For example, all of Geotest’s PXI chassis can be configured programmatically to enable any of the trigger lines between adjacent segments as well as set direction.

Figure 11: PXI Trigger Bus Segments

System Reference Clock

The PXI 10 MHz system clock (PXI_CLK10) is also part of the PXI standard. It resides on the PXI backplane and is distributed to all peripheral slots. This common reference clock can be used for synchronization of multiple instruments or as a time base reference for measurement instrumentation. In cases where a more accurate 10MHz reference is required, the PXI clock can be sourced via the Star Trigger module. If the presence of this Star Trigger clock is detected, circuitry on the PXI backplane will automatically disconnect the backplane reference and connect the 10 MHz system clock lines to the Star Trigger module’s 10 MHz reference.

PXI Chassis Power Supply specifications

The PXI Standard also specifies the minimum power supply requirements for each slot of the PXI chassis regardless of the number of slots or the instrument form factor (3U or 6U). The PXI chassis supplies +5VDC, +3.3VDC, +12VDC and -12VDC to each slot. Figure 12 below shows the minimum power requirements for each slot in the chassis.
Note: All Geotest PXI chassis form factors meet and/or exceed these specifications.

Figure 12: PXI Chassis Minimum Power Supply Specifications

Summary

The PXI specification provides a very well defined and robust architecture for building high performance functional test systems. With over 1500 modules available today and over 60 PXI suppliers, the user can select from a broad range of products and vendors. The standard is over 10 years old which offers further proof to the longevity and acceptance of PXI as the primary card modular standard for the test and measurement industry.

ATEasy Forms Z-Order and Tab Order - Published on 3/18/2010

3/18/2010

ATEasy forms consist of controls such as Buttons, Text Boxes, and Charts (AForm.Controls property).  Each individual control is a distinct object created at design time (also at run-time)  within the form editor. This article discusses the order of drawing of the control on the form and TAB key sequence when navigating between the controls using the Tab key.

The tab order is the order in which focus moves from one control to another by pressing the TAB key.  The order in which these controls are placed on the form determines their Tab Order.  By default, the first control placed on a form will have tab order #0, the second control that accepts keyboard input will have tab order #1 and so on.

The Z-Order is the order in which the controls are stacked on a form and are drawn by ATEasy when the area on the form that they occupy require redraw.  A control on the bottom of the Z-Order will be drawn on the form first and a control on the top of the Z-Order will be drawn on the form last.  If two controls occupy the same space on the form, the control at the top of the Z-Order will overlap the control at the bottom of the Z-Order, partially or completely hiding it.

When you set the Tab-Order of your controls, you are also setting the order that the controls will be placed on the form.  The first control in the Tab-Order is placed at the bottom of the Z-Order.  Subsequent controls in the Tab-Order are stacked on top of the first control, obscuring it if they overlap.


        Figure 1 - The button with Tab-Order #0 is at the bottom of the Z-Order, so other buttons overlap it.

Making changes to the order of controls:

At design time ATEasy allows you to change the order of controls using the Edit, Arrange, Tab Order command or by pressing on the Tab-Order button from the Form Design Toolbar as shown in Figure 1.

At run time you can change the order of controls in the AForm.Controls using the AControl.ZOrder property.

For example, the command:

tbMyControl.ZOrder=aWindowZOrderTop

will bring the control named tbMyControl to the top of the ZOrder and the top of the layers of controls. Conversely, the command:

tbMyControl.ZOrder=aWindowZOrderBottom

will place the control at the bottom of the layer.

The following code was added to the AForm.OnLoad event for the form from Figure 1, resulting in btn1 now overlapping button2:

btn1.ZOrder=aWindowZOrderTop

Figure 2 - After running the code, btn1 now overlaps btn2 but retains it’s position in Tab-Order

Using an Alias to address PXI instruments - Published on 2/4/2010

2/4/2010

When writing a test program, often you must "hard code" the configuration of the test system into your application; for example, the PXI slot numbers of the instruments.  If a future system upgrade necessitates reordering the instrument slot numbers, you would need to modify the test program code to accommodate those changes - often requiring recertification of the test program before it can be released for use.

A more flexible approach, and one that avoids code recertification, is to use PXI/PCI Explorer to assign a text Alias in place of the instrument slot number, and reference the alias in your system configuration code.  The alias can remain the same regardless of which slot the instrument is installed in, so reordering instrument slots will not affect the test program code.  The following example illustrates this concept.

Assume you have two GX5282 Dynamic Digital I/O modules installed in slots 15 and 17 of your GX7000A system.  And assume that the GX5282 installed in slot 15 is going to be used for providing 32 channels of digital stimulus patterns to the UUT, and that the GX5282 installed in slot 17 will be used to capture 32 channels of digital response patterns from the UUT.  Using ATEasy to write your test program, you could initialize these instrument using the Driver Shortcut slot settings (figure 1), or by directly calling the initialization driver procedure, as shown below:

nMaster1:  Short=1
nMaster2:  Short=2
nSlot1:  Short=15
nSlot2:  Short=17

InitializeMaster(nMaster1,nSlot)
InitializeMaster(nMaster2,nSlot)

Figure 1: Setting the GX5282 Driver Shortcut slot number parameter

In both cases, if later the instrument slot positions were changed, the test program would need to be modified, recompiled and possibly recertified before the new program can be released.

However, if each instrument were assigned an alias text name, and the text name were used to initialize the instrument, instead of it's slot position, then the test program operation is independent of the instrument slot positions. To assign an alias for these two instruments, open the PXI/PCI Explorer application that is installed with any Geotest product. Expand the slot parameter for the GX5282 installed in slots 15 and 17. Assign the alias for the GX5282 in slot 15 to "Stimulus", and the alias for the GX5282 in slot 17 to "Response" (figure 2).

Figure 2: Assigning the "Stimulus" and "Response" alias to the GX5282's

To initialize the instrument based on its assigned alias, use the HW function Long HwPciGetAliasChassisSlot(String sAlias). The HW Device Driver installed with Geotest products provides low-level access and information about resources installed in a test system. Insert the HW.DRV driver into your ATEasy System. The HW.DRV HwPciGetAliasChassisSlot() function returns the slot position of the instrument matching the text string contained in the sAlias parameter, which can be used to initialize the instrument. Additional information about the HW device driver can be found here. The ATEasy code to initialize the GX5282's using their alias is:

gxStimulus: Long
gxResponse: Long

HW Initialize()

gxStimulus=HW Pci Get AliasLegacySlot("Stimulus")
DIO Initialize Master(1,gxStimulus)

gxResponse=HW Pci Get AliasLegacySlot("Response")
DIO1 Initialize Master(2,gxResponse)

In summary, using an alias in place of an instrument slot number provides many benefits, the most important being decoupling the instrument slot position from your test code and providing configuration independent operation of your test program.

Scanning a PXI system to learn about system resources. - Published on 2/4/2010

2/4/2010

When writing test programs, the test engineer is often faced with the task of obtaining information about the instruments installed in a chassis. This information may be essential to the ATE program, or to determine how to establish a communication link between the test program and the test resources. The HW instrument driver can be used to query a PCI-type instrument (PCI, cPCI, PXI, PCIe, or PXIe) and return information about those resources. This article focuses on the how to use the HW device driver for querying the PCI system resources.

The HW driver is a Device Driver that is installed with any Geotest product (PXI Instrument, PCI Instruments, ATEasy, DIOEasy, WAVEasy…). There are many procedures within the HW driver that are useful for determining the system configuration. The HW driver is installed in your machine under Program Files\Geotest\HW. This article will focus on just a couple of them, for more information see the HW folder, HW.h for function definition, and the HW.drv ATEasy driver:

Initialize()

The Initialize() procedure Initializes the HW driver and must be called prior to calling any of the other procedures in the HW library.

PciGetSlotNumbers([Val] Word wVendorId, [Val] Word wDeviceId, Var Short panSlotNumbers[], Var Word pwDevicesFound)

The PciGetSlotNumbers() procedure will return an array of slot number(s) for all devices matching the specified Vendor ID and Device ID.

PciGetSlotDevice(Val Long lSlot, Var structHWPCIDEVICE pstPciDev)

The PciGetSlotDevice() procedure returns device information for the instrument installed in the specified slot. The device information is contained in the structure structHWPCIDEVICE.

The structure of the structHWPCIDEVICE data type is shown below:

structHWPCIDEVICE: Struct Public
{

dwVendorId: DWord
dwDeviceId: DWord
dwBus: DWord
stPciSn: structPciSlotNumber   !PCI/PXI slot number  \
                              (5 low bit: device #, 3 bits: function #, \
                              8 bits: Lgacy slot, 16 chassis/slot : 0x203)
stPciCfg: strictPciCommonConfig
aResDesc: structCmPartialResourceDescriptor[8]
aMemDesc: structHwMemoryDesc[8]
szId: Char[256]

}

structPciSlotNumber: Struct Public
{

dwAsUlong: DWord

}

structPciCommonConfig: Struct Public
{

wVendorId: Word
wDeviceId: Word
wCommand: Word
wStatus: Word
ucRevisionId: Byte
ucProgIf: Byte
ucSubClass: Byte
ucBaseClass: Byte
ucCacheLineSize: Byte
ucLatencyTimer: Byte
ucHeaderType: Byte
ucBIST: Byte
stType0: structPciHeaderType0
dwDeviceSpecific: Byte[192]

}

structPciHeaderType0: Struct Public
{

adwBaseAddresses: DWord[6]
dwSubSystem: DWord
dwSubVendorID: DWord
dwROMBaseAddress: DWord
adwReserved2: DWord[2]
ucInterruptLine: Byte
ucInterruptPin: Byte
ucMinimumGrant: Byte
ucMaxinumLatency: Byte

}

structPxiChassisInfo: Struct Public
{

dwSize: Long                   !Fill with sizeof (PXIChassisInfo)
apcidevBridges: structHWPCIDEVICE[4] ! Bridges in the chassis
wChassisModel: Word            !Chassis model # : i.e. 7010
wChassisRevision: Word
dwChassisSerial: DWord
acUserDefinedData: Char[64]
wNumberOfSlots: Word           !Total number of slots in the chassis

}

structCmPartialResourceDescriptor: Struct Public
{

ucType: Byte
ucShareDisposition: Byte
wFlags: Word
Address1: DWord
Address2: DWord
Address3: DWord

}

structHwMemoryDesc: Struct Public
{

dwPhAddrLow: DWord
lPhAddrHigh: Long
dwLength: DWord
pvVirtualAddress: DWord

}

With these three procedures, you can perform many useful queries that will return information about the hardware residing on your PCI bus, although we are most interested in just the test instreuments. If, for example, you wanted to know how many GX5290 instruments were installed in a PXI chassis, their slot numbers, and the firmware revision of those instruments, you could use the following code:

wVendorId: Word =0x16E2 ! Geotest Vendor ID
wDeviceId:Word=0x5290 ! GX5290 Device ID
anSlotNumbers: Short[32] ! Array of slot numbers found
wDevicesFound:Word ! Number of slots matching the Vendor and Device ID’s
stPciDev: structHWPCIDEVICE
sDeviceInfo: String
i: Long:

Initialize()
PciGetSlotNumbers(wVendorId, wDeviceId, anSlotNumbers, wDevicesFound)
If wDevicesFound<>0
  For i=0 to wDevicesFound-1
    PciGetSlotDevice(panSlotNumbers[i], stPciDev)
    sDeviceInfo= stPciDev.szId
    Print "Slot "+Format(anSlotNumbers[i],"00")+" Firmware: "+Mid(sDeviceInfo, \
              Pos("SUBSYS_",sDeviceInfo)+7,4)
  Next
EndIf

Once the slot number for an instrument is obtained, it would be a simple matter to initialize the instrument using the slot number(s). In the code below, each GX5290 instrument found in the system scan performed above, is initialized as a DIO Master.

nMasterHandle: Short =0
nBrdNum: Short
wSlot: Word
nDensity:Short
nBanks: Short
anHandle:Short[1]
nStatus:Short

If wDevicesFound<>0
  Redim anHandle[wDevicesFound]
  For nBrdNum=0 to wDevicesFound-1
    wSlot=anSlotNumbers[nBrdNum]
    DioSetupInitialization(nMasterHandle, nBrdNum, wSlot, nDensity, \
                nBanks, anHandle[nBrdNum], nStatus)
  Next
EndIf

For additional information, review the HW programming example installed with ATEasy (HW.PRJ).

White Paper: Using PXI Digital Instrumentation for Video Test Applications - Published on 2/1/2010

2/1/2010

Abstract

The use of video imaging and high performance displays has become common-place on virtually all Mil-Aero airframes and weapons systems.
This in turn, has placed new demands on the test systems and instrumentation that are used to test and support these complex systems. In the past, test systems have relied upon “box” video generators to evaluate monitors and displays that might be part of a flight deck’s avionics package. However, with the advent of sophisticated imaging sensors and processors and high-definition video, more advanced techniques and instrumentation are needed.
Today’s test techniques are incorporating high performance digital instrumentation in conjunction with software and specialized “video adaptation” hardware to support the generation and analysis of high definition video signals.

Download the complete white paper

Comparing Structurers in ATEasy - Published on 2/1/2010

2/1/2010

Programming languages typically do not support structure comparison directly. In ATEasy, structures can be compared by converting them to a Variant and then comparing the variants. In ATEasy, when a structure is assigned to a variant, the structure is converted to an array of variant data types, where each field of the structure becomes an element in the array.

A generic structure comparison procedure can be coded as follows:

Procedure CompareStructs(vrStruct1, vrStruct2): Bool
! Compare structs of the same type, return TRUE if equal, FALSE otherwise
--------------------------------------------------------------------------------
vrStruct1: Val Variant
vrStruct2: Val Variant
i: Long
{
! Must have the same number of fields
If VarDimSize(vrStruct1, 0)<> VarDimSize(vrStruct2, 0) Then Return FALSE

! Compare each element/field
For i=0 To VarDimSize(vrStruct1, 0)-1
   ! Test if element is another array/structure
   If VarDimSize(vrStruct1[i], 0)
      ! Re-call CompareStructs() procedure
      Return CompareStructs(vrStruct1[i],vrStruct2[i])
   Else
      ! Test for same data type
      If VarType(vrStruct1[i])<>VarType(vrStruct2[i]) Then Return FALSE
      ! Test for same value
      If vrStruct1[i]<>vrStruct2[i] Then Return FALSE
  EndIf
Next

! structs are equal
Return TRUE
}

Following are example tests to compare two structs of the same type with both Pass and Fail results, and two nested structures with both Pass and Fail results:

Types
================================================================================
strTest: Struct
{
  Field1: Long
  Field2: Long
  Field3: String
}

strTest2: Struct
{
  Field1: String
  Field2: strTest
}
================================================================================

Variables
================================================================================
  st1: strTest
  st2: strTest
  nst1: strTest2
  nst2: strTest2
================================================================================

Tests
================================================================================
Task 1 : "Test Compare Structs"
--------------------------------------------------------------------------------

Test 1.1 : "Struct Compare"
--------------------------------------------------------------------------------
Type = Precise
Value = -1
{
  st1.Field1=1
  st1.Field2=2
  st1.Field3="123"

  st2.Field1=1
  st2.Field2=2
  st2.Field3="123"

  TestResult=CompareStructs(st1,st2)
}

Test 1.2 : "Struct Not Compare"
--------------------------------------------------------------------------------
Type = Precise
Value = -1
{
  st1.Field1=1
  st1.Field2=2
  st1.Field3="123"

  st2.Field1=1
  st2.Field2=2
  st2.Field3="132"

  TestResult=CompareStructs(st1,st2)
}

Task 2 : "Test Compare Nested Structs"
--------------------------------------------------------------------------------

Test 2.1 : "Struct Compare"
--------------------------------------------------------------------------------
Type = Precise
Value = -1
{
  nst1.Field1="Test"
  nst1.Field2.Field1=1
  nst1.Field2.Field2=2
  nst1.Field2.Field3="123"

  nst2.Field1="Test"
  nst2.Field2.Field1=1
  nst2.Field2.Field2=2
  nst2.Field2.Field3="123"

  TestResult=CompareStructs(nst1,nst2)
}

Test 2.2 : "Struct Not Compare"
--------------------------------------------------------------------------------
Type = Precise
Value = -1
{
  nst1.Field1="Test"
  nst1.Field2.Field1=1
  nst1.Field2.Field2=2
  nst1.Field2.Field3="123"

  nst2.Field1="Test"
  nst2.Field2.Field1=1
  nst2.Field2.Field2=2
  nst2.Field2.Field3="132"

  TestResult=CompareStructs(nst1,nst2)
}

Running the Task/Test programs produces the following results:

Test Log Results:

Task 1 : Test Compare Structs
------------------------------------------

#   Test Name          Pin    Unit     Value      Result   Status
--- ------------------ ------ ------ ---------- ---------- ------
001 Struct Compare     -      -         -1.0000    -1.0000 Pass
002 Struct Not Compare -      -         -1.0000    +0.0000 Fail*

Task 2 : Test Compare Structs
------------------------------------------

#   Test Name          Pin    Unit     Value      Result   Status
--- ------------------ ------ ------ ---------- ---------- ------
001 Struct Compare     -      -         -1.0000    -1.0000 Pass
002 Struct Not Compare -      -         -1.0000    +0.0000 Fail*

White Paper: Addressing Instrument Obsolescence - Published on 2/1/2010

2/1/2010

Abstract

Many projects and programs rely upon test systems that were designed at the beginning of a program for on-going system support and maintenance. However, as pro-grams are extended beyond their original life term, the equipment, including test systems, must undergo a modernization phase every few years in order to ensure continued sup-port and maintenance of the system and its sub-assemblies. One of the major issues typically addressed by this upgrade phase is equipment obsolescence. As technology evolves, even programs (and test systems) that were originally designed for a long life term can face obsolescence issues. This paper reviews and compares the options available to program managers and test engineers facing test instrument obsolescence problems. Various options and tradeoffs are discussed including stocking of spare instruments, on-going maintenance & repair of cur-rent instrumentation, replacement through the used market, migration of existing Test Pro-gram Sets (TPSs) to fit a new test system, re-placement using similar products with software or hardware adapters, and replacement using same Form-Fit-Function instrumentation.

Download the complete white paper

White Paper: White Paper: Designing PXI-Based Systems for Field and Flight-Line Applications - Published on 2/1/2010

2/1/2010

Abstract

PXI has become a mainstream test and data acquisition platform in the MIL/Aero market. Numerous programs addressing Depot and Intermediate-level test requirementsnow use PXI as the core of the product.
While the Mil/Aero market and specifically the military would prefer the use of PXI based systems for field and flight-line test applications due to its small size, weight, and cost, the question of suitability needs to be addressed. Is PXI suitable as a platform for field and flight-line applications? Can PXI be used in harsh environments?
This paper addresses these issues and demonstrates how PXI can be used in harsh environments, and how Commercial Off The Shelf (COTS) solutions can replace the once traditional solutions of custom test equipment.

Download the complete white paper

White Paper: A Common Core PXI Test Platform for Factory and Depot Applications - Published on 2/1/2010

2/1/2010

Abstract

The test requirements for the manufacturing and maintenance of military - aerospace components, subsystems, and systems should ideally be addressed by a common test platform. The ability to leverage test programs, fixturing, test resources and even product knowledge all points to the use of a common core platform. However, more often than not, the requirements for supporting and maintaining these assemblies results in specifying and developing completely different test solutions- resulting in higher capital and maintenance expenditures for deployed systems and components. This paper reviews how one can successfully address the test needs associated with both the manufacture and maintenance of systems and components - based on a common core
solution and built around the PXI architecture, which can successfully address both the performance and economics aspects of test. The paper also presents a real world example of how this strategy has been successfully implemented on a current weapons system program.

Download the complete white paper

White Paper: New Ruggedized COTS field tester is an attractive and economic alternative - Published on 2/1/2010

2/1/2010

Abstract

While COTS Test Systems are becoming more widely used in Depot and Second-Level Test Sets, Field-Level COTS Testers are beginning to gain acceptance by Military customers and OEM suppliers. Ruggedized lightweight housings with general purpose COTS cards and backplanes are now serving roles once reserved exclusively for custom dedicated designs. COTS PXI instrument-on-a-card manufacturers are learning how to migrate commercial designs to meet the challenges of first-line testing. These ruggedized COTS testers, offering a wide range of capabilities, are more easily upgradeable and re-configurable than their dedicated counter-parts. They also cost substantially less, making them a technically attractive and economic alternative.

Download the complete white paper

White Paper: Integration of Software Technologies into a Test System - Published on 2/1/2010

2/1/2010

Abstract

Test applications often require integration of many software technologies. The white paper describes the benefits and the ways to integrate software technologies into an application. Several samples are provided:

A specific instrument driver is available only in a particular technology. Re-using or integrating the driver requires using that technology.

The application requires use of external software components to provide additional functionality such as databases to store test results or test requirement, user interface (i.e., ActiveX controls), spreadsheet, test log generation (HTML/XML), data analysis libraries, communication protocols, and more.

Existing or legacy code can be integrated into the current application.

Integration of these technologies will maximize code reuse and will allow faster completion of the test system application. The use of intuitive software can minimize coding, making integration of these technologies possible.

Download the complete white paper

White Paper: Independent Integrator Consolidates Resources - Published on 2/1/2010

2/1/2010

Abstract

Support equipment capability and availability are frequently not primary issues facing recipients of new Military Systems - but they should be! Such support equipment is invariably provided as a part of the Military System field deployment - support equipment whose objective is narrowly defined, and sometimes exclusively focused on the one system, subsystem, or device. Unlike the Prime Contractor (who is motivated to support only their own products), an independent PXI Systems Integrator is sometimes able to consolidate test resources by broadening the mission of the support equipment. Utilizing COTS PXI technology, an Independent Integrator could expand the mission of a Bench-Top Maintenance Tester to include a family of applications, often including UUTs from multiple OEM suppliers, and ultimately save ground support and depot support organizations millions of dollars.

Download the complete white paper

White Paper: Obsolescence Replacement—Applied Technology - Published on 2/1/2010

2/1/2010

Abstract

Equipment obsolescence is a growing concern for both military and commercial test equipment users. Many critical test systems currently in use were designed to remain in service for many years - sometimes even decades - using the most innovative technology at the time. However, as technology constantly evolves, newer, more advanced systems have since taken the place of these legacy systems. In fact, many of the older technologies are no longer in production so when instruments fail, the replacement components may not be available and the instruments become nonmaintainable.
This paper covers the options available to test engineers and program managers facing test equipment obsolescence problems. These include on-going maintenance & repair, replacement through a secondary (used) market, replacement using similar products and software or hardware adapters, re-hosting all existing Test Program Sets (TPSs) to a new target system, and replacement using 100% form-fitfunctioninstrumentation.

Download the complete white paper

Running a batch file or command prompt from ATEasy - Published on 12/23/2009

12/23/2009

The procedure we will be using for calling our batch files is the ATEasy internal function WinExec. Using WinExec causes ATEasy to run a batch file or an executable as an independant child process.

To run a batch file, simply reference it in the WinExec procedure call. The batch file is looked for in several places including the directory in which the project resides. The list of locations and their priorities is located in the ATEasy help files.

! default directory is the directory of execution
WinExec("test.bat")

To clear up any filename ambiguity, you can reference a specific location for the batch file. You can enter the full directory location, but since you are writing a string, you must use escape characters where appropriate (e.g C:\test.bat becomes "C:\\test.bat")

! run batch file in non-default directory
WinExec("C:\\test.bat")

When specifying a location, directories with spaces require quotes around them (e.g. C:\My Documents\test.bat becomes "\"C:\\My Documents\\test.bat\"")

! run batch file in non-default directory (spaces in folder name)
WinExec("\"C:\\My Documents\\test.bat\"")

In these last examples your batch files appeared on the screen while they ran. To get the files to execute in the background, you must pass an optional parameter into your procedure call.

! batch file runs in background
WinExec("test.bat", aformShowHide)

So far we have run the batch files directly. For your purposes, you may want to run your executables through the command prompt. Running the following command opens the command prompt.

! call cmd prompt
WinExec("cmd")

Or, to add some more functionality. We will open the command prompt and run our batch file. Using the /k modifier with cmd.exe causes the window to stay open after completing it's task.

! call cmd prompt to run a batch file and remain open
WinExec("cmd /k test.bat")

Alternately, we can use the cmd.exe modifier /c to have the command prompt close after execution and the ATEasy parameter aFormShowHide to have it run in the background.

! call cmd prompt to run a batch file silently and close itself.
WinExec("cmd /c test.bat", aformShowHide)

Finally, to allow a bit of end-user interaction, we could create a form with a textbox and allow the user to enter the name of the file that needs to be run and any additional parameters. In this example, the name of the textbox would be changed to tbUserInput. On a button click, the user input would be inserted into the WinExec command call as follows.

! call a cmd prompt to run a file based on user input
WinExec("cmd.exe /k " + tbUserInput.Text)

The WinExec function launches the command console as a child process and continues the execution of the ATEasy program in parallel with the command console. If you wish for your program to pause and wait until the command console is close, the following example can be used:

Procedure CommandTest() : Void
h : AHandle
{
     ! assign the window to the AHandle variable
     h=WinExec("cmd")

     ! wait for the window to close
     WaitForSingleObject(h)
}

How the GTX2200/GC2200 Series Timer Counter Gate works - Published on 12/22/2009

12/22/2009

The GTX2200 and GC2200 series timer/counter allows the user to set a gate time through either the software front panel or through a API call GxCntSetGateTime().

The gate will stay open until one full period of the input signal has completed.

If the gate time is set to a value that is less than one period of the input signal, then the gate will actually remain open until one signal period has completed. This is why a valid measurement is obtained when the gate time is set to a value less than the input signal period.

This behavior also explains the "plus up to one signal period" in the gate time specification (GTX2200 Datasheet). If the gate time expires in between a period of the input signal, the gate will remain open until that cycle (period) completes.

An example of this is as follows:
If the gate time is set to 500 uS, and the input signal's period is 200 uS, the gate will actually close at 600 uS, after the 3rd cycle has completed (it will not close mid-cycle at 500 uS).

Therefore the function of the gatetime is to allow the user to force the instrument to oversample an input signal. The instrument does not allow the user to select a gate time that will result in a closure part way through a cycle of the measured signal.

The Measurement Timeout can be set by using the API function call GxCntSetMeasurementTimeout() to make sure that a very slow signal will not cause unnecessary delays in your program.

Calling DLL functions with CDECL callback function parameters - Published on 12/21/2009

12/21/2009

ATEasy can interface with DLL functions that accept call back function pointers as parameters.
When dealing with function pointers, you should keep in mind that there are two types of x86 calling convention, CDECL and STDCALL.

CDECL –The caller will clean up the stack when the function returns.
STDCALL – The called function will clean up the stack when it returns.

If the two calling conventions are missmatched (between the DLL’s function pointer parameter declaration and the passed in parameter’s function declaration), the stack could become corrupted resulting in an ATEasy run-time error.

By default ATEasy will pass in a STDCALL function pointer that wraps around the native ATEasy procedure. This behavior can be changed to CDECL by changing certain options in the procedure’s properties page.

First, you must create the procedure in either the System module or in a Driver module.

Then you must set the procedure’s properties such that the export checkbox is set and CDECL is selected from the drop down menu. Once these properties have been set, the procedure can be passed into the DLL function.

Note: Make sure your procedure's prototype is equivalent to the function pointer prototype of the DLL function's callback parameter.

White Paper: DTIF (IEEE-1445) - Based Digital Test Solution - Published on 10/1/2009

10/1/2009

Abstract

The digital test interchange format (DTIF) is defined by the IEEE-1445 specification and provides a standardized digital data interchange format that can be used with various digital test environments. This standardized format, when used in conjunction with tools for post-processing of DTIF files and appropriate functional test digital hardware, offers a cost effective and viable solution for migrating legacy TPS’s to a modern digital test system platform.

This paper provides an overview of how DTIF files generated by simulator tools such as Teradyne’s LASAR simulator can be used in conjunction with modern digital test post-processing tools and hardware to provide a robust TPS migration strategy for legacy digital test applications including support for Go / No-Go tests, guided probe and fault dictionary functionality. All of these capabilities are supported by the DtifEasy software tool set which can be used with the GX5292 or GX5055 digital instrumentation to re-host legacy applications developed on GenRad, Teradyne, Hewlett-Packard, or Schlumberger functional test systems.

Download the complete white paper

White Paper: Integration of Software Technologies into a Test System - Published on 10/1/2009

10/1/2009

Abstract

Test applications often require the integration of many different software technologies. This paper provides an overview of how several Windows-based technologies can be incorporated into a single application by employing ATEasy's common software framework and architecture. Technologies discussed are DLL, ActiveX/COM, .NET, Function Panel drivers (.fp, VXI Plug&Play drivers), IVI-C and IVI-COM. ATEasy is used to demonstrates several of these technologies.

Download the complete white paper

White Paper: Implementing Serial Bus Interfaces with General Purpose Digital Instrumentation - Published on 10/1/2009

10/1/2009

Abstract

The use of generic digital test instruments for emulating common serial bus protocols can provide benefits over dedicated bus test products, and often presents a trade-off between functionality, flexibility and cost. For example, a dedicated test instrument solution can offer more extensive test capabilities such as protocol support for controlling and analyzing traffic between a bus controller and a device under test. However, a more general-purpose solution that utilizes a digital test instrument can offer the flexibility to adapt to non-standard line rates and timing as well as supporting other digital test needs. This paper presents an overview of how a general-purpose digital I/O instrument such as the PXI GX5290 series of DIO cards can used to support three widely used serial bus interfaces. By using a general-purpose digital I/O solution, users can potentially realize a lower cost test solution, a more compact test system footprint, multi-site test capability, a common user control interface and expandability for future requirements.

Download the complete white paper

White Paper: Consolidating Test Resources for Avionics Production Test – Requirements and Applications - Published on 9/24/2009

9/24/2009

Abstract

The manufacturing and test of avionics products for military and commercial aircraft presents a unique set of requirements and challenges. Historically, the development and deployment of production test systems for avionics products such as aircraft data acquisition and recording systems, navigation and communication products, and aircraft network systems have been addressed on a product specific basis – resulting in a variety of test platforms and solutions with little test system commonality and technology.

Additionally, this lack of test system commonality and the requirement to maintain legacy products with long product life cycles results in increased maintenance and logistics costs for manufacturing and support test. The adoption of a common test platform can offer producers of avionics products lower test costs, improved test resource utilization, and the flexibility to support both new and legacy products. This paper reviews the requirements and the implementation of a common test platform and environment based on the GX7100A PXI 6U/3U chassis and ATEasy. The resulting solution offers a high level of efficiency, supports the implementation of routine test processes, offers reusability, and allows the consolidation of test resources to facilitate the collection of reliability data and test results.

Download the complete white paper

White Paper: Automating Flight Line Testing for Proximity Sensor Maintenance Applications - Published on 9/22/2009

9/22/2009

Abstract

Embedded passive position sensors in various commercial aircraft locations have exhibited substantial failure rates and have resulted in costly turnbacks and delayed flights. Responding to the need to proactively identify marginal sensors prior to failure, Geotest and Alaska Airlines have developed an inexpensive test system that can facilitate the maintenance and troubleshooting of passive flaps and slats sensors for the Boeing 737-400 aircraft. The test system is used during heavy maintenance on commercial aircraft to identify, predict and analyze the failures of these embedded sensors.

Download the complete white paper

White Paper: DATSA Obsolescence Management Approach - Published on 9/22/2009

9/22/2009

Abstract

The AN/GSM-305 Depot Automated Test System for Avionics (DATSA) is an aging Automatic Test Equipment (ATE) used by the U.S. Air Force on the B1B and F-15 programs since the late seventies. Originally built by Emerson, the DATSA systems are now faced with many obsolescence and reliability problems due to the “advanced age” of the systems. While there is no current funded program to replace all the DATSA systems in the inventory, each Air Logistics Center (ALC) is taking the necessary steps to improve the current situation and “patch up” the DATSA for their own local needs. One of these efforts, by Oklahoma City ALC (Tinker AFB), includes extending the DATSA life by replacing key obsolete instruments that can no longer be maintained.
Another effort by Ogden ALC (Hill AFB) led to the replacement of the DATSA altogether with an off-the-shelf tester that already had most of the TPSs for that program. This paper compares these two cases of extending life and complete replacement.

Download the complete white paper

White Paper: Joint Strike Fighter Alternate Mission Equipment Test Set - Published on 9/22/2009

9/22/2009

Abstract

With the Joint Strike Fighter (JSF) program underway, many new airborne products will have to be tested and maintained for the next few decades. The tester selected by the U.S. Air Force to be the standard platform for manufacturing, ESS (Environmental Stress Screening) and depot-level testing is the Lockheed Martin LM-STAR test set. LM STAR is an open-architecture test set with most of the test set’s components being Commercial
Off The Shelf (COTS) products. Using COTS products helps reduce up-front and maintenance costs and simplified the development process. The test set platform is only the beginning and hundreds of Test Program Sets (TPSs) will be developed for the LM STAR in the next decade to support the 3000+ aircraft to be used by the U.S. Air Force and our allies.

Download the complete white paper

White Paper: Instrument Certification as part of a Modular Test platform Architecture - Published on 9/22/2009

9/22/2009

Abstract

The use of modular test systems for depot, intermediate, and factory test applications has increased dramatically in the last two decades. Today, the primary card modular architecture is based on the PCI Extensions for Instrumentation (PXI) standard with thousands of PXI-based systems in use today. The flexibility and configurability associated with PXI has also created new challenges for the calibration and certification of these systems. Historically, the process for re-certification of modular instruments has been to remove and return the modules to the original equipment manufacturer (OEM) or a 3rd party test house, resulting in system down time. However, a better certification method for a card modular architecture is to develop an overall methodology and implementation that allows recertification of modules within the host system. This paper discusses the features and benefits associated with incorporating a PXI-based standards module (GX1034) as the basis for implementing a system level re-certification strategy. By employing a standards module within the system, recertification logistics and maintenance can be simplified, resulting in extended system up time and offering test managers added flexibility for supporting in-house certification of the system and system components. The GX1034 incorporates frequency, resistance and voltage standards and source / measurement facilities allowing the system designer to implement a baseband re-certification strategy for an automatic test system (ATS) platform.

Download the complete white paper

Related Product: GX1034 - Standards Module

Creating ATEasy Controls Dynamically - Published on 6/16/2009

6/16/2009

There are two processes for adding controls to a form in ATEasy, at design time, and dynamically at run time. The topic of adding controls at design time and referrencing the control objects from an array are discussed in Knowledgebase article Q200161. This article is an extension of Q200161 and will focus on using arrays to access controls that were placed on the form dynamically at run time.

The InsertControl() method allows you to create a control during run-time. The syntax is:

[ ctrl = ] Object.InsertControl ( sControlName, sControlClassType, [fLeft], [fTop], [fWidth], [fHeight], [sContainer], [bVisible], [vNameOrIndex] )

A full description of this method, and the associated AddHandler statement can be found in the ATEasy help document. An example of inserting a new GroupBox with eight Switches and a Label onto an existing ATEasy form is shown below. This code duplicates controls that were placed on the form at design time. Note: Code for setting the dynamically created controls properties and creating an event handlers, while not discussed, were included for completeness. The resulting form and controls are shown in figure 1:

Module Variables:

objGB:  AGroupBox
objLBL:  ALabel
aobjGroup:  ASwitch[8]

Procedure:

lWidth:  Long
lHeight:  Long
lPosX:  Long
lPosY:  Long
i:  Long

lWidth=gb1.Width
lHeight=gb1.Height
lPosx=gb1.Left
lPosY=gb1.Top+lHeight+50
i=Form.ControlsCount

!  Add new GroupBox control to form "MyForm" and set the Caption property
objGB=Form.InsertControl("objGB","AGroupBox",lPosX,lPosY,lWidth,lHeight,"MyForm",True,i)
objGB.Caption="Run-Time Controls"

! Add new Label control to form "MyForm" and set properties
objLBL=Form.InsertControl("objLBL","ALabel",170,lPosY+lHeight+10,76,17,"MyForm",True,i+1)
objLBL.Alignment=alblCenter
objLBL.Font.Name="MS Sans Serif"
objLBL.Font.Size=8
objLBL.Font.Bold=True
objLBL.Caption="Byte Value"

! Add eight Switch control to the new GroupBox control and set properties
For i=0 to 7
  aobjGroup[i]=Form.InsertControl("swGB"+Str(i),"ASwitch",343-i*47,41,24,58,"objGB",True,i)
  aobjGroup[i].Caption=""
  aobjGroup[i].OffText=""
  aobjGroup[i].OnText=""
  aobjGroup[i].Style=4
! Add an OnSwitchChange event handler for each new switch created
  AddHandler aobjGroup[i], "OnChange", OnSwitchChange
Next

OnSwitchChange Procedure(objCtrl):

objCtrl:  VAL AControl
lByteValue:  Long
i:  Long

For i=0 to 8
    lByteValue=lByteValue+((2^i)*aobjGroup[i].Value)
Next
objLBL.Caption=Str(lByteValue)

Figure 1 - Design Time and Run Time generated controls

Refer to the Forms.PRG example in the ATEasy Examples.

Using arrays of control objects in ATEasy - Published on 6/16/2009

6/16/2009

When creating a test program that utilizes many controls, often it is desirable to query or manipulate those controls in a controlled sequence, such as a For/Next loop. An example of this might be a group of eight Switch controls representing the value of a binary byte (figure 1). In these instances it is necessary to create an array of control objects that can be referenced using the loop count variable.

Figure 1 - Using switches to enter or display binary values in a program

The typical method for accessing a control is to reference the control by it’s name. If, for example, you created a Switch control, and named that switch object swMySwitch, then to print the switch position (Value) for swMySwitch you would use the following:

Print swMySwitch.Value

But if, as in the example in figure 1, you had eight switches, or 16 or 32, then you would need to reference each switch specifically by its unique name in order to print the switch position:

Print swMySwitch0.Value
Print swMySwitch1.Value
Print swMySwitch2.Value
Print swMySwitch3.Value
Print swMySwitch4.Value
Print swMySwitch5.Value
Print swMySwitch6.Value
Print swMySwitch7.Value

A much simpler approach would be to print the switch positions using a For/Next loop:

For index=0 to 7
Print objMySwitch[index].Value ! Reference switch by array index number
Next

To use an array of control objects, first you must define a variable array to store the objects in. The array variable must be of a Control Object type - refer to the ATEasy Help for a comprehensive list of the standard control types. You can use the generic AControl type object, or you can use the specific control object, like ASwitch:

objMyGeneric: AControl[8]
objMySwitch: ASwitch[8]

The advantage of using the specific control type, like ASwitch, is that all of the properties and methods associated with the control are available using ATEasy's code completion tools.  This is because the ASwitch object uses Early Binding, which exposes all of the properties of an object at design time.  The generic AControl or Object object uses Late Binding and does not display all of the properties of all controls.  Late binding exposes the object to the application at run time, so the properties of the object are not known to the application at design time.  For example, the Value property of an ASwitch control can be accessed via a dropdown list with a variable of type ASwitch, but not with a variable of type AControl.  The Value property can still be referrenced within a program for a generic type control, assuming it is valid for the control object stored in the AControl variable, but you must type the property manually in your program code.

The advantage of using the generic AControl object is that any control type can be assigned to it in a "mix-n-Match" process.  Since not all controls represented in mix-n-match grouping will share the same properties, you can use the ATEasy Try/Catch statement to test for non-existant controls or properties and avoid ATEasy run-time errors.  Refer to the ATEasy help for information regarding Early and Late binding objects.  The remaining examples in the article will use control objects with Early Binding.

Once an appropriate array variable has been defined, then you must copy the control object to the array.  There are two methods for doing this.  The first is to reference the object by it's name, the second is to use the object's Tab Order.  The first method is shown in the code segment below.  An array of type ASwitch is created with 8 elements, then each of the eight ASwitch objects are copied to the array in ascending order:

aobjSwitch: ASwitch[8]

aobjSwitch[0]=swMySwitch0
aobjSwitch[1]=swMySwitch1
aobjSwitch[2]=swMySwitch2
aobjSwitch[3]=swMySwitch3
aobjSwitch[4]=swMySwitch4
aobjSwitch[5]=swMySwitch5
aobjSwitch[6]=swMySwitch6
aobjSwitch[7]=swMySwitch7

This is an inefficient process for placing control objects into an array by name. Fortunately, the Controls() statement provides a much simpler process for referencing an object either by it's unique text name (shown below), or by its Tab Order (discussed later):

i: Long
aobjSwitch: ASwitch[8]

For i=0 to 7
aobjSwitch[i]=Controls("swMySwitch"+Str(i)) ! Reference control by text name
Next

The tab order is the order in which a user moves from one control to another in an application when pressing the TAB key. Each form has its own tab order, and some controls, such as the GroupBox, has its own tab suborder. Usually, the tab order is the same as the order in which you created the controls within an ATEasy form, or within an ATEasy control. However, the tab order can be redefined at anytime using the TabOrder button. Refer to the ATEasy online help for additional information about Tab Orders.

By clicking on the TabOrder button while the form containing the eight switches from figure 1 is active, you can see the current tab order for the switches (figure 2). The order was defined as the controls were created, with the switch on the right representing the LSB and tab order 0. The MSB is tab order 7, and the label with the text "Byte Value" is tab order 8. The tab order can be redefined simply by clicking on the controls in whatever tab order you desire.

Figure 2 - Tab ordering of controls on a form

By utilizing the Controls statement you can take advantage of the tab order to simplify the process of assigning control objects to an array. The Controls statement returns a control object as specified by a given control name or index. The index value is the tab order, so the eight switch control objects can be stored in the aobjSwitch[] array using the simple For/Loop structure shown below:

i: Long
aobjSwitch: ASwitch[8]

For i=0 to 7
aobjSwitch[i] = Controls(i) ! Reference control by tab order
Next

Once the switch objects are stored to the control array, the controls can be used by referencing the array and index, the same as if you used the control directly. For example, if you wanted to calculate the byte value represented by the switch positions, the following procedure could be used:

i:  Long
lByteValue:  Long=0

For i=0 to 7
    lByteValue=lByteValue+((2^i)*aobjSwitch[i].Value)
Next
lblValue.Caption=Str(lByteValue)

Figure 3 - Byte value represented by switch positions

As mentioned previously in this article, some ATEasy controls allow embedding other controls within them. The AGroupBox is an example of this type of control. In this case, the tab order for controls embedded within another control have a sub-index number, or an indented tab order. If you were to place the eight byte-value switches inside a AGroupBox control, the AGroupBox control would have the major tab order, or index value, and each of the switches would have a sub tab order. Assuming the GroupBox control had a tab order of 0, then the switche controls inside the AGroupBox would have a tab order of 0.0, 0.1, 0.2 and so on, up to tab order 0.7, and the Byte Value label which had been tab order 8 is now tab order 1 (figure 3).

Figure 4 - Tab ordering of controls within controls

A new reference level is added for accessing the switch control objects. Since they are now embedded in the AGroupBox, you must reference the AGroupBox control first, before having access to the switch controls within it. This is done by adding another level of the Controls property to reference the GroupBox. The code below demonstrates how to build the array of ASwitch objects from switches embedded in a AGroupBox:

i: Long
aobjSwitch: ASwitch[8]

For i=0 to 7
aobjSwitch[i] = Controls(0).Controls(i)
Next

Refer to Knowledgebase article Q200169 for an example of how to create controls dynamically on an ATEasy form.

How to call a program procedure from the system or from a driver - Published on 6/16/2009

6/16/2009

ATEasy does not allow you to call program procedures directly from the system or a driver as that would make them dependent on specifc programs. Doing so will generate a compiler error. Only one Program module can be active at any time, and it is possible that a procedure defined in one program module would not exist in another module. ATEasy would not be able to resolve this procedure call from the Driver or System module.

The following procedure shows how to call a program procedure from the System or Driver module.

In ATEasy you can call program procedures using procedure variables. For example: If you pass a procedure as an argument to a system procedure, that system can call the program procedure using a procedure variable as shown here:

In the program Program create your procedure ( called 'a' in this example):

Procedure a()
{
!Place procedure code here
}

Create a public System (or a Driver) procedure variable (called m_procA in this example) and at the beginning of your application assign it to Procedure a, as shown below:

Program.OnInit()
{
system.m_procA=a
}

In the system the program procedure can be called as follows:

m_procA()

PCI/PXI Bus Enumeration - Published on 5/28/2009

5/28/2009

The Plug and Play features of the PCI bus were designed to automate the process of allocating resources to PCI devices. A simplifed process of enumeration is as follows:

When a PC is first powered on, the BIOS is loaded and starts the Plug and Play BIOS to enumerate all devices on the PCI bus. Upon boot up, all PCI devices connected to the bus are in an inactive state with no resources assigned and the Plug and Play BIOS must rescan the bus to ascertain what devices are currently present in the system.

The CPU will request the PCI Controller to query each combination of bus, device, and function numbers for a corresponding Device ID and Vendor ID.

If a device is found for the specified bus device and function, the BIOS will read the configuration space for required resources from the device and memory range (Base Address Registers), IO ports, DMA, and IRQ accordingly. If a PCI-to-PCI bridge is encountered, all the devices behind the bridge are enumerated and allocated resources before continuing past the bridge.

The configuration data is recorded in the Extended System Configuration Data (ESCD) file which is stored in non-volatile memory.

If the PCI Controller times out, it will return the maximum value with all bits set high (0xFFFF) indicating that no device was found at the specified device and function number.

When Windows XP boots up, it will check the ESCD file along with the PCI bus to determine if any new hardware was installed. If so, it will start the process of trying to install the correct device driver. Windows will typically leave the hardware configuration up to the BIOS as to not risk exposing latent BIOS bugs by optimizing resource allocation.

The BIOS and Windows work in concert to establish the Plug and Play operation of the PCI bus. The level of control given to Windows can sometimes be changed in the BIOS configuration utility for older motherboards. When the PnP OS option is set to No, the BIOS will configure all PnP PCI devices before Windows boots. If the PnP OS option is set to Yes, then the BIOS will only configure boot critical devices (Hard Drive, VGA etc.) and leave the rest of the configuration to Windows. ACPI compatible (newer) motherboards do not provide this option.

The following is a screenshot of the Geotest PCI/PXI Explorer showing the enumerated PCI devices and their respective resources.

Reference Knowledge Base Article Q200132 for information on how to resolve PCI resource allocation errors.

How to repeat a test based on the TestStatus variable - Published on 5/18/2009

5/18/2009

There are a number of ways to repeat a test based on the value of a variable. This example will use the OnEndTest event to repeat test 4.2 up to three times if the test fails. Code in the OnEndTest Event will run at the end of every test, so if the retry is only required on specific tests, then the OnEndEvent code should check for the specific Test Number(s) to prevent retrying all the tests in the application. This example assumes that if Task# 4 Test# 2 fails, then it should be rerun a maximum of 3 times or until it passes. In this example will use a global varaible (m_iTestCount) to keep count of the test retries. A constant iCount will be used to indicate the maximum number of retries.

Program Global Variables:
! First declare iCount as a Short Constant and give it a value of 3
m_iCount: Short Const = 3 ! Limit the number of retries to 3
m_iTestCount:  Short

Procedure Program.OnEndTest() ! Event
{
if Test.Number = "4.2"   !Check if this is Test Number 4.2

    ! Check if the test has failed and the number of retries is less than iCount-1
    ! Remember the test has already been run at least once at this stage
    if TestStatus=FAIL AND m_iTestCount < m_iCount-1

           ! Increment the m_iTestCount variable to track the number of retries
           m_iTestCount=m_iTestCount + 1

           ! Rerun the current test. Remember Index is zero-based
          Task EndEvents Task.Index+1, Test.Index+1

          m_iTestCount = 0

    EndIf

Endif
}

Calling a DLL Function with Variable Parameter Lists from ATEasy - Published on 4/28/2009

4/28/2009

Sometimes it is desirable to create and use C/C++ functions within a DLL, that accept a variable number of parameters instead of a fixed set of parameters.

ATEasy supports use of such a function and calling it from within your test program.

The first step is to insert the appropriate DLL into your ATEasy project.

You will then need to manually define the DLL function you wish to use by inserting a new procedure in the DLL sub-module.

After inserting a new DLL procedure, select CDecl from the type drop down list of the DLL procedure properties page. CDecl is an x86 calling convention that requires the calling function to clean the stack after the called function returns, allowing a variable number of parameters to be used.

Define all the fixed parameters as you would normally.

When you get to the variable list, use the Any parameter type. Define as many Any parameters as you would expect to use in your variable list and mark them as optional. These optional parameters will serve as the variable list interface. Use Val Any type parameters to push parameters to the function (pass by value) or Var Any type parameters to push a pointer (pass by reference).

Please refer to Tests 6.8 and 6.9 in the Language.prg example program for more information on implementation of variable parameter lists for sprintf and scanf.

Note: In order to use a variable parameter list, the DLL must be built using the CDECL convention. Please reference the Microsoft knowledge base article:
Microsoft KB Article

You must also have ATEasy 6.0 Build 136 or greater installed (Val/Var Any changes are required for this to work).

How to retrieve Windows Environment variables in ATEasy - Published on 4/28/2009

4/28/2009

There are several methods that can be used for retrieving Windows environment variables
1) Using the .NET Framework Environment class and
2) Using the Windows API GetEnvironmentVariableA() function

1) Using the .NET Framework Environment Class:

Note: If you do not have the .NET Framework installed on your computer it can be downloaded and installed for free from the Microsoft web site or by using Windows update.

To use the Environment class, first right click on the Libraries submodule in your program and select Insert Library Below. Click on the .NET Assemblies tab and scroll down to mscorlib. Expand mscorlib and scroll down to System. Expand System and scroll down to Classes. Expand Classes and check the box beside Environment. Then select Insert. ATEasy will automatically insert the Environment Class into your program. Now define a string variable (called sEnvironVar in the example below) that will be used to store the Environment variable.

! The following example will find the value of the Windows Environment variable COMPUTERNAME.
! First declare sEnvironVar as a String variable
! Get the Windows Environment variable COMPUTERNAME
sEnvironVar = Environment.GetEnvironmentVariable("COMPUTERNAME")
Print sEnvironVar !Print COMPUTERNAME

2) Using the Windows API GetEnvironmentVariableA() function

To use this function, first right click on the Libraries submodule in your program and select Insert Library Below. Click on the DLL tab. For the DLL Filename select kernel32.dll from the Windows\System32 folder and select Insert. ATEasy will insert the kernel32 library into your program. Then under the library procedures define a procedure:

GetEnvironmentVariableA(sName: Val String, psBuffer: Var String, dwSize: Val DWord) : Public DWord.

When you call this function make sure to allocate the psBuffer string parameter (use SetLen).

! This example will find the value of the Windows Environment variable COMPUTERNAME
! First declare sEnvironVar as a String variable
! Allocate an appropiate amount of memory to the sEnvironVar string parameter
setlen(sEnvironVar,512)
! Get the Windows Environment variable COMPUTERNAME
GetEnvironmentVariableA("COMPUTERNAME", sEnvironVar, 512)
Print sEnvironVar ! Print COMPUTERNAME

White Paper: PXI - The Future of Test - Published on 4/14/2009

4/14/2009

Abstract

As commercial and military electronic technology evolves so does the need for more sophisticated, reliable, and cost-effective test equipment. The new PXI platform fills this gap and provides the ultimate test solution for field, laboratory, or manufacturing test applications. This paper discusses the evolution of test that led to the development of the PXI standard and provides technical information of the PXI Bus.

Download the complete white paper

White Paper: PXI for Military Test Applications - Published on 4/14/2009

4/14/2009

Abstract

As PXI is gaining in-roads into military test applications, systems integrators start using the PXI platform as the core of military testers for manufacturing, service, and field test. This paper discusses two such applications. The first is a production tester used in the manufacturing of the Longbow launcher and the second is a portable field tester for the Maverick Missile System.

Download the complete white paper

White Paper: Military and Field Test Applications Using Modified COTS Products - Published on 4/14/2009

4/14/2009

Abstract

Field test for military and industrial applications requires special test equipment that meets stringent environmental requirements. These test applications require hardware that can provide high-performance and capabilities, yet be portable and rugged to ensure usability in the field. Typical environmental requirements include extended temperature range, shock & vibration, altitude, humidity, salt-fog, explosive atmosphere, EMI/RFI and more. The required levels are in most cases higher than those provided by Commercial Off The Shelf (COTS) equipment, which dictates a different approach by the tester designer. This paper discusses design approaches for such testers or data acquisition systems and advocates the use of modified COTS as the preferred solution.

Download the complete white paper

White Paper: Next Generation COTS Test Systems - Published on 4/14/2009

4/14/2009

Abstract

This paper surveys card-to-card coordination, synchronization, triggering, and cross triggering in PCI eXtensions for Instrumentation (PXI) commercial off-the-shelf (COTS) systems. It provides an overview with some design guidelines for COTS designers and offers some suggestions to system integrators.

Download the complete white paper

White Paper: Testing MicroProcessor-Based Boards - Published on 4/14/2009

4/14/2009

Abstract

Testing Microprocessor-based boards (µP) could be a challenge even for the experienced test engineer. This paper reviews the related challenges and available test philosophies for the functional testing of these products.

Download the complete white paper

White Paper: Integrating VISA, IVI and ATEasy to Migrate Legacy Test Systems - Published on 4/14/2009

4/14/2009

Abstract

New software technology, such as Interchangeable Virtual Instruments (IVI), benefits customers of Automatic Test Equipment by reducing cost of ownership. The costs of rehosting test program software due to obsolescence issues can be reduced by using application development environments such as ATEasy and IVI. ATEasy provides the means of changing instruments and test system resources similar to IVI via its interchangeable Instrument Technology (I2T). IVI further allows the customer end-user to make the change without compiling the application, as ATEasy would require. Bycombining the power of both technologies, both the customer and the integrator benefit from maximum flexibility and options for instrumentation obsolescence.
This paper discusses the issues and concerns in applying this strategy to a deliverable test system. It discusses some of the obstacles and "speed-bumps" that were overcome during development. Although IVI has been around for over 5 years, it's still a new technology and early adopters will have the work around issues such as driver availability, varying levels of support by equipment vendors, and the lack of experience in the industry applying IVI.
The ATEasy environment can leverage the current, state-of-the art technology while positioning the user and integrator for the future.

Download the complete white paper

White Paper: Migrating an Electro-Optic Test Bench to PXI - Published on 4/14/2009

4/14/2009

Abstract

This paper describes how the Electro-Optic Test Bench ground support test equipment for the TOW Missile has been pressed into extended service even though it is not supported and is obsolete. A new COTS PXI-based test system and optical bench has been designed to replace the obsolete test set for all versions of TOW.

Download the complete white paper

Using Trigger Mapping on the GX7XXX Smart Chassis - Published on 3/26/2009

3/26/2009

One of the capabilities that differentiate a test and measurement instrument installed in a PXI chassis from traditional rack-and-stack instruments and instruments installed in a PCI mainframe, is the addition of the PXI trigger bus.  This bus facilitates a more tightly integrates suite of instrument by allowing PXI-based instruments to synchronize operation using common clocks and triggers, without the need for external wires or cables.  However, due to the nature of the PCI bus, and by extension, the PXI bus, bridges are required to link bus segments together when more than 8 devices are installed on the bus.  The PCI bridge extends the computer data bus, but does nothing about extending the PXI trigger bus across multiple bus segments, which is necessary to maintain the synchronization capabilities designed into the PXI bus across the full backplane.

Early introductions of PXI chassis' accommodated extending the PXI trigger bus by using jumpers on the chassis backplane to enable triggers and set the direction control of the trigger signals between bus segments.  If for any reason the trigger bus ever needed to be reconfigured, the chassis would have to be powered down, instruments removed to gain access to the backplane jumpers, and the jumpers manually reconfigured to accommodate the new triggering requirements.  This dated technique is still used by many PXI chassis’.

With the introduction the Smart Chassis series from Geotest, this dated methodology has been replaced with software control for mapping and enabling PXI triggers across bus segments.  Trigger mapping can now be set using software commands or virtual instrument panels, all while the chassis is powered on and instruments installed.  Geotest chassis’ that include this “Smart” feature are the GX7000A, GX7100A, GX7300 and GX7600.

To configure trigger mapping you must have the appropriate chassis DLL driver installed and be connected to the chassis using either an embedded controller or a PXI bus extender connected to an external host PC.  To manually set the trigger direction, launch the Chassis Panel application by selecting GxChassis Panel on your desktop or from the Windows Start Menu.  Click on the Initialize button and follow the directions for initializing the chassis (figure 1).

Figure 1 - Generic GX7XXX Chassis Panel

From the main panel select the PXI Trigger Lines tab. The PXI Trigger Lines tab will reflect the number of slots available on the chassis being controlled. The GX7000A and GX7300 each have twenty (20) slots (figures 2 and 3, respectively), the GX7100A has fourteen (14) slots (figure 4) and the GX7600 has nine (9) slots (figure 5).

Figure 2 - GX7000 Chassis Triggers Tab Figure 3 - GX7300 Chassis Triggers Tab

Figure 4 - GX7100 Chassis Triggers Tab Figure 5 - GX7600 Chassis Triggers Tab

The screen indicates which slots are the primary slots and which slots are the secondary slots associated with each bridge. The chassis will continuously monitor the state of the triggers on all of the bus segments and report them via the panel as either a logic "0" or a logic "1". Each bridge between bus segments provides three controls for each trigger line. Simply click on the desired control and a drop-down list will be presented that allows you to select the appropriate parameter:

Direction Control - Direction of the trigger mapping:

NC Trigger Mapping Disabled)

L -> R Primary to Secondary Mapping

L <- R Secondary to Primary Mapping

Primary Control / Secondary Control - Define whether the trigger is passive (monitored only) or actively driven by the chassis:

X Monitor only, driven by instruments installed on that bus segment

0 Force trigger line to logic "0"

1 Force trigger line to logic "1"

blank Monitor only, mapped to (driven by) the opposite bus segment

Once all of the triggers have been mapped for each bridge, the settings can be saved to EEPROM by selecting the Temperature Settings tab and clicking on the Save User Settings button, as represented by the GX7300 panel in figure 6. Once saved, the user defined PXI trigger mapping can be restored manually by clicking on the Recall User Setting button on the Temperature Setting tab, or automatically on power-up by clicking on the Recall User Settings radio button under the Load Settings On Power Up control group. Be sure to save user settings each time you change the Load Settings On Power Up control or the new selection will not be remembered during the next power cycle.

Figure 6 - Save/Recall User Settings

Setting of the PXI bridge trigger mapping can also be accomplished programmatically using the GxChassisSetPxiTriggerLine function, and the GxChassisGetPxiTriggerLine function can be used to query the current trigger mapping settings . The format for these functions are described fully in the GX7XXX User Guide:

GxChassisSetPxiTriggerLine (nHandle, nLine, nSegment, ucDirection, nPrimaryMode, nSecondaryMode,pnStatus)

GxChassisGetPxiTriggerLine (nHandle, nLine, nSegment, pucDirection, pnPrimaryMode, pnSecondaryMode,pnStatus)

The Load Settings On Power Up parameter can be set programmatically using the GxChassisRecallSettings function. The format for this function is described fully in the GX7XXX User Guide:

GxChassisRecallSettings (nHandle, nSettingSource, pnStatus)

Support for ECL / PECL Logic Levels - Published on 3/25/2009

3/25/2009

Instruments that provide PECL interfacing are the GX5050, GX5150 and GX5152, provide they are configured with the GX5940 PECL I/O module. The GX5280 Series or the GX5290 Series do not have support for PECL.

ECL (Emitter Coupled Logic) and PECL (Positive ECL) are both differential I/O interfaces and are not compatible with single-ended logic families. ECL logic is designed to work with negative power supply levels, and the normal logic levels for ECL are:

V(OH) = -0.9 V
V(OL) = -1.7 V

The term PECL means we are using ECL logic but with Positive power supply voltages. The normal logic levels for PECL are:

V(OH) = 4.1 V
V(OL) = 3.3 V

The GX5280 and GX5290 series Digital I/O instruments support two types of logic interfaces, Programmable LVTTL and LVDS – except for the GX5291, which supports only Programmable LVTTL levels. Neither LVTTL nor LVDS are compatible with ECL or PECL logic.

LVTTL is a single ended I/O standard with output levels programmable in the range of:

Min: 1.4V
Max: 3.6V

This is compatible with TTL/LVTTL/CMOS/LVCMOS logic families.
The input thresholds for the LVTTL interface is selectable:

1.5 V, 1.8V, 2.5V, or 3.3 V (all are 5V tolerant)

LVDS is a differential signal, similar to ECL and PECL, but the levels are incompatible with either ECL or PECL. The levels for LVDS/LVDM/M-LVDS are:

Differential Output Voltage:
480mV (Min.); 650mV (Max.)
Input Threshold:
Positive going threshold: 50mV (Max.)
Negative going threshold: -50mV (Min.)
Input voltage hysteresis: 25mV (Typ.)

Using WaveEasy with the GX1110 Arbitrary Waveform Generator - Published on 3/25/2009

3/25/2009

WaveEasy can interface with the Geotest GX1110 Arbitrary Waveform Generator software front panel, allowing users to create waveforms using the powerful waveform editor and then downloading the wavefform into the GX1110 memory to generate the wave. The following steps described the process:

1. Create either a standard waveform, a complex mathematical function, or a free hand waveform within WaveEasy. Further information on using WaveEasy to create waveforms can be found in the GtWave Manual.

2. Open the GX1110 Software Front Panel from within WaveEasy; Select GtWave Panel from the WaveEasy Tools menu or click on the GtWave Panel button in the toolbar as shown here:

The GtWave Panel will be displayed:

3. Initialize the GX1110 Software Front Panel and select Arbitrary Waveform Generator from the Operation Mode drop down list:

4. Enter the ARB Start Address (typically 0) and the Length (number of samples) of the waveform you created in WaveEasy:

5. Select [! WaveEasy as the source for loading data and enter the Start (Start pointbv typically 0) and the number of points (Points) you would like to load (typically the waveform size as noted in step 4). Then click Execute:

6. Now the waveform data has been loaded from WaveEasy to the GX1110. Make any changes to the set up of the GX1110 such as amplitutde, sample rate, etc. and click on Apply. Check the Output Enabled box to prepare for output.

7. Use the Run button to start generating the wave, and Stop button to suspend the waveform output:

GX5290 or GX5280 Series Causing Windows Code 12 Error Indicating Insufficient Resources - Published on 1/13/2009

1/13/2009

When using multiple GX5290 and/or GX5280 DIO devices, Windows might not be able to allocate enough contiguous memory resources causing the OS to generate an error code 12.

The code 12 error is caused by a limitation in the PC's BIOS and PCI memory allocation system. Each DIO card requires 16MB of PCI of contiguous memory space to map to the DIO's internal memory structure.

To fix this issue, change the BIOS settings and disable unused peripherals such as LPT1, COM (serial) port, built in audio, and shared graphics memory. This will free up enough resources to allow BIOS and Windows to allocate memory correctly.

You should also update your system with the latest BIOS version.

ATEasy v6.0 SP2 (build 136) - List of changes - Published on 1/12/2009

1/12/2009

The following changes were done since build 132:

ATEasy v6.0 build 136b, November 2008

Check All/Check Module does not check if data type of variables, procedures and types is undefined.

"Too few elements" error message when setting the array initial value with smaller number of elements in the variable property page. ATEasy allows to initial the array with smalller number of elements than what defined in the array.

.NET set-only properties are rejected when loading the assembly.

Assigning Variant to array of enumerated type generated an exception.

TestExec. Prompt On Failure does not prompt unless Pause on Failure was checked.

AChart. Current bar value for HiLo Horizontal Bar chart were not drawn correctly, it was drawn vertically instead of horizontally.

Unable to load a driver saved in build 136/142 with WinSocket interface.

New ATEasy.EXE command line option /s used with /b to suppress the error message that is displayed if the build results in error.

ATEasy v6.0 build 136a, October 2008 (intermidiate build)

When inserting the TestExec driver it create TestExecA shortcut name instead of TestExec.

Passing array of BString to COM method VAR BSTR[] does not work.

Passing array element to Var parameter of late-binding COM/.NET method does not work.

Comparison operands with Variant and unsigned integer returns wrong result.

Passing Var String parameter to an error statement generates an exception.

Passing CreateThread a form procedure generate exception.

VarDimSize() lDim parameter is now optional (0).

Setting AForm.OnQueryUnload pbCancel to TRUE does not keep the form when exiting a a catch block.

When inserting a variable under procedure the workspace displays the procedure variable mistakenly.

Project EXE/DLL file path is relative instead of absolute if not overrode by the user from the Project property page.

TestStatus=ERR terminate the application.

Setting AForm.OnQueryUnload pbCancel to TRUE does not prevent the form from close when exiting a a catch block inside a try statement.

ATEasy v6.0 build 136, August 2008 (service pack 2)

Includes all issues (see below) since build 132 (service pack 1) was release.

New propery AApp.Info property and new type enumAppInfoApp. The property is similar to App.Flags however it retuns a single flag. Two new flags were added aAppInfoIdeAbort and aAppInfoIdeReset indicating True if the user press the IDE abort or Reset command.

Fix. Test executive exit if the abort / reset statements called from within the program (134c issue).

Fix. Test executive did not display fail statistics when abort.

Fix. Type/COM Library display to show void * as Val Any and void ** as Var Any (in both cases address of the variable is pushed).

Fix. #ifdef work also on symbols (variable, types, procedures) and can be used to test if they exist.

Compiler error is generated if passing Const or literal to Var Any.

Fix. Calling a module event in DoIt! mode sometimes ignored.

Fix. VarChangeType/Str did not work properly with BYREF variants.

Fix. ATEasy generated exception when cleaning up a parameter after a DLL call with NULL BString.

Fix. Improved error handling for operation and assignments when using variant data types containg unsigned integers that are unsupported by ole automation.

Fix. New statement for COM or .NET class does not work if the class resided outside of the current module.

Fix. Opening a text format driver file with discrete I/O operations did not read the discrete file correctly resulting in removal of the discrete values.

Fix. Assignment statement between a method or a property to a procedure type variable resulted in NoProcedure.

Fix. Assignment statement between a module event to a procedure sometimes generates NoProcedure.

Fix. Assignment statement between a module event to a procedure sometimes resulted in NoProcedure.

Fix. Opening a workspace files from Windows Explorer sometimes generated an exception.

Fix. Compiling a reference to a .NET class virtual property generated an exception.

New support for Variant data types with VT_Ux (unsigned integers) for operators such as add or subtract. Support for these types also expanded for older Windows (e.g. Windows 2K).

New HW v3.1 (PCI/PXI explorer and hardware access driver) is included in this release - more information is available under Program Files folder, Getotest\HW, ReadMe.txt.

ATEasy v6.0 build 134c, April 2008 (intermidiate build)

DLL Procedure view display the procedure vertically centered next to the +/-.

Task/Test property page will rename the task/test name when untitled base on the task/test title.

Form with many controls are slow to draw in design time.

Changing Tab Order after run and running again genrate exception.

Changing title or name of a symbol not always reflected immediately in the Properties window title.

Startup dialog does not enable the OK button in the Recent page if no recent files are available in the list.

ATEasy About dialog displays the product Serial Number.

Variables initial value is shown in the Properties Value page for types such as DateTime, Double and more.

Viewing a Program DLL Constant value caused it value to be deleted after importing the DLL from header file.

Importing string constant from a hedaer file added extra space to the string.

Deleting a procedure variable from the command view is not updated in the command view procedures view.

Some third party controls (such as Microsoft TreeView, ListView) do not anchor correctly after its parent form or container is resize.

ATEasy generate exception when calculating watch expression with Late Bind expression with typedef return (for example AHandle).

On Empty Workspace, Print Document\Selection Enabled instead of disable.

Unable to set the software license on Vista with user Access Control On.

Loading text format module that have command arguments with function calls corrupt the command argument

Commands displays a procedure in the parameters box instead of no procedure when the top level command is selcted (i.e. Driver)

Improvments to import C/C++ header file.

Improvements to performance of ComRecive/SetInterfaceEvent.

When IDE Reset command is executed. OnReset events are called prior to reloading the application.

Toolbar button stays pressed when a combination of buttons is pressed.

Creating MDI child on a different thread than the MDI frame generate exception.

New support for Val/Var Any to DLL procedure to push Value/Pointer instead of just Pointer.

New examples in Language.prg to show calling sprintf and sscanf using optional Var/Val Any.

Optional [Val] Any not passing Null for second level procedure with [Val] Any parameter.

Optional [Val] array did not allocate one element for each dimension if an array was not passed as an argument.

Assigning lLong=vVariant[2] failed while dDouble=vVariant[2] is OK (vVariant contains array of LONG).

COM Interface with Xon/Xoff handshake not working properly when set from the driver property page (ComSetup does work).

SetLogString() with no argument generate exception.

AImageListImage.ExtracIcon changed to AImageListImage.ExtractIcon.

AImageListImage.ExtractIcon generate exception if Icon not exist.

InputBox/MsgBox window is not using the Windows MessageBox font and sometimes is displayed behind the application window.

AForm.RemoveControl/AForm.RemoveMenu returns Bool value change was reverse to void since causes compatability issue with EXE files.

Internal Error after when event set by AddHandler is called on a form procedure and the procedure calls another control event.

After editing of a test exec profile, the profile will be reloaded if being used by the test executive.

Fault Analysis condition string size limitation increased to 5K.

Test Executive Log Word Wrap is to True to allow longer text not to clip.

Several improvements to the profile action, count and conditions.

New HW v3.0 (PCI/PXI explorer and hardware access driver) is included in this release - more information is available under Program Files folder, Getotest\HW, ReadMe.txt.

New drivers: GX1034, GX2002 and GX2472.

Build 134b November 29, 2007 v6.0 (intermidiate build)

ATEasy now traps exception generated by a DLL when DLL is unloaded

Test Executive/Profile forms for Select Program/UUT/Profile are sizable

AForm.RemoveControl/AForm.RemoveMenu returns Bool with False if an error occured

New drivers GX5290 (GX5292)

Build 134a November 2, 2007 v6.0 (intermidiate build)

GetCallerName - new internal function to return the caller procedure procedure name or test id

Support for Right to Left or non-english Locale:

When Form.RightToLeft is TRUE, menu, statusbar, and toolbar are displayed from right to left
All controls will display text using the current system locale
property pages for controls will display text using the current locale
Form.RightToLeft can be set at run-time (not read-only property)

New Variant constants: VarEmpty, VarErrorArgMissing,

DebugLog can be set at run-time (not read-only property anymore)

ATEasy v7.0 - List of changes - Published on 1/12/2009

1/12/2009

ATEasy version 7.0 contains numerous enhancements to the test development environment, run-time and Test Executive. The following list describes the main changes in this version.

Development Environment

ATEasy DLL - ATEasy supports creating a DLL from ATEasy code. The new Library Wizard creates a Library DLL project. Export commands supports generating of .vb/.h header files with prototypes of the functions exported by the DLL so they can be called from C or Visual Basic languages.

Threads Window - a new debug window for debugging a multi-threaded application. You can use the Threads window to view thread information - call stack and local variables.

Batch Build - a new command that displays the Batch Build dialog allowing you to select multiple workspace projects for build. The selected projects are saved to the workspace file.

Back/Forward navigation commands - these new View commands use the history of windows and symbols viewed and allows you to navigate between these symbols. Similar to Internet Explorer, a drop down history lists all symbols viewed in the ATEasy session.

New Log file format, Web Archive Single File format (.mht) is available in File Open as well as in ALog's Save and SaveAs methods for Log files.

ATML support - provides functions to export and import ATEasy test results and test descriptions in ATML format (.xml).

Support for LabView v8.5, v8.6 (all versions from 7.0 to 8.6 are now supported) and enhanced support for .NET.

Support for USB driver interface - provides control of USB RAW or TMC devices using IO Tables or the internal library.

New IDE Workspace Option for default file saving - Binary and Text format saves in both file formats every time the user saves . Allows you to maintain an up to date text format that can be used by external tools such as text editor or a source control application.

New IDE Options: Arguments for External Tools - a set of predefined variables that are available for invoking External Tools. The Customize Tools dialog has been modified to accept new arguments and their values are passed when the tools are launched.

New IDE Option Auto Recover - this new option, when set, will cause ATEasy to save your work (modified files) every x minutes to a temporary location. When the workspace is loaded again after a system or any other failure, ATEasy will notify you of the modified files that are available for recovery.

New IDE command: Open Containing Folder - opens a folder in Windows' Explorer which contains the selected file.

New ATEasy Development Environment automation server (Application) - provides access to some of the IDE functionality.

Run Time Engine

New LoadLibrary/UnloadLibrary statements for dynamic loading and unloading of DLL libraries while running.

New USB procedures to control USB RAW or USBTMC devices and support for USB driver interface.

New String tokenizer functions : Split, Join, Filter, Replace.

New Math functions - Min and Max returns the minimum or maximum value of two numbers.

New Misc function - GetCallerName used to retrieve the current or caller procedure name or test id.

New Time functions: Now, Date, Time, Year, Month, Day, Weekday, Hour, Minute, Second.

New ATask/ATest properties StartTime and EndTime.

New AApp.Info property and enumAAppInfo returns information about the application.

New Variant constants VarEmpty and VarErrorArgMissing and support for 64 signed and unsigned bit variant integers.

Support for converting a string to DateTime/Currency data types and vice versa.

New optional parameter added to CreateObject() : bFreeThreadingModel. Allows the user to specify the server's threading model to be Free, instead of the Apartment model.

New HW v3.1 (Geotest PCI/PXI explorer and hardware access driver) is included in this release to support VISA, multiple PXI chassis, USB and more. More information is available under Program Files folder, Getotest\HW, ReadMe.txt.

Test Executive Enhancements

External Programs (EXE) Support - Unlike a typical project containing all test programs, supports for external programs allows you to create executables, each containing one (or more) programs, while still allowing all programs to run from the same user interface. The main benefit is the support for modular test program development which allows adding programs to the test executive after the initial release of the application.

Profile driver - create and modify test sequences or profiles programmatically using commands.

Support for Web Archive Single File (.mht) - allows the user to save an HTML test log containing images into a single file.

Ability to disable checking or un-checking of tests and tasks in the tree pane.

New Option to show or hide the Log Summary tab (enOptionsDisplayLogSummaryTab).

New Option to retry a failed Task automatically (enOptionsRetryFailedTask).

See the Test Executive Help for detailed information regarding these new features.

New Examples/Drivers

ATEasyDLL.prj - this example shows how to create an ATEasy DLL and how to use the DLL from ATEasy code or from a C or VB based application.

Profile.prj - this example shows how to use profile commands to create a profile programmatically.

Visa.prj - VISA driver and example - this example shows how to use VISA to control an instrument from ATEasy using the ATEasy Visa.drv driver.

ATML.prj - this example shows how to use the new ATEasy ATML driver (ATML.drv) to export and format test description and results.

Ki210x.prj - driver/example for USB based driver Keithley 2100 DMM.

New Geotest drivers for GX1034, GX2002, GX2472 and GX5290.

List of changes in GTDIO/DIOEasy Software version 3.20 build 42 - Published on 12/8/2008

12/8/2008

GTDIO/DIOEasy Version 3.2 Build 42 (December 2008) Change List

  - Hardware Support Changes:
  - New support for the GX5055 DIO board.
  - New support for the GX5291 DIO board.
  - GtDio versions 3.1 (Build 40) and above does not supports the GT5900, GT2550 and GT5150
    ISA boards anymore, use GTDDIO v3.0 to control these cards.

  - Fixed issues:
     • Driver:DioSetupClkStrobeDelay() returns an error when the handle passed into the function is a File handle.
     • DIOEasy: Gx529X and Gx5055 file types would crash when trying to copy and past channels.

  - New driver (Firmware) functionality:
     • Gx528X/Gx529X:
       - Additional offset (advance or delay) of -3.0 to +3.0 nSec (0.25 increments) was added
         in order to ease timing alignment between DIO boards in a domain. See DioSetupClkStrobeDelay()
         function in the "DIO Programmer’s Reference Guide".
      • Gx529X:
       - Firmware version 0x8A00 and above allow reading the I/O pins data when the card is in PUASE/HALT state.
       - Firmware versions 0x8A00 and above integrates high speed memory read back operation.

  - New driver functions:
     • DioSetupExternalRefClkFrequency() - sets the External refernce clock frequency.
     • DioGetExternalRefClkFrequency() - returns the External refernce clock frequency.
     • DioFileSetChannelsOrder() - sets all 32-channels logical order in a DIO file.
     • DioFileGetChannelsOrder() - returns all 32-channels logical order in a DIO file.

  - DIO Virtual panel:
     • Support configurations using VISA and new multiple chassis slot numbering as
       well as legacy slot numbering.
     • Cut execution time for upgrading DIO's firmware.
     • Add Domain Setting Save and Recall - allow the user to save/recall the domains
       timing calibration settings after calibrating the clock and strobe delays between
       boards in the domain.

  - DIO User's Guides:
     • Update all User's Guides "Chapter 3: Installation and Setup" to reflect the
       support for the new HW v3.0 (PCI/PXI explorer and hardware access driver).
     • Update the "DIO Software User’s Guide" with the latest DIO panel description
       and Configuration.

  - Examples
     • New C example named "GtDioExampleC" supporting all PXI/PCI DIO boards.
     • New VB 6.0 and VB .NET 2005 examples.
     • New Microsoft Visual Basic .NET (2005) GtDio COM Object example.
     • New LabView library and examples.

  - New HW v3.2 ](PCI/PXI explorer and hardware access driver)
  - The new HW v3.2 is included in this release to support VISA, multiple chassis and more -
    more information is available under Program Files folder, Getotest\HW, ReadMe.txt.
    The new HW provides the following new/revised functionality:
    • New function, DioSetupInitializationVisa() - initializes the board using VISA, use VISA
      resource string or alias (configure using HW PXI Explorer) to identify the board
     (require NI-MAX).
    • GtDio boards are shown in VISA resource manager (NI-MAX), using HW v3.1.
    • DioSetupInitialization() function supports multiple chassis slot numbering (for example
      0x203 - chassis 2 Slot 3) as well as legacy slot numbering (1-255) as displayed
      in HW v3.1 PXI/PCI explorer.

Should OCLK and CLK_LVDS have the same phase? - Published on 12/2/2008

12/2/2008

CLK_LVDS (J4-P4 and J4-P38) and OCLK (J3-P22) are sourced from different PLL outputs within the DIO's FPGA, so it is possible for them to have different frequencies and different phase settings. Even if the phase settings are the same for both clocks, the actual phase observed at the output will be different since the respective signal paths are quite different.  Due to the programmability of it, the OCLK goes thru added logic, such as dividers, delays and an external buffer IC. The LVDS clock exits the PLL and goes straight from the FPGA to the connector, resulting in a much shorter signal path.

WARNING:  The CLK_LVDS signal is driven directly from the FPGA.  Shorting the CLK_LVDS may cause damage to the FPGA device.

See Also:  Q200126

Using USBTMC instruments in ATEasy 7.0 - Published on 12/2/2008

12/2/2008

ATEasy 7.0 has the capability to control two types of USB devices, USBTMC instruments and USB RAW instruments.

The following steps will outline how to install, configure, and use the Keithley 2100 USBTMC DMM instrument - this procedure can be applied to other USBTMC instruments:

Plug your USBTMC device into an available USB port on your PC

When Windows finds the new hardware, install either the VISA (if you have installed NI VISA for example) USBTMC driver or the Geotest HW driver

The Geotest HW driver inf file can be found in Program FIiles\Geotest\HW\Hw.inf

From within ATEasy, verify that the driver module you want to use supports USBTMC by checking the driver properties. Make sure the USBTMC and USB checkboxes are set

Insert the appropriate driver into your System module

Right click on the driver shortcut and go to the properties to select "USB" within the interfaces tab. Select your USBTMC device in the drop down menu labled "Device".

Make sure the Vendor ID, Device ID, and Serial Number match your device.

Your USBTMC device can now be used in ATEasy by accessing the configured driver.

USBTMC devices can also be accessed using the built in ATEasy internal procedures for USB such as USBOpen(), USBSetup(), USBSend(), etc. More information can be found in the ATEasy help under the USB heading.

How does the programmable clock delay affect the CLK_LVDS or OCLK signal? - Published on 12/2/2008

12/2/2008

The programmable clock delay (DioSetupClkStrobeDelay) applies to both the internal and external versions of the OCLK; it is the same signal. OCLK (J3-P22) is derived from an internally generated clock, the delayed version of which actually controls the pattern sequencing. Because the data is clocked using the delayed OCLK, the phase relationship of Data Out to OCLK is consistent regardless of the delay setting.

The programmable delay has no affect on the CLK_LVDS signal.

See Also: Q200124

How can you play a sound file within an ATEasy application - Published on 10/7/2008

10/7/2008

One of the simplest methods for playing a sound within an ATEasy application involves using the Windows API function sndPlaySound that resides in Winmm.dll.

The sndPlaySound function plays the waveform sound specified either by a file name or by an entry in the registry or the WIN.INI file. The function is described in detail in the Microsoft Developers Network library under the path:

- Win32 and COM Development
    - Graphics and Multimedia
        - Windows Multimedia
            - Multimedia Reference
                - Multimedia Functions

The direct link is: MSDN sndPlaySound. The method for using the sndPlaySound function can be applied to any of the functions described in the MSDN library.

To use the sndPlaySound function within an ATEasy application you will need to:

Insert the Winmm.dll library under the Libraries sub-module of any ATEasy module (System, Driver or Program) - this example uses the Driver module. You can do this by right clicking on Libraries and selecting Insert Library Below. Select the DLL tab and for the DLL File Name parameter, enter: Winmm.dll. Since the DLL resides in the Windows System folder, the DLL file path can be omitted.

Click Insert.

Declare in the libraries Procedures submodule the following function:
sndPlaySoundA(Val String : sSoundFile, Val DWord dwFlags) : Bool

The constants for the dwFlags parameter are described in the MSDN Library and the header file Mmsystem.h.  The three parameters used in this example are:
SND_SYNC = 0x0000 ! Play synchronously (default)
SND_ASYNC = 0x0001  ! Play asynchronously
SND_LOOP = 0x0008  ! Loop the sound until next sndPlaySound

The ATEasy Getting Started manual explains how to define a DLL and DLL procedures in an ATEasy application.  There are also examples for calling DLL procedures and defining Windows API's in the ATEasy Language.prj example.

Assuming you have a WAV file in the "C:\Sounds" directory called Alert.wav, then the following ATEasy code can be used to play the sound:

sSoundFile: String
{
sSoundFile="C:\\Sounds\\alert.wav" ! Define the WAV file path
sndPlaySoundA(sSoundFile,SND_SYNC) ! Play the sound file
}

The flags can be combined (added) to produce additional effects, such as repeatedly looping the sound for awhile before stopping:

sSoundFile: String
{
  sSoundFile="C:\\Sounds\\alert.wav" ! Define the WAV file path
  sndPlaySoundA(sSoundFile,SND_LOOP+SND_ASYNC) ! Loop the sound indefinately
  Delay(2000) ! Allow sound loop to play for 2 seconds
  sndPlaySoundA(sSoundFile,SND_SYNC) ! Terminate the prior sound loop
}

How to terminate an application from within ATEasy - Published on 10/7/2008

10/7/2008

You can use the following Windows API functions defined in Kernel32.dll to terminate an application using the application's name: Process32First, Process32Next, OpenProcess, GetExitCodeProcess, and TerminateProcess.

First you will need to insert kernel32.dll under Libraries sub-module of the ATEasy module (System, Driver or Program). You can do this by right clicking on Libraries and selecting Insert Library Below. Select the DLL tab and enter the following file path under DLL File Name:
kernel32.dll. Since the DLL resides in the Windows System folder, the DLL file path can be omitted.

Click Insert.

You will now need to define several functions under the procedures section of the newly inserted kernel32 library as shown below:

You will also need to define a structure under the types section of the kernel32 library as shown below:

And finally, will need to define the following variables in your module:

Now you can enter the code required to scan a list of all open processes and terminate one based on its name. In this example, the first instance of Wordpad.exe will be terminated.

CreateToolhelp32Snapshot(2, 0)

ProcInfo.dwSize = sizeOf(ProcInfo)

!Get first Process's information
Process32First(lHandle, ProcInfo)

!Loop until wordpad.exe is found or the end of the process list has been reached
repeat

        !Get the exe file name
        sProcName = lcase(ProcInfo.szExeFile)

        !Check if the current process is wordpad.exe
        if (sProcName = "wordpad.exe")

                !If wordpad.exe is found get its ProcessID
                lHandle = OpenProcess(0x1F0FFF,0, ProcInfo.th32ProcessID)

                   !Terminate wordpad.exe
                TerminateProcess(lHandle, -100) ! -100 is user defined exit code
                exitloop

        endif

until not Process32Next(lHandle, ProcInfo)

How does ATEasy support GPIB Service Requests (SRQ) - Published on 10/7/2008

10/7/2008

There are several ways to support GPIB SRQ's within ATEasy. They are:

Using SetInterfaceEvent() internal function

Using the GPIB driver and implementing OnInterface event

Using EnableInterrupt() internal function

Using I/O Table Receive operation

This article will demonstrate the process for using ATEasy's SetInterfaceEvent() procedure, allowing you to set an ATEasy procedure that will be called by ATEasy when a GPIB SRQ interrupt occurs for a particular GPIB Controller card. A full description of this function is available in ATEasy Help. As there is only one GPIB SRQ line on the GPIB bus, when the event procedure is called, you will have to poll each of the instruments, using GpibSpl(), to find which one requires servicing.

For example, to assign event procedure OnGpibCntlr1SRQ() to the SRQ interrupt of GPIB controller card1 (there may be more than one GPIB controller card in the system), use the following code:

status = SetInterfaceEvent(aioGpib, 0x10000, aioGpibSRQ, OnGpibCntlr1SRQ)

Create a service procedure called OnGpibCntlr1SRQ(). The function will search for all of the GPIB drivers in the application system to find the GPIB instrument generating the SRQ:

OnGpibCntlr1SRQ()
! Declare the following variables
! i                       !short variable to be used as a loop counter
! sDriverName   !String to hold the drivers name
! lAddress         !string to hold GPIB instrument address
! sData              !String to hold instruments buffer information
{
       !Search all the drivers assigned to the application to find the GPIB drivers
       i=1  !System driver numbers start at 1
       while i <= System.DriversCount
              ! System.DriversCount gives the number of drivers assigned to the application
              sDriverName = GetDriverName(i)  !Get the name of the driver
              !Check if it is a GPIB driver
              if GetDriverType(sDriverName) = aioGpib
                  !Get the address of the GPIB driver
                  lAddress = GetDriverAddress(sDriverName)
                  ! Now check Request Service bit (RQS is Bit6) in the instruments Status
                  ! Byte Register (STB). RQS will be set to 1 if service is requested
                  if(GpibSpl(lAddress) and 0b01000000) <> 0  !Check if RQS (bit6) is set
                     !Read the instruments buffer for information on the SRQ
                     sData="" !Clear the buffer array
                     GpibReceive(lAddress, "\r\n", 1, 150, 0, sData, 20)
                     !TODO: Add code to handle the SRQ
                    !...

                 endif
              GpibClear(lAddress)  !Reset the Gpib Instrument if required
          endif
     endwhile
)

How to use C language structure with bit fields from ATEasy - Published on 9/22/2008

9/22/2008

Solution:

ATEasy language, similar to Microsoft Visual Basic, does not have a bit field data type as C language structures. This does not prevent you from using bit fields structures when calling to C DLLs. In C, bit fields are grouped to integers (short, long, etc) and in ATEasy you substitute the group with the bit field basic type (for example DWord). To Access the specific field in ATEasy you use AND and SHR operators. For example, if in C you have the following structure:

typedef struct
{
  UINT32 data1 : 10;
  UINT32 data2 : 6;
  UINT32 data3 : 14;
  UINT32 data4 : 2 ;
} DWORDBITS;

In ATEasy the structure is defined as DWord (dwBits). Accessing data2 field is done as follows:

dwData2=(dwBits shr 10) and 0x3F

dwData2=(dwBits shr 10) and 0b111111

A more elegant and prone to changes (in the structure fields) is to use a procedure for setting and getting the fields values. Constants that hold the offset and the fields size can be also used as shown here:

DWORDBITS_DATA2_OFFSET : Word Const = 10
DWORDBITS_DATA2_SIZE : Word Const = 6

Procedure DWordBitsField(pdwBits, wOffset, dwSize, dwValue) : DWord
  pdwBits: Var DWord
  wOffset : Val Word     ! offset of field, 0 based
  dwSize : Val DWord     ! # of bits for the field
  dwValue: [Val] DWord   ! optional, value of the field
  dwMask : DWord
{
  ! get or set DWordBits fields
  dwMask=(2ul ^ dwSize) -1  ! calc mask, 8 bit integer

  If ArgMissing(dwValue)
    ! get and return the field value
    Return   (pdwBits shr wOffset) and dwMask
  Else
    ! set the field and return all the bits
    pdw=(pdwBits and  not (dwMask shl wOffset))  or (dwValue shl wOffset)
    Return pdw
  Endif
}

Now to set data2 to 35 in dwBits:

dwData2=DWordbitsField(dwBits, DWORDBITS_DATA2_OFFSET, DWORDBITS_DATA2_SIZE, 35)

To get data2 from dwBits:

dwData2=DWordbitsField(dwBits, DWORDBITS_DATA2_OFFSET, DWORDBITS_DATA2_SIZE)

Notes:

When you import a C header file that contains bit fields ATEasy substitute them with the basic type.

You can also use the ATEasy Bit() function in the internal library to access (get or set) a single bit.

How can I have two versions of ATEasy in the same computer - Published on 9/4/2008

9/4/2008

ATEasy does not allow running two versions at the same time on the same computer. When you upgrade ATEasy to a newer version, ATEasy setup overrides and replaces current files not allowing you to have two versions of ATEasy on the same computer. The procedure below shows how to install more than one version on the same computer and how to switch between the versions to run specific version.

The following steps describe installing version 5.0 and 7.0 at the same compute. Make sure to read and understand the whole procedure before attempting to perform it:

1. Install ATEasy 5 (run ATEasy5.exe and follow the instructions).
2. Copy ATEasy folder and subdirectories (C:\Program Files\ATEasy) to C:\Program Files\ATEasy5.
3. In the Windows System folder (usually C:\Windows\System32) copy ATEasy files and add 5 to the files name. There may be up to 6 files to copy: ATERT.dll, ATERCTL.dll, ATEasy.usr, ATEasyPanel.cpl and optionally ATEasy2_32.dll and ATEZUSER32.dll – add 5 to the filename. For example copy ATERT.dll to ATERT5.dll.
4. Install/upgrade to 7 by running ATEasy7.exe and follow the instructions.
5. Repeat steps 2 and 3 (above) this time to ATEasy7 folder and ATERT7.dll etc.
6. At this time ATEasy 7 in ready to run (ATEasy 5 will not run).
7. When you need to switch from version X to Y (5 to 7 or 7 to 5), delete the ATEasy folder and copy ATEasyY folder to ATEasy folder (copy ATEasy5 folder to ATEasy) and copy the ATEasy System files to the original files (for example ATERT5.dll to ATERT.dll). Once files are copied, you will need to re-register the files by opening the windows command prompt (Start, Run Cmd), change the current directory to the Windows System folder ("cd c:\windows\system32") and re-register the two files ATERT.dll and ATECTL.dll ("regsvr32 ATERT.DLL" and "regsvr32ATECTL.dll"). At this point version Y is ready for use.

Notes:
1. You can create a batch file to automate this process and launch ATEasy at the end. You can create shortcut on your desktop to switch to version Y.
2. Make sure not to attempt to run executables created with newer version of ATEasy with older run time version. Newer run time can run older EXE files.
3. Modifying files created such as programs with newer version of ATEasy with older version of ATEasy is not recommended.
4. If you wish to have diffrenet options and settings for each version you may also need to copy and restore the ATEasy registry settings under HKEY_LOCAL_MACHINE\SOFTWARE\Geotest\ATEasy and HKEY_CURRENT_USER\Software\Geotest\ATEasy.

How to inform an ATEasy application of a UPS Power Failure - Published on 8/21/2008

8/21/2008

This process will be broken into two parts: first create an application (EXE) that will be called by the UPS Management Software when a power failure occurs. This application should create an AEvent object with a name "UPSPowerFailEvent". After creating it, use the PulseEvent() method to signal the test application that the UPS is now running on battery power and it needs to shut down. Second, the test application will create a thread to watch for a UPSPowerFailEvent signal and if received shut down gracefully.

Step 1: Create an application to be run by the UPS Management Software in the event of a power failure. Note: the UPS Management Software is supplied with the UPS

In ATEasy create an application (for example UPSPowerFailure). In the OnInit event procedure create an object called UPSPowerFailEvent (an object with the same name will be created by the test application). Then use the PulseEvent() method to signal the test application that a power failure has occured.

Procedure System.OnInit()
obUPSEvent: AEvent !Object to inform test application of UPS power failure
{
obUPSEvent = CreateObject("AEvent") ! Create an AEvent object
obUPSEvent.Name="UPSPowerFailEvent" ! Give it the same name as the test application thread
obUPSEvent.PulseEvent() ! Signal the test application of the UPS power failure and that it
! should shutdown
}

Compile the application and add the name of the executable file to the UPS Management Software Event Notification command line.

Step 2: The test application should create a thread when it starts (OnInit). The thread will call a procedure (called MonitorForUPSEvent() in this example). In the procedure create an event with the same name "UPSPowerFailEvent" as used Step 1 above. Then call WaitForSingleObject() to monitor the event signal. Once the wait returns perform the shut down of the application (call abort, exit, display a message etc):

Procedure MonitorForUPSEvent(lThread)
lThread: Val Long ! Required to create the thread
obUPSEvent: AEvent ! Object to be monitored for UPS Failure
{
obUPSEvent = CreateObject("AEvent") ! Create an object
obUPSEvent.Name=" UPSPowerFailEvent " ! Give it the same name as Step 1
WaitForSingleObject(obUPSEvent.Handle,) ! Wait for a Pulse Event to occur

! Once the PulseEvent has occurred there are multiple ways of dealing with the shutdown process. These will mainly depend
! on the UPS battery run time. In this example we will use Abort.

Abort !Jump to System.OnAbort. Add code to OnAbort to run all the instrument and application shutdown routines

}

Procedure System.OnInit()
{
CreateThread(MonitorForUPSEvent)
}

For instructions on shutting down Windows from ATEasy see KB Article Q200070

The language.prg has additional examples of how to use events.

GX5280 and GX5290 Delay Settings - Published on 7/18/2008

7/18/2008

The Gx5280 and Gx5290 boards use a multi-step delay circuit to perform two critical functions:

1. Time-align the internal main clocks across a multi-module digital domain.
2. Adjusting the timing between the data clock (data out) and strobe clock (data in) signals on each module to ensure that valid setup and/or hold parameters are met while testing the UUT.

Domain Offset
While all modules in a digital domain use a common reference clock to maintain synchronization of the data clock and strobe clock, the alignment of theese clock edges is not guaranteed across all of the modules in the domain. The Domain Offset delay can be used to calibrate the modules in a domain so that the respective data and strobe clocks on each module are not only phase locked to each other, but are also phase aligned. The edge of each module’s master clock can be adjusted in a +/- 3nS range with 250pSec resolution, with slower edges adjusted in the negative direction, and faster edges adjusted in the positive direction, until all clock edges are aligned.

Clock and Strobe Delays
The clock and strobe delays are achieved using a two stage process. The first stage is a programmable delay generator capable of generating delays from 0.0nS to 3.0nS, with a 250pS resolution. The second stage consists of a fixed delay generator with six output taps, each offset by 4nS. A switching circuit routs the clock or strobe signal through the appropriate delay path to produce a cumulative delay of the desired value.

Delay Ranges
There is a gap between the maximum 3.0nS programmable delay in the stage one delay circuit and the minimum 4.0nS delay tap in the stage two delay circuit. These 1nS gaps are found between 3.0nS and 4.0nS, 7.0nS and 8.0nS, 11.0nS and 12.0nS, 15.0nS and 16.0nS, 19.0nS and 20.0nS and 23.0nS and 24.0nS. The second reason for the non-linearity is that there are added propagation delays introduced whenever the stage two delay circuit is included in the signal path. Because these additional delay factors are uncontrolled, each module has the potential for slight variations in the cumulative delays.

Changing the log result during run time after the test result is appended to the log - Published on 7/18/2008

7/18/2008

Solution:
You can change the log result during run time (even for tests that have already completed) by utilizing the ATEasy ALog’s Document object. The Document object is consistent with the Document Object Model (DOM of the Internet Explorer) .

In the example code below, the various data members of the ALog Document object are used to modify the contents of the ATEasy test log. The Document object has access to all the text that is output to the test log.

You can modify the text of each entry in the test log by accessing the appropriate innerText property.

Use the following code to modify the log entry corresponding to the first test in the first task:

! obj is a variable of type Object

obj=Log.Document.getElementsByTagName("TABLE")

obj.item(3).cells.item(5).innerText="Some Text"

! Destroy reference to Document object
obj= Nothing

Here is an explanation of how to index the different lines of the test

obj.item(3) corresponds to the first test line in the first task and cells.item(5) corresponds with the sixth column of that particular test line (if you are using a min/max test then this means the test result).

Here are some other examples:

If you have 1 task with 2 tests then obj.item(3) will correspond with task1 test1, and obj.item(4) will correspond with task1 test2.

You have to add 1 to the obj.item index if you are crossing a task. So if you have two tasks, each with 1 test, then obj.item(3) will correspond with task1 test1, and obj.item(5) will correspond with task2 test1.

Use the View Source Log context menu to see the HTML table structure generated by ATEasy.

Note: ATEasy Log must be configured to HTML format in order to use the methods described in this article (log.PlainText=False).

Using threads to execute code within a specified time interval - Published on 6/17/2008

6/17/2008

You can create a thread to execute code at a specified time interval. This can be useful if you want to take a measurement or reading for example every 200 millisecond. Use the following two part process:

1. Create a thread procedure that accepts one parameter and contains the code you want to repeat on a regular, timed, basis.

The following thread procedure takes 50 measurements. Each measurement takes 200 mSec. Once the measurement is taken, the thread is suspended for the remaining time (of the 200mSec) using the Sleep function, releasing the CPU to handle other tasks:

Procedure MeasurementThreadProcedure(num) : Void
{
    num: Long
    dwTimeStart : DWord
    dwTimeEnd : DWord
    i : Long

    ! take 50 measurements each should take no more than 200 mSec
    for i=0 to 49
        !Record time before measurement
        dwTimeStart = Tick()
        !Make measurement
        DMM Measure (g_adMeasurement[i])
        !Record time after measurement
        dwTimeEnd = Tick()
        !Let thread sleep for the remaining time of this 200ms time cycle
        sleep(200-(dwTimeEnd-dwTimeStart))
    next
}

2. In your main program, you create the thread (in this case supended), start it, and then wait for the thread to end before continuing the main program.

- Create a variable of type AHandle in your variables submodule.

- Instantiate a thread object and link it to the previously created procedure using the following code:

hMeasurementThread = CreateThread(MeasurementThreadProc, 1, True, )

This line of code will create a thread and wait for you to start it with the Resume method.
In this example, MeasureThreadProc is the name of the procedure created in step 1 and MeasurementThreadHandle is the name of the AHandle variable created earlier.

- Optionaly. Set the priority of the thread to time critical for improved timing accuracy.


SetThreadPriority(hMeasurementThread, aPriorityTimeCritical)

- Start the thread by calling its ResumeThread function:


ResumeThread(hMeasurementThread)

- Use the WaitForSingleObject procedure to wait for the thread to finish execution (with a 20 second time out) before finishing your main ATEasy program.


WaitForSingleObject(hMeasurementThread, 20000)

Determining the frequency measurement accuracy of the GTX2200 and GC2200 Timer/Counter - Published on 6/17/2008

6/17/2008

For frequency measurements, the GTX2200 family uses a technique known as Reciprocal Counting, a method where the accuracy of the measurement is based on the relationship of the reference clock period and the measurement window duration (gate time), and not the input signal frequency.

This method measures the time interval between two identical trigger points on the input signal, as defined by the trigger level setting and the trigger slope setting.  During the gate time – the window in which the instrument is taking a measurement, the instrument simultaneously counts the number of cycles of the input signal, and the number of clock pulses from the built-in frequency reference.  A microprocessor then calculates the frequency of the input signal.  The absolute resolution of a measurement is the period of one reference clock cycle, and the relative resolution is equal to the absolute resolution divided by the gate time.

For example, if the counter incorporates a 100MHz reference clock, then the absolute resolution is eight digits (10nS = 1.0E-8 Seconds).  Using a gate time of 100mS, the relative resolution is seven digits irrespective of the input signal frequency (10 nS/0.1S = 1.0E-7 Seconds).  The GTX2210, GTX2220 and GTX2230 all use a 100 MHz reference clock, but the GTX2220 and GTX2230 use an interpolation technique which yields an effective absolute resolution of 10 digits, equivalent to a 10 GHz reference clock.

The overall accuracy of the measurement is degraded by the combined effects of the jitter on the measured signal, the jitter on the reference clock, the accuracy of trigger detection circuit and the accuracy of the gate timer.  The frequency measurement accuracies for the GTX2200 family of products are:

GTX2210/GC2210:

#Digits	Gate Time (s)
8	1.000
7	0.100
6	0.010
5	0.001

GTX2220/GC2220 and GTX2230/GC2230:

#Digits	Gate Time (s)
10	1.000
9	0.100
8	0.010
7	0.001

Why is my plain text Log columns not aligned? - Published on 6/17/2008

6/17/2008

When the ALog.PlainText property is set to True, ATEasy will use the Internet Explorer (IE) fixed pitch font. By default this will be set to "Courier New", however some systems may have set it to non-fixed pitch font (using IE options). You can override that by setting the ALog.FixedFont.Name in your application. Once the font is set to a fixed pitch, any print statement in this mode will generate the same spacing for every character.

The log control font can be set as follows:

Log.FixedFont.Name = "Courier New"

The log control font size can be set as follows:

Log.FixedFont.Size= 11

How do I change the order of controls on a form? - Published on 6/16/2008

6/16/2008

The form controls are drawn according to the order of the Form.Controls where 0 is drawn first and 1 is on top of 0, etc. This is sometimes reffered to as ZOrder of controls.

At design-time, you can change the order of controls at design time using the Tab Order command (Edit, Arrange, Tab Order) or by dragging the control in the Controls drop down list at the form editor.

At run-time, you can use the following code to change the ZOrder using the following code:

img1.ZOrder(aWindowZOrderTop)

will draw the img1 control on top of all controls. If you want img1 on top of img3, do the following:

img3.ZOrder(aWindowZOrderTop)
img1.ZOrder(aWindowZOrderTop)

How to change the default printer that ATEasy uses for printing - Published on 5/29/2008

5/29/2008

The following example shows how to change the default printer used by ATEasy when printing using ALog.PrintLog method or internal functions such as LogPrint, FilePrint. The example prints the ALog control (log1) to a network printer:

Procedure btnPrint.OnClick(): Void Public Compile ! Occurs
! when the mouse button is pressed and released upon the object.
    sDefaultPrinter: String
    sPrinter: String
    ob: Object
{
    ! Example for Log Printing with printer different than default

    ! Use the following to print while prompting the user to select printer
    !log1.ExecWB(alogOleCmdIdPrint, alogOleCmdExecOptPromptUser)

    ! Use the following code to change the default printer
    ! (that ATEasy uses when printing) programmatically
    ! print to sPrinter to (may be different than current default)
    sPrinter="\\\\geoserver\\Dell Laser Printer 5100cn PCL6"
    ! Get current default printer
    ob=CreateObject("WScript.Shell")
    sDefaultPrinter=ob.RegRead("HKCU\\Software\\Microsoft\\Windows NT\\"
    "CurrentVersion\\Windows\\Device")
    sDefaultPrinter=Left(sDefaultPrinter, Pos(",", sDefaultPrinter))
    ! Set default printer
    ob=CreateObject("WScript.Network")
    ob.SetDefaultPrinter(sPrinter)
    ! Print
    log1.PrintLog()
    ! Restore default printer
    ob.SetDefaultPrinter(sDefaultPrinter)
    ob=Nothing
}

Creating Dynamic Forms Using ATEasy - Published on 12/14/2007

12/14/2007

ATEasy supports creating dynamic forms. Usually the form contents: Controls and menus is created at design time using the ATEasy form editor. Dynamic forms are forms that their content is created at run time. While it possible to create the form with all the possible controls that you expecting to use at design time and then use the control Visible property to show or hide control and Move method to position them, sometimes you may want to create the controls at run-time based on the form logic.

To create a dynamic form you create a form at design time with the fixed controls on it. At run time you call the InsertControl, AForm class method to create and add additional controls:

btnClicked=InsertControl("btnClicked", "AButton", Form.Width/2-80, Form.Height/2-14, 160, 28)

Once the control is created you can link the control events with an event handler procedure (btnClicked.OnClick) using the AddHandler statement as shown here:

AddHandler btnClicked.OnClick, btnClickedOnClick

Call the RemoveHandler statement and the RemoveControl method to and release the handler and delete the control.

For more information on dynamic forms see the Dynamic Form task in the Forms.prg example.

ATEasy v6.0 Service Pack 1 (build 134) - list of changes - Published on 7/20/2007

7/20/2007

ATEasy 6 build 134 contains all fixes and changes since version 6 (build 132).

The following list the changes that were made:

Enhanced support for .NET and new support for .NET namespace

Enhanced support for WinSocket interface interface re-openeing when InterfaceInfo changes, support for terminators

Project new option AutoIncrementFileVersion

LoadOnAccess new option for DLL

AdoDB example - new task that show how to use System.Data for databases using .NET

DotNet example - new task showing how to send email using System.Net.Mail using .NET

Enhanced License Server support with automated setup as service and a way to set the server from the client

New drivers for Signametrix SM2060/55, SMX4030/32, Navatek NT6000, GX5733, GX5641, GX5642, GX2002, GX6377, GX6384, GxChassis, Gx7xxxA smart chassis), Keithley Instruments 2000/1/2/10 DMMs, Keithley Instruments PXI (DAQ and DIO) boards, Sorensen DCS and DLM600 power supplies

New command line options for the setup:

          /s

                  Silent mode

            /SetupType"[Typical, Full, LicenseServer]"

                  Specify one of the setup type, i.e Typical, Full,

                  LicenseServer

                  Default=Typical

                  This command only apply to clean installation

            /TargetDir"Path"

                  Specify the target directory for the installation

                  Default="C:\Program File\ATEasy"

                  This command only apply to clean installation

            /Uninst

                  Uninstall ATEasy

GetLogString - new constant aLogStringAppend to enumALogStringType to return the current append statements string

Enahance support for WinSocket interface (OnInterface, AutoAccept)

New Units in the test property page

Allow passing of Form procedures to DLL/callbacks

Readonly control properties were change to read/write (for example BorderStyle, Sorted, Style, etc)

AUsers.ShowLogInDialog() returns a user token and AUsers.Login() accept a token

CreateObject internal function support for remote host (DCOM) and free treading model

Tolerance test type Plus and Minus values if left empty allow open end

New code completion support for .NET overloaded methods and constructors

Bug fixes

What is the accuracy of the Delay() function? Is background processing occurs while Delay() is called? - Published on 3/13/2007

3/13/2007

Delay() is accurate to 1msec, however, since the Delay() function allows form events and interrupts to be dispatched, it may not always be accurate to 1msec. You can use the Sleep() function if you would like to completely suspend the thread and get better accuracy , however your form events will not be dispatched and will look frozen until Sleep is returned (if sleep is called in the form thread). The SetThreadPriority() may also be used to improve accuracy. While delay is processing an event is, the delay can only return after the event is executed, so make sure the event processing time is short as possible.

If you still want to process events while you are waiting but want to consume less CPU, use the Tick() function to implement your own delay and allow other processing such as interrupts, form events and other custom processing while doing it. You should call WaitForEvent() function to suspend the thread and consume less CPU while waiting to the next event resulting in a better delay function as in the following example:

lStart=tick()
while tick()-lStart
    ! optional  - do something

    ! suspend to conserve CPU but still allow form events interrupts etc
    WaitForEvent(tick()-lStart)

endwhile

Calculating time diffrerence using DateTime data type - Published on 3/8/2007

3/8/2007

ATEasy's DateTime type values are really a Double data type - the same applies to a DateTime value in a variant (vtDate) type.
The integer part of the double number is the number of days since 12-30-1899. The fractional part is effectively the time-of-day.
The easiest way to convert a date string into our DateTime is to assign the string to a variant and then assign the variant to a DateTime variable, for example:

vr01 = "8/25/2006 17:49"
dt01 = vr01

DateTime values can be compared with the expected meaning. Since they are really Double values, if you subtract them and store the result in a Double, you have the number of days between the two dates. Similarly, adding a Double to a DateTime, adjusts the date and time by that many days plus a fraction of a day.
Here is an example of subtracting two day/time:

vr1:Variant
vr2:Variant

vr1="08/27/06 "
print VarChangeType(vr1, vtDate)
print vr1
vr2="08/28/06 10:48"
print VarChangeType(vr2, vtDate)
print vr2
print vr2-vr1

The example will print:

0
8/27/2006
0
8/28/2006 10:48:00 AM
1.44999999999709 (one day and .449 of 24 hours)

ATEasy is unable to load a DLL error when I start my ATEasy application - Published on 12/15/2006

12/15/2006

ATEasy 6.x and above uses LoadLibraryEx Windows Application Programming Interface (API) function at run time to load the DLLs you described in the ATEasy module (program, system or driver). The function returns a details status which ATEasy displays when it fails. The error will show as "Unable to Load the '%1' DLL file '%2'. Windows API LoadLibraryEx returned error # %3 (0x%4): %5". Prior version of ATEasy returned the error "Unable to load the '%1' DLL file '%2' Error %3 (0x%4): %5".

Here are a list of possible causes and solution to this problem in case the error description (%5) is "The specified DLL or a referenced DLL could not be found" (error #127/0x7F) or "the specified module could not be found" (error #127/0x7F) or "the specified procedure could not be found" (error #126/0x7E):

Check the DLL library file path and make sure the DLL exist. You can check this from ATEasy DLL Properties. The property page display if the file exist or not, if the file exist it will show the exact location where the DLL file name will be used at run-time. If you are using relative (i.e. ..abc.dll) or no path name in the DLL path in ATEasy you need to make sure the DLL will be located in a folder found relative to the EXE file name as displayed in the Project property page. If you are not using a path in the file name (i.e. kernel32.dll) using no You may have several DLLs of the same name make sure the DLL on the disk is the one you think is loaded - Try to temporary change the DLL Library path in ATEasy to a full path name instead of relative path or no path. This procdure is used usally for error # 127 or 0x7F.

The DLL you are using may depends on other DLLs. You can download a tool called DEPENDS.EXE from
http://www.support.microsoft.com/kb/198038 to see what DLLs are used by the DLL you are trying to load. After you download it, run the program and open the DLL you are trying to load from the DEPENDS file menu and it will show a list of DLLs that are used by your DLL. If it's missing it will show it in red the DLL that is missing. This procdure is used usally for error # 126 or 0x7E.

Some DLLs will have initialization code that is called when they are loaded. This code may fail. Follow the DLL manufacturer instruction for setup and preparation before using it or contact the manufacturer for support.

How can i disable the popup menu of the ALog control? - Published on 12/11/2006

12/11/2006

The ALog.ShowContextMenuItem method can be used to hide individual items of the contecxt menu. For example:

log1.ShowContextMenuItem(alogContextMenuItemClear, False)

would hide the Clear from the context menu.

To remove the context menu all together add the following to the Form.OnLoad event:

log1.ShowContextMenuItem(-1, False)

How to use Microsoft Excel to calculate a statistical/mathematical/financial function from ATEasy - Published on 12/7/2006

12/7/2006

The example creates a hidden Excel workbook, fill the data and calculate TINV value and return it to ATEasy.

TINV Excel function used in this example returns the t-value of the Student's t-distribution as a function of the probability and the degrees of freedom.

You can modify the example to calculate and to use any excel mathematical/statistical/financial formula.

ob: Object

ob=CreateObject("Excel.Application")
if ob=Nothing
    MsgBox("Unable to Create Excel.Application. Check if MS Excel is intsalled properly. Aborting...")
    abort
endif
ob.Caption="ATEasy Excel Function Call Using COM"
ob.Visible=TRUE     ! show/activate execl main window

ob.Workbooks.Add()  ! add workbook

ob.Cells.Item(1, 1).Value = 0.054644927
ob.Cells.Item(2, 1).Value = 60.0
ob.Cells.Item(1, 2).Value = "=TINV(A1, A2)"

print ob.Cells.Item(1, 2).Value

ob.Workbooks.Item(1).Close(FALSE)    ! close workbook do not save changes
ob.Quit()
ob=Nothing

Can an ATEasy executable (EXE) handle command line parameters? - Published on 7/21/2006

7/21/2006

Use the App.CommandLine to retrieive these parameters. The on-line help explains how to use the CommandLine property of the AApp class.

For example if you call your exe:

abc.exe a.log

The App.CommandLine will be equal to "a.log" and in you code you can use it:

SaveLog(App.CommandLine)

How can I display a PDF file from ATEasy application using WinExec? - Published on 7/21/2006

7/21/2006

Use WinExec() internal function to open a window with a the PDF document. For example

iStatus=WinExec("\"\\\\MyServerName\\SharedFolder\\Program Files\\" "ATEasy\\Corporate\\Mercuri\\Help\\MERCURI HELP.pdf\"")

Note also that the file name is surrounded with double quotes since the file name may contain space which. A space will cause ATEasy the think the first part (up to the space) is the exe and the second is the command line parameters, so to avoid this we use the quotes .

WinExec will noot generate exception so there is no need for try statement just check as the help says that the returned status or handle is greater than 32.

How do I modify the test log results numbers format to not display numbers in scientific format? - Published on 7/21/2006

7/21/2006

There are several ways to change the formatting of the test results in the log:

1. Use the FormtLogString()to internal functions change the table columns and their contents

2. In OnEndTest event call GetLogString(), modify the string and call SetLogString().

The FormatLogString() automatically switches to Scientific format (i.e. 1.2E+07) if the number cannot be displayed. You can override this by changing the test result:

TestResult=Round(TestResult, -3) ! Will truncate and leave only 3 digits after the decimal point.

The second method is a bit more flexible and it gives you full control over the way the TestResult number is displayed in the log string and than send it back to ATEasy. Once you identify using string manipulation functions the position of the test result in the log string, use the Format() function to convert the number to a string the way you use it and than replace the test result string. Make sure the code you'll put will work with both HTML and Text test logs.

ATEasy v6.0 Detailed List of Changes - Published on 7/21/2006

7/21/2006

Development Environment

Fresh new look for the development environment includes auto hide docking windows, gradient and color customization for menus and toolbars.

Multiple level programs in your project allow you to organize your projects test programs under user defined folders and divide them to categories.

Create folders in your projects to store baggage files of your projects such as documentation, dlls, software components and more. You can open/edit/print these files directly from ATEasy (using Windows shell verbs).

New program Parameters property page allow you to create and define parameters at design time for AProgram of type Numeric, String and enumerated type. Document shortcuts have description and program shortcut have a way to override and change the program UUT name set in the Program.

Procedure property page: new Compile checkbox, to force a procedure to compile even if not referenced.

Run-Time

New class AVirtualKeyboard allow you to control and display the Virtual keyboard on the screen. The virtual keyboard enables touch pane; support for control that require text input using a keyboard that is displayed on the screen and designed for touch panel user interface.

EnableTouchScreen new internal function to configure and enable automatic support touch panel to your application including support for scrollbar sizing, font changes etc.

AForm.AutoScale - new property enables auto sizing and scaling of the form by setting the AForm.Font.

AProgram, ASystem, ADriver new property Type and new eneum enumAAppItemType.

AProgram, ASystem, ADriver new property Parent to return the parent folder.

AProgram.Parameters new property, ADriver.Parameters also extended to support write at run-time.

ADriver.MiscFolder, AProgram.MiscFolder and ASystem.MiscFolder new property used to store the application files.

ADriver.Tag, AProgram.Tag and ASystem.Tag new property used to store user defined string to the module files.

New classes AAppFolder and AAppShortcut used for module based user defined folders and baggage files.

New statement Append statement - allows you to append text to be appended to the log after the test results is printed.

Support for dynamically creating of menus AMenu.InsertMenu new method to dynamically insert a menu, AMenu.Move new method to move a menu item, AMenu.RemoveMenu. This is similar to 5.0 dynamically creating of form controls using AForm.InsertControl and AForm. RemoveControl.

AButton - multi-line and word wrap text support.

New File and directory functions FileGetStatus, FileCopy, DirectoryCreate, DirectoryRename, DirectoryDelete new internal functions, FileFind now returns optional structure structFileStatus.

ParseDateTime and FormatDateTime new internal functions for date time string manipulation.

The statement AddHandler and RemoveHandler now support .NET, COM events, Control and Menu events (any object type that generate events).

ATEasy now support importing of the new .NET 2.0 framework and Lab View 8.0 (up from .NET 1.1 and LabView 7.1).

AButton, ARadioButton, ACheckBox new support for multiple lines text and word wrap for the caption property.

AStatusBarPane new support for Progress bar pane - new properties ProgressMin/Max and Value, asbrpStyleProgressBar new member of enumStatusBarPaneStyle.

enumGetDir has new constants aGetDirApp, aGetDirAppExe, also the aGetDirATEasy now always return the ATEasy folder (and not the EXE when running outside of the IDE).

New internal function, GetCallbackThunkAddress, the function return the ATEasy procedure thunk so it can be called from an external DLL.

ControlsCount and Controls properties are now available only to controls that are containers: ATab, APanel and AGroupbBox (also AForm).

Test Executive

Full support for touch panel user interface:

Modal and Modeless user interface. Modal user interface used mainly for touch panel to replace menus and toolbars with buttons forms to navigate and control the test executive.
The user can define forms designed for touch panel user interface that includes test executive commands or user defined commands to control the test executive"s capabilities via the touch panel in Modal mode.
User groups based user interface, allow you to customize the user interface for production users, test engineers etc. Each group can have its own privileges and user interface (forms, menu, toolbars and options).
Customization of forms, menus, toolbar options and more per users group can be set by the administrator with no programming.

Automatic management and backup, save, delete and naming of log files.

Compatibility issues

ATEasy 6.0 is fully backward compatible with prior versions of ATEasy (3.0-5.0) . Binary files saved in version 6.0 can be loaded using version 5.0 build 94a (but not always with versions prior to 94a). ATEasy 6 can also run EXE created with prior versions.

See Q200075 for a summary and less detailed list of features.

ATEasy v6.0 Main New Features Summary - Published on 7/20/2006

7/20/2006

Run time and Development:

Fresh new look for the development environment includes auto hide docking windows, gradient and color customization for menus and toolbars.

New support for applications that have a large number of programs, we now provide an easy way to organize these programs. Essentially, the user can define folders under the Programs folders and organize its test program in a tree structure according to their functionality or UUT variants.

Create folders within the project modules that can contain "baggage" information. Things like UUT documentation, fixture wiring, TRDs', software components, etc. These can be opened directly from ATEasy regardless of their application type - i.e. Word, Excel. Etc. The advantage to this is that now, all of the specific files needed for an application can be located in one location, facilitating source control, archiving and backup.

New Full feature, virtual on-screen virtual keyboard. This allows full keyboard support for applications that are designed for touch panel. This feature also includes support for an increased scrollbar size for all windows controls, multi line push buttons and automatic sizing/scaling of a form when it font is changed.

The Internal library contains several new functions and class including support for extended directory and file manipulation, date time parsing, dynamic menu and control creation and extended support for .NET/ActiveX events.

New support for .NET 2.0, LabView 8.0, ActiveX/COM event handlers, DLL callback.

Tested under Windows VISTA (b2)

Test Executive Features:

Full support of test executive features using a touch panel user interface:

The user can define forms designed for touch panel user interface that includes test executive commands or user defined commands to control the test executive's capabilities via the touch panel.

Virtual keyboard will automatically popup when the current control requires text entry.

Customize the user interface for different classes of users - i.e. operators, technicians, test engineers, etc. Each group can have its own privileges and user interface (forms, menu, toolbars and options).

Automatic management of log files - i.e. when to backup, when to delete, when to save, how to name log files, etc. Previously, the user had to code these capabilities as part of the logging process.

See Q200076 for additional and more detailed list of features.

Getting Return Code from External Process Started with WinExec - Published on 4/24/2006

4/24/2006

Solution:

WinExec() does not operate synchronously and will not wait until the called process is closed before returning to the calling application. Instead, it will return immediately and return a process handle indicating if the process was successfully created or not. To access the code returned by the application launched with WinExec(), you will need to use code similar to the following:

hProcess=WinExec("...")
if hProcess<21
! error creating the process
return
endif
WaitForSingleObject(hProcess)
GetExitCodeProcess(hProcess, dwCode)

The GetExitCodeProcess function retrieves the termination status of the specified process, and is defined in kerner32.dll. You will need to define it under a kernel32.dll entry within your module libraries. In ATEasy this function will be defined as:

GetExitCodeProcess(hProcess: Val AHandle, pdwCode : VAR DWord) : BOOL

A description of the function is provided below:

GetExitCodeProcess:

BOOL GetExitCodeProcess
(
HANDLE hProcess, // handle to the process
LPDWORD lpExitCode // termination status
);

Parameters:

hProcess [in] - Handle to the process. For Windows NT/2000/XP, the handle must have PROCESS_QUERY_INFORMATION access. For more information, see Process Security and Access Rights.

lpExitCode [out] - Pointer to a variable to receive the process termination status.

Return Values:
If the function succeeds, the return value is nonzero. If the function fails, the return value is zero. To get extended error information, call GetLastError.

Remarks:
If the specified process has not terminated, the termination status returned is STILL_ACTIVE. If the process has terminated, the termination status returned may be one of the following:

The exit value specified in the ExitProcess or TerminateProcess function.

The return value from the main or WinMain function of the process.

The exception value for an unhandled exception that caused the process to terminate.

How do I send email from ATEasy? - Published on 4/18/2006

4/18/2006

Solution:

You can do it by using the Microsoft CDO ActiveX/COM library :

1. Insert the CDO library to your module

2. Define the following variables:

cdocfg: CDO.Configuration
msg: CDO.Message
sMyHTMLMessage: String ! HTML message

3. The following code is an example of how to use the CDO library to send email (may require some changes for error handling message text):

! create configuration
cdocfg=CreateObject("CDO.Configuration")
cdocfg.Fields.Item(cdoSMTPConnectionTimeout).Value=400
cdocfg.Fields.Item(cdoSMTPServer).Value="10.10.1.1" ! server address could be also something like "smtp.primenet.com"
cdocfg.Fields.Item(cdoSendUsingMethod).Value=cdoSendUsingPort
cdocfg.Fields.Update()

! create a message
msg=CreateObject("CDO.Message")
msg.Configuration=cdocfg
msg.From="rony@geotestinc.com"
msg.Subject="Hello world!"
msg.HTMLBody=sMyHTMLMessage
msg.To="\"Ron Y\""

! send the message
Try
msg.Send()
Catch Else
! error message
EndTry

!clean up
mgs=Nothing
cdocfg=Nothing

How do I shut down or restart windows from my ATEasy application? - Published on 3/21/2006

3/21/2006

Solution:

To shut down or restart windows, You need to call a Windows API that is found in USER32.dll. The function is described here:

ExitWindowsEx(uFlags: Val DWord, dwReason: VAL DWord): Bool

Parameters
uFlags - [in] Shutdown type. This parameter must include one of the following values:

EWX_LOGOFF - 0 - Shuts down all processes running in the logon session of the process that called the ExitWindowsEx function. Then it logs the user off. This flag can be used only by processes running in an interactive user's logon session.

EWX_POWEROFF - 0x00000008 - Shuts down the system and turns off the power. The system must support the power-off feature. The calling process must have the SE_SHUTDOWN_NAME privilege. For more information, see the following Remarks section.

EWX_REBOOT - 0x00000002 -  Shuts down the system and then restarts the system. The calling process must have the SE_SHUTDOWN_NAME privilege. For more information, see the following Remarks section.

EWX_SHUTDOWN - 0x00000001 - Shuts down the system to a point at which it is safe to turn off the power. All file buffers have been flushed to disk, and all running processes have stopped. The calling process must have the SE_SHUTDOWN_NAME privilege. For more information, see the following Remarks section. Specifying this flag will not turn off the power even if the system supports the power-off feature. You must specify EWX_POWEROFF to do this.
Windows XP SP1:  If the system supports the power-off feature, specifying this flag turns off the power.

This parameter can optionally include one of the following values:

EWX_FORCE - 0x00000004 -  Windows 2000/NT:  Forces processes to terminate. When this flag is set, the system does not send the WM_QUERYENDSESSION and WM_ENDSESSION messages. This can cause the applications to lose data. Therefore, you should only use this flag in an emergency. Starting with Windows XP, these messages will always be sent.

EWX_FORCEIFHUNG - 0x00000010 - Forces processes to terminate if they do not respond to the WM_QUERYENDSESSION or WM_ENDSESSION message within the timeout interval. For more information, see the Remarks. Windows NT and Windows Me/98/95:  This value is not supported.

dwReason  - [in] Reason for initiating the shutdown. This parameter must be one of the system shutdown reason codes. If this parameter is zero, the SHTDN_REASON_FLAG_PLANNED reason code will not be set and therefore the default action is an undefined shutdown that is logged as "No title for this reason could be found". By default, it is also an unplanned shutdown. Depending on how the system is configured, an unplanned shutdown triggers the creation of a file that contains the system state information, which can delay shutdown. Therefore, do not use zero for this parameter. Windows 2000/NT and Windows Me/98/95:  This parameter is ignored.

Return Values
If the function succeeds, the return value is nonzero. Because the function executes asynchronously, a nonzero return value indicates that the shutdown has been initiated. It does not indicate whether the shutdown will succeed. It is possible that the system, the user, or another application will abort the shutdown.

See Also

See microsoft.com for more information regarding this function.

See the ATEasy Getting Started manual for more information of how to define an call an external DLL function.

List of issues/changes for ATEasy v4.0 build 94 and ATEasy v5.0 build 104 - Published on 12/5/2005

12/5/2005

Here is the list of changes/issues resolved in build 104a/94a. Changes in [ATEasy5] are specific to v5.0 (104a), changes without [ATEasy5] applies to both build 94a and 104a since 92a and 102a was released.

IDE (development environment)

Property page of Precise,Tolerance, or Min/Max test types displays "Out of range" warning when enter a hex value between 0x80000000 - 0xFFFFFFFF.

'Insert Driver' dialog does not display correctly, controls sometime overlap each other

Viewing/Saving ATEasy program in text mode (.pgt) results in REFX values printed/displayed as decimal rather than hex.

ATEasy sometimes crashed when it tries to load/import Function Panel file (.fp) of Version 3.0

Unable to select HiMetric scale mode from AForm's Scale property page.

Auto Type Information tooltips does not display the description of the attached procedure when hovering the mouse over command item.

Go To Definitions Of 'xxx' does not show the command when "if" is preceding the command

DLL procedures are checked twice when using Check All

New option to clear the Build Log before build

Function Panel files (.fp) conversion/import was improved

Compiler error generate an internal error for struct variable.enumfield.constant

Code Completion should not displays enum constants when entering '.' character after variable of type enum

Command is not properly updated when insert/delete its attached procedure's parameter(s)

'Goto Defnition Of' does not work for Struct types in the Code View

Call Completion listbox window's width is not calculated correctly

Problem undo/redo AForm's menu items

Unable to build stand-alone EXE in Windows 95/98/Me.

A breakpoint at the last line of a test only works if it's right after the last line of code.

Find dialog hang when searching for non-exist symbol in active view only and current active view is the local varariables frame.

Escape sequence string support for AComboBox and AListBox controls.

App.ModulePath property has been changed to return the ATEasy folder instead of the application EXE file path when running from the IDE.

Module protection did not protect the documents from viewing / changing in all cases.

Enhanced Font property page of form and controls to include font scripts (e.g. Western, Hebrew etc...).

ATEasy will detect if a wrong version/build of the ATERT.DLL is used.

ATEasy may crashes when loading invalid or corrupted project file

Renaming project file name may crashs ATEasy if File tree view is the current active view of the Workspace window.

Watch window generates 'access violation exception' after entering build-in procedure name (e.g. Sin, Cos, Abs, Round etc...) into the watch list.

Duplicate items in call stack when paused in interrupt handler or Dll call back procedure.

[ATEasy 5] ATEasy crashed when importing IviConfigServer.h header file and ATEasyPreprocessor.h is missing

Run-Time

During Run-Time Error processing, Ignore statement in OnError() cause ATEasy to crash

'Unsupported MSXML2 type' error when inserting Microsoft CML, v5.0 type library

Program's Status property is not reset to NONE before run

ATEasy crashed while running example Excel project

Repeated Ignore of "Unable to open interface for driver" errors which occurred in IOTable caused ATEasy to crash

Redim preserve of array of struct containing field of type Object crash ATEasy

Unable to print enum's constants (i.e. PRINT enumATestStatus.PASS)

Text file (.drt, .pgt) loading is terminated when encounter an unclosed string, e.g. "xyz, as supplied parameter in command

Changing Form.Backcolor does not update the background when AutoRedraw is TRUE

Form.PopupMenu method does not work if the popup menu does not belong to any menubar or the menubar is not visible

Setting the Form.AutoRedraw to True for MDI form will corrupt the display of its client area

Unable to close or save changes in Users dialog after selecting 'Clear User'

Compiler error when references non-public nested menu , e.g. Menu1.Popup1.Item1, while inside a form event or procedure

Omitting the error number from the catch module statements, e.g. CATCH MODULE DMM, generate "Expected end-of-line" compiler error

Array of procedure does not get initialized with its initial value when running in EXE mode

WSReceive() erroneously return 0 if the remote socket was closed instead of -1 as documented in the Help

Form's mouse cursor change does not take effect until the mouse is moved

Unable to load ActiveX library with version >= 10.0

Problem accessing AForm's procedures and variables using array of form

New optional EndEvents keyword for Exit statement

Val(sHexString, 16) function's behavior has been modified, it will now convert sHexString to an unsigned integer (i.e. 0xFFFF is 65,535 instead of -1)

'Unsupported Types' error when loading ActiveX library containing 64-bit integer data type

Generates OnQueryUnload and OnUnload events for MDI child form when its parent MDI form is being destroyed.

ATEasy EXE will detect if a different build is used for ATERT.dll and ATECTL.dll

ATEasy crashed when run TestExec project more than one and m_stRunTime struct is being watched in the Watch view

New aFlagsExit flag was added to enumARuntimeFlags which can be used to indicate whether an Exit EndEvents statement has been executed

Optional EndEvents keyword to be used with Exit statement (i.e. Exit EndEvents)

AProgram's Uut information is not serialized in text mode.

[ATEasy 5] Fixed several bugs related to 'Optimize Short Circuit Boolean Expressions'

[ATEasy 5] Added supports for callback procedures, this feature provides a way for an external instrument driver (i.e., DLL) or Windows API to call ATEasy procedure when a certain event occurs.

[ATEasy 5] Added supports for late binding COM/.NET events using AddHandler and RemoveHandler statements.

Library

AForm's DrawText() does not return the width and height.

AForm/Acontrol's Image property does not return the content if window is not visible or covered

MDI child form's OnQueryUnload and OnUnload events are not generated when its parent MDI form is being destroyed.

Problem Inserting AChart control into design time dialog of Visual C

Using Common Dialog with multiple selection files does not return the selections

APicture.Render() method does not work

AControl. Creating a control from text file (property bag) will use the control name as the caption instead of the Caption/Text stored in the text file

AToolbar with labels displays fixed width buttons instead of variable width buttons base on the button's text

When a modeless form is unloaded, its parent form was not activated

ALabel's appearance always look 3D regardless of the Appearance property setting

Some of ALog's events were never generated.

ALog.Find() method does not work

AForm.DrawText() does not use FillColor as background when FontTransparent is True

AForm.DrawText() method with aformDrawTextVCenter draw mode does not center the text vertically (text is a bit down)

AForm.Circle() method uses the ForeColor as default color instead of the FillColor

AForm.Circle() method ignored lArcStart, lArcEnd

Calling ComSend to send a BString with # of bytes equals 1 fails

Calling ComOpen after ComClose with no delay between cause ComOpen to fail

ComSetup - XOn/Xoff Setup sometime does not work

Form's General property page should not restrict ClientWidth and ClientHeight to 102 and 27 respectively

ATEasy crashed when the focus was changed while inside one of Form's KeyPreview events.

The run-time will detect different version of ActiveX libraries when running EXE.

AListBox control's OnClick() and OnMouseDown() events are not generated for left mouse button

Setting AForm's menu bar dynamically at run-time (e.g. Form.MenuBar=menu2) causes ATEasy to crash on the next run or exit.

MsgBox and InputBox always enable its owner window when close regardless of whether the owner was previously disabled.

[ATEasy 5] Enhanced ACommonDialog control to support directory selection using acdlgOpenOptionsDirectory option.

[ATEasy 5] AListBox control with CheckBox style and contains no item (empty) may cause ATEasy to crash

[ATEasy 5] ATab control's OnPageSelChange() event does not set 'PageNew' parameter correctly

[ATEasy 5] Added supports for .NET assemblies.

[ATEasy 5] Added supports for dynamicly created controls using AForm's InsertControl and RemoveControl methods.

TestExec

When CLEAR LOG is pressed after START, the font and log alignments are not as they should

OnReset called twice after we call the reset statement

Fixed problem related to RunProgram command.

[ATEasy 5] Replaced all occurences of 'Exit' statement with 'Exit EndEvents'

Drivers

SM204X ATEasy Driver Diode Range off by 1

All ATEasy DIO drivers DioGetDriverSummary generate RT error

TE5200 ATEasy driver problem

New and updated DLLs for various Geotest drivers

Setup

When installing a new ATEasy version/build, personalized settings disappear.

Setting form variables and calling form procedures from the creator of the form before the form is displayed. - Published on 9/1/2005

9/1/2005

Solution:

For a modeless form (Load frmVariable, FALSE):

1. Use frmVariable.variableName where the variableName is a form’s public variable.

2. Use a form procedure to set or get the variable’s value. For example:

frmVariable.SetVariableValue(value)
frmVariable.GetVariableValue():type. Note: procedure must be public.

For a modal form (Load frm.Variable, TRUE):

The caller cannot set the variable or call a procedure because the control does not return to the Load’s callee until the form is destroyed.

1. You can use a Module (program, system or driver) Procedure or a variable to retrieve a value and use it in the OnLoad Form Event.

2. You can create the form as modeless (as shown above), set the form’s variables, call the form's procedure and use the Load statement again with TRUE as the mode parameter. See the example below:

Load frmVariable, FALSE
frmVariable.variableName=value
frmVariable.procName()
Load frmVariable, TRUE

Note: This procedure can only be implemented in ATEasy 4.0 (build 94) or ATEasy 5.0 (build 102b and above). You can initialize the form to be hidden and then show it just before the second Load statement (frmVariable.Visible=True). See the example below:

Load frmVariable, FALSE
frmVariable.variableName=value
frmVariable.Visible=True
Load frmVariable, TRUE

This added line (line 3) will prevent the user from accessing the form control before the form is ready.

Acquiring data into a file/database without interrupting the current acquisition process. - Published on 8/26/2005

8/26/2005

Problem:

I am trying to get more functionality from my IOTech DaqLab 2000. I have data acquisition on 32 channels that run at about 1Hz each. This data logging is uninterrupted for days at a time. I would like to be able to look at old data without interrupting the current acquisition. I would prefer one continuous file or a database like Access or Oracle that could be viewed and manipulated while the data is logging without causing any data loss.

Solution:

In ATEasy, you can write a small program that can gather a DAQ’s data and insert it into a text, binary, excel, or database file. You can use IOTech’s DLL functions to gather data and the ATEasy internal library for everything else. The ATEasy Getting Started Manual, which can be downloaded from the Geotest web site, discusses DLL function implementation.

There are several ways to write to a database file. In the ATEasy Getting Started Manual, an example is provided to show you how to use the Microsoft Active Data Object COM Component (see also the AdoDB.prj example). This library supports a long list of databases that includes Microsoft Access (.mdb files), SQL Server and Oracle.

You can also read and write to a database using an ODBC driver or a DLL.

ATEasy 5.0 Main New Features Summary - Published on 11/9/2004

11/9/2004

Solution:

ATEasy 5.0 Main New Features Summary

Enhanced Test Executive with:

Touch Screen user interface; allows operation of test set via touch-screens with a special customized toolbars.
Users and Groups based privileges and customization; the administrator can customize the test executive per user groups without writing code. Each option and each menu command can be hidden or disabled. The toolbar buttons can be also customized per group and its buttons can be hidden or arranged. User can use the administrator set of customization and customize it further if the administrator allowed it.
Complete customization of toolbars menu with or without using users and groups feature.
Many new options including: selection of debugging level for the operator – allows the test engineer to disable selection and running of individual tests or tasks, log failures only.
New commands for better controls of the test executive options and behavior. New test conditions, option to disable menus while program is running, Windows XP style menus and much more.
On-line Help for the test executive to provide detail on how to operate and customize the test executive.

New Fault Library:

Fault Library provides a powerful troubleshooting tool for electronic circuits.
A Fault Editor allows program developers to define Fault Conditions to be analyzed by ATEasy during runtime.
When activated during runtime, the operator can be prompted to replace assemblies or components based on the actual failures (i.e. “Replace U1 and Re-Test”).

Open Architecture Improvements:

Built in support for IVI drivers. ATEasy now includes ATEasy drivers for all the IVI driver classes currently available (DC power supply, Digital multimeter, Function generator & Arb, Oscilloscope, Power meter, RF signal generator, Spectrum analyzer and Switch. ATEasy also support of importing non-class compliant IVI drivers using a new IVI Wizard and support both IVI driver formats: IVI-C and IVI-COM
Support for .NET components .Net. assemblies or assemblies components can be imported to ATEasy and used similar to the way you would use them from Visual Studio .NET languages. This capability provides a truly open architecture by embracing new technologies and is similar to the way COM and DLL extend ATEasy capabilities.
ATEasy can now import functions and type declarations directly from C/C++ header file (.h). This reduces the development cycle and eliminates any errors when calling external DLL library.
LabView VIs – ATEasy users can now use existing LabView code in their test applications. All the user needs to do is selects the VI (Virtual Instrument or LLB (library) file and the ATEasy Insert LabView wizard generates an ATEasy procedure to call the VI.
Lab Windows Function Panels Drivers (.fp) import was improved and generates more accurately ATEasy driver from LabWindows drivers – this feature allows users to use these drivers without the need to re-write them.
ATEasy now includes a Summation Import Wizard that allows import of Summation TestCase programs into ATEasy.

Enhanced Forms Features:

Two new controls were added: Tab Control (ATab) and Panel Control (APanel)
Current controls where enhanced. For example, the AListBox now support a list of checkboxes. Additionally, Controls now have the XP theme look and the AMenu support the new .NET style menus..
ATEasy forms now support automatic form and controls sizing. Similar to .NET controls, each control can be anchored and aligned. This allows users to implement sizable forms with minimal coding to size the controls when the form is sized.

Programming Language Enhancements:

New support for COM events handlers using the AddHandler/RemoveHandler statements. This allows users to interface with COM applications that generate events.
ATEasy now supports callback procedures. ATEasy procedures can be called by an external DLL directly. This feature provides a way for an external instrument driver (i.e. DLL) to call ATEasy procedure when a certain event occurs. Windows API also uses callbacks.
Internal library have new bit manipulation, help, log functions and more. Also new classes properties and methods extend the internal library further.
Support for 64 bit integers.

Other Improvements and Enhancements:

The Integrated Development Environment (IDE) has new dialogs such as Save Modified, new popup Conditions menu and new menu commands. Additionally, many editing features were added or improved.
Many new additional ATEasy drivers.
New examples

And much, much more…

How to Customize log string for the program header - Published on 6/9/2004

6/9/2004

Solution:

ATEasy generates the following test log string when a program is start to run. The output is generated after the Program Init events are called as shown here:

Program  : Program5
UUT  :
Serial #  :
Start time  : 6/9/2004 9:21:46 AM

--------------------------------------------------------------------------------

To customize the test log program start string you need to add some code of the Program Events OnInit() and OnInitTask(). If the change is for all programs in the project you can place ad the same code in the System Events OnInitProgram() and OnInitTask().

The code in OnInit/OnInitProgram should load the your form with the special serial number / uut information and than set the log off to prevent ataesy from output it log string and than, output your own customized log string.

Program.OnInit() or System.OnInitProgram()
{

! display my serial num form
Load frmMySerialNum

! Take control over log printing for this event!
SetLogOff()

! print to log (two ways

! one way is to modify the ateasy log string
! s=GetLogString()
! modify s using Mid., Pos etc
! print s

! second way is to output a completly new string, (shown here is the default log string)

print ";" \
   ""; \
   ""; \
   ""; \
   ""; \
   ""; \
   ""; \
   ""; \
   ""; \
   "

"
}

The code shown above is for HTML test log you can make your program works for HTML and Text by using the Log.PlainText property:

If Log.PlanText
! print text
else
! print HTML
endif

You can figure out the ATEasy default log string by right clicking on the log window and selecting View Source from the menu.

Finally in OnInitTask we have to enable the log again:

Program.OnInitTask()
{
SetLogOn()
}

Using ADO to Access a Database from ATEasy - Published on 6/3/2004

6/3/2004

Solution:

Note: ATEasy 5.x and above provide a more elaborate example (AdoDb.prj) for accessing database from ATEasy.

The following describes how to access database using ADODB Active Data Objects) ActiveX library:

Add ADO (Active Data Objects) type library to your module libraries (You must have VB or Access installed on your machine).

The following code shows how to open a database for R/W (Declare rs as ADODB.Recordset and sSrc and sCon as String):

rs=CreateObject("ADODB.Recordset")

sSrc="SELECT "+m_sField1+", "+ m_sField2+" FROM "+m_sTableName

sCon="Provider=Microsoft.Jet.OLEDB.4.0;Data Source="+m_sDataBaseFile

rs.Open(sSrc, sCon,,adLockPessimistic)

Notes:

m_sField1 and m_sField2 are database field names
m_sTableName is the database table name that contains m_sField1 and m_sField2
m_sDataBaseFile is the path to the database file.

The following code shows how to read a field in the current record:

rs.Fields.Item(m_sField1).Value

The following code shows how to set a field in the current record, then update the record:

rs.Fields.Item(m_sField1).Value=Value

rs.Update()

The following code shows how to move to the next record:

rs.MoveNext

The following code shows how to close the database connection:

rs.Close()

You can browse on the library object and classes if you need more operations. If you need more help on this select the ADODB library from ATEasy under Libraries and press F1.

ATEasy 4.0 build 92 changes - Published on 4/5/2004

4/5/2004

Solution:

We have release a new build of ATEasy 4.0.

The new release includes several bug fixes that were found since build 90 was released and some new features as shown here:

Run-Time

1.   Form.Refresh method did not invalidate the rectangle and only update the window.
2.   Non-public form procedures and events were accessible outside the form even if they are not public.
3.   Error in Catch block need to be sent to outer Try Block instead of the current one.
4.   Path of CompanyLogo.gif in the test log was changed to absolute from the ATEasy folder. This allows proper display of the log file from any folder.
5.   When running from the IDE OnEnd for drivers sometimes did not get called.
6.   Assignment of Driver type Structure that is alias (typedef) to a driver DLL type structure to a literal in a program fails loading of EXE. Executable returned ‘Unknown Error’ when running EXE.
7.   GPIB IO Table timeout with NI board does not take effect unless with set the timeout in NI max properties.
8.   Setting App.StartProgram before the start program gets called did not had any effect.
9.   Tolerance test display +3/+0 instead of +3/-0 in the test log.
10.  Assign a variant array member which is also an array into another variant generated run-time error #310 : 'Unable to assign a value'.
11.  Using function that return a structure field will crash at run-time.
12.  Hour glass is displayed when the EXE is loaded.
13.  Calling the Abort statement twice will terminate the application.
14.  Calling ExitTest statement from OnInitTest will skip OnEndTest.
15.  Nested modal forms may hang if no messages are available in Windows queue.
16.  After Run/Start, calling Form.TextWidth second time loading same Modal form returns 0 instead of the actual width.
17.  Test.Type property can be set at run-time.
18.  Form.Tag, Control.Tag type was changed from string to variant.
19.  Double precision test type Min/Max/Tolerance Pass/Fail status is evaluated within a 1e-15 tolerance rounded result to avoid floating point errors.
20.  Run-time now supports changing the test type at run-time.
21.  Allow assign of array literal with different dim size but same count.
22.  Assign incompatible data type to initial value of indirect data type VARIANT/DOUBLE/DATETIME/CURRENTCY leaked memory.
23.  When calling abort or reset statements ATEasy print ..."Application abort or reset  by user" instead of "Application abort or reset".
24.  MF42CLOC.DLL causes ATEasy to display ??? in various message boxes and in the Control property pages names.
25.  When calling DLL function stack miss-match is now reported if the function is prototype with wrong number of parameters or wrong CDecl/StdCall DLL function definition.
26.  Passing a string to VAR Any passes the address of the address of the string instead of the address of the string.
27.  Passing NULL to DLL procedure’s parameter of type VAL OBJECT generates 'Internal Run-time Error # 28'.
28.  Passing 'NULL' to DLL procedure's parameter of type [VAR] STRING generates compiler error # 620 'Expected l-value'.
29.  Passing 'Nothing' to DLL procedure's parameter of type [VAL/VAR] ANY no longer working (did not pass NULL).
30.  Compiler Error # 650 "Type 'Object' is undefined" when calling DLL proc which has parameter of type [VAL] OBJECT.
31.  Run-time error #310 'Unable to assign a value' when accessing the returning struct's members from a call using Procedure variable.
32.  s=FuncReturnVariantContainsStringArray()[0] caused GP fault.
33.  Print ProcReturnComplexStruct().m_ArrayOfStruct[0].m_lField1 caused GP fault.
34.  Changing TestStatus (i.e. to FAIL) at OnEndTest() event does not have any affect on UUT Status (GetUUTStatus()).
35.  StringArray2D[0]=ByteArray1D generated a GP fault.
36.  Calling DLL procedure with parameter of type VAR BString generated "Memory Access Violation" run-time error.
37.  Assign DateTime to Variant will result in vtDouble instead of vtDate.
38.  Goto a label within  the same TRY block generates run-time error #330 - 'Catch or EndTry executed without Try'.
39.  Unable to 'Ignore' recoverable error inside a CATCH block.
40.  FileRead() should not allow reading more than the size of the Fixed size string.
41.  Log.Append will not display the image unless an absolute file path is stated.
42.  Assignment of array of bytes to string assignement xcaused internal error -33 line -2
43.  MemoryCopy() does not work between array element (string/byte).
44.  FileEOF() always returns zero, even when end of file is reached.
45.  Changing procedure variable to parameter, setting a constant value, and than changing parameter to var or val causes ATEasy to lock.

IDE (integrated Development Environment)

1.   Variables property page. Changing procedure variable parameter from none, setting a constant value, and changing parameter to var or val causes ATEasy to lock.
2.   Debugger. Aborting the application from the IDE when the form.OnLoad() is in process causes ATEasy Crash upon when Call Stack view is open.
3.   Driver shortcut Interface property page. Unable to populate I/O address IO1 with a range of values in the drivers properties/interface section.
4.   Text file format. Constants variables should display their initial value even if it’s the same as the default value.
5.   Paste Bellow command was enabled for the text editor.
6.   Code completion displays function prototype in a different format than text file format.
7.   Paste a procedures to procedure view with no procedures will crash.
8.   Switching to another user with the same access rights should update menus and views with the new access rights.
9.   After loading ATEasy, pressing TaskIt does not necessarily run the task that is shown by the cursor (as gray, not blue).
10.  Do not allow drag anything to enum unless it has long + const
11.  Globals. Internal Page did not display correct value for CONTROL and FORM variables.
12.  ATEasy crashes when the command line is missing the file name after the option flag (e.g. /b).
13.  Changes in the current user’s access rights (because of log in) was not reflected to the IDE only after the IDE was closed and open again.
14.  Setting the initial value of Optional Variant Val Parameter to 'Nothing' will crash ATEasy upon Save.
15.  Converting a number that start with a ‘.’ (i.e. .234) failed when serializing with text file format and from property pages.
16.  Command parameters font is using the code editor font.
17.  Parsing commands built-in arguments sometimes failed.
18.  Changing public attribute of module variable from the variables property page cleared initial value.
19.  Double click on a Form will not open the form if we have a browser window open with Forms selected and the form selected in the object view in list mode.
20.  ATEasy Crash with ProgramIt after setting the active project.
21.  Description in the property page. Tab setting is not the same as in the description view.  Pressing enter in the description of the property page will insert a new line. Word wrap was also enabled.
22.  Under Windows XP the tree/list view will not show the selection if the window does not have focus.
23.  Comparing two drivers that turned out  to be identical display a very big message box.
24.  The new address when changing the address of a driver from the driver shortcut property page does not always save.
25.  Test Property Page. Changing the test type from Min Max to Tolerance or Precise should reuse the values.
26.  Change the test type  from MIN-MAX to TOLERANCE gets caught in an endless loop
27.  Importing FP that uses the new 5.1 specifications crashes ATEasy.
28.  Missing files when opening Drivers.wsp (GP1008.drv, GP1650.prj and GT1648.prj).
29.  When trying to copy constants from one ATEasy DLL driver to another (replacing all existing duplicates), the program hung up and did not respond to Windows.
30.  Clicking on a menu procedure when the properties window is open will cause the document to be modified.
31.  Sorted List sym view did not refresh correctly after deleting an item.
32.  Occasional crash when running Language and aborting out of multi-threading task.
33.  Monitor Window crashes when Clear with Properties Window open.
34.  Bitmaps displayed in menus and toolbar have transparent look when running on XP.
35.  FileCreate/FileOpen mode enum displayed in decimal instead of hexadecimal.
36.  Watch window's display format "All Hexadecimal" caused Bool var to display Hex instead of True/False.
37.  Watching variant of type VT_UI4, VT_UI2 (reference) crashed ATEasy.
38.  Struct displayed in Watch or CallStack windows will crash ATEasy after Redim the struct's field of type BString array.
39.  Redim array which is currently expanded displayed  in global call stack caused GP fault.
40.  Not all of ATEasy Context Menu update handlers are checking user's rights - for example enabled Edit/Save/View doc for Tester.
41.  Breakpoint after the last line of code disappear after refreshing the code view as result of window close or display of different symbol.
42.  Run-Current-Task, etc. are enabled even though there is no program module for the project Start-Program and there is no System module.
43.  Loading text file with version's time beetween [Dec 31 69 16:00:00] and [Dec 31 69 17:00:00] crashed ATEasy.
44.  Internal run-time error #1 when running EXE which contained a module event with local variables and empty code. (i.e. program's OnEndTask()).
45.  Startup dialog hang if the recent workspaces list contains a workspace file from a disabled (Power Off or removed from network) network's computer. (i.e. //UNIT219-01//ATeasy//Workspace.wsp).
46.  Run-time sometimes stops at breakpoint that is no longer exists.
47.  View in Text Format will display current date and user instead of the original one.
48.  Project’s Start program is now displayed in bold in the workspace window.
49.  Build All will now generate warning if a defined DLL function does not exist in the DLL.
50.  License Server was modified to run as a service. Server-client communication was improved. See ReadMe.txt for more information.
51.  Code Completion will not work for non-project modules.
52.  Text format for ATEasy modules doesn't include Stdcall/CDecl attribute for DLL procs.
53.  Changing 'Untitled' Task/Test's title using property page does not update the test/task's Id to a new id based on its name.
54.  Saving new module file as a text file format saved it in a binary format.
55.  Reloading a driver file since it was modified externally causes the system to be marked as changed.
56.  Edit-Find-Replace dlg FindAll flag cannot be remembered correctly - registry says All (True), but ATEasy does not come back with the All option checked.
57.  Find in current document doesn't search in menu items until a menu item has been selected.
58.  Find-Replace All OldName to NewName can get into very tight loop when there already exist two procedures named OldName and NewName and RenamSym fails on proc OldName because proc NewName already exists.
59.  Opening a driver shortcut property pages and changing the driver file name to an invalid file name and switching to Misc. page crashed ATEasy.
60.  Access violation opening test in Tests view. Test is under nested task.
61.  62Sizing of Members list/Parameters Suggestion for code completion is now remembered between sessions of ATEasy and between subsequent displays.
62.  Goto Definition of internal library symbol (i.e. enumATestStatus) in a project without a system (i.e. Language) crashed ATEasy.
63.  Drag and Drop is now allowed from one DLL to another.
64.  Endless "Illegal Type" message box when viewing parameter of type optional VAR ([VAR]). For example, Add method of treeview's nodes collection.
65.  File difference can now use a folder in one of the fields From/To instead of a file.
66.  Changing Project Defines should invalidate all compiled code.
67.  After pressing Ignore in the dafault error handling the status bar continues to display in red the error message.
68.  Changing procedure's local variable of type Fixed string to Val/Var parameter generated endless "Illegal Type" message.
69.  Run/Doit! will remove newly typed text of the Debug window.
70.  I/O address in the ISA Interface property page is not saved.

Test Executive

1.   Hour glass is displayed when filling the tree view when a new program or a profile is selected.
2.   New commands to set wait cursor.
3.   New commands to set the status bar.
4.   Status bar will display driver initialization progress when the test executive is started.
5.   TestExec will run a task with out being checked after test -1 statement
6.   Menu and Toolbar Icons support the XP transparent Style, Also images are now included for all commands
7.   OnEndProgram. Move print of the GetLogString to the beginning to complete the test log before calling other drivers OnEndProgram (e.g. they  might call SaveLog).
8.   After user login, the string for the log header does not updated by the new user name.
9.   Test Executive has a new command to set the CompanyLogo.gif file displayed on the top of the test log.
10.  When loading a program to the tree view program tasks are not get expanded to save loading time.

Examples

1.   Language.prg Example has new test showing how to use DLL CDecl function call. Th example shows call to atof() using MSVCRT.DLL. also added new examples for Variables, Structures and more.

New Drivers

1.   HW.drv does not return the board description.
2.   GT1648.drv - New driver for the GT1648 - analog output.
3.   GX5731.drv - New driver for the GX5731 - digital I/O with 128 channels and 32 customizable channels PXI board from Geotest.
4.   GX1648.drv - New driver for the GX1648 - analog output.
5.   GX1838.drv - New driver for the GX1838 - programmable discrete outputs.
6.   GX5050.drv - New driver for the GX5050 - 50MHz digital I/O.
7.   NvNT5000.drv - New driver for the NX500/NT5000 ROM emulator boards from Navatek.
8.   PiLPxi.drv - driver for System 40 PXI switching board from Pickering Interfaces.

ATEasy 4.0 - What's new - Published on 10/7/2003

10/7/2003

ATEasy version 4.0 contains numerous enhancements to the test development environment. Among the new features included are the ability to import Function Panel (FP) driver files and convert to ATEasy drivers, Integration with Microsoft Source Safe, the ability to show and edit ATEasy documents in text mode and to display file differences side by side. The Test Executive driver was enhanced greatly and uses a new Profile driver that allows you to create and run a profile that is a subset of the application programs, tasks and tests in a user specific/defined order and count. Version 4.0 also contains enhancements to the ATEasy run time engine. New functions were added, for examples, functions to read and write directly to physical memory, which can be useful when writing or creating drivers or prototype to PCI boards. We also improved the speed of the run time engine so that it runs ATEasy application 30% faster than version 3.0. The following lists new features available in ATEasy 4.0:

Open Architecture

Ability to import Function Panel driver files. Function Panel driver file (.fp) is a file of a specific format used by software packages (LabWindows and HP VEE) drivers. The function panel file format is based on the VXIPlug&Play Instrument Driver specifications published by VXIPlug&Play organization (http://www.vxipnp.org). Using the File Open command a Function Panel file (.fp) can be opened and then, converted to ATEasy driver format (.drv). ATEasy will generate a command tree, procedures, DLL function calls, constants and data types as defined in the function panel file and its accompanied C/C++ header file. ATEasy also loads an optional SUB file, which commonly used by IVI drivers.

Source Safe Integration. ATEasy directly interfaces with Microsoft Visual Source Safe. You can 'source control' ATEasy documents/files: Add, Check in, and Check out files directly from ATEasy. It also allows comparing files between versions of ATEasy and showing their versions. Differences are clearly marked and highlighted.

You can edit or view in text mode ATEasy documents, Program, Driver, System and Project, directly from ATEasy.

Command line options allow you to log on to ATEasy as a specific user, as well as allow you to build an application, print a file or load a file to ATEasy.

IDE User Interface

Startup dialog allows opening examples, driver examples and recent workspaces files or create new files or an application using the Application Wizard. This dialog can be programmed to show up at the start up of ATEasy, as well as it is available from File menu command.

Workspace Window has a new Files Tab. The current workspace window is displayed in the Objects Tab while a new tab, Files is showing each current workspace file. This provides a simpler file view of your project file and faster navigation between files.

Workspace window. When ATEasy starts up, the active project is expanded, and Files/Objects tab and selection is restored.

Description button was added to various views. The description view now has a button, displayed on the module view (new), the Forms, Procedures, Tests, and Commands View that can show or hide the view. The button has an indication to show whether the description is empty or not.

Description of objects (sub modules, etc) was enhanced and is more self-explanatory.

Module view. A new view is shown when you click on a module (e.g. Program). The new view displays the module's sub-modules and a larger area containing the module description.

Find and Replace dialogs. They have new options to skip the internal library and whether to re-start the search when the end of file is reached ('All').

New Program is now created with a Task and a Test.

Insert Object Below/After/At menu command now displays the type of object being inserted, e.g. Insert Variable Below.

New context menu to show/hide toolbars and dockable windows.

Display documents and type libraries progress during ATEasy loading a workspace in the status bar.

Selecting colors from the property pages (e.g. chart, status bar) was enhanced and allows using system colors for controls.

ATEasy notifies you if another application or user modified externally the document that you are currently working on.

Save As Text context menu command allows saving the current file in text mode (same file name with text file extension) without prompting.

Variables and their types (and initial values and descriptions) can be typed directly when renamed from the list view. Additional command was added to perform the in-place editing of the name and type of a variable (Ctrl+F2). For example, you can type "i:int=3!index starts at 3"

Application Wizard was enhanced to support the new Profile driver.

Programit! New command lets you execute any program, which may not be the first one.

Go to Definition. New menu command (and context menu) opens a window containing the definition or type of the selected symbol. This is a convenient tool that you can use during coding.

Project has an optional setting (in the project property page) that allows including or excluding unreferenced procedures during build.

Certain List view such as variables can now be sorted by Name, Type or Description (display only) by clicking on its column header.

In the procedures or form view, the procedure combo box provides the Drag and Drop capability. After pulled down the combo list box, you can drag and drop a procedure within the combo list, so that you can re-arrange the procedure list.

The Build menu, Check All includes checking of making sure Dll procedures defined in a module (under Libraries) actually exist in the Dll.

Debugger

Auto Data Tips - ATEasy will display variables values on the code view in a tooltip window during debugging when the application is paused.

When an application paused via break point, one can view each variable/parameter value in the variable/parameter view.

Watch and CallStack/Global windows will retain the values even after the current run terminates.

Run Time Engine

Speed Improvements. Run-time engine runs ATEasy application faster, at least by 30%.

Peek and Poke functions. New functions to read and write directly to the PC physical memory. This is mainly to support PCI/ISA boards driver development.

MemoryCopy function. New function to copy and fill data between two ATEasy variables.

ArgMissing function. New function to indicate whether an optional parameter was passed to a procedure.

DoEvents function. New function to allow form events to be nested. Useful when performing long operation in a form event.

Redim statement. New statement to change the dimension of an array size programmatically.

AClipboard class. Allow you to perform clipboard operations and to transfer data between applications (Cut, Copy, Paste, Clear).

AChart, ASlider, ASwitch controls uses the control area better and optimized more.

EndEvents keyword. New optional keyword to be used with the Run, Task and Test statements.

HTML Log uses CSS style sheet that allows changing the test log format attributes easier, e.g., font, color...

ADriver.InterfaceType can be set during run-time.

Test Executive and Profile

Added support to Text and HTML log format.

New Options dialog allows you to specify the default Log format, Clear and Save log before run.

The main window can be divided to two main panes. The left pane, the Tests Pane displays the program tests while the right pane, the Log pane shows the test Log as shown the previous test executive version.

The Tests pane displays in a tree the available tests of the current selected program or profile. A check box appears next to each Program, Task or Test. The user can select individual tests, tasks and programs from the Tests pane to run from the Tests pane. Program or Task is displayed in bold if they are partial selection (e.g. one test is checked and one is unchecked).

At run-time, these tests are color coded to reflect the test status at run time (black for none, green for Pass and Light Red for Fail and Red for Error).

The left pane bottom area displays the current selected test properties such as the test Name, Type, Required, Result and Status. At run-time it shows the current running test properties.

The Log, Tests and Tests Properties panes may be visible or hidden from the View menu. At list one Tests or Log Pane must be visible.

Window position and size and Log Options are remembered between sessions.

New Profile driver. The profile driver allows the user or the test engineer to create profile files for an application. A profile file contains tests, tasks and programs list that can be executed in that specific order and count.

Test Executive can dynamically supports the new Profile. Adding the profile to your system and the Profile command will show in the test executive menus.

New Examples/Drivers

Hp34401a, FP driver - example for a converted function panel driver.

MultiPad example - example for MDI application that provides text editor similar to NotePad.

HW example - example for Port I/O, Memory I/O and PCI device handling.

Additional drivers (Geotest, Adlink, UEI, PC Instruments and more).

ATEasy 4.0 build 90 – Release Notes - Published on 7/22/2003

7/22/2003

Solution:

IDE/Run-Times New Features/Changes

1.   AApp.Flags - new flags and re-organizing existing flags. The new flags were added to allow the test executive to synchronize the tree view and the execution after the application uses the Run/Task and Test statements.

2.   Call Stack window will display binary/hex values of Bool type variables

3.   You can override an internal function by declaring it. ATEasy will call your function instead of the internal one. You can still call the internal one using Internal.Function Name

4.   Drag and drop inside the procedures combo box was added. Also, the drop down list is stayed dropped after dropping

5.   The debugger will pause after stepping/tracing on the last line and will let you examine local variable before exiting the procedure

6.   Leaving Task and Test ID empty should cause their property page to regenerate new Ids
7.   Source Safe. Check In will always save the file without prompting the user unless it is a read-only file.

8.   Source Safe. Check Out/Undo Check Out will not prompt the user to save the changes. (This is unnecessary since the file will be replaced by source safe.)

9.   Source Safe. If the file is under source control and was not checked out, any attempt to modify it will be ignored, or the user will be prompted to check out the file. (Depends on the setting of the new "Check Out When Edited' option).

10.  Insert At/After was added to drag and drop depends on the position of the mouse cursor

11.  When debugging (e.g. Doit!) the run-time thread is kept until you restart the application again. This allows DLLs to retain their initialization between subsequent DoIt!s. DLLs and Applications will now initialize and load only between different starts.

12.  Insert Command will prompt for code completion for parameters

13.  DLL libraries can be merged using drag and drop

14.  Control, Form, and Menu property pages supports escape sequence strings in Caption and Text properties

15.  Recent page in Startup dialog has a new button called “Other” that allows opening other files that are not listed in the list

16.  During pause, debugged forms remain painted to allow you to examine the run-time form while pausing

17.  Step-Out is now enabled and allows stepping out of a test

18.  Step Over will not activate the application form causing debugging a form using the Step Over to cause flickering

19.  CreateObject/GetObject now supports "LibraryName.ClassName" or "Class" instead of only supporting the registry ProgID

20.  Any type is now supported as a variable type and not only as a parameter to a DLL procedure

Compatibility

1.   It is recommended to rebuild your EXE application before using it on the new run-time engine. This is especially needed when running applications that contain the test executive driver.

Bug/Issues

1.   Compiler. Compiler error was mistakenly reported 'Function has no return statement' when performing CheckIt! on a function

2.   Compiler. The statement "if lAttrib or ~0xA0" did not generate compiler error

3.   Compiler. Checkit! On a module shortcut caused the containing module to be checked instead of the module.

4.   Compiler. Doit! generated compiler error on no-return statement

5.   Compiler. Did not generate error for Val Object type with initial value

6.   Compiler. Did not allow taking address of Const variable even though it allows address of literal constant.

7.   Compiler. Problem with passing Val enumXXX from System to Program.

8.   Compiler. When system procedure with parameter type of public system enum is called via system command, the parse fails the first time, but it is OK on subsequent compilations

9.   Compiler. Structure size and member offset are incorrectly calculated if packing order is greater than 1 when loading type information from a type library.

10.  Compiler. Omitting parameter list when comparing variant to function return value, e.g."IF TestResult < GetTestMax" - will generate wrong PCode that will crash the run-time

11.  Run-Time. Assignment of array of characters to a string could crash ATEasy

12.  Run-Time. ExitTask and Test -1 statements will not work properly in Taskit mode

13.  Run-Time. Calling empty module event crashed ATEasy in stand-alone EXE

14.  Run-Time. Calling System.OnXXX event from a driver will crash if the event does not exist

15.  Run-Time. Passing variant containing array of non-object (LONG[], DOUBLE[], STRING[] etc...) to procedure's parameter of type VAL OBJECT[] (array of type object) could crash ATEasy.

16.  Run-Time. Passing a non-array variant to a procedure's parameter of type VAL array crashed ATEasy.

17.  Run-Time. Test Log tables header for HTML and text displays different strings for Text and HTML: Test-Name and Name.

18.  Run-Time. Changing Projects did not reset the FormatLogString() settings

19.  Run-Time. Late bound call to method which has a parameter which is a safe array fails

20.  Run-Time. Assigning a variant to another did not set the LValue variant type as the right side

21.  Run-Time. Passing array of string to a variant generated run-time error #427

22.  Run-Time. DoIt! of program code followed by Run-Start command did not compile or execute program events

23.  Run-Time. Form's drawing functions (Circle, Rectangle, DrawText etc...) did not work after the first usage.

24.  Run-Time. Passing negative number to Output IO table operation generated sometimes "Out Of Range" message

25.  Run-Time. Print statement in HTML mode truncated string above 1024 characters caused the log to display garbage

26.  Run-Time. Assigning structure literal to element of structure array VAR parameter generated access violation in RT

27.  Run-Time. Return statement in procedure which returns a complex type and which also has structure literal generated run-time error when run from EXE file

28.  Run-Time. Passing address of a variable to a Val parameter of type LONG generated parser error #612 'Type of argument is incompatible'.

29.  Run-Time. Setting default value of optional parameter that its type is resolved to object will crash during Build/Execute.

30.  Run-Time. Passing variable of type object to a parameter of type "[Var] Variant" generated run-time error # 407.

31.  Run-Time. The statement proc=Program.OnInit did not work from the driver

32.  Controls. Changing list item's text using List() property of AListBox or AComboBox reset item data to 0.

33.  Controls. Inserting, deleting or changing item of a sorted AListBox or AComboBox control in design mode using List property page unsorted current items.

34.  Controls. Changing round slider control's ticks spacing to non-auto (interval, division) could crash ATEasy.

35.  Controls. ALog.SaveAs will not work when Visible=FALSE

36.  Commands. Reducing procedures # of parameters will corrupt a command that uses this procedure with a constants/changed parameters

37.  Commands. Creating a command that is assigned to a procedure with two with two enum parameters does not saved the commands parameters (constants) properly

38.  Debugger. A Change in array dimension size followed by a Redim statement was not reflected in Watch/Call Stack window or code completion.

39.  Debugger. Changing display format of the Watch/Call Stack windows did not refresh the value with new format

40.  Debugger. Changing array elements in the Watch window could crash ATEasy

41.  Debugger. Char is displayed as a number in the Watch window

42.  Debugger. Aborting while in error handling OnError caused breakpoints placed in OnAbort to be ignored.

43.  Debugger. Duplicated items were shown in the call stack when paused while displaying a message box/input box.

44.  Debugger. Step Over (F10) the last line of the nested call does not always work. It behaved like Continue (F4) instead of pausing at the next line after the call.

45.  Debugger. Step out from interrupt procedure did not continue stepping at point of interrupt.  Step into when interrupt procedure is fired did not continue stepping at start of interrupt procedure.

46.  Property Page. Fixed string did not retain the its value from the Value property page

47.  Property Page. Terminator in Winsock Interface of a Driver was missing from the property page

48.  Property Page/ActiveX controls. TabStrip ActiveX control. Making changes in its property page (Remove Tab) was not caused the page to be marked as dirty and not saved.

49.  Property Page. Open On Access fro GPIB, VXI and ISA was mistakenly displayed in the driver shortcut property page

50.  Property Page. Document property page File Browse button initializes the current directory instead of the document path directory.

51.  Property Page. Form property pages of READ ONLY document does not disable some of controls.

52.  Property Page. REFX tests use as default 0x0 mask instead of 0xfffffffffffffff.

53.  Property Page. Changing the Form ScaleMode in design time will confuse the form editor

54.  Property Page. Pressing Del when the driver shortcut is selected with the Misc page sometimes crashed ATEasy

55.  Property Page. Selecting new file to replace the currently modified file using file browse dialog (instead of typing the file name) crashed ATEasy.

56.  Property Page. GPIB Primary secondary address spin button behavior was wrong

57.  Property Page. Com method/property/variable or type allowed to change its type from the property page

58.  Code Completion. Syntax coloring problem with '\"' marks the rest of the line as comment

59.  Code Completion. Replacing a string with a ‘.’ did not display the members list box

60.  Code Editor. Selecting a variable or placing the cursor at the end of the variable makes the Go To Definition disabled

61.  Code Editor. Test header did not show the Task number and name when having two level tasks or more

62.  List View. List View edit label box was sometimes too small to type in long variable name, etc

63.  List View. Types such as Enum, Struct edit labeling with F2 display the type incorrectly.

64.  List View. Commands View. Insert After, Undo, Insert Below may crash ATEasy

65.  Undo/Redo. Undo of copy/paste of multiple controls  could crash ATEasy

66.  Copy/Paste. After Copy and Paste of controls, selection of a particular button selects other control

67.  Copy/Paste. Paste into Procedures combo box disregards what is being selected, it always paste at the end

68.  Copy/Paste. Paste Task/Test did not always checked for unique ID.

69.  Find/Replace. Various problems were fixed.

70.  Source Control. Source control status did not correctly displayed status of read-only files

71.  Source Control. All changes will be rolled back after CheckOut or Undo CheckOut.

72.  Source Control. Source control file changed notification did not work under Windows 95/98/Me.

73.  Source Control. File difference combo box does not always offer to use the latest folder/file in the to combo box

74.  Options. Removed unused 'Menu Return' option from the Option dialog.

75.  Document. Menu text format serialization does not serialize the shortcut information

76.  Document. Save In Text Format on binary format document resets the document modified flag

77.  FP Document. Conversion of FP file could crash ATEasy

78.  FP Document. After Converting FP file and running the application ATEasy crashes since the FP author did not enclose a string GPIB0::5::0::INSTR with double quotes.

79.  ATEasy 2 conversion. Converting INS files IO Table with Input IO operation generates an extra argument

80.  ATEasy 2 conversion. ATEasy2 I/O table conversion did not work with Input mode "File"

Test Executive/Profile

1.   Will synchronize the tree view and the execution with the Run/Task/Test/ExitTask/ExitProgram (Task -1) statements

2.   Profile forever count did not work

3.   Test Executive will disabled itself when debugging from the IDE using TaskIt/TestIt/ProgramIt!

4.   Profile Editor Up Down caused endless message boxes to be displayed

5.   Node tags of the Test Executive/Profile stored information using array of variants instead of single string

6.   Redesigned parts of the test executive execution mechanism to provide better performance handling of flow control statements

7.   The Test Executive commands where organized and new commands where added to provide better application control

Drivers

1.   SM2040x - added/modified new ranges, added new function such as pulse width

2.   SM2020 - DMMReadBuferStr spelled incorrect, DMM Measure command uses the DMMReadNorm instead of DMMReadDbl

3.   PCI42x - DLL file name was wrong under NT/2000/XP - users must change the DLL manually if using the driver on these OSs. This is now documented in the driver

4.   HW.drv - better support for PCI and Plug and Play configuration and resource handling

5.   New drivers for NIDAQ (National Instruments), NT5000 (Navatek), various Geotest PXI Instruments and Adlink Data Acquisition.

How to control the vertical scroll bar in the ALog control - Published on 7/22/2003

7/22/2003

Solution:

To hide the scroll bar:

log.Object.Document.Body.Scroll="No"

To show the scroll bar (same as ALog default):

log.Object.Document.Body.Scroll="Yes"

To show the scroll bar only if needed:

log.Object.Document.Body.Scroll="Auto"

Implementing a loop micro-code command by writing directly to the control memory (GX5050/GC5050/GT2550) - Published on 4/17/2003

4/17/2003

Solution:

The following table shows the control memory content in order to create the sequence of loop three times and then Halt.

Note: All 32 channels direction are set to OUT, i.e. bits 28-31 are low.

When writing commands to the control memory all commands need to be spread on four consecutive steps.

Step #	Control Memory value
0	0x00000002
1	0x00000002
2	0x00000002
3	0x00000002
4	0x00000000
5	0x00000000
6	0x00000000
7	0x00000004
8	0x00000004
9	0x00000004
10	0x00000004
11	0x00000000
12	0x000E0000
13	0x000E0000
14	0x000E0000
15	0x01CE0000

Steps 0-3:
Command Sets register A equal to 2 with no conditions in order to loop a total of 3 times we set register A to 2.
The first three steps (0 through 2) hold the Register value (bits 0 through 15). The fourth consecutive step (3)
has the register number (bits 20-21) ORed with the Loop address value.

Steps 4-6:
Command No Operation

Steps 7-11:
Command: Loop on A. Loop steps 4 through 10 the number of times register A is set to.
The first three steps (7 through 9) hold the Loop address value (bits 0 through 16 for a total of 128K).
The fourth consecutive step (10) holds the Operation Code (bits 22 through 24) ORed with the Loop address value.

Step 11:
Command No Operation

Steps 7-11:
Command: Halt. The first three steps (12 through 14) hold the Halt command condition value (bits 17-19).
The fourth consecutive step (15) holds the Operation Code, bits 22 through 24 ORed with Halt command condition value.

Loop command flow chart:

Note: The value of register A at the end of a Loop command is 65535 (0xFFFF).

Accelerating the execution of ARM or TRIG commands when using GT2550 board - Published on 4/16/2003

4/16/2003

Solution:

The GT25/50 driver has embedded delays (about 30-40 mS) in order for it to work properly under different operating systems, carrier cards or different computers.

In GTDIO/DIOEasy v3.0 build 12 and above users can accelerate the execution of DioArm or DioTrig procedures when the GT25/50 run in frequencies greater then 200KHz using the DioSetOperationMode procedure. See the Dio on-line books for details on how to use this function.

GX5150 VHI0, VHI1 VREF, VTH0, VTH1 Pins - Published on 4/15/2003

4/15/2003

Solution:

It is not necessary to connect these pins. The GT5930 provides return path for all 32 channels on the wire opposite the signal wire.

Setting test requirements (e.g. Min/Max) from an external file - Published on 2/20/2003

2/20/2003

Solution:

The following describe a way to use external requirements files:

Open the external test requirements file in Program.OnInit.

Read the new requirements file.

Set the program test objects properties. You can set the test properties in OnInitTest (e.g., Test.Min=dMin) or for the whole program at once during Program.OnInit by looping and setting the test's objects (e.g., Program.Tests(name or number).Min=dMin).

If you want to set the test requirements for all the program tests at one time, do that after the program is running (e.g. OnInitProgram and not in OnInitSystem) since the run statments will reset any requirements you set.

The external file can be text, binary, an Excel spreadsheet, or a database. Text and binary files can be opened and read using ATEasy's FileXXX internal library functions. Excel spreadsheets or database files can be opened using Excel or ADO COM objects using a type library. For example code, refer to the ATEasy Excel example.

How Do I Call a DLL Created in Microsoft.NET from ATEasy 3.x or 4.x? - Published on 2/3/2003

2/3/2003

Solution:

ATEasy 3.x or 4.x (ATEasy 5.x and above support importing and using .NET assemblies directly) cannot call Microsoft.NET assemblies directly. Even if you create a Microsoft.NET class library with public methods, Microsoft.NET will compile these into Microsoft.NET assembly. This assembly will still have a .DLL extension, but it is NOT a dynamic link library (DLL). For more information on assemblies, see Microsoft.com assemblies.

One way to use the .NET assembly from ATEasy is by wrapping the .NET classes in your .NET library to ActiveX COM objects using a tool that is provided with .NET. This tool works as follows:

1. Register the .NET assembly using the .NET Framework Assembly Registration Utility (RAGASM.EXE) for example:

RGEASM MyLib.dll /tlb

The /tlb option is optional and will create and register a type library with the name MyLib.tlb. The type library can then inserted to the ATEasy sub module Libraries and can be used as other early binding objects.

2. Install the assembly into the Global Assembly Cache (GAC) using the .NET Framework Global Assembly Cache Utility (GACUTIL.EXE) for example:

GACUTIL –I MyLib.dll

3. After these step the .NET components can be used similar to any other COM object from ATEasy. Both methods early and late binding can be used.

Another workaround is to create an actual dynamic link library (DLL) from a Microsoft.NET language. This can be done with Visual Studio.NET. From within Visual Studio.NET, select File » New » Project. You can then select Visual C++ as the Project Type and Win 32 Project as the Template. After you click OK, you can then select Application Settings, rather than Overview. Then select DLL as the Application Type and select Export Symbols as Additional Options

How to use a DCOM component from ATEasy - Published on 12/16/2002

12/16/2002

Solution:

Use the following procedure to use a DCOM component from ATEasy:

1.   Register the server application on the server computer (usually by running it)

2.   Run the component setup to register the server component on the client computer

3.   Run Component Services Windows application (Start, Run, dcomcnfg.exe) on the server computer and select the application from the Component Services, My Computer, DCOM Config and set the security to allow remote computer to access the component

4.   Run Component Services Windows application (Start, Run, dcomcnfg.exe) on the client computer and select the application from the Component Services, My Computer, DCOM Config and set the application computer location

5.   From ATEasy use CreateObjec() or GetObject()  internal functions to create the remote objects as creating local object

Note: Since ATEasy version 6.0, CreateObject() has a new optional parameter (sHostName) that can be used (in addition to the method described here) to create remote objects.

ATEasy's Sleep(), Delay() and WaitForEvent() Functions Usage - Published on 12/6/2002

12/6/2002

Solution:

Sleep suspends the thread from which it was called (meaning it will also suspend UI such as form events, painting, etc.). If you wish to create an interval of time, you may call Delay() instead. However, Delay() consumes CPU time (see knowledge base article Q200030).

If that is a problem, you can use the following code:

Procedure DelayEx(lDelay)
{
lStart=Tick()

loop
   lTime=Tick()
   if lTime-lStart>lDelay than exitloop
   WaitForEvent(lStart+lDelay-Time)
   ! optional - call DoEvent() if you are calling this from a form event
endloop
}

PCI/PXI explorer hangs when opened - Published on 12/3/2002

12/3/2002

Solution:

The problem can be replicate usually on new Dell computers since their mother board contains a PCI device with function #7.

To replicate the problem, you can run the HWTEST application from the Program Files\Geotest\HW from the command prompt:

HWTEST pci

After running it you will see endless list of PCI devices displayed in the command window.

Geotest fixed this issue with HW (hardware access device driver) v2.11. This driver is shipped with every Geotest product that was released after December, 3 2002.

ATEasy 2.x DLG Based Dialog Boxes Appear Narrower in ATEasy 3.0 than in ATEasy 2.x - Published on 10/31/2002

10/31/2002

Solution:

This problem occurs because the Windows Dialog Base Unit (DBU) works differently in Win32 than in Win16.

DBUs are a Windows unit that let you specify control in a portable way that will allow different system to display text without clipping (to prevent the problem that cause fonts to be truncated).

Dialog Base Units (DBU) are used in DlgEasy and by Windows specify control size and position which are later on converted to pixels before being displayed by Windows.

Microsoft recommends to UI designers to add 30% width to controls that display text to prevent font clipping when changing system. If this rule is not followed, font truncating is not guaranteed. In addition, moving from WIN16 to WIN32 DBU translation to pixels was changed by Microsoft and made a bit narrower. However if the 30% rule was used than in most cases migrating dialog (in C or ATEasy) will work. Designing a dialog box in Visual C 1.5 and recompiling it to Visual C 6.0 may cause the same problem.

If font is truncated the only workaround is to resize the dialog controls in DlgEasy before using it from ATEasy 3.0.

Changing ATEasy control properties that affect the control window area does not take effect until you return from the form/control event - Published on 10/31/2002

10/31/2002

Solution:

For example changing the ASwitch control Value property will not take effect (in the control area in the form) until you exit the form event.

Use one of the following methods to force painting:

1.  Call DoEvent() this will cause events to be handled while the form event is handled. (ATEasy 4.0)

2.  Use the control Refresh() method (ATEasy 4.0 build 90 and above).

3.  You can use User32.dll UpdateWindow(hwnd) to force painting (hwnd is the control.hWnd property).

How to make the ATEasy log window update immediately after print during a form event - Published on 10/28/2002

10/28/2002

Solution:

You need to use the Flush() method of the log control. Just call the method after the print statement or append method and the log control will be updated immediately.

CoolBar control in Microsoft Window Common Control 3 not supported with ATEasy - Published on 10/16/2002

10/16/2002

Solution:

ATEasy does not support control that contains other controls (control container using ISimpleFrameSite interface). This interface is not documented by Microsoft and is currently supported only by VB. (Not supported by other application such as: Access or FoxPro MFC or ATL).

ATEasy EXE File Compatibility with Older Run-Time (RT) Engine Builds - Published on 10/16/2002

10/16/2002

Solution:

In general, ATEasy created executables (EXE) files run with the same run-time that was used to build the EXE. The EXE can also run with newer version of the ATEasy run-time.

Upgrading the target computer with the build that that you used to build the EXE along with the EXE file will always work. However, steps have been to reduce incapability between versions of ATEasy, so you will be able to mix different run time and EXE versions.

Since the file format of the ATEasy EXE or files rarely changes, you may not always need to send the run-time engine with your rebuilt EXE file. Starting from ATEasy 3.0 build 54 we made several changes to prevent the need for sending run-time updates.

How to Find the Free Disk Space from an ATEasy Application - Published on 9/27/2002

9/27/2002

Solution:

You need to call the Windows API that resides in a system dll. See the on-line help how to declare and call DLL function.

You can call GetDiskFreeSpace or GetDiskFreeSpaceEx declared in kernel32.dll or SHGetDiskFreeSpace in shell32.dll (check the Microsoft web site for declaration of these functions).

Below is a sample GetDiskFreeSpace declaration in ATEasy:

GetDiskFreeSpace(
lpRootPathName : val string,          ! root path e.g. "c:\\"
lpSectorsPerCluster: var dword,    ! sectors per cluster
pBytesPerSector: var dword,        !bytes per sector
lpNumberOfFreeClusters: var dword,  ! free clusters
lTotalNumberOfClusters: var dword:
) : Bool

Free space is calculated as:

dFreeSpace=lpSectorsPerCluster*1.0*pBytesPerSector*lpNumberOfFreeClusters

the *1.0 in the above code is used to convert to double and to avoid overflow since the result could be >4GB

Make ATEasy Wait until WinExec Application/Process Completes - Published on 9/25/2002

9/25/2002

Solution:

In ATEasy 3.0 build 54b and above, WinExec returns a true handle.

hHandle=WinExec(..)

WaitForSingleObject(nHandle) ! wait until app is completed

….

For ATEasy 3.0 build 54a and below, you must use FindWindow (user32) on the caption of you application or the class of its main window (using spy):

WinExec(...)

while FindWindow(...)
endwhile

How to copy a file from an ATEasy application - Published on 9/25/2002

9/25/2002

Solution:

ATEasy 6.x and above have a FileCopy() function that can be used to copy file. The following provides a way to copy a file using ATEasy 3.x-5.x:

Copy the following to your text file Libraries section:

DLL Kernel32
--------------------------------------------------------------------------------
File = Kernel32.dll

DLL Types
--------------------------------------------------------------------------------

DLL Procedures
--------------------------------------------------------------------------------

Procedure CopyFile(sExitingFileName, sNewFileName, bFaiIfExist): Bool
--------------------------------------------------------------------------------
sExitingFileName: Val String
sNewFileName: Val String
bFaiIfExist: Val Bool

Toggling the DTR line with an RS232 COM port from ATEasy - Published on 9/25/2002

9/25/2002

Solution:

Before starting, you must know the base address for the port, which can be obtained from Windows Device Manager Resource tab. Usually the base address for COM1 is 0x3F8.

The DTR line is connected to Modem Control Register (MCR) bit 0 at an offset of 4 (e.g., 0x3F8 + 4). Setting this bit to 1 makes the line active.

For example:

iBase=0x3F8
ucByte=PortInByte(iBase+4)

! set DTR On
PortOutByte(iBase+4, ucByte or 0x1)
Delay(500)

! set DTR Off
PortOutByte(iBase+4, ucByte and 0xFE)

ATEasy 2.x and 3.x GPIB Secondary Addresses - Published on 9/25/2002

9/25/2002

Solution:

In ATEasy 3.0 and above, Secondary Address 0 is used as a None secondary address. Use 1 to 31 as a Secondary Address for GPIB instruments.

ATEasy 2.x uses 0 as the first Secondary Address. To remain compatible with ATEasy 3.0 and above, add 1 to ATEasy 2.x application Secondary Address (e.g., use 1 instead of 0).

Printing an Image or Form Data from ATEasy - Published on 9/25/2002

9/25/2002

Solution:

The process is comprised of two steps. The first step is to save the chart to a image file. The second step is to print the image file.

1. To save to an image file, use the Image property with the SavePicture() internal library routine.

2. Use one of the following methods to print the saved image file:

Use WinExec() with MSPAINT or any other application that supports printing of picture from the command line (/p).
Use the Log control in HTML mode to insert a picture tag to it with the file saved. Then, use Log.PrintLog. This method is very flexible, as you may add text and/or other drawing elements to your printout.
Use COM libraries such as Word and Excel to send a picture and to print.

High CPU Utilization when Using ATEasy's Delay() - Published on 9/25/2002

9/25/2002

Solution:

Calling Delay() does not put your thread to sleep; events and interrupts continue to be monitored in your thread.

If you don't want to monitor events, you can use Sleep(), which does not use as much CPU.

Is there a way to know if my application is running from the ATEasy development env (IDE)? - Published on 9/25/2002

9/25/2002

Solution:

If app.ModulePath has the string value "ATEasy.EXE", then your application is running from the ATEasy development environment.

PCI/PXI Instruments not working properly when several instruments of the same type are installed on the same Windows NT machine - Published on 9/25/2002

9/25/2002

Solution:

Cause: The Windows NT Hardware Abstraction Layer (HAL) HAL assigned an I/O port address or memory resource to a PCI device that overlaps with an existing PCI device, causing a PCI resource conflict on your system. Under normal operation, the system BIOS is responsible for setting the PCI device resource requirements. When Windows NT loads, the Windows NT HAL sometimes moves the PCI device resources. PCI devices are dynamically configurable. However, the Windows NT HAL sometimes assigns overlapping I/O port addresses or memory resources for the PCI devices.

Resolution: Adding the /PCILOCK switch to the BOOT.INI file forces the Windows NT HAL to use the PCI device resources allocated by the system BIOS. After modifying the BOOT.INI file the system must be rebooted.

Example: The following is a typical Boot.INI file with the /PCILOCK switch

[boot loader]
timeout=3
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)WINNT="Windows NT Workstation
Version 4.00"/PCILOCK
multi(0)disk(0)rdisk(0)partition(1)WINNT="Windows NT Workstation
Version 4.00 [VGA mode]" /basevideo /sos /PCILOCK

On Windows 9x ATEasy will not notify if file used by ATEasy was saved externaly on a network driver - Published on 9/19/2002

9/19/2002

Solution:

This problem can happen only in ATEasy 4.x and above running on Windows 9x.

This is due to a known windows 98 bug with FindFirstChangeNotification Windows API used by ATEasy that does not return notification when file saved on network drive.

VB Controls or Objects are Slow When Running from the ATEasy IDE - Published on 9/19/2002

9/19/2002

Solution:

Visual Basic 6.0 objects are single threaded by default. VB objects that are run in the ATEasy IDE will run in the IDE's main process thread apartment. ATEasy must then use a proxy when creating a control from the run-time thread, which slows performance (50-100 times).

To increase performance when using VB objects, make sure to change your VB project setting to use the Apartment Threaded threading model.

Customizing the ATEasy Log Header and Footer when printing - Published on 9/19/2002

9/19/2002

Solution:

If you are using ATEasy 5.x and above the PrintLog() internal function and the ALog.PrintLog has parameters to support setting the page header and footer for printing.

For ATEasy 3.x and 4.x users use the following solution:

The ATEasy Log window is based on Internet Explorer (IE). When printing, the ATEasy log window uses the IE page setup options that are stored in the Registry. To change the settings, you can run IE, select Page Setup from the File menu, then edit the header and footer fields as required. You can also do this programmatically -- you'll need to locate the registry entry and write to it on the fly before calling Log.PrintLog().

ATEasy USB License Key Does Not Work in Windows NT 4.0 - Published on 2/28/2001

2/28/2001

Solution:

Windows NT does not support USB devices. Therefore, the USB Rainbow protection key is not supported under Windows NT.

The USB protection key is supported only under Windows 9x/ME and Windows 2000.

How to Create and Use C Structure Bit Fields in ATEasy - Published on 2/12/2001

2/12/2001

Solution:

Bit fields are not part of the ATEasy language. To create a bit field-like structure, you can define a member as an integer and manipilate the field using the Or or And operators to set values in the fields. To clear a field you can use the Not operator.

For example if the C structure was :

Struct Fields { ... DWORD a : 5; DWORD b: 3; ... }

Define the Bit field as dw in ATEasy:

struct Fields { ... dwFields : Dword ... }

Define some constants:

A _MASK: Dword=0x1F A _POS: Dword=0 B_MASK : Dword=0x7 B_POS: Dword=5

To clear b use:

f.dwFiellds =f.dwFiellds & not (B_MASK shl B_POS)

To set b use:

f.dwFiellds =f.dwFiellds & not (B_MASK shl B_POS) or (bNew shl B_POS)

Can I Pass an ATEasy Procedure to a DLL for CallBack? - Published on 2/12/2001

2/12/2001

Solution:

Passing an ATEasy procedure to a callback is supported from version 6.0 and above.

The following workaround provides the same functionality for ATEasy version 3.x-5.x:

1.   Write a DLL with the callback function and pass it to the function that requires callback function.

2.   To pass the address, call the Windows API GetProcAddresss(), then pass the result as long to the function that requires callback function.

3.   The DLL callback function can use another ATEasy thread to perform an action in ATEasy when the call back was called. The thread can be triggered by an ATEasy synchronization object (AEvent), using a global variable or an ATEasy user interrupt.

ATEasy Log Control Hangs or Crashes - Published on 10/13/2000

10/13/2000

Solution:

The ATEasy ALog control may hang or crash if appending too much text.

The ATEasy Log Windows is based on Microsoft Internet Explorer (IE). IE does not provide an easy and fast way to determine the limitation on the IE page size. The limit is highly dependent on IE platform, version, and memory. Usually the log file can be very large (several MB) if Windows have enough memory.

If each program run is saved to a separate log file (default), this will not should be an issue.

ATEasy SNMP Protocol Support - Published on 10/4/2000

10/4/2000

Solution:

The SNMP protocol API comes with Windows NT/2000 and above, and can be accessed from ATEasy using Windows SNMP APIs.

http://msdn.microsoft.com/en-us/library/aa378988.aspx

Additionally, there are third party ActiveX or .NET SNMP components available, including:

PowerTCP SNMP Tool http://www.dart.com/power

Cyberons http://www.netaphor.com

ATEasy Properties or IDE Dockable Window Disappears or is not Positioned Properly - Published on 9/26/2000

9/26/2000

Solution:

This issue is caused by corrupted ATEasy Workspace key the the Windows registry.

This problem can be fixed by editing the Windows Registry which will cause ATEasy IDE to reset all windows position to default:

1.   Exit ATEasy.

2.   Start the Registry Editor (REGEDIT.EXE).

3.   In the Registry editor, select the

HKEY_CURRENT_USER\Software\Geotest\ATEasy\Workspace

4. To delete the whole IDE windows position delete the whole key.
To delete the properties window position and size delete the PropertiesPlacement from the Full key.

Bypassing the Windows NT Logon Process - Published on 9/20/2000

9/20/2000

Solution:

WARNING: Use this procedure only when absolutely necessary. Follow the procedures carefully. If the registry editor is used improperly, you may have to reinstall Windows NT to correct problems. Back-up pertinent data. Geotest - Marvin Test Systems, Inc. provides this information as a courtesy to its users. Geotest is not responsible nor liable for any damage caused by following these procedures.

Windows NT allows you to automate the logon process by storing your password and other pertinent information in the Registry database.

Note: Storing login and password information in the Registry database allows other users to start your computer and use the account you establish to automatically logon. Timing conflicts can also occur. For example, if you have several network transports loaded, enabling automatic logon may make Windows NT attempt to connect to network resources before the network transports are completely loaded.

Use the Registry Editor (REGEDT32.EXE), available as part of Windows NT operating system, to add your logon information, as follows:

1.   Start REGEDT32.EXE and locate the following Registry subkey:
      HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon

2.   Establish your domain name, account name, and password using the values you would normally type when logging on. You should assign the following values:

DefaultDomainName
DefaultUserName
DefaultPassword

Note: The DefaultPassword value may not exist. If it doesn't, from the Edit menu, choose Add Value. In the Value Name field, type:
DefaultPassword

Select REG_SZ for the Data Type. In the String field, type your password. Save your changes.

Also, if no DefaultPassword value string is specified, Windows NT automatically changes the value of the AutoAdminLogon key from 1 (true) to 0 (false), thus disabling the AutoAdminLogon feature.

3.   From the Edit menu, choose Add Value. Enter AutoAdminLogon in the Value
      Name field. Select REG_SZ for the Data Type. Enter 1 in the String field. Save your changes.

4.   Exit REGEDT32.

5.   Exit Windows NT and turn off your computer.

6.   Restart your computer and Windows NT. You should be able to logon automatically.

ATEasy Timers - Published on 7/28/2000

7/28/2000

Solution:

ATEasy has two types of timers:

1. ATimer control

2. INT_TIMERx interrupts

The ATimer is based on the windows WM_TIMER message (not an accurate timer). Windows documentation describes the WM_TIMER message as a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue.

The INT_TIMERx interrupts are based on the Window MultiMedia Timers (see the Windows SDK for timeSetEvent API). The multimedia timers provide accuracy up to 1 ms. ATEasy's ability to deliver 1 ms interrupts depends on the time required to execute a single PCode command. Since interrupts cannot be called in the middle of a PCode command in that thread, this time may be long if the thread calling a DLL function takes a long time before it completes.

The following list alternatives to the above mentioned timers:

Create an ATEasy thread and use the Sleep() function to form a delay between events. Call SetThreadPriority() to ensure more accurate timer.

Write a DLL and use the multimedia timer timeSetEvent. This method is accurate, but requires a callback function that must be implemented in a DLL. This method could be more accurate if implemented in its own thread.

Write a DLL and use the Windows SetWaitableTimer. This method is accurate (better than 1 ms), but requires a callback function must be implemented in a DLL in its own thread.

Use hardware to implement the handler functionality.

Can't obtain a license from ATEasy License Server - Published on 7/11/2000

7/11/2000

Solution:

The following list reasons why license cannot be obtained from an ATEasy Network License server:

1. ATEasy v6.0 (build 136 and above) support automatic installation of the license server in the server. It installs the server as a service in the server computer and have more reliable and flexible way of communication with the workstations.
2. The License server must be running and have enough licenses installed to accommodate requests from the workstations.
3. The workstation ATEasy version must be equal or smaller than the license installed in the license server. If the workstation have an ATEasy 4.x and the server license is for ATEasy 4.x and above it will work. For example You can not have 7.0 client and a 4.0 license.
4. ATEasy workstations must have a direct and a reliable connection to the license server at all time. Same IP subnet is recommended for both server and workstation.

Cannot Call an ATEasy Program Procedure from a Driver or a System - Published on 6/20/2000

6/20/2000

Solution:

Calling a program procedure from a driver or a system is prohibited by design. Drivers or systems should be designed so that they are independent the active program's implementation, which can be changed when the application is running.

Program events, however, can be called by a driver or system using, for example, Program.OnInit().

The following procedure provides a workaround using procedure variable:

1.   Program pass in the procedure to a procedure variable stored in a driver or a system module.
2.   The driver or system can now call the program procedure using the procedure variable.

The following procedure provides a workaround using interrupts:

1.   Program installs an interrupt
2.   When a driver needs to call the program procedure, it sets the interrupt
3.   The program interrupt handler can then call a driver function to retrieve the parameters, or can use driver public variables to pass parameters

Modifying ATEasy Code During Debugging - Published on 5/31/2000

5/31/2000

Solution:

ATEasy Code that was already parsed will not re-parsed to include the new code changes in the code editor. Code that was not yet parsed by the ATEasy's Just In Time compiler is parsed when called and the latest code changes will take effect.

When the application is started, ATEasy first compiles the application module events and the procedures and commands referenced by these events. When a program is run ateasy first compile its events. Tasks tests are compiled before they are about to be executed (one task at a time). When a DoIt! is executed only the highlighted code and the referenced procedures and commands are compiled.

Since module events are always parsed when the application is started, code changes in module events will only take effect when the application is started but not during debugging.

Removing ATEasy License from a Machine - Published on 5/31/2000

5/31/2000

Solution:

Use the following procedure to remove an ATEasy license from a machine:

1.   Open the ATEasy About dialog box from the Help menu.

2.   Press Ctrl + Alt + Shift + K. A confirmation dialog box is displayed.

3.   Click Yes.

4.   Write down the confirmation code and send to customer support for verification. A temporary file containing this information is also generated in the temp directory. It is recommended to take a screen capture and send to Geotest for approval the confirmation code to avoid mistakes while copying the confirmation code from the screen.

Reasons why ATEasy Save Command Fails - Published on 5/19/2000

5/19/2000

Solution:

A Save Document operation may fail under any one of the following conditions:

The file's security permissions or attributes are set to Read Only

Another application or instance of ATEasy is using the file

A user on another machine is accessing the file

ATEasy Form.Visible, and .WindowState Values During OnLoad Event - Published on 3/28/2000

3/28/2000

Solution:

During the form loading the properties have the following values:,

Form.Visible = False
Form.WindowState = Normal

After the OnLoad is return these properties are restored as set in design mode.

This behavior is similar to Microsoft Visual Basic's forms behavior.

Multisite in a Single Domain Solution	Single Site Per Domain Solution
Programming is required to Create Digital Test File	Automatic Generation of Digital Test File
Reduced number of PXI Slots and Boards	More Slots/Digital Test Boards
Lower Hardware Cost	Higher Hardware Cost
Slower Deployment	Faster Deployment
Requires complicated programming to find the faulty DUT	Better Diagnostics
Lower Test Yield	Maximum Test Yield