Geotest - Knowledge Base Articles

Installing and Using ATEasy Network License - Published on 1/5/2012

1/5/2012

Note: This article was modified to reflect the automated setup for the license server and the better client-server connectivity that was introduced in v6.0 build 134. If you are using an older version of ATEasy please upgrade ATEasy License server with the latest ATEasy version. We also recommended upgrading clients if possible. The network license handling in the client and in the server sides are backward compatible and were considerably enhanced to provide better performance and automated setup.

The server application, License Server, must be installed at the computer that will be the ATEasy license server. The License Server computer must be a 32/64 bit Windows Operating System (Windows 2K and above). The computer must be turned ON and connected to the network while the clients are running. We recommend to install it on one of the the company servers (typically Windows Server) since it always turned on.

Setup the License Server

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.
Note that for ATEasy versions prior to build 134 setup of the service was done manually and not using the setup. The procedure to install the server manually is described in ALicenseServerService.rtf file located in the ATEasy folder (instructions for manual installation also at the bottom of the page).

Install the License Key in the server

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.

An ATEasy Computer ID is displayed in the bottom field. The 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 incident using your Geotest account or call Geotest Technical Support at (949) 263-2222 to obtain a license string or file.

Once you receive the license string or file, open the License Setup dialog box again.

Type in the License String or File. Click OK. The about dialog should display the # of license installed.

Set Up the Client

Perform this step only after you have obtained and installed the license string or file on the server.

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

Start ATEasy.

Open the License Setup dialog box.

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). Click OK.

For more information regarding ATEasy Licensing, see the ATEasy On-Line Books help.

Programming GX1110 for AM and FM Modulation - Published on 9/9/2011

9/9/2011

Summary:  This article discusses how program the GX1110 Arbitrary Waveform Generator instrument to apply Amplitude Modulation or Frequency Modulation to a carrier signal.

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.  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

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.

Consume a web service in ATEasy - Published on 7/28/2011

7/28/2011

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

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.

How to use Microsoft Visual Studio to debug a DLL function called from ATEasy - Published on 5/12/2011

5/12/2011

ATEasy is capable of interface and call 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 reside 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\):

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:

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.

Accessing ATEasy Internal Classes from other programming languages - Published on 4/29/2011

4/29/2011

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 for allowing external programming languages such as C++.

IDispatch: Using the methods and properties of an ATEasy object

The 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.

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 Visual Studio 2005 and entitled IDispatchExample. It is provided at the bottom of this article.

The Microsoft knowledge base article 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. Since ATEasy does not support variable arguments, the ATEasyClassMethod() function will take 4 variants as parameters and then check to see if each variant has been defined before calling Autowrap(). 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/*=VT_EMPTY*/, VARIANT vtParam2/*=VT_EMPTY*/, VARIANT vtParam3/*=VT_EMPTY*/, VARIANT vtParam4/*=VT_EMPTY*/)
{
    if (vtParam1.vt==VT_EMPTY)
         AutoWrap(DISPATCH_METHOD, NULL, pATEasyObject, sMethod, 0);
    else
        if (vtParam2.vt==VT_EMPTY)
            AutoWrap(DISPATCH_METHOD, NULL, pATEasyObject, sMethod, 1, vtParam1);
        else
             if (vtParam3.vt==VT_EMPTY)
                 AutoWrap(DISPATCH_METHOD, NULL, pATEasyObject, sMethod, 2,
                       vtParam2, vtParam1);
             else
                 if (vtParam4.vt==VT_EMPTY)
                     AutoWrap(DISPATCH_METHOD, NULL, pATEasyObject, sMethod, 3, vtParam3,
                           vtParam2, vtParam1);
                 else
                     AutoWrap(DISPATCH_METHOD, NULL, pATEasyObject, sMethod, 4, vtParam4,
                             vtParam3, vtParam2, vtParam1);
}

Testing the DLL with ATEasy

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
}

Applications

Integration of ATEasy and a scripting language.

Passing ATEasy objects out to be parsed externally.

Downloads

VS2005 C++ Project
ATEasy Test Workspace

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

The ATEasy Crash Analysis Tool - Published on 4/6/2011

4/6/2011

What is the ATEasy crash analysis tool?

The ATEasy Crash Analysis Tool replaces the default exception window generated by Windows when any application running 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 Geotest engineers.

The crash analysis tool is available in ATEasy version 8 and later.

The following window shows the genereic exception as displayed by WIndows when it traps the application exception:

The Windows Generic Exception Dialog

The following windows show the ATEasy Exception window:

The ATEasy Exception Dialog

Breakdown: What does the log information mean?

Sample Exception Log Window Information:

Unhandled exception at 0x7614fbae in C:\Windows\system32\kernel32.dll: 0xe06d7363
Thread (Current) Index=0, ID=0x1178, Handle=0x2e0
     HeartBeatMonitor.tmrHeartBeat.OnTimer Line 12
     IoPort.Msg8Byte Line 11
     Program1.Erase_HOST_EEPROM Line 76
     Program1.4 Line 1
     Internal Call Stack
          ...
     Internal PCode
          ...
Thread Index=1, ID=0x1484, Handle=0x4a0
     AbortTest.WaitOnEvent Line 2
Thread Index=2, ID=0x17f8, Handle=0x560
     Program1.GUI_Abort.btnAbort.OnClick Line 7
     Program1.startAbortBtn Line 6

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 and thread created by the 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 a top level items of the tree view.

Call Stack and PCODE. The items bellow the 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 Geotest 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?

Right-click My Computer and click Manage
Navigate the tree view to System Tools | Event Viewer | Application
Use menu item View | Filter... and set event source to 'ATEasy' and click OK

Each entry in the Event Log corresponds to 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 XML, CSV, TXT and EVT/EVTX. The EVT log for Windows XP (EVTX for Vista/7) can be reopened in the Event Viewer at a later time. This is the preferred file format when submitting information to Geotest.

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 (0x5) but could also shows as unexpected behavior since memory is corrupted.

Buffer Not Allocated: Similar to buffer overrun, however the crash will show excetly the location of the problem. Usally memory access as well (0x5). 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.

Comparing C/C++, C#, VB and ATEasy Basic Data Types - Published on 3/16/2011

3/16/2011

Data type reference table

The following table describes ATEasy equivelenet data types when calling procedures defined in other programming languages such as C/C++. The table is 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.

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-define 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

DC Characterization of ICs Using PXI Instrumentation - Published on 3/8/2011

3/8/2011

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 demonstate 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 Geotest 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. 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 Geotest 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 digitial 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 adaquately 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.

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

Terminate an ATEasy software license - Published on 2/9/2011

2/9/2011

Solution:

To terminate the software license:

1.   Launch ATEasy (for single license) or the ATEasy License Server at the server (for network license).
2.   For ATEasy, click Help from the toolbar and then click About. For the license server open the About dialog by clicking on the icon in the Windows task bar.
3.   When the About dialog box appears, press: CTRL+ALT+SHFT+K (be sure to press and hold the first three keys before pressing the K key)

Pay special attention to the following Steps:

4.   A dialog box will appear asking you to confirm the termination of the key.  Click Yes.
5.   DO NOT click OK when the next dialog box appears with a string of characters. Write down the Termination Code string of characters appearing on the dialog box. You will need this string of characters later. You can also take a screen capture (Alt+Screen Capture keys, paste to MS Paint, Save).
6.   Click OK.
7.   Close ATEasy.
8.   Log into M@GIC.
9. Post the Termination Code string of characters you wrote down in Step 5 (or screen capture) to a new or existing incident as proof of license termination.

Passing an array from a .NET object to an ATEasy callback procedure - Published on 2/2/2011

2/2/2011

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:

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.

Importing Teradyne* DTB files to the Geotest GX5960 Digital Subsystem - Published on 1/24/2011

1/24/2011

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 Geotest's 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 Geotest 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 Geotest 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 Geotest XML file

Once the digital subsystem has been loaded with the DTB derived XML file, the configuration can be edited and saved in a Geotest native XML file format for later use by calling GtDio6xFileSaveConfiguration and GtDio6xFileLoadConfiguration.

* Teradyne is trademark of Teradyne, Inc.

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.

Capturing channels simultaneously with the GX2472 Digitizer - Published on 11/22/2010

11/22/2010

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.

Controlling a GX3500 FPGA Design Using Register Reads and Writes - Published on 11/9/2010

11/9/2010

Introduction

To understand how to access registers on the GX3500 FPGA instrument, it is necessary to have a design the 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.

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 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

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

Translating Waveform Generation Language Files (WGL) to Geotest DIO File Format - Published on 10/14/2010

10/14/2010

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.

To illustrate the Geotest 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 Geotest 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 Geotest DIO products support both functions, this article will demonstrate importing the sample WGL file both ways.

Activating DIOEasy-FIT - WGL Import Toolkit

The Geotest WGL import utility is a licensed product of Geotest, 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 Geotest WGL import utility is supported using DIOEasy, Geotest's 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 Geotest web page:

http://www.geotestinc.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 Geotest 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 Geotest 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.

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) ).

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

Using the Winsock (TCP/IP) ATEasy Driver Interface - Published on 5/19/2010

5/19/2010

The following walkthrough demonstrates the creation and configuration of an 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.

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):

Proper Termination of High-Speed Digital Signals - Published on 5/19/2010

5/19/2010

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².

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 (excepth 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.

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}

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.

How to set up and control an LXI instrument from ATEasy - Published on 4/27/2010

4/27/2010

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 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.

GT95014 Digital I/O Single-ended Beakout Adapter Board Product Information - Published on 4/27/2010

4/27/2010

The GT95014 is a breakout adapter for all Geotest 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 Geotest 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 65 and 67 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

GT95015 Differential Digital I/O Beakout Adapter Board Product Information - Published on 4/27/2010

4/27/2010

The GT95015 is a breakout adapter that can be used with all Geotest 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 (Geotest 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

Geotest 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)

What is the Geotest HW driver? - Published on 3/31/2010

3/31/2010

The HW package - Geotest's Hardware Access Driver, is used by all Geotest instrument drivers and ATEasy to access to the PC resources (memory, IO ports, DMA etc), PCI/PXI configuration and more. The HW package includes libraries used to program and create instrument drivers for PC/PCI/PXI based instruments. A PXI/PCI Explorer utility to configure and display PXI/PC based systems is also included. The utility includes a VISA configuration utility for PXI and PXI express instruments (similar to NI-MAX) and support for Geotest and other vendors PXI chassis, controllers and expanders.

The HW driver supports running on Windows 9x-Windows 7 and support 16, 32 and 64 bit Windows applications.

The following files are installed when running the HwSetup.exe setup for HW:

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.

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 - Windows kernel mode device driver for HW.INF boards, installed to the Windows System Drivers directory.

HwPxiExpress.dll - Provides information to Geotest Chassis, Controller and Peripheral PXIe devices, installed to the Windows System directory.

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.

HwCIns32.dll and HwClins64.dll - Windows Class Installer for HwDevice.sys and HwDevice64.sys.

HwVdd.dll - VDD for 16 app running on 2000-Vista, installed to the Windows System directory.

Hw.inf - Driver information files for Geotest's PXI/PCI boards.  Installed to the Windows System\INF directory.

HwPciExplorer.cpl and HwPciExplorer64.cpl - PXI/PCI Explorer - Windows Ccontrol Panel applet 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 Geotest board driver. Installed to the Windows System directory.

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++ application using the HW.dll and Hw64.dll.

ReadMe.txt - Contains the latest release information about the HW package.

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 example of using the objects listed below for querying the PXI system resources:

Initialize():
Initializes the HW library

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. So knowing the structure of the data type is key to fully utilizing the HW driver. The full structure is provided in the ATEasy HW driver, and provided below for review:

Struct structHWPCIDEVICE
  Dword dwVendorId
  Dword dwDeviceId
  Dword dwBus
  Struct structPciSlotNumber stPciSn
    Dword dwAsUlong
  Struct strictPciCommonConfig stPciCfg
    Word wVendorId
    Word wDeviceId
    Word wCommand
    Word wStatus
    Byte ucRevisionId
    Byte ucProgIf
    Byte ucSubClass
    Byte ucBaseClass
    Byte ucCacheLineSize
    Byte ucLatencyTimer
    Byte ucHeaderType
    Byte ucBIST
    Struct structPciHeaderType0 stType0
      Dword adwBaseAddresses[6]
      Dword dwSubSystem
      Dword dwSubVendorID
      Dword dwROMBaseAddress
      Dword adwReserved2[2]
      Byte ucInterruptLine
      Byte ucInterruptPin
      Byte ucInterruptPin
      Byte ucMinimumGrant
      Byte ucMaxinumLatency
    Byte dwDeviceSpecific[192]
  Struct structCmPartialResourceDescriptor  aResDesc[8]
    Byte ucType
    Byte ucShareDisposition
    Word wFlags
    DWord Address1
    DWord Address2
    DWord Address3
  Struct structHwMemoryDesc aMemDesc[8]
    DWord dwPhAddrLow
    Long lPhAddrHigh
    DWord dwLength
    DWord pvVirtualAddress
  Char szId[256]

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; slot numbers can identify instruments, instruments can be identified by a resource descriptor (VISA) and board numbers can be used - these are the most common means of identification.

The HW library also supports a simplified means of referencing a device; by it's Alias. 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. A detailed explanation of how to do this is discussed in Knowledge Base article #Q200187.

Figure 1: Using PXI/PCI Explorer to assign an instrument Alias

The typical process for establishing communication with an instrument is to “Initialize” the instrument by passing the iappropriate dentification 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 the instrument.  This process is very similar to that of opening a file, and using the returned “file handle” for subsequent reading or writing to the file.

Identification of instruments can be done at program design time by hard-coding the instrument identification into the test program, or at runtime 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 runtime, the HW Initialize() procedure must be called prior to calling any of the other procedures in the HW driver.

Once initialized, the PciGetSlotNumbers() procedure will return an array of PXI slot numbers that contain instruments matching the search criteria – often the Vendor ID and Device ID.  The PciGetSlotDevice() procedure returns the device information for the instrument in the specified slot.  The device information is contained in the structure structHWPCIDEVICE (listed above).  If, for example, you wanted to know how many GX5290 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=0x16E2 ! Geotest Vendor ID
Word wDeviceId=0x5290 ! GX5290 Device ID
Short panSlotNumbers[32] ! Array of slot numbers found
Word pwDevicesFound ! Number of slots matching the Vendor and Device ID’s
structHWPCIDEVICE pstPciDev
String sDeviceInfo
Long i

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

Once the slot number for an instrument is obtained, it would be a simple matter to initialize the instrument by calling the instrument's Initialize() procedure and passing the slot number obtained by scanning the PXI system using the example above.

For additional information about how to use the HW driver, review the HW programming example installed with ATEasy (Hw.prj) and the HW files installed the Program Files\Geotest\HW. More informatiion is also avilable in the folowing knowledge base articles: Q182, Q187.

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.

Calling Geotest DLL functions from a C# Visual Studio .NET Project - Published on 3/22/2010

3/22/2010

All Geotest 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 Marshalling where unmanaged data types are converted to managed .NET CLR (Common Language Runtime) data types. Each .NET datatype has a default unmanaged data type that the CLR will use to marshall 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 mashalled datatype can be changed in the C# code. The figure below illustrates the relationship between the .NET classes and the Geotest 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 Geotest 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 delcare 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 marshalled datatype.

In this example the GxFpgaInitialize, GxFpgaGetDriverSummary and GxFpgaWriteMemory C functions along with some contants, 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 marshalled datatype of LPTSTR (unicode). The default marshalled dataytpe 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.

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

National Instruments BIOS Compatibility software and MXI-Express - Published on 3/18/2010

3/18/2010

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 compatibilty 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.

Real-Time Digital IO Compare Example - Published on 3/18/2010

3/18/2010

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 modify the ATEasy Log output - Published on 2/8/2010

2/8/2010

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

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

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

How to Repeat a test multiple times - Published on 2/1/2010

2/1/2010

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.

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:

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)
}

PXI Bus expander configuration - Published on 12/22/2009

12/22/2009

It is often necessary to join two or more PXI busses, 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 ajoining 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 Geotest 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 Geotest offers:

Desktop PC to Chassis

For example Desktop to GX7600 PXI Express Chassis

PCI to PXI (GX7000A , GX7100A, and GX7300 chassis's 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's only)

MXI-EXPRESS - x1 lane, single port (one chassis)

MXI-EXPRESS - x1 lane, dual port (two chassis')

PCI Express to PXI Express GX7600 Chassis only

MXIe1-EXPRESS - 192 MB/s Express x1 connection

MXIe4-EXPRESS - 798 MB/s Express x4 connection

Laptop to Chassis

PCMCIA to PXI (GX7000A , GX7100A, and GX7300 chassis's only)

MXI-PXI-L - Star Fabric type connector

ExpressCard to PXI (GX7000A , GX7100A, and GX7300 chassis's only)

MXIe1-PXI-L - ExpressCard Laptop Interface

ExpressCard to PXI Express GX7600 Chassis only

MXIe1-EXPRESS-L - ExpressCard Laptop Interface

Chassis to Chassis

PXI to PXI (All chassis's 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 seperately upon request.

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.

How to print a HTML or TEXT file from within an ATEasy application - Published on 12/15/2009

12/15/2009

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
  }

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

How to calculate the frequency measurement accuracy of the GTX22x0 series of Time Interval Counter PXI Cards - Published on 7/10/2009

7/10/2009

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.

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.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.

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

Creating an RS170 Video Signal with WaveEasy - Published on 4/21/2009

4/21/2009

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.

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.

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.

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