Geotest - Knowledge Base Articles

PMU Functionality with the GX5960 Series - Published on 5/7/2012

5/7/2012

The Gx5960 Series of Digital I/O devices include the ability to configure each of its I/O channels to operate in either dynamic or PMU mode. This article focuses on the PMU mode.

Each digital channel includes a parametric measurement unit (PMU) which can be used to characterize and measure a digital pin’s DC characteristics. The PMU can be configured for force current, measure voltage, or force voltage, measure current. The PMU’s range of operation is listed below:

Force voltage range: -10 volts to +15 volts (plus vMid Voltage)

Force current range: +/- 25 mA FS or +/- 200 mA

Measure voltage range: -10 volts to +15 volts (plus vMid Voltage)

Measure current range: +/- 25 mA FS or +/- 200 mA

API Functions

The following are the API calls required to set up the instrument for PMU operation:

VOID WINAPI GtDio6xSetChannelMode(SHORT nHandle, LONG lChannelListArraySize, PLONG palChannelListArray, SHORT nMode, PSHORT pnStatus);

VOID WINAPI GtDio6xSetChannelForcedVoltage(SHORT nHandle, LONG lChannelListArraySize, PLONG palChannelListArray, DOUBLE dVoltage, SHORT nCurrentRange, DWORD dwSetupMode, DOUBLE dMaxCurrent, PSHORT pnStatus);

VOID WINAPI GtDio6xSetChannelForcedCurrentCommutatingVoltage(SHORT nHandle, LONG lChannelListArraySize, PLONG palChannelListArray, DOUBLE dVComHi, DOUBLE dVComLo, PSHORT pnStatus);

Note that the voltage clamps only apply for forced current operation up to 24mA. If this current is exceeded, the voltage clamps are no longer effective.

Example Code

The following C code performs the following:
1. Set Channel 0 Mode to PMU Force Current
2. Set Channel 0 PMU Force Current Voltage clamps to +5V and -5V
3. Set Channel 0 to Force 10mA in 25mA range
4. Measure the output current
5. Set Channel 0 Mode to PMU Force Voltage
6. Set Channel 0 to Force 12V with the current range set to 25mA
7. Measure the output voltage

//Use channel 0
alChannelListArray[0]=0; //Use channel 0
GtDio6xInitialize(1, &nHandle, &nStatus);
GtDio6xSetChannelConnect(nHandle, 1, alChannelListArray, TRUE, &nStatus);
//Set Channel Mode to PMU Force Current
GtDio6xSetChannelMode(nHandle, 1, alChannelListArray, GTDIO6X_CHANNEL_MODE_PMU_FORCE_CURRENT, &nStatus);
//Set Clamping voltages to +5V and -5V
GtDio6xSetChannelForcedCurrentCommutatingVoltage(nHandle, 1, alChannelListArray, 5, -5, &nStatus);
//Force 10 mA in 25mA range
GtDio6xSetChannelForcedCurrent(nHandle, 1, alChannelListArray, 10, GTDIO6X_PMU_CURRENT_RANGE_N25MA_TO_P25MA, &nStatus);
//Measure the current output
GtDio6xMeasure(nHandle, 0, GTDIO6X_MEASURE_OUTPUT_CURRENT, &dMeasurement, 1, 0, 0, &nStatus);

//Set Channel Mode to PMU Force Voltage
GtDio6xSetChannelMode(nHandle, 1, alChannelListArray, GTDIO6X_CHANNEL_MODE_PMU_FORCE_VOLTAGE, &nStatus);
//Force 12 Volts
GtDio6xSetChannelForcedVoltage(nHandle, 1, alChannelListArray, 12.0, GTDIO6X_PMU_CURRENT_RANGE_N25MA_TO_P25MA, GTDIO6X_PMU_FV_SETUP_DEFAULT, 20, &nStatus);
//Measure the voltage output
GtDio6xMeasure(nHandle, 0, GTDIO6X_MEASURE_IO_VOLTAGE, &dMeasurement, 1, 0, 0, &nStatus);

More information on the GX5960 series can be found on the Geotest website.

Look at the following articles for more information about PMU and related applications: PMU White Paper , Semiconductor Testing with GX5295 PMU

Programming I/O Width on the GX5290 Series - Published on 5/7/2012

5/7/2012

The GX5290 series of DIO cards have a programmable I/O width feature that allows the user to trade I/O channel width for vector memory depth. The GX5292, GX5292e, GX5293 and GX5295 cards each offer 256MB of vector memory and the GX5291 offers 128MB of vector memory. Under software control, the vector memory can be configured to support channel widths shown in the table below.

Vector Width	GX5292/GX5292e/GX5293/GX5295 Vector Depth	GX5291 Vector Depth	Corresponding DIO Channels
32 Ch	64Mbit/Ch	32Mbit/Ch	Ch0-31
16 Ch	128Mbit/ch	64Mbit/ch	Ch0-15
8 Ch	256Mbit/ch	128Mbit/ch	Ch0-7
4 Ch	512Mbit/ch	256Mbit/ch	Ch0-3
2 Ch	1Gbit/ch	512Mbit/ch	Ch0-1
1 Ch	2Gbit/ch	1Gbit/ch	Ch0

Additional information on this subject can be found in the GTDIO Programmers Reference Manual under the DIOWriteOutMemory() and DIOWriteDirectionMemory() functions.

Configuring DIO cards for vector widths of 4, 2 or 1

To utilize all of the vector memory when using vector widths of 4, 2 or 1 channel(s), the vector data needs to be packed into a DWORD array (32-bit boundary) before it can be transmitted. The vector data is packed into the DWORD array starting at the LSB of the first DWORD array element. For example, a vector array with the following 32 4-bit hexadecimal values starting at element 0 as shown here in this ATEasy example:

0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F,0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F

will be packed into the DWORD array called adwTxData[] starting at element 0, as follows:

adwTxData[0] = 0x76543210
adwTxData[1] = 0xFEDCBA98
adwTxData[2] = 0x76543210
adwTxData[3] = 0xFEDCBA98

From the above example, it is clear that the packing process is very straightforward and utilizes all available vector memory. To perform the packing function the programmer can use either the GX529x driver DioDataPack() function or can write a custom function to pack the data. Direction control information will also need to be packed into a DWORD array in the same way as the transmit data array. It is important to note that when writing the DWORD array to the DIO cards Output Memory (DioWriteOutMemory()) or to the Direction Control Memory (DioWriteDirectionMemory()) that the dwSize parameter is the number of vectors to transmit not the number of elements in the DWORD array. For example, using the data from the above array the DioWriteOutMemory() and DioWriteDirectionMemory() functions will be as follows:

DioWriteOutMemory(nMasterHandle,adwTxData,0, 32, nStatus)
DioWriteDirectionMemory(nMasterHandle, adwDirCtrl, 0, 32, nStatus)

Notice the dwSize parameter is 32 not 4.

Note: If the DIO card is receiving data, this data will be stored in the receive memory in a packed format in the same way the transmit data is packed above. To analyze the received data it can be unpacked from the DWORD format to its original width using the DioDataUnpack() function.

Configuring the DIO cards for vector widths of 8 and 16 channels

When using vector widths of 8 and 16 channels the transmit data and direction control data does not need to be packed as this process is done automatically by the DioWriteOutMemory() and DioWriteDirectionMemory() functions. The only requirements for using these widths are:
1) When using a vector width of 8 channels the vector data must be in a BYTE array and
2) When using a vector width of 16 channels the vector data must be in a WORD (16-bit) array.

Below are two examples showing how the data can be packed. Example 1 uses the DioDataPack() function and Example 2 uses standard compiler shift commands.

Example 1: Transmit a number of 4-bit elements previously stored in BYTE array called aucFileData[]. The number of elements to transmit is indicated by dwFileSize. This example assumes that the vector data is stored as one 4-bit vector per array element.

To pack the 4-bit data, 8 elements at a time are transferred to a temporary BYTE array (aucTemp[]) and then the DioDataPack() function is used to write the data to each element of the adwTxData[] DWORD array.

!Pack the 4-bit data into adwTxData[] (a DWORD (32-bit) array)
k=0
for i=0 to dwFileSize-1
   !Transfer 8 4-bit elements to be packed into a temporary array aucTemp[]
   for j=0 to 7 do
       aucTemp[j] = aucFileData[i]
        i=i+1
   next
  !Now pack the lower 4 bits of the first eight elements of the aucTemp[] array
  !into the adwTxData[] array starting at location 0. This is the data to be transmitted.
  DioDataPack(4, 8, 0, 1, adwTxData[k], aucTemp, nStatus)
  k=k+1
  !Undo the last increment from the above For {j} loop because For {i} loop will also increment i
  i=i-1
next

!Write the adwTxData array to the Output memory. Remember the dwSize parameter is the
!number of vectors to be transmitted not the number of elements in the adwTxData array.
DioWriteOutMemory(nMasterHandle,adwTxData,0, dwFileSize,nStatus)

Example 2: Transmit a number of n-bit wide elements (where n=4,2 or 1) previously stored in BYTE array called aucFileData[]. The number of elements to transmit is indicated by dwFileSize. This ATEasy example assumes that the vector data is stored as one vector per array element.

This example is written using standard compiler shift commands instead of using the DioDataPack() function. It uses the ATEasy GX529x driver commands but also expands on the above example by working with vector widths of 4, 2 or 1. First, the DIO instrument I/O configuration is read and based on the channel width value (nChWidth), the data mask (nMask) and number of channels (nNumCh) variables are assigned appropiate values. nMask is used to mask the unwanted vector data bits in each aucFileData[] array element and nNumCh is used to shift the data during the packing process.

!Get the DIO I/O Configuration information
DIO Get IOConfiguration(nMasterHandle, nChWidth, nDir)

!Set the nMask and nNumCh variables depending on the channel width
select nChWidth
  Case aChannelsWidth4  !Using a vector width of 4 Channels
      nMask = 0x0f  !Mask out upper 4 bits. In this example data is in lower 4 bits
      nNumCh = 4    !Number of DIO channels. Used to shift data for packing purposes
  Case aChannelsWidth2  !Using a vector width of 2 Channels
     nMask = 0x03   !Mask out upper 6 bits. Data is in the lower 2 bits
     nNumCh = 2     !Number of DIO channels. Used to shift data for packing purposes
  Case aChannelsWidth1  !Using a vector width of 1 Channel
     nMask = 0x01   !Mask out upper 7 bits. Data is in the LSB
     nNumCh = 1     !Number of DIO channels.
endselect

!Now pack the vector data into DWORD (32-bit) array called adwTxData[]
i=0  !Used to count through the vector data array dwFileData[]
k=0  !Used to count through the adwTxData[] as data gets packed
while i < dwFileSize
    j=0
    !Pack aucFileData[] elements into 32bit boundaries
    while j<(32 div nNumCh) and i < dwFileSize
      adwTxData[k]=adwTxData[k] or ((aucFileData[i] and nMask) shl (j*nNumCh))
      i=i+1 !Increment aucFileData[] counter
      j=j+1 !Increment while loop counter
    endwhile
    k=k+1   !Increment adwTxData[] counter
endwhile

!Write the adwTxData array to the Output memory. Remember the dwSize parameter is the
!number of vectors to be transmitted (dwFileSize) not the number of elements in the
!adwTxData array.
DIO Write Memory Out (nMasterHandle,adwTxData,0,dwFileSize)

Program examples

An ATEasy application that demonstrates how to setup a GX5295 DIO card for various vector widths can be downloaded by clicking on this link Q200226.zip. The application has three tests

InitializeDIO. This initializes the GX5295.
4ChWidthDLL: This is example 1 above. This uses the GTDIO DLL commands to setup the card for a 4 channel vector width and to transmit a clock pattern on all four channels.
nChWidthATEasy: This is example 2 above. It uses the GX5295 ATEasy commands to setup the card for a 4 channel vector width and to transmit a clock pattern on all four channels. To change the configuration to output on two channels or only one channel, replace the aChannelsWidth4 parameter value in the configuration setup line
DIO Setup IOConfiguration(nMasterHandle,aChannelsWidth4, 0x0)

with aChannelsWidth2 for a two channel vector width or to aChannelsWidth1 for a single channel vector width.

White Paper: Next Generation Test System Architectures for Depot and O-Level Test - Published on 3/1/2012

3/1/2012

Abstract:
For over 30 years, ATE has been a key resource and tool for the maintenance and repair of electronic systems, subsystems and board level assemblies deployed on a wide range of military-aerospace systems. ATE has been relied upon to maintain and support electronic assemblies for avionics, weapons systems, and communication systems. In addition, repair logistics and the “up-time” demands for these systems have resulted in the need for repair / support strategies that shorten the repair loop. For the US Marine Corp, the need to minimize this repair loop is acute and has resulted in the adoption of a maintenance / repair strategy that employs Depot – level test capabilities which can also be deployed at the field or O-level.

This paper discusses how a PXI-based architecture which employs the GX5960 subsystem can provide the basis for replacing a Teradyne VXI M9 digital test solution. The successful development and implementation of software tool set for migrating M9 or LASAR-based test programs is also presented. The resulting solution offers a downsized test platform that supports legacy test programs while offering portability and performance at a significantly lower cost for both Depot and O-level test needs.

Download the complete white paper

How to Display an Animated GIF File in an ATEasy Form - Published on 2/27/2012

2/27/2012

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

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

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

log1.Append("")

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

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

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

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

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

  ! set the ALog Window to HTML mode to display the animated image file
  logAnimated.PlainText=False
  ! remove the Scroll bar
  logAnimated.Document.body.setAttribute("scroll", "no")
  ! position the image in the Top-Left corner of the ALog control
  logAnimated.Document.Body.LeftMargin=0
  logAnimated.Document.Body.TopMargin=0
  ! get the dimensions of the ALog control for the image height and width settings
  fHeight=logAnimated.Height-4
  fWidth=logAnimated.Width-4
  ! place the image in the ALog window
  sText="        " \"width=\""+str(fWidth)+" \"height=\""+str(fHeight)+"\">"
  logAnimated.Append(sText)

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

Semiconductor Continuity Test Using the GX5295 Digital IO w/PMU - Published on 2/24/2012

2/24/2012

Introduction

Prior to testing the functionality of a semiconductor device, it is often a requirement to verify the structural integrity of the device by measuring its DC parameters. If a device fails any of the DC parameter tests, then there is no need to waste time (or money) running a functional test. DC Parametric Measurement Units (PMU's) can be used to perform dc characterization tests on a device by forcing a voltage and measuring a current, and by forcing a current and measuring a voltage. Using these two simple processes, a full range a DC parameters can be measured.

This article is the first in a series that demonstrates how the per-pin PMU capabilities of the GX5295 can be used to perform DC characterization tests on semiconductor devices. The test programs are written in ATEasy, although any modern programming language could be used, and all screen captures are of the ATEasy application. The tests described here can be conducted on a wide variety of devices, from semiconductor IC's to printed circuit boards, so the ATEasy application was written to allow easier migration to other devices.

Continuity Test

The first step in the test process, and the focus of this article, is to determine if the Device Under Test (DUT) is connected to the tester resources – in this case the GX5295 Digital IO (DIO). This test is called a “Continuity” test, and it verifies continuity between the tester and DUT by detecting the ESD diode found on IC pins. Tester-to-DUT continuity is measured by forcing a small current on to the DUT pins, and measuring for the presence or absence of a voltage. This utilizes the Force Current, Measure Voltage (FIMV) capability of the GX5295’s PMU. The ESD protection diode is a semiconductor device, and the voltage developed across it when a current flows is consistent with the voltage drop across a semiconductor junction. If the ESD diode is not present, or in the case of continuity tests, if the tester is not connected to the DUT pin, current will not flow through the ESD diode and the voltage will be inconsistent with semiconductor junction voltage drops. If the ESD diode is defective, then other voltage anomalies can be detected, such as “0” volts measured across an ESD diode in cases where the diode is shorted.

Pin Mapping

Before any test or measurement can be performed, you must define the system configuration. An ATEasy "Command" was created that allows the test programmer to define the number of DUT's (Device Under Test) installed in the test fixture, and their pin counts. For additional information about defining commands in ATEasy, refer to the ATEasy Help/Commands on-line documentation. It is assumed that all of the DUT's are of the same type device. The command specifys the number of DUT devices to test (nCount), and the number of pins per DUT (nPins), takes the form:

Dut Define Counts(nCount, nPins)

In order to force currents and measure voltages on DUT pins, it is necessary to define in software the connections between the tester resources and the DUT IO. In this example, pin mapping is performed using another special command defined in ATEasy that will store the “Tester-Channel to DUT-Pin” correlation in a structured array. The pin-map structure also holds the DUT pin name and pin type (Output, Input, IO, Vcc1:4 and Ground) - which is useful for providing information about the pins being tested. When used, the “Dut Define PinMap” command specifies the DUT pin_type, the DUT pin_name, the DUT pin_number, and an array containing the DIO channel numbers channel_number. An array is used for the DIO channel numbers to support mapping pins from multiple DUT devices to appropriate DIO channels. The command takes the form:

Dut Define PinMap pin_type ("pin_name", pin_number, channel_number[])

The sample device used is an SN74HC273 octal latch in a 20-pin TSSOP package. The commands for defining the number of DUT devices, the DUT pin count, and the DUT/DIO pin mapping are shown below.

Note: The DIO channel array is defined in line with the pin mapping commands for clarity, but could be entered via oteher means, such as reading from a file or spreadsheet, or by entering the channel numbers from a dedicated GUI, to mention a few:

Dut Define Counts(1,20)

Dut.DioChannels={0}
Dut Define PinMap Input ("Clr-", 1, Dut.DioChannels)
Dut.DioChannels={1}
Dut Define PinMap Output ("Q1"  , 2, Dut.DioChannels)
Dut.DioChannels={2}
Dut Define PinMap Input ("D1"  , 3, Dut.DioChannels)
Dut.DioChannels={7}
Dut Define PinMap Input ("D2"  , 4, Dut.DioChannels)
Dut.DioChannels={4}
Dut Define PinMap Output ("Q2"  , 5, Dut.DioChannels)
Dut.DioChannels={5}
Dut Define PinMap Output ("Q3"  , 6, Dut.DioChannels)
Dut.DioChannels={6}
Dut Define PinMap Input ("D3"  , 7, Dut.DioChannels)
Dut.DioChannels={3}
Dut Define PinMap Input ("D4"  , 8, Dut.DioChannels)
Dut.DioChannels={8}
Dut Define PinMap Output ("Q4"  , 9, Dut.DioChannels)
Dut.DioChannels={-1}
Dut Define PinMap Ground ("Gnd" ,10, Dut.DioChannels)
Dut.DioChannels={17}
Dut Define PinMap Input  ("Clk+",11, Dut.DioChannels)
Dut.DioChannels={15}
Dut Define PinMap Output ("Q5"  ,12, Dut.DioChannels)
Dut.DioChannels={10}
Dut Define PinMap Input  ("D5"  ,13, Dut.DioChannels)
Dut.DioChannels={13}
Dut Define PinMap Input  ("D6"  ,14, Dut.DioChannels)
Dut.DioChannels={12}
Dut Define PinMap Output ("Q6"  ,15, Dut.DioChannels)
Dut.DioChannels={11}
Dut Define PinMap Output ("Q7"  ,16, Dut.DioChannels)
Dut.DioChannels={14}
Dut Define PinMap Input  ("D7"  ,17, Dut.DioChannels)
Dut.DioChannels={9}
Dut Define PinMap Input  ("D8"  ,18, Dut.DioChannels)
Dut.DioChannels={16}
Dut Define PinMap Output ("Q8"  ,19, Dut.DioChannels)
Dut.DioChannels={1000}
Dut Define PinMap Vcc1   ("Vcc" ,20, Dut.DioChannels)

Note: Two special pin mapping parameters need to be mentioned. First, the "-1" DIO channel specified for the DUT "Gnd" signal indicates that this DUT pin is not mapped to any DIO channel. In this case, this is due to the layout of the DUT load board, which connected the DUT Gnd pin to a ground plane, rather than a DIO channel. Second, specifying DIO channel "1000" for the DUT "+5V" Vcc pin means the Vcc pin is connected to one of the four auxilliary IO pins on the GX5295. These "Aux" channels are mapped to DIO channels starting at 1000. Specifying DIO channel 1000 as the DUT Vcc input means that the GX5295 AUX 0 channel will be supplying the Vcc voltage for the DUT.

Continuity Measurement

To test for continuity, another ATEasy command has been defined. This command accepts the DUT number and the DUT pin. The DUT pin is a type Variant and can accept the DUT name, as defined by the pin mapping command, the DUT pin number as a text parameter, or the DUT pin number as a numeric parameter. Two other parameters are passed by reference (pointer) and return the DUT pin number and DUT pin name associated with the DUT pin Variant. The command returns a type Double voltage measurement for the specified pin after a small negative current is first applied to the pin. The command takes the form:

dMeasurement = Dut PMU Measure Continuity (nDutNumber, varDutPin, pnDutPin, psDutPin)

As an object oriented programming language, ATEasy allow a unique name for each test defined in it’s Task/Test structure (see ATEasy Help/Test). The test name is accessible as a text string at run-time using the "Test" object variable and the “Name” property, as shown below:

string = Test.Name

This simplifies the overall test program to simply calling the Dut PMU Measure Continuity() command using Test.Name, and defining the Test.Name to be either the DUT pin name, or the DUT pin number. The example below measures continuity on the DUT pin defined by the test name, and using ATEasy’s internally defined TestResult variable to store the continuity measurement. The continuity measurements can all be invoked the same for each test:

TestResult=Dut PMU Measure Continuity (1, Test.Name, pnDutPin, psDutPin)

An example of the ATEasy Task/Test structure is shown in figure 1 below. Notice that each test name is unique and the same as the names used in the pin mapping commands from above. Notice also that each test provides the minimum and maximum voltages for determining the Pass/Fail status of the continuity test (Min/Max parameters are visible just above the highlighted command). ATEasy will automatically evaluate the measurement returned to TestResult against the Min/Max parameters to determine the Pass/Fail status of each continuity measurement, and will automatically report the results of the evaluation to the Test Log (standard output) or Test Executive (ATEasy’s Test Management driver utility).

Figure 1: Continuity Task/Test Structure and Test Command

The Test PMU Measure Command is attached to a procedure call where the continuity measurement occurs. The procedure, TestContinuity, is located in a driver called DUT, as are the commands discussed in this article. The procedure calls another procedure, _GetPinInfo, which searches the structure array for the name or number of the DUT Variant pin passed in by the command, and when found, extracts the DUT pin number and DIO channel number associated with that pin. The code for _GetPinInfo is shown below:

Procedure _GetPinInfo(nDutNumber, varDutPin, nDioPin, pnDutPin, psDutPin): Void
--------------------------------------------------------------------------------
nDutNumber: Val Short          !DUT device number
varDutPin: Val Variant         !DUT Pin ("Name", "Number" or valNumber)
nDioPin: Var Short             !DIO Channel number
pnDutPin: Var Short            !Returned DUT pin number
psDutPin: Var String           !Returned DUT pin name
nHandle: Short                 !DIO handle
iPin: Long                     !Pin index counter

{
! Get the DIO session handle
   Dio Get MasterHandle(nHandle)

   If VarType(varDutPin)=vtBstr
   ! The procedure searches the structure array for the "name"
   ! or "number" of the DUT pin passed in by the command,...
      For iPin=0 to m_nDutCount[1]-1
         !  and when "name" is found...
         If LCase(m_astDomain[nDutNumber-1,iPin].Name)=LCase(varDutPin)
            ! the DUT pin number is saved, ...
            pnDutPin=iPin+1
            ! the DUT pin name is saved, ...
            psDutPin=m_astDomain[nDutNumber-1,iPin].Name
            ! the DIO channel number is used for the measurement process
            nDioPin=m_astDomain[nDutNumber-1,iPin].DIO
            ExitLoop ! exit the loop
         ! or when "number" is found...
         ElseIf Val(varDutPin)=(iPin+1)
            ! the DUT pin number is saved, ...
            pnDutPin=iPin+1
            ! the DUT pin name is saved, ...
            psDutPin=m_astDomain[nDutNumber-1,iPin].Name
            ! the DIO channel number is used for the measurement process
            nDioPin=m_astDomain[nDutNumber-1,iPin].DIO
            ExitLoop ! exit the loop
         EndIf
      Next

      ! If the DUT pin "name/number" was not found...
      If iPin=m_nDutCount[1]
         ! generate an error exception and return
         Error 1,"DUT pin name/number \""+varDutPin+"\" not found"
         Return
      EndIf
   Else
      pnDutPin=varDutPin
      ! If the DUT pin number exceeds it's limits...
      If pnDutPin<1 or pnDutPin>m_nDutCount[1]
         ! generate an error exception and return
         Error 1,"DUT pin number "+Str(pnDutPin)+" invalid"
         Return
      EndIf

      ! The DUT pin name is saved, and ...
      psDutPin=m_astDomain[nDutNumber-1,pnDutPin-1].Name
      ! the DIO channel number is used for the measurement process
      nDioPin=m_astDomain[nDutNumber-1,pnDutPin-1].DIO
   EndIf
}

The DIO channel number returned by _GetPinInfo is used for the continuity measurement. The DIO channel is placed in the Force Current mode and the commutating voltages (voltage clamps) of +5V and -2V are applied to the DIO channel to keep the DUT pin voltage to a level that is safe for the DUT. A small negative current (-0.5mA) is applied to the DIO channel, and the resulting voltage is measured. Once the measurement is complete, the DIO channel is returned to dynamic mode (default) and the measured voltage is returned to the calling command. The full ATEasy algorithm is shown below:

Procedure TestContinuity(nDutNumber, varDutPin, pnDutPin, psDutPin): Double
--------------------------------------------------------------------------------
nDutNumber: Val Short          !DUT device number
varDutPin: Val Variant         !DUT Pin ("Name", "Number" or valNumber)
pnDutPin: Var Short            !Returned DUT pin number
psDutPin: Var String           !Returned DUT pin name
nDioPin: Short                 !DIO Channel number
dContinuity: Double            !Continuity voltage measurement
nHandle: Short                 !DIO handle
{
! Get the DIO session handle
Dio Get MasterHandle(nHandle)

_GetPinInfo(nDutNumber,varDutPin,nDioPin,pnDutPin,psDutPin)

! The DIO channel is placed in the Force Current mode and...
Dio Setup Channels Mode PmuForceCurrentMode RangeOfChannels(nHandle,nDioPin,nDioPin)
! commutating voltages (voltage clamps) of +5V and -2V are defined
Dio Setup Channels PMU ForcedCurrentCommutatingVoltage RangeOfChannels(nHandle,nDioPin,nDioPin,5.0,-2.0)
! A small negative current (-0.5mA) is applied to the DIO channel, and...
Dio Setup Channels PMU ForceCurrent RangeOfChannels(nHandle,nDioPin,nDioPin,-0.5,aPmuCurrentRange_n2ma_to_p2ma)

! the resulting voltage is measured
Dio Measure PmuVoltage(nHandle,nDioPin,dContinuity,250)

! The DIO channel is returned to dynamic (default) mode and...
Dio Setup Channels Mode DynamicIo RangeOfChannels(nHandle,nDioPin,nDioPin)

!  the measured voltage is returned to the calling command

Return dContinuity
}

Results

ATEasy automatically evaluates the measurement returned to TestResult against the test’s Min/Max parameters to determine the Pass/Fail status of each continuity measurement, and reports the results of the evaluation to the Test Log (standard output) or Test Executive (ATEasy’s Test Management driver utility). Figure 2 shows the Test Executive output with a DUT open continuity failure for pin 2, and a DUT short continuity failure for pin 9.

Figure 2: ATEasy Test Executive Output with DUT continuity Failures

The ATEasy project files for this article can be downloaded here.

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:

Task 1 : Test Compare Structs
------------------------------------------

#   Test Name          Pin    Unit     Value      Result   Status
--- ------------------ ------ ------ ---------- ---------- ------
001 Struct Compare     -      -         -1.0000    -1.0000 Pass
002 Struct Not Compare -      -         -1.0000    +0.0000 Fail*

Task 2 : Test Compare Structs
------------------------------------------

#   Test Name          Pin    Unit     Value      Result   Status
--- ------------------ ------ ------ ---------- ---------- ------
001 Struct Compare     -      -         -1.0000    -1.0000 Pass
002 Struct Not Compare -      -         -1.0000    +0.0000 Fail*

White Paper: Addressing Instrument Obsolescence - Published on 2/1/2010

2/1/2010

Abstract

Many projects and programs rely upon test systems that were designed at the beginning of a program for on-going system support and maintenance. However, as pro-grams are extended beyond their original life term, the equipment, including test systems, must undergo a modernization phase every few years in order to ensure continued sup-port and maintenance of the system and its sub-assemblies. One of the major issues typically addressed by this upgrade phase is equipment obsolescence. As technology evolves, even programs (and test systems) that were originally designed for a long life term can face obsolescence issues. This paper reviews and compares the options available to program managers and test engineers facing test instrument obsolescence problems. Various options and tradeoffs are discussed including stocking of spare instruments, on-going maintenance & repair of cur-rent instrumentation, replacement through the used market, migration of existing Test Pro-gram Sets (TPSs) to fit a new test system, re-placement using similar products with software or hardware adapters, and replacement using same Form-Fit-Function instrumentation.

Download the complete white paper

White Paper: Designing PXI-Based Systems for Field and Flight-Line Applications - Published on 2/1/2010

2/1/2010

Abstract

PXI has become a mainstream test and data acquisition platform in the MIL/Aero market. Numerous programs addressing Depot and Intermediate-level test requirementsnow use PXI as the core of the product.
While the Mil/Aero market and specifically the military would prefer the use of PXI based systems for field and flight-line test applications due to its small size, weight, and cost, the question of suitability needs to be addressed. Is PXI suitable as a platform for field and flight-line applications? Can PXI be used in harsh environments?
This paper addresses these issues and demonstrates how PXI can be used in harsh environments, and how Commercial Off The Shelf (COTS) solutions can replace the once traditional solutions of custom test equipment.

Download the complete white paper

White Paper: A Common Core PXI Test Platform for Factory and Depot Applications - Published on 2/1/2010

2/1/2010

Abstract

The test requirements for the manufacturing and maintenance of military - aerospace components, subsystems, and systems should ideally be addressed by a common test platform. The ability to leverage test programs, fixturing, test resources and even product knowledge all points to the use of a common core platform. However, more often than not, the requirements for supporting and maintaining these assemblies results in specifying and developing completely different test solutions- resulting in higher capital and maintenance expenditures for deployed systems and components. This paper reviews how one can successfully address the test needs associated with both the manufacture and maintenance of systems and components - based on a common core
solution and built around the PXI architecture, which can successfully address both the performance and economics aspects of test. The paper also presents a real world example of how this strategy has been successfully implemented on a current weapons system program.

Download the complete white paper

White Paper: New Ruggedized COTS field tester is an attractive and economic alternative - Published on 2/1/2010

2/1/2010

Abstract

While COTS Test Systems are becoming more widely used in Depot and Second-Level Test Sets, Field-Level COTS Testers are beginning to gain acceptance by Military customers and OEM suppliers. Ruggedized lightweight housings with general purpose COTS cards and backplanes are now serving roles once reserved exclusively for custom dedicated designs. COTS PXI instrument-on-a-card manufacturers are learning how to migrate commercial designs to meet the challenges of first-line testing. These ruggedized COTS testers, offering a wide range of capabilities, are more easily upgradeable and re-configurable than their dedicated counter-parts. They also cost substantially less, making them a technically attractive and economic alternative.

Download the complete white paper

White Paper: Integration of Software Technologies into a Test System - Published on 2/1/2010

2/1/2010

Abstract

Test applications often require integration of many software technologies. The white paper describes the benefits and the ways to integrate software technologies into an application. Several samples are provided:

A specific instrument driver is available only in a particular technology. Re-using or integrating the driver requires using that technology.

The application requires use of external software components to provide additional functionality such as databases to store test results or test requirement, user interface (i.e., ActiveX controls), spreadsheet, test log generation (HTML/XML), data analysis libraries, communication protocols, and more.

Existing or legacy code can be integrated into the current application.

Integration of these technologies will maximize code reuse and will allow faster completion of the test system application. The use of intuitive software can minimize coding, making integration of these technologies possible.

Download the complete white paper

White Paper: Independent Integrator Consolidates Resources - Published on 2/1/2010

2/1/2010

Abstract

Support equipment capability and availability are frequently not primary issues facing recipients of new Military Systems - but they should be! Such support equipment is invariably provided as a part of the Military System field deployment - support equipment whose objective is narrowly defined, and sometimes exclusively focused on the one system, subsystem, or device. Unlike the Prime Contractor (who is motivated to support only their own products), an independent PXI Systems Integrator is sometimes able to consolidate test resources by broadening the mission of the support equipment. Utilizing COTS PXI technology, an Independent Integrator could expand the mission of a Bench-Top Maintenance Tester to include a family of applications, often including UUTs from multiple OEM suppliers, and ultimately save ground support and depot support organizations millions of dollars.

Download the complete white paper

White Paper: Obsolescence Replacement—Applied Technology - Published on 2/1/2010

2/1/2010

Abstract

Equipment obsolescence is a growing concern for both military and commercial test equipment users. Many critical test systems currently in use were designed to remain in service for many years - sometimes even decades - using the most innovative technology at the time. However, as technology constantly evolves, newer, more advanced systems have since taken the place of these legacy systems. In fact, many of the older technologies are no longer in production so when instruments fail, the replacement components may not be available and the instruments become nonmaintainable.
This paper covers the options available to test engineers and program managers facing test equipment obsolescence problems. These include on-going maintenance & repair, replacement through a secondary (used) market, replacement using similar products and software or hardware adapters, re-hosting all existing Test Program Sets (TPSs) to a new target system, and replacement using 100% form-fitfunctioninstrumentation.

Download the complete white paper

Running a batch file or command prompt from ATEasy - Published on 12/23/2009

12/23/2009

The procedure we will be using for calling our batch files is the ATEasy internal function WinExec. Using WinExec causes ATEasy to run a batch file or an executable as an independant child process.

To run a batch file, simply reference it in the WinExec procedure call. The batch file is looked for in several places including the directory in which the project resides. The list of locations and their priorities is located in the ATEasy help files.

! default directory is the directory of execution
WinExec("test.bat")

To clear up any filename ambiguity, you can reference a specific location for the batch file. You can enter the full directory location, but since you are writing a string, you must use escape characters where appropriate (e.g C:\test.bat becomes "C:\\test.bat")

! run batch file in non-default directory
WinExec("C:\\test.bat")

When specifying a location, directories with spaces require quotes around them (e.g. C:\My Documents\test.bat becomes "\"C:\\My Documents\\test.bat\"")

! run batch file in non-default directory (spaces in folder name)
WinExec("\"C:\\My Documents\\test.bat\"")

In these last examples your batch files appeared on the screen while they ran. To get the files to execute in the background, you must pass an optional parameter into your procedure call.

! batch file runs in background
WinExec("test.bat", aformShowHide)

So far we have run the batch files directly. For your purposes, you may want to run your executables through the command prompt. Running the following command opens the command prompt.

! call cmd prompt
WinExec("cmd")

Or, to add some more functionality. We will open the command prompt and run our batch file. Using the /k modifier with cmd.exe causes the window to stay open after completing it's task.

! call cmd prompt to run a batch file and remain open
WinExec("cmd /k test.bat")

Alternately, we can use the cmd.exe modifier /c to have the command prompt close after execution and the ATEasy parameter aFormShowHide to have it run in the background.

! call cmd prompt to run a batch file silently and close itself.
WinExec("cmd /c test.bat", aformShowHide)

Finally, to allow a bit of end-user interaction, we could create a form with a textbox and allow the user to enter the name of the file that needs to be run and any additional parameters. In this example, the name of the textbox would be changed to tbUserInput. On a button click, the user input would be inserted into the WinExec command call as follows.

! call a cmd prompt to run a file based on user input
WinExec("cmd.exe /k " + tbUserInput.Text)

The WinExec function launches the command console as a child process and continues the execution of the ATEasy program in parallel with the command console. If you wish for your program to pause and wait until the command console is close, the following example can be used:

Procedure CommandTest() : Void
h : AHandle
{
     ! assign the window to the AHandle variable
     h=WinExec("cmd")

     ! wait for the window to close
     WaitForSingleObject(h)
}

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
  }

For more information about how to select a printer for printing refrer to Q000090

White Paper: DTIF (IEEE-1445) - Based Digital Test Solution - Published on 10/1/2009

10/1/2009

Abstract

The digital test interchange format (DTIF) is defined by the IEEE-1445 specification and provides a standardized digital data interchange format that can be used with various digital test environments. This standardized format, when used in conjunction with tools for post-processing of DTIF files and appropriate functional test digital hardware, offers a cost effective and viable solution for migrating legacy TPS’s to a modern digital test system platform.

This paper provides an overview of how DTIF files generated by simulator tools such as Teradyne’s LASAR simulator can be used in conjunction with modern digital test post-processing tools and hardware to provide a robust TPS migration strategy for legacy digital test applications including support for Go / No-Go tests, guided probe and fault dictionary functionality. All of these capabilities are supported by the DtifEasy software tool set which can be used with the GX5292 or GX5055 digital instrumentation to re-host legacy applications developed on GenRad, Teradyne, Hewlett-Packard, or Schlumberger functional test systems.

Download the complete white paper

White Paper: Integration of Software Technologies into a Test System - Published on 10/1/2009

10/1/2009

Abstract

Test applications often require the integration of many different software technologies. This paper provides an overview of how several Windows-based technologies can be incorporated into a single application by employing ATEasy's common software framework and architecture. Technologies discussed are DLL, ActiveX/COM, .NET, Function Panel drivers (.fp, VXI Plug&Play drivers), IVI-C and IVI-COM. ATEasy is used to demonstrates several of these technologies.

Download the complete white paper

White Paper: Implementing Serial Bus Interfaces with General Purpose Digital Instrumentation - Published on 10/1/2009

10/1/2009

Abstract

The use of generic digital test instruments for emulating common serial bus protocols can provide benefits over dedicated bus test products, and often presents a trade-off between functionality, flexibility and cost. For example, a dedicated test instrument solution can offer more extensive test capabilities such as protocol support for controlling and analyzing traffic between a bus controller and a device under test. However, a more general-purpose solution that utilizes a digital test instrument can offer the flexibility to adapt to non-standard line rates and timing as well as supporting other digital test needs. This paper presents an overview of how a general-purpose digital I/O instrument such as the PXI GX5290 series of DIO cards can used to support three widely used serial bus interfaces. By using a general-purpose digital I/O solution, users can potentially realize a lower cost test solution, a more compact test system footprint, multi-site test capability, a common user control interface and expandability for future requirements.

Download the complete white paper

White Paper: Consolidating Test Resources for Avionics Production Test – Requirements and Applications - Published on 9/24/2009

9/24/2009

Abstract

The manufacturing and test of avionics products for military and commercial aircraft presents a unique set of requirements and challenges. Historically, the development and deployment of production test systems for avionics products such as aircraft data acquisition and recording systems, navigation and communication products, and aircraft network systems have been addressed on a product specific basis – resulting in a variety of test platforms and solutions with little test system commonality and technology.

Additionally, this lack of test system commonality and the requirement to maintain legacy products with long product life cycles results in increased maintenance and logistics costs for manufacturing and support test. The adoption of a common test platform can offer producers of avionics products lower test costs, improved test resource utilization, and the flexibility to support both new and legacy products. This paper reviews the requirements and the implementation of a common test platform and environment based on the GX7100A PXI 6U/3U chassis and ATEasy. The resulting solution offers a high level of efficiency, supports the implementation of routine test processes, offers reusability, and allows the consolidation of test resources to facilitate the collection of reliability data and test results.

Download the complete white paper

White Paper: PXI Based Flight-Line Test Sets - Published on 9/24/2009

9/24/2009

Abstract

In the past decade, PXI has proven to be a powerful and robust standard that is suitable for most Mil-Aero test applications. PXI-based testers are widely used today in engineering test stations, as production acceptance testers, environmental stress screening testers, as well as full-fledged Intermediate-Level and Depot-Level testers. A lesser known fact is the success of PXI for field and flight-line test applications. This paper discusses several flight-line and back-shop test applications based on Commercial-Off-The-Shelf (COTS) PXI products. The applications include a Field Test Set for the Maverick missile system, a back-shop test set for the Alternate Mission Equipment (AME) for the F-35 Joint Strike Fighter (JSF), a back-shop armament test set for the TA-50 and FA-50 aircraft, and a portable test set for the C-130. These four testers are all based on an ultra-rugged COTS PXI platform - the MTS- 206 / 207 which has been successfully deployed since 2004 and has demonstrated the ability to operate reliably in any operational theater. The four testers demonstrate PXI’s viability as an ultra-rugged field and flight-line platform - offering performance and capabilities that were previously only achievable with custom electronics or MIL-SPEC VME products.

Download the complete white paper

White Paper: Automating Flight Line Testing for Proximity Sensor Maintenance Applications - Published on 9/22/2009

9/22/2009

Abstract

Embedded passive position sensors in various commercial aircraft locations have exhibited substantial failure rates and have resulted in costly turnbacks and delayed flights. Responding to the need to proactively identify marginal sensors prior to failure, Geotest and Alaska Airlines have developed an inexpensive test system that can facilitate the maintenance and troubleshooting of passive flaps and slats sensors for the Boeing 737-400 aircraft. The test system is used during heavy maintenance on commercial aircraft to identify, predict and analyze the failures of these embedded sensors.

Download the complete white paper

White Paper: DATSA Obsolescence Management Approach - Published on 9/22/2009

9/22/2009

Abstract

The AN/GSM-305 Depot Automated Test System for Avionics (DATSA) is an aging Automatic Test Equipment (ATE) used by the U.S. Air Force on the B1B and F-15 programs since the late seventies. Originally built by Emerson, the DATSA systems are now faced with many obsolescence and reliability problems due to the “advanced age” of the systems. While there is no current funded program to replace all the DATSA systems in the inventory, each Air Logistics Center (ALC) is taking the necessary steps to improve the current situation and “patch up” the DATSA for their own local needs. One of these efforts, by Oklahoma City ALC (Tinker AFB), includes extending the DATSA life by replacing key obsolete instruments that can no longer be maintained.
Another effort by Ogden ALC (Hill AFB) led to the replacement of the DATSA altogether with an off-the-shelf tester that already had most of the TPSs for that program. This paper compares these two cases of extending life and complete replacement.

Download the complete white paper

White Paper: Joint Strike Fighter Alternate Mission Equipment Test Set - Published on 9/22/2009

9/22/2009

Abstract

With the Joint Strike Fighter (JSF) program underway, many new airborne products will have to be tested and maintained for the next few decades. The tester selected by the U.S. Air Force to be the standard platform for manufacturing, ESS (Environmental Stress Screening) and depot-level testing is the Lockheed Martin LM-STAR test set. LM STAR is an open-architecture test set with most of the test set’s components being Commercial
Off The Shelf (COTS) products. Using COTS products helps reduce up-front and maintenance costs and simplified the development process. The test set platform is only the beginning and hundreds of Test Program Sets (TPSs) will be developed for the LM STAR in the next decade to support the 3000+ aircraft to be used by the U.S. Air Force and our allies.

Download the complete white paper

White Paper: Instrument Certification as part of a Modular Test platform Architecture - Published on 9/22/2009

9/22/2009

Abstract

The use of modular test systems for depot, intermediate, and factory test applications has increased dramatically in the last two decades. Today, the primary card modular architecture is based on the PCI Extensions for Instrumentation (PXI) standard with thousands of PXI-based systems in use today. The flexibility and configurability associated with PXI has also created new challenges for the calibration and certification of these systems. Historically, the process for re-certification of modular instruments has been to remove and return the modules to the original equipment manufacturer (OEM) or a 3rd party test house, resulting in system down time. However, a better certification method for a card modular architecture is to develop an overall methodology and implementation that allows recertification of modules within the host system. This paper discusses the features and benefits associated with incorporating a PXI-based standards module (GX1034) as the basis for implementing a system level re-certification strategy. By employing a standards module within the system, recertification logistics and maintenance can be simplified, resulting in extended system up time and offering test managers added flexibility for supporting in-house certification of the system and system components. The GX1034 incorporates frequency, resistance and voltage standards and source / measurement facilities allowing the system designer to implement a baseband re-certification strategy for an automatic test system (ATS) platform.

Download the complete white paper

Related Product: GX1034 - Standards Module

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.

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

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

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

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

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

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

White Paper: PXI - The Future of Test - Published on 4/14/2009

4/14/2009

Abstract

As commercial and military electronic technology evolves so does the need for more sophisticated, reliable, and cost-effective test equipment. The new PXI platform fills this gap and provides the ultimate test solution for field, laboratory, or manufacturing test applications. This paper discusses the evolution of test that led to the development of the PXI standard and provides technical information of the PXI Bus.

Download the complete white paper

White Paper: PXI for Military Test Applications - Published on 4/14/2009

4/14/2009

Abstract

As PXI is gaining in-roads into military test applications, systems integrators start using the PXI platform as the core of military testers for manufacturing, service, and field test. This paper discusses two such applications. The first is a production tester used in the manufacturing of the Longbow launcher and the second is a portable field tester for the Maverick Missile System.

Download the complete white paper

White Paper: Military and Field Test Applications Using Modified COTS Products - Published on 4/14/2009

4/14/2009

Abstract

Field test for military and industrial applications requires special test equipment that meets stringent environmental requirements. These test applications require hardware that can provide high-performance and capabilities, yet be portable and rugged to ensure usability in the field. Typical environmental requirements include extended temperature range, shock & vibration, altitude, humidity, salt-fog, explosive atmosphere, EMI/RFI and more. The required levels are in most cases higher than those provided by Commercial Off The Shelf (COTS) equipment, which dictates a different approach by the tester designer. This paper discusses design approaches for such testers or data acquisition systems and advocates the use of modified COTS as the preferred solution.

Download the complete white paper

White Paper: Next Generation COTS Test Systems - Published on 4/14/2009

4/14/2009

Abstract

This paper surveys card-to-card coordination, synchronization, triggering, and cross triggering in PCI eXtensions for Instrumentation (PXI) commercial off-the-shelf (COTS) systems. It provides an overview with some design guidelines for COTS designers and offers some suggestions to system integrators.

Download the complete white paper

White Paper: Testing MicroProcessor-Based Boards - Published on 4/14/2009

4/14/2009

Abstract

Testing Microprocessor-based boards (µP) could be a challenge even for the experienced test engineer. This paper reviews the related challenges and available test philosophies for the functional testing of these products.

Download the complete white paper

White Paper: Integrating VISA, IVI and ATEasy to Migrate Legacy Test Systems - Published on 4/14/2009

4/14/2009

Abstract

New software technology, such as Interchangeable Virtual Instruments (IVI), benefits customers of Automatic Test Equipment by reducing cost of ownership. The costs of rehosting test program software due to obsolescence issues can be reduced by using application development environments such as ATEasy and IVI. ATEasy provides the means of changing instruments and test system resources similar to IVI via its interchangeable Instrument Technology (I2T). IVI further allows the customer end-user to make the change without compiling the application, as ATEasy would require. Bycombining the power of both technologies, both the customer and the integrator benefit from maximum flexibility and options for instrumentation obsolescence.
This paper discusses the issues and concerns in applying this strategy to a deliverable test system. It discusses some of the obstacles and "speed-bumps" that were overcome during development. Although IVI has been around for over 5 years, it's still a new technology and early adopters will have the work around issues such as driver availability, varying levels of support by equipment vendors, and the lack of experience in the industry applying IVI.
The ATEasy environment can leverage the current, state-of-the art technology while positioning the user and integrator for the future.

Download the complete white paper

White Paper: Migrating an Electro-Optic Test Bench to PXI - Published on 4/14/2009

4/14/2009

Abstract

This paper describes how the Electro-Optic Test Bench ground support test equipment for the TOW Missile has been pressed into extended service even though it is not supported and is obsolete. A new COTS PXI-based test system and optical bench has been designed to replace the obsolete test set for all versions of TOW.

Download the complete white paper

Using Trigger Mapping on the GX7XXX Smart Chassis - Published on 3/26/2009

3/26/2009

One of the capabilities that differentiate a test and measurement instrument installed in a PXI chassis from traditional rack-and-stack instruments and instruments installed in a PCI mainframe, is the addition of the PXI trigger bus.  This bus facilitates a more tightly integrates suite of instrument by allowing PXI-based instruments to synchronize operation using common clocks and triggers, without the need for external wires or cables.  However, due to the nature of the PCI bus, and by extension, the PXI bus, bridges are required to link bus segments together when more than 8 devices are installed on the bus.  The PCI bridge extends the computer data bus, but does nothing about extending the PXI trigger bus across multiple bus segments, which is necessary to maintain the synchronization capabilities designed into the PXI bus across the full backplane.

Early introductions of PXI chassis' accommodated extending the PXI trigger bus by using jumpers on the chassis backplane to enable triggers and set the direction control of the trigger signals between bus segments.  If for any reason the trigger bus ever needed to be reconfigured, the chassis would have to be powered down, instruments removed to gain access to the backplane jumpers, and the jumpers manually reconfigured to accommodate the new triggering requirements.  This dated technique is still used by many PXI chassis’.

With the introduction the Smart Chassis series from Geotest, this dated methodology has been replaced with software control for mapping and enabling PXI triggers across bus segments.  Trigger mapping can now be set using software commands or virtual instrument panels, all while the chassis is powered on and instruments installed.  Geotest chassis’ that include this “Smart” feature are the GX7000A, GX7100A, GX7300 and GX7600.

To configure trigger mapping you must have the appropriate chassis DLL driver installed and be connected to the chassis using either an embedded controller or a PXI bus extender connected to an external host PC.  To manually set the trigger direction, launch the Chassis Panel application by selecting GxChassis Panel on your desktop or from the Windows Start Menu.  Click on the Initialize button and follow the directions for initializing the chassis (figure 1).

Figure 1 - Generic GX7XXX Chassis Panel

From the main panel select the PXI Trigger Lines tab. The PXI Trigger Lines tab will reflect the number of slots available on the chassis being controlled. The GX7000A and GX7300 each have twenty (20) slots (figures 2 and 3, respectively), the GX7100A has fourteen (14) slots (figure 4) and the GX7600 has nine (9) slots (figure 5).

Figure 2 - GX7000 Chassis Triggers Tab Figure 3 - GX7300 Chassis Triggers Tab

Figure 4 - GX7100 Chassis Triggers Tab Figure 5 - GX7600 Chassis Triggers Tab

The screen indicates which slots are the primary slots and which slots are the secondary slots associated with each bridge. The chassis will continuously monitor the state of the triggers on all of the bus segments and report them via the panel as either a logic "0" or a logic "1". Each bridge between bus segments provides three controls for each trigger line. Simply click on the desired control and a drop-down list will be presented that allows you to select the appropriate parameter:

Direction Control - Direction of the trigger mapping:

NC Trigger Mapping Disabled)

L -> R Primary to Secondary Mapping

L <- R Secondary to Primary Mapping

Primary Control / Secondary Control - Define whether the trigger is passive (monitored only) or actively driven by the chassis:

X Monitor only, driven by instruments installed on that bus segment

0 Force trigger line to logic "0"

1 Force trigger line to logic "1"

blank Monitor only, mapped to (driven by) the opposite bus segment

Once all of the triggers have been mapped for each bridge, the settings can be saved to EEPROM by selecting the Temperature Settings tab and clicking on the Save User Settings button, as represented by the GX7300 panel in figure 6. Once saved, the user defined PXI trigger mapping can be restored manually by clicking on the Recall User Setting button on the Temperature Setting tab, or automatically on power-up by clicking on the Recall User Settings radio button under the Load Settings On Power Up control group. Be sure to save user settings each time you change the Load Settings On Power Up control or the new selection will not be remembered during the next power cycle.

Figure 6 - Save/Recall User Settings

Setting of the PXI bridge trigger mapping can also be accomplished programmatically using the GxChassisSetPxiTriggerLine function, and the GxChassisGetPxiTriggerLine function can be used to query the current trigger mapping settings . The format for these functions are described fully in the GX7XXX User Guide:

GxChassisSetPxiTriggerLine (nHandle, nLine, nSegment, ucDirection, nPrimaryMode, nSecondaryMode,pnStatus)

GxChassisGetPxiTriggerLine (nHandle, nLine, nSegment, pucDirection, pnPrimaryMode, pnSecondaryMode,pnStatus)

The Load Settings On Power Up parameter can be set programmatically using the GxChassisRecallSettings function. The format for this function is described fully in the GX7XXX User Guide:

GxChassisRecallSettings (nHandle, nSettingSource, pnStatus)

Support for ECL / PECL Logic Levels - Published on 3/25/2009

3/25/2009

Instruments that provide PECL interfacing are the GX5050, GX5150 and GX5152, provide they are configured with the GX5940 PECL I/O module. The GX5280 Series or the GX5290 Series do not have support for PECL.

ECL (Emitter Coupled Logic) and PECL (Positive ECL) are both differential I/O interfaces and are not compatible with single-ended logic families. ECL logic is designed to work with negative power supply levels, and the normal logic levels for ECL are:

V(OH) = -0.9 V
V(OL) = -1.7 V

The term PECL means we are using ECL logic but with Positive power supply voltages. The normal logic levels for PECL are:

V(OH) = 4.1 V
V(OL) = 3.3 V

The GX5280 and GX5290 series Digital I/O instruments support two types of logic interfaces, Programmable LVTTL and LVDS – except for the GX5291, which supports only Programmable LVTTL levels. Neither LVTTL nor LVDS are compatible with ECL or PECL logic.

LVTTL is a single ended I/O standard with output levels programmable in the range of:

Min: 1.4V
Max: 3.6V

This is compatible with TTL/LVTTL/CMOS/LVCMOS logic families.
The input thresholds for the LVTTL interface is selectable:

1.5 V, 1.8V, 2.5V, or 3.3 V (all are 5V tolerant)

LVDS is a differential signal, similar to ECL and PECL, but the levels are incompatible with either ECL or PECL. The levels for LVDS/LVDM/M-LVDS are:

Differential Output Voltage:
480mV (Min.); 650mV (Max.)
Input Threshold:
Positive going threshold: 50mV (Max.)
Negative going threshold: -50mV (Min.)
Input voltage hysteresis: 25mV (Typ.)

Using WaveEasy with the GX1110 Arbitrary Waveform Generator - Published on 3/25/2009

3/25/2009

WaveEasy can interface with the Geotest GX1110 Arbitrary Waveform Generator software front panel, allowing users to create waveforms using the powerful waveform editor and then downloading the wavefform into the GX1110 memory to generate the wave. The following steps described the process:

1. Create either a standard waveform, a complex mathematical function, or a free hand waveform within WaveEasy. Further information on using WaveEasy to create waveforms can be found in the GtWave Manual.

2. Open the GX1110 Software Front Panel from within WaveEasy; Select GtWave Panel from the WaveEasy Tools menu or click on the GtWave Panel button in the toolbar as shown here:

The GtWave Panel will be displayed:

3. Initialize the GX1110 Software Front Panel and select Arbitrary Waveform Generator from the Operation Mode drop down list:

4. Enter the ARB Start Address (typically 0) and the Length (number of samples) of the waveform you created in WaveEasy:

5. Select [! WaveEasy as the source for loading data and enter the Start (Start pointbv typically 0) and the number of points (Points) you would like to load (typically the waveform size as noted in step 4). Then click Execute:

6. Now the waveform data has been loaded from WaveEasy to the GX1110. Make any changes to the set up of the GX1110 such as amplitutde, sample rate, etc. and click on Apply. Check the Output Enabled box to prepare for output.

7. Use the Run button to start generating the wave, and Stop button to suspend the waveform output:

GX5290 or GX5280 Series Causing Windows Code 12 Error Indicating Insufficient Resources - Published on 1/13/2009

1/13/2009

When using multiple GX5290 and/or GX5280 DIO devices, Windows might not be able to allocate enough contiguous memory resources causing the OS to generate an error code 12.

The code 12 error is caused by a limitation in the PC's BIOS and PCI memory allocation system. Each DIO card requires 16MB of PCI of contiguous memory space to map to the DIO's internal memory structure.

To fix this issue, change the BIOS settings and disable unused peripherals such as LPT1, COM (serial) port, built in audio, and shared graphics memory. This will free up enough resources to allow BIOS and Windows to allocate memory correctly.

You should also update your system with the latest BIOS version.

ATEasy v6.0 SP2 (build 136) - List of changes - Published on 1/12/2009

1/12/2009

The following changes were done since build 132:

ATEasy v6.0 build 136b, November 2008

Check All/Check Module does not check if data type of variables, procedures and types is undefined.

"Too few elements" error message when setting the array initial value with smaller number of elements in the variable property page. ATEasy allows to initial the array with smalller number of elements than what defined in the array.

.NET set-only properties are rejected when loading the assembly.

Assigning Variant to array of enumerated type generated an exception.

TestExec. Prompt On Failure does not prompt unless Pause on Failure was checked.

AChart. Current bar value for HiLo Horizontal Bar chart were not drawn correctly, it was drawn vertically instead of horizontally.

Unable to load a driver saved in build 136/142 with WinSocket interface.

New ATEasy.EXE command line option /s used with /b to suppress the error message that is displayed if the build results in error.

ATEasy v6.0 build 136a, October 2008 (intermidiate build)

When inserting the TestExec driver it create TestExecA shortcut name instead of TestExec.

Passing array of BString to COM method VAR BSTR[] does not work.

Passing array element to Var parameter of late-binding COM/.NET method does not work.

Comparison operands with Variant and unsigned integer returns wrong result.

Passing Var String parameter to an error statement generates an exception.

Passing CreateThread a form procedure generate exception.

VarDimSize() lDim parameter is now optional (0).

Setting AForm.OnQueryUnload pbCancel to TRUE does not keep the form when exiting a a catch block.

When inserting a variable under procedure the workspace displays the procedure variable mistakenly.

Project EXE/DLL file path is relative instead of absolute if not overrode by the user from the Project property page.

TestStatus=ERR terminate the application.

Setting AForm.OnQueryUnload pbCancel to TRUE does not prevent the form from close when exiting a a catch block inside a try statement.

ATEasy v6.0 build 136, August 2008 (service pack 2)

Includes all issues (see below) since build 132 (service pack 1) was release.

New propery AApp.Info property and new type enumAppInfoApp. The property is similar to App.Flags however it retuns a single flag. Two new flags were added aAppInfoIdeAbort and aAppInfoIdeReset indicating True if the user press the IDE abort or Reset command.

Fix. Test executive exit if the abort / reset statements called from within the program (134c issue).

Fix. Test executive did not display fail statistics when abort.

Fix. Type/COM Library display to show void * as Val Any and void ** as Var Any (in both cases address of the variable is pushed).

Fix. #ifdef work also on symbols (variable, types, procedures) and can be used to test if they exist.

Compiler error is generated if passing Const or literal to Var Any.

Fix. Calling a module event in DoIt! mode sometimes ignored.

Fix. VarChangeType/Str did not work properly with BYREF variants.

Fix. ATEasy generated exception when cleaning up a parameter after a DLL call with NULL BString.

Fix. Improved error handling for operation and assignments when using variant data types containg unsigned integers that are unsupported by ole automation.

Fix. New statement for COM or .NET class does not work if the class resided outside of the current module.

Fix. Opening a text format driver file with discrete I/O operations did not read the discrete file correctly resulting in removal of the discrete values.

Fix. Assignment statement between a method or a property to a procedure type variable resulted in NoProcedure.

Fix. Assignment statement between a module event to a procedure sometimes generates NoProcedure.

Fix. Assignment statement between a module event to a procedure sometimes resulted in NoProcedure.

Fix. Opening a workspace files from Windows Explorer sometimes generated an exception.

Fix. Compiling a reference to a .NET class virtual property generated an exception.

New support for Variant data types with VT_Ux (unsigned integers) for operators such as add or subtract. Support for these types also expanded for older Windows (e.g. Windows 2K).

New HW v3.1 (PCI/PXI explorer and hardware access driver) is included in this release - more information is available under Program Files folder, Getotest\HW, ReadMe.txt.

ATEasy v6.0 build 134c, April 2008 (intermidiate build)

DLL Procedure view display the procedure vertically centered next to the +/-.

Task/Test property page will rename the task/test name when untitled base on the task/test title.

Form with many controls are slow to draw in design time.

Changing Tab Order after run and running again genrate exception.

Changing title or name of a symbol not always reflected immediately in the Properties window title.

Startup dialog does not enable the OK button in the Recent page if no recent files are available in the list.

ATEasy About dialog displays the product Serial Number.

Variables initial value is shown in the Properties Value page for types such as DateTime, Double and more.

Viewing a Program DLL Constant value caused it value to be deleted after importing the DLL from header file.

Importing string constant from a hedaer file added extra space to the string.

Deleting a procedure variable from the command view is not updated in the command view procedures view.

Some third party controls (such as Microsoft TreeView, ListView) do not anchor correctly after its parent form or container is resize.

ATEasy generate exception when calculating watch expression with Late Bind expression with typedef return (for example AHandle).

On Empty Workspace, Print Document\Selection Enabled instead of disable.

Unable to set the software license on Vista with user Access Control On.

Loading text format module that have command arguments with function calls corrupt the command argument

Commands displays a procedure in the parameters box instead of no procedure when the top level command is selcted (i.e. Driver)

Improvments to import C/C++ header file.

Improvements to performance of ComRecive/SetInterfaceEvent.

When IDE Reset command is executed. OnReset events are called prior to reloading the application.

Toolbar button stays pressed when a combination of buttons is pressed.

Creating MDI child on a different thread than the MDI frame generate exception.

New support for Val/Var Any to DLL procedure to push Value/Pointer instead of just Pointer.

New examples in Language.prg to show calling sprintf and sscanf using optional Var/Val Any.

Optional [Val] Any not passing Null for second level procedure with [Val] Any parameter.

Optional [Val] array did not allocate one element for each dimension if an array was not passed as an argument.

Assigning lLong=vVariant[2] failed while dDouble=vVariant[2] is OK (vVariant contains array of LONG).

COM Interface with Xon/Xoff handshake not working properly when set from the driver property page (ComSetup does work).

SetLogString() with no argument generate exception.

AImageListImage.ExtracIcon changed to AImageListImage.ExtractIcon.

AImageListImage.ExtractIcon generate exception if Icon not exist.

InputBox/MsgBox window is not using the Windows MessageBox font and sometimes is displayed behind the application window.

AForm.RemoveControl/AForm.RemoveMenu returns Bool value change was reverse to void since causes compatability issue with EXE files.

Internal Error after when event set by AddHandler is called on a form procedure and the procedure calls another control event.

After editing of a test exec profile, the profile will be reloaded if being used by the test executive.

Fault Analysis condition string size limitation increased to 5K.

Test Executive Log Word Wrap is to True to allow longer text not to clip.

Several improvements to the profile action, count and conditions.

New HW v3.0 (PCI/PXI explorer and hardware access driver) is included in this release - more information is available under Program Files folder, Getotest\HW, ReadMe.txt.

New drivers: GX1034, GX2002 and GX2472.

Build 134b November 29, 2007 v6.0 (intermidiate build)

ATEasy now traps exception generated by a DLL when DLL is unloaded

Test Executive/Profile forms for Select Program/UUT/Profile are sizable

AForm.RemoveControl/AForm.RemoveMenu returns Bool with False if an error occured

New drivers GX5290 (GX5292)

Build 134a November 2, 2007 v6.0 (intermidiate build)

GetCallerName - new internal function to return the caller procedure procedure name or test id

Support for Right to Left or non-english Locale:

When Form.RightToLeft is TRUE, menu, statusbar, and toolbar are displayed from right to left
All controls will display text using the current system locale
property pages for controls will display text using the current locale
Form.RightToLeft can be set at run-time (not read-only property)

New Variant constants: VarEmpty, VarErrorArgMissing,

DebugLog can be set at run-time (not read-only property anymore)

ATEasy v7.0 - List of changes - Published on 1/12/2009

1/12/2009

ATEasy version 7.0 contains numerous enhancements to the test development environment, run-time and Test Executive. The following list describes the main changes in this version.

Development Environment

ATEasy DLL - ATEasy supports creating a DLL from ATEasy code. The new Library Wizard creates a Library DLL project. Export commands supports generating of .vb/.h header files with prototypes of the functions exported by the DLL so they can be called from C or Visual Basic languages.

Threads Window - a new debug window for debugging a multi-threaded application. You can use the Threads window to view thread information - call stack and local variables.

Batch Build - a new command that displays the Batch Build dialog allowing you to select multiple workspace projects for build. The selected projects are saved to the workspace file.

Back/Forward navigation commands - these new View commands use the history of windows and symbols viewed and allows you to navigate between these symbols. Similar to Internet Explorer, a drop down history lists all symbols viewed in the ATEasy session.

New Log file format, Web Archive Single File format (.mht) is available in File Open as well as in ALog's Save and SaveAs methods for Log files.

ATML support - provides functions to export and import ATEasy test results and test descriptions in ATML format (.xml).

Support for LabView v8.5, v8.6 (all versions from 7.0 to 8.6 are now supported) and enhanced support for .NET.

Support for USB driver interface - provides control of USB RAW or TMC devices using IO Tables or the internal library.

New IDE Workspace Option for default file saving - Binary and Text format saves in both file formats every time the user saves . Allows you to maintain an up to date text format that can be used by external tools such as text editor or a source control application.

New IDE Options: Arguments for External Tools - a set of predefined variables that are available for invoking External Tools. The Customize Tools dialog has been modified to accept new arguments and their values are passed when the tools are launched.

New IDE Option Auto Recover - this new option, when set, will cause ATEasy to save your work (modified files) every x minutes to a temporary location. When the workspace is loaded again after a system or any other failure, ATEasy will notify you of the modified files that are available for recovery.

New IDE command: Open Containing Folder - opens a folder in Windows' Explorer which contains the selected file.

New ATEasy Development Environment automation server (Application) - provides access to some of the IDE functionality.

Run Time Engine

New LoadLibrary/UnloadLibrary statements for dynamic loading and unloading of DLL libraries while running.

New USB procedures to control USB RAW or USBTMC devices and support for USB driver interface.

New String tokenizer functions : Split, Join, Filter, Replace.

New Math functions - Min and Max returns the minimum or maximum value of two numbers.

New Misc function - GetCallerName used to retrieve the current or caller procedure name or test id.

New Time functions: Now, Date, Time, Year, Month, Day, Weekday, Hour, Minute, Second.

New ATask/ATest properties StartTime and EndTime.

New AApp.Info property and enumAAppInfo returns information about the application.

New Variant constants VarEmpty and VarErrorArgMissing and support for 64 signed and unsigned bit variant integers.

Support for converting a string to DateTime/Currency data types and vice versa.

New optional parameter added to CreateObject() : bFreeThreadingModel. Allows the user to specify the server's threading model to be Free, instead of the Apartment model.

New HW v3.1 (Geotest PCI/PXI explorer and hardware access driver) is included in this release to support VISA, multiple PXI chassis, USB and more. More information is available under Program Files folder, Getotest\HW, ReadMe.txt.

Test Executive Enhancements

External Programs (EXE) Support - Unlike a typical project containing all test programs, supports for external programs allows you to create executables, each containing one (or more) programs, while still allowing all programs to run from the same user interface. The main benefit is the support for modular test program development which allows adding programs to the test executive after the initial release of the application.

Profile driver - create and modify test sequences or profiles programmatically using commands.

Support for Web Archive Single File (.mht) - allows the user to save an HTML test log containing images into a single file.

Ability to disable checking or un-checking of tests and tasks in the tree pane.

New Option to show or hide the Log Summary tab (enOptionsDisplayLogSummaryTab).

New Option to retry a failed Task automatically (enOptionsRetryFailedTask).

See the Test Executive Help for detailed information regarding these new features.

New Examples/Drivers

ATEasyDLL.prj - this example shows how to create an ATEasy DLL and how to use the DLL from ATEasy code or from a C or VB based application.

Profile.prj - this example shows how to use profile commands to create a profile programmatically.

Visa.prj - VISA driver and example - this example shows how to use VISA to control an instrument from ATEasy using the ATEasy Visa.drv driver.

ATML.prj - this example shows how to use the new ATEasy ATML driver (ATML.drv) to export and format test description and results.

Ki210x.prj - driver/example for USB based driver Keithley 2100 DMM.

New Geotest drivers for GX1034, GX2002, GX2472 and GX5290.

List of changes in GTDIO/DIOEasy Software version 3.20 build 42 - Published on 12/8/2008

12/8/2008

GTDIO/DIOEasy Version 3.2 Build 42 (December 2008) Change List

  - Hardware Support Changes:
  - New support for the GX5055 DIO board.
  - New support for the GX5291 DIO board.
  - GtDio versions 3.1 (Build 40) and above does not supports the GT5900, GT2550 and GT5150
    ISA boards anymore, use GTDDIO v3.0 to control these cards.

  - Fixed issues:
     • Driver:DioSetupClkStrobeDelay() returns an error when the handle passed into the function is a File handle.
     • DIOEasy: Gx529X and Gx5055 file types would crash when trying to copy and past channels.

  - New driver (Firmware) functionality:
     • Gx528X/Gx529X:
       - Additional offset (advance or delay) of -3.0 to +3.0 nSec (0.25 increments) was added
         in order to ease timing alignment between DIO boards in a domain. See DioSetupClkStrobeDelay()
         function in the "DIO Programmer’s Reference Guide".
      • Gx529X:
       - Firmware version 0x8A00 and above allow reading the I/O pins data when the card is in PUASE/HALT state.
       - Firmware versions 0x8A00 and above integrates high speed memory read back operation.

  - New driver functions:
     • DioSetupExternalRefClkFrequency() - sets the External refernce clock frequency.
     • DioGetExternalRefClkFrequency() - returns the External refernce clock frequency.
     • DioFileSetChannelsOrder() - sets all 32-channels logical order in a DIO file.
     • DioFileGetChannelsOrder() - returns all 32-channels logical order in a DIO file.

  - DIO Virtual panel:
     • Support configurations using VISA and new multiple chassis slot numbering as
       well as legacy slot numbering.
     • Cut execution time for upgrading DIO's firmware.
     • Add Domain Setting Save and Recall - allow the user to save/recall the domains
       timing calibration settings after calibrating the clock and strobe delays between
       boards in the domain.

  - DIO User's Guides:
     • Update all User's Guides "Chapter 3: Installation and Setup" to reflect the
       support for the new HW v3.0 (PCI/PXI explorer and hardware access driver).
     • Update the "DIO Software User’s Guide" with the latest DIO panel description
       and Configuration.

  - Examples
     • New C example named "GtDioExampleC" supporting all PXI/PCI DIO boards.
     • New VB 6.0 and VB .NET 2005 examples.
     • New Microsoft Visual Basic .NET (2005) GtDio COM Object example.
     • New LabView library and examples.

  - New HW v3.2 ](PCI/PXI explorer and hardware access driver)
  - The new HW v3.2 is included in this release to support VISA, multiple chassis and more -
    more information is available under Program Files folder, Getotest\HW, ReadMe.txt.
    The new HW provides the following new/revised functionality:
    • New function, DioSetupInitializationVisa() - initializes the board using VISA, use VISA
      resource string or alias (configure using HW PXI Explorer) to identify the board
     (require NI-MAX).
    • GtDio boards are shown in VISA resource manager (NI-MAX), using HW v3.1.
    • DioSetupInitialization() function supports multiple chassis slot numbering (for example
      0x203 - chassis 2 Slot 3) as well as legacy slot numbering (1-255) as displayed
      in HW v3.1 PXI/PCI explorer.

Should OCLK and CLK_LVDS have the same phase? - Published on 12/2/2008

12/2/2008

CLK_LVDS (J4-P4 and J4-P38) and OCLK (J3-P22) are sourced from different PLL outputs within the DIO's FPGA, so it is possible for them to have different frequencies and different phase settings. Even if the phase settings are the same for both clocks, the actual phase observed at the output will be different since the respective signal paths are quite different.  Due to the programmability of it, the OCLK goes thru added logic, such as dividers, delays and an external buffer IC. The LVDS clock exits the PLL and goes straight from the FPGA to the connector, resulting in a much shorter signal path.

WARNING:  The CLK_LVDS signal is driven directly from the FPGA.  Shorting the CLK_LVDS may cause damage to the FPGA device.

See Also:  Q200126

Using USBTMC instruments in ATEasy 7.0 - Published on 12/2/2008

12/2/2008

ATEasy 7.0 has the capability to control two types of USB devices, USBTMC instruments and USB RAW instruments.

The following steps will outline how to install, configure, and use the Keithley 2100 USBTMC DMM instrument - this procedure can be applied to other USBTMC instruments:

Plug your USBTMC device into an available USB port on your PC

When Windows finds the new hardware, install either the VISA (if you have installed NI VISA for example) USBTMC driver or the Geotest HW driver

The Geotest HW driver inf file can be found in Program FIiles\Geotest\HW\Hw.inf

From within ATEasy, verify that the driver module you want to use supports USBTMC by checking the driver properties. Make sure the USBTMC and USB checkboxes are set

Insert the appropriate driver into your System module

Right click on the driver shortcut and go to the properties to select "USB" within the interfaces tab. Select your USBTMC device in the drop down menu labled "Device".

Make sure the Vendor ID, Device ID, and Serial Number match your device.

Your USBTMC device can now be used in ATEasy by accessing the configured driver.

USBTMC devices can also be accessed using the built in ATEasy internal procedures for USB such as USBOpen(), USBSetup(), USBSend(), etc. More information can be found in the ATEasy help under the USB heading.

How does the programmable clock delay affect the CLK_LVDS or OCLK signal? - Published on 12/2/2008

12/2/2008

The programmable clock delay (DioSetupClkStrobeDelay) applies to both the internal and external versions of the OCLK; it is the same signal. OCLK (J3-P22) is derived from an internally generated clock, the delayed version of which actually controls the pattern sequencing. Because the data is clocked using the delayed OCLK, the phase relationship of Data Out to OCLK is consistent regardless of the delay setting.

The programmable delay has no affect on the CLK_LVDS signal.

See Also: Q200124

What is the mating connector for the Geotest DIO products - Published on 12/2/2008

12/2/2008

The Geotest DIO cards use 68-pin female VHDCI connector with a shielded, double pin row receptacle. The mating connector is the Honda HDRA-E68MA+ (or equivalent). The plastic shell part number is HDRA-E68LGKPE.

For more information check the Honda Web Site.

Connector Image and Information

How can you play a sound file within an ATEasy application - Published on 10/7/2008

10/7/2008

One of the simplest methods for playing a sound within an ATEasy application involves using the Windows API function sndPlaySound that resides in Winmm.dll.

The sndPlaySound function plays the waveform sound specified either by a file name or by an entry in the registry or the WIN.INI file. The function is described in detail in the Microsoft Developers Network library under the path:

- Win32 and COM Development
    - Graphics and Multimedia
        - Windows Multimedia
            - Multimedia Reference
                - Multimedia Functions

The direct link is: MSDN sndPlaySound. The method for using the sndPlaySound function can be applied to any of the functions described in the MSDN library.

To use the sndPlaySound function within an ATEasy application you will need to:

Insert the Winmm.dll library under the Libraries sub-module of any ATEasy module (System, Driver or Program) - this example uses the Driver module. You can do this by right clicking on Libraries and selecting Insert Library Below. Select the DLL tab and for the DLL File Name parameter, enter: Winmm.dll. Since the DLL resides in the Windows System folder, the DLL file path can be omitted.

Click Insert.

Declare in the libraries Procedures submodule the following function:

sndPlaySoundA(Val String : sSoundFile, Val DWord dwFlags) : Bool

The constants for the dwFlags parameter are described in the MSDN Library and the header file Mmsystem.h. The three parameters used in this example are:

SND_SYNC = 0x0000 ! Play synchronously (default)
SND_ASYNC = 0x0001 ! Play asynchronously
SND_LOOP = 0x0008 ! Loop the sound until next sndPlaySound

The ATEasy Getting Started manual explains how to define a DLL and DLL procedures in an ATEasy application. There are also examples for calling DLL procedures and defining Windows API's in the ATEasy Language.prj example.

Assuming you have a WAV file in the "C:\Sounds" directory called Alert.wav, then the following ATEasy code can be used to play the sound:

sSoundFile: String
{
sSoundFile="C:\\Sounds\\alert.wav" ! Define the WAV file path
sndPlaySoundA(sSoundFile,SND_SYNC) ! Play the sound file
}

The flags can be combined (added) to produce additional effects, such as repeatedly looping the sound for awhile before stopping:

sSoundFile: String
{
  sSoundFile="C:\\Sounds\\alert.wav" ! Define the WAV file path
  sndPlaySoundA(sSoundFile,SND_LOOP+SND_ASYNC) ! Loop the sound indefinately
  Delay(2000) ! Allow sound loop to play for 2 seconds
  sndPlaySoundA(sSoundFile,SND_SYNC) ! Terminate the prior sound loop
}

How to terminate an application from within ATEasy - Published on 10/7/2008

10/7/2008

You can use the following Windows API functions defined in Kernel32.dll to terminate an application using the application's name: Process32First, Process32Next, OpenProcess, GetExitCodeProcess, and TerminateProcess.

First you will need to insert kernel32.dll under Libraries sub-module of the ATEasy module (System, Driver or Program). You can do this by right clicking on Libraries and selecting Insert Library Below. Select the DLL tab and enter the following file path under DLL File Name:
kernel32.dll. Since the DLL resides in the Windows System folder, the DLL file path can be omitted.

Click Insert.

You will now need to define several functions under the procedures section of the newly inserted kernel32 library as shown below:

You will also need to define a structure under the types section of the kernel32 library as shown below:

And finally, will need to define the following variables in your module:

Now you can enter the code required to scan a list of all open processes and terminate one based on its name. In this example, the first instance of Wordpad.exe will be terminated.

CreateToolhelp32Snapshot(2, 0)

ProcInfo.dwSize = sizeOf(ProcInfo)

!Get first Process's information
Process32First(lHandle, ProcInfo)

!Loop until wordpad.exe is found or the end of the process list has been reached
repeat

        !Get the exe file name
        sProcName = lcase(ProcInfo.szExeFile)

        !Check if the current process is wordpad.exe
        if (sProcName = "wordpad.exe")

                !If wordpad.exe is found get its ProcessID
                lHandle = OpenProcess(0x1F0FFF,0, ProcInfo.th32ProcessID)

                   !Terminate wordpad.exe
                TerminateProcess(lHandle, -100) ! -100 is user defined exit code
                exitloop

        endif

until not Process32Next(lHandle, ProcInfo)

How does ATEasy support GPIB Service Requests (SRQ) - Published on 10/7/2008

10/7/2008

There are several ways to support GPIB SRQ's within ATEasy. They are:

Using SetInterfaceEvent() internal function

Using the GPIB driver and implementing OnInterface event

Using EnableInterrupt() internal function

Using I/O Table Receive operation

This article will demonstrate the process for using ATEasy's SetInterfaceEvent() procedure, allowing you to set an ATEasy procedure that will be called by ATEasy when a GPIB SRQ interrupt occurs for a particular GPIB Controller card. A full description of this function is available in ATEasy Help. As there is only one GPIB SRQ line on the GPIB bus, when the event procedure is called, you will have to poll each of the instruments, using GpibSpl(), to find which one requires servicing.

For example, to assign event procedure OnGpibCntlr1SRQ() to the SRQ interrupt of GPIB controller card1 (there may be more than one GPIB controller card in the system), use the following code:

status = SetInterfaceEvent(aioGpib, 0x10000, aioGpibSRQ, OnGpibCntlr1SRQ)

Create a service procedure called OnGpibCntlr1SRQ(). The function will search for all of the GPIB drivers in the application system to find the GPIB instrument generating the SRQ:

OnGpibCntlr1SRQ()
! Declare the following variables
! i                       !short variable to be used as a loop counter
! sDriverName   !String to hold the drivers name
! lAddress         !string to hold GPIB instrument address
! sData              !String to hold instruments buffer information
{
       !Search all the drivers assigned to the application to find the GPIB drivers
       i=1  !System driver numbers start at 1
       while i <= System.DriversCount
              ! System.DriversCount gives the number of drivers assigned to the application
              sDriverName = GetDriverName(i)  !Get the name of the driver
              !Check if it is a GPIB driver
              if GetDriverType(sDriverName) = aioGpib
                  !Get the address of the GPIB driver
                  lAddress = GetDriverAddress(sDriverName)
                  ! Now check Request Service bit (RQS is Bit6) in the instruments Status
                  ! Byte Register (STB). RQS will be set to 1 if service is requested
                  if(GpibSpl(lAddress) and 0b01000000) <> 0  !Check if RQS (bit6) is set
                     !Read the instruments buffer for information on the SRQ
                     sData="" !Clear the buffer array
                     GpibReceive(lAddress, "\r\n", 1, 150, 0, sData, 20)
                     !TODO: Add code to handle the SRQ
                    !...

                 endif
              GpibClear(lAddress)  !Reset the Gpib Instrument if required
          endif
     endwhile
)

PXI Addressing Using Geotest and VISA based Drivers - Published on 9/24/2008

9/24/2008

To initialize a VISA based PXI drivers, you call viOpen(.., resource, …_) function passing resource string as an address that can be one of the following:

Canonical resource name – “PXI::15::INSTR” PXI bus 0 device 15, or using slot numbers “PXI::CHASSIS1::SLOT3::INSTR” –In this case, when you move the board to another slot in the chassis you need to specify different string and change the application.

Alias Name!! ]– “DMM1” – DMM1 need to be defined in the VISA resource manager (usually NI-MAX) Alias Editor and assigned to physical PXI address – In this case, when you move the board to another slot in the chassis you need to open the VISA resource manager and change the alias to point to the new slot – no change to the application is required.

Geotest drivers for PXI instruments are supplied with HW - Geotest Hardware Access Driver. These drivers works in two modes, using VISA or using HW:

Using VISA – Using the Geotest driver GxxxInitializeVisa( … ,sResource, …) function - Allow you to initialize using resource string or alias as in VISA : “PXI::15::INSTR” or “DMM1”) – Using an alias will allow moving of the card without changing the address (you need to change using the VISA resource manager Alias Editor).

Using HW – the Geotest driver GxxxxInitialize(.., nSlot, …) function – You can specify the nSlot parameter in two ways: logical number (legacy slot, for example 3) or physical slot number: chassis*256+slot - 0x103 for chassis 1 slot 3. If you use the logical slot number (3) when you move the board from slot 3 to 4 – You can reassign 4 to 3 logical number using the Geotest PCI/PXI Explorer applet and the app will work with no changes. HW also support alias name, you can set alias name using PXI Explorer and use a HW function to convert the “DMM1” alias as entered in PXI Explorer applet to nSlot to allow using names instead of addresses.

The following are the HW v3.2 functions used to map between alias and physical PXI/PCI address as defined in hw.h:

// returns the VISA resource for the specified alias
INT  HwPciGetAliasVisaResource(PCSTR pszAlias, PSTR pszResource);

// returns the chassis slot for the specified alias (Chassis*256+Slot)
INT  HwPciGetAliasChassisSlot(PCSTR pszAlias);

// returns the legacy slot for the specified alias
INT  HwPciGetAliasLegacySlot(PCSTR pszAlias);

In ATEasy, you configure PXI driver address from the driver shortcut property page. Newer ATEasy drivers (for example GX2200.drv) supports the same type of initialization of the instrument: using VISA or using HW. If you intend to use VISA, set the VISAResource driver parameter to a resource string or alias. If you intend to use HW, set the Slot parameter to legacy or slot number (you can also call the HwPciGetAliasChassisSlot if you intend to use alias).

Notes:

Geotest drivers that were release with HW v1.x or v2.x do not support VISA

Alias mapping is provided with HW 3.2 and above

How to use C language structure with bit fields from ATEasy - Published on 9/22/2008

9/22/2008

Solution:

ATEasy language, similar to Microsoft Visual Basic, does not have a bit field data type as C language structures. This does not prevent you from using bit fields structures when calling to C DLLs. In C, bit fields are grouped to integers (short, long, etc) and in ATEasy you substitute the group with the bit field basic type (for example DWord). To Access the specific field in ATEasy you use AND and SHR operators. For example, if in C you have the following structure:

typedef struct
{
  UINT32 data1 : 10;
  UINT32 data2 : 6;
  UINT32 data3 : 14;
  UINT32 data4 : 2 ;
} DWORDBITS;

In ATEasy the structure is defined as DWord (dwBits). Accessing data2 field is done as follows:

dwData2=(dwBits shr 10) and 0x3F

dwData2=(dwBits shr 10) and 0b111111

A more elegant and prone to changes (in the structure fields) is to use a procedure for setting and getting the fields values. Constants that hold the offset and the fields size can be also used as shown here:

DWORDBITS_DATA2_OFFSET : Word Const = 10
DWORDBITS_DATA2_SIZE : Word Const = 6

Procedure DWordBitsField(pdwBits, wOffset, dwSize, dwValue) : DWord
  pdwBits: Var DWord
  wOffset : Val Word     ! offset of field, 0 based
  dwSize : Val DWord     ! # of bits for the field
  dwValue: [Val] DWord   ! optional, value of the field
  dwMask : DWord
{
  ! get or set DWordBits fields
  dwMask=(2ul ^ dwSize) -1  ! calc mask, 8 bit integer

  If ArgMissing(dwValue)
    ! get and return the field value
    Return   (pdwBits shr wOffset) and dwMask
  Else
    ! set the field and return all the bits
    pdw=(pdwBits and  not (dwMask shl wOffset))  or (dwValue shl wOffset)
    Return pdw
  Endif
}

Now to set data2 to 35 in dwBits:

dwData2=DWordbitsField(dwBits, DWORDBITS_DATA2_OFFSET, DWORDBITS_DATA2_SIZE, 35)

To get data2 from dwBits:

dwData2=DWordbitsField(dwBits, DWORDBITS_DATA2_OFFSET, DWORDBITS_DATA2_SIZE)

Notes:

When you import a C header file that contains bit fields ATEasy substitute them with the basic type.

You can also use the ATEasy Bit() function in the internal library to access (get or set) a single bit.

How can I have two versions of ATEasy in the same computer - Published on 9/4/2008

9/4/2008

ATEasy does not allow running two versions at the same time on the same computer. When you upgrade ATEasy to a newer version, ATEasy setup overrides and replaces current files not allowing you to have two versions of ATEasy on the same computer. The procedure below shows how to install more than one version on the same computer and how to switch between the versions to run specific version.

The following steps describe installing version 5.0 and 7.0 at the same compute. Make sure to read and understand the whole procedure before attempting to perform it:

1. Install ATEasy 5 (run ATEasy5.exe and follow the instructions).
2. Copy ATEasy folder and subdirectories (C:\Program Files\ATEasy) to C:\Program Files\ATEasy5.
3. In the Windows System folder (usually C:\Windows\System32) copy ATEasy files and add 5 to the files name. There may be up to 6 files to copy: ATERT.dll, ATERCTL.dll, ATEasy.usr, ATEasyPanel.cpl and optionally ATEasy2_32.dll and ATEZUSER32.dll – add 5 to the filename. For example copy ATERT.dll to ATERT5.dll.
4. Install/upgrade to 7 by running ATEasy7.exe and follow the instructions.
5. Repeat steps 2 and 3 (above) this time to ATEasy7 folder and ATERT7.dll etc.
6. At this time ATEasy 7 in ready to run (ATEasy 5 will not run).
7. When you need to switch from version X to Y (5 to 7 or 7 to 5), delete the ATEasy folder and copy ATEasyY folder to ATEasy folder (copy ATEasy5 folder to ATEasy) and copy the ATEasy System files to the original files (for example ATERT5.dll to ATERT.dll). Once files are copied, you will need to re-register the files by opening the windows command prompt (Start, Run Cmd), change the current directory to the Windows System folder ("cd c:\windows\system32") and re-register the two files ATERT.dll and ATECTL.dll ("regsvr32 ATERT.DLL" and "regsvr32ATECTL.dll"). At this point version Y is ready for use.

Notes:
1. You can create a batch file to automate this process and launch ATEasy at the end. You can create shortcut on your desktop to switch to version Y.
2. Make sure not to attempt to run executables created with newer version of ATEasy with older run time version. Newer run time can run older EXE files.
3. Modifying files created such as programs with newer version of ATEasy with older version of ATEasy is not recommended.
4. If you wish to have diffrenet options and settings for each version you may also need to copy and restore the ATEasy registry settings under HKEY_LOCAL_MACHINE\SOFTWARE\Geotest\ATEasy and HKEY_CURRENT_USER\Software\Geotest\ATEasy.

How to inform an ATEasy application of a UPS Power Failure - Published on 8/21/2008

8/21/2008

This process will be broken into two parts: first create an application (EXE) that will be called by the UPS Management Software when a power failure occurs. This application should create an AEvent object with a name "UPSPowerFailEvent". After creating it, use the PulseEvent() method to signal the test application that the UPS is now running on battery power and it needs to shut down. Second, the test application will create a thread to watch for a UPSPowerFailEvent signal and if received shut down gracefully.

Step 1: Create an application to be run by the UPS Management Software in the event of a power failure. Note: the UPS Management Software is supplied with the UPS

In ATEasy create an application (for example UPSPowerFailure). In the OnInit event procedure create an object called UPSPowerFailEvent (an object with the same name will be created by the test application). Then use the PulseEvent() method to signal the test application that a power failure has occured.

Procedure System.OnInit()
obUPSEvent: AEvent !Object to inform test application of UPS power failure
{
obUPSEvent = CreateObject("AEvent") ! Create an AEvent object
obUPSEvent.Name="UPSPowerFailEvent" ! Give it the same name as the test application thread
obUPSEvent.PulseEvent() ! Signal the test application of the UPS power failure and that it
! should shutdown
}

Compile the application and add the name of the executable file to the UPS Management Software Event Notification command line.

Step 2: The test application should create a thread when it starts (OnInit). The thread will call a procedure (called MonitorForUPSEvent() in this example). In the procedure create an event with the same name "UPSPowerFailEvent" as used Step 1 above. Then call WaitForSingleObject() to monitor the event signal. Once the wait returns perform the shut down of the application (call abort, exit, display a message etc):

Procedure MonitorForUPSEvent(lThread)
lThread: Val Long ! Required to create the thread
obUPSEvent: AEvent ! Object to be monitored for UPS Failure
{
obUPSEvent = CreateObject("AEvent") ! Create an object
obUPSEvent.Name=" UPSPowerFailEvent " ! Give it the same name as Step 1
WaitForSingleObject(obUPSEvent.Handle,) ! Wait for a Pulse Event to occur

! Once the PulseEvent has occurred there are multiple ways of dealing with the shutdown process. These will mainly depend
! on the UPS battery run time. In this example we will use Abort.

Abort !Jump to System.OnAbort. Add code to OnAbort to run all the instrument and application shutdown routines

}

Procedure System.OnInit()
{
CreateThread(MonitorForUPSEvent)
}

For instructions on shutting down Windows from ATEasy see KB Article Q200070

The language.prg has additional examples of how to use events.

GX5280 and GX5290 Delay Settings - Published on 7/18/2008

7/18/2008

The Gx5280 and Gx5290 boards use a multi-step delay circuit to perform two critical functions:

1. Time-align the internal main clocks across a multi-module digital domain.
2. Adjusting the timing between the data clock (data out) and strobe clock (data in) signals on each module to ensure that valid setup and/or hold parameters are met while testing the UUT.

Domain Offset
While all modules in a digital domain use a common reference clock to maintain synchronization of the data clock and strobe clock, the alignment of theese clock edges is not guaranteed across all of the modules in the domain. The Domain Offset delay can be used to calibrate the modules in a domain so that the respective data and strobe clocks on each module are not only phase locked to each other, but are also phase aligned. The edge of each module’s master clock can be adjusted in a +/- 3nS range with 250pSec resolution, with slower edges adjusted in the negative direction, and faster edges adjusted in the positive direction, until all clock edges are aligned.

Clock and Strobe Delays
The clock and strobe delays are achieved using a two stage process. The first stage is a programmable delay generator capable of generating delays from 0.0nS to 3.0nS, with a 250pS resolution. The second stage consists of a fixed delay generator with six output taps, each offset by 4nS. A switching circuit routs the clock or strobe signal through the appropriate delay path to produce a cumulative delay of the desired value.

Delay Ranges
There is a gap between the maximum 3.0nS programmable delay in the stage one delay circuit and the minimum 4.0nS delay tap in the stage two delay circuit. These 1nS gaps are found between 3.0nS and 4.0nS, 7.0nS and 8.0nS, 11.0nS and 12.0nS, 15.0nS and 16.0nS, 19.0nS and 20.0nS and 23.0nS and 24.0nS. The second reason for the non-linearity is that there are added propagation delays introduced whenever the stage two delay circuit is included in the signal path. Because these additional delay factors are uncontrolled, each module has the potential for slight variations in the cumulative delays.

Changing the log result during run time after the test result is appended to the log - Published on 7/18/2008

7/18/2008

Solution:
You can change the log result during run time (even for tests that have already completed) by utilizing the ATEasy ALog’s Document object. The Document object is consistent with the Document Object Model (DOM of the Internet Explorer) .

In the example code below, the various data members of the ALog Document object are used to modify the contents of the ATEasy test log. The Document object has access to all the text that is output to the test log.

You can modify the text of each entry in the test log by accessing the appropriate innerText property.

Use the following code to modify the log entry corresponding to the first test in the first task:

! obj is a variable of type Object

obj=Log.Document.getElementsByTagName("TABLE")

obj.item(3).cells.item(5).innerText="Some Text"

! Destroy reference to Document object
obj= Nothing

Here is an explanation of how to index the different lines of the test

obj.item(3) corresponds to the first test line in the first task and cells.item(5) corresponds with the sixth column of that particular test line (if you are using a min/max test then this means the test result).

Here are some other examples:

If you have 1 task with 2 tests then obj.item(3) will correspond with task1 test1, and obj.item(4) will correspond with task1 test2.

You have to add 1 to the obj.item index if you are crossing a task. So if you have two tasks, each with 1 test, then obj.item(3) will correspond with task1 test1, and obj.item(5) will correspond with task2 test1.

Use the View Source Log context menu to see the HTML table structure generated by ATEasy.

Note: ATEasy Log must be configured to HTML format in order to use the methods described in this article (log.PlainText=False).

Using threads to execute code within a specified time interval - Published on 6/17/2008

6/17/2008

You can create a thread to execute code at a specified time interval. This can be useful if you want to take a measurement or reading for example every 200 millisecond. Use the following two part process:

1. Create a thread procedure that accepts one parameter and contains the code you want to repeat on a regular, timed, basis.

The following thread procedure takes 50 measurements. Each measurement takes 200 mSec. Once the measurement is taken, the thread is suspended for the remaining time (of the 200mSec) using the Sleep function, releasing the CPU to handle other tasks:

Procedure MeasurementThreadProcedure(num) : Void
{
    num: Long
    dwTimeStart : DWord
    dwTimeEnd : DWord
    i : Long

    ! take 50 measurements each should take no more than 200 mSec
    for i=0 to 49
        !Record time before measurement
        dwTimeStart = Tick()
        !Make measurement
        DMM Measure (g_adMeasurement[i])
        !Record time after measurement
        dwTimeEnd = Tick()
        !Let thread sleep for the remaining time of this 200ms time cycle
        sleep(200-(dwTimeEnd-dwTimeStart))
    next
}

2. In your main program, you create the thread (in this case supended), start it, and then wait for the thread to end before continuing the main program.

- Create a variable of type AHandle in your variables submodule.

- Instantiate a thread object and link it to the previously created procedure using the following code:

hMeasurementThread = CreateThread(MeasurementThreadProc, 1, True, )

This line of code will create a thread and wait for you to start it with the Resume method.
In this example, MeasureThreadProc is the name of the procedure created in step 1 and MeasurementThreadHandle is the name of the AHandle variable created earlier.

- Optionaly. Set the priority of the thread to time critical for improved timing accuracy.


SetThreadPriority(hMeasurementThread, aPriorityTimeCritical)

- Start the thread by calling its ResumeThread function:


ResumeThread(hMeasurementThread)

- Use the WaitForSingleObject procedure to wait for the thread to finish execution (with a 20 second time out) before finishing your main ATEasy program.


WaitForSingleObject(hMeasurementThread, 20000)

Determining the frequency measurement accuracy of the GTX2200 and GC2200 Timer/Counter - Published on 6/17/2008

6/17/2008

For frequency measurements, the GTX2200 family uses a technique known as Reciprocal Counting, a method where the accuracy of the measurement is based on the relationship of the reference clock period and the measurement window duration (gate time), and not the input signal frequency.

This method measures the time interval between two identical trigger points on the input signal, as defined by the trigger level setting and the trigger slope setting.  During the gate time – the window in which the instrument is taking a measurement, the instrument simultaneously counts the number of cycles of the input signal, and the number of clock pulses from the built-in frequency reference.  A microprocessor then calculates the frequency of the input signal.  The absolute resolution of a measurement is the period of one reference clock cycle, and the relative resolution is equal to the absolute resolution divided by the gate time.

For example, if the counter incorporates a 100MHz reference clock, then the absolute resolution is eight digits (10nS = 1.0E-8 Seconds).  Using a gate time of 100mS, the relative resolution is seven digits irrespective of the input signal frequency (10 nS/0.1S = 1.0E-7 Seconds).  The GTX2210, GTX2220 and GTX2230 all use a 100 MHz reference clock, but the GTX2220 and GTX2230 use an interpolation technique which yields an effective absolute resolution of 10 digits, equivalent to a 10 GHz reference clock.

The overall accuracy of the measurement is degraded by the combined effects of the jitter on the measured signal, the jitter on the reference clock, the accuracy of trigger detection circuit and the accuracy of the gate timer.  The frequency measurement accuracies for the GTX2200 family of products are:

GTX2210/GC2210:

#Digits	Gate Time (s)
8	1.000
7	0.100
6	0.010
5	0.001

GTX2220/GC2220 and GTX2230/GC2230:

#Digits	Gate Time (s)
10	1.000
9	0.100
8	0.010
7	0.001

Why is my plain text Log columns not aligned? - Published on 6/17/2008

6/17/2008

When the ALog.PlainText property is set to True, ATEasy will use the Internet Explorer (IE) fixed pitch font. By default this will be set to "Courier New", however some systems may have set it to non-fixed pitch font (using IE options). You can override that by setting the ALog.FixedFont.Name in your application. Once the font is set to a fixed pitch, any print statement in this mode will generate the same spacing for every character.

The log control font can be set as follows:

Log.FixedFont.Name = "Courier New"

The log control font size can be set as follows:

Log.FixedFont.Size= 11

How do I change the order of controls on a form? - Published on 6/16/2008

6/16/2008

The form controls are drawn according to the order of the Form.Controls where 0 is drawn first and 1 is on top of 0, etc. This is sometimes reffered to as ZOrder of controls.

At design-time, you can change the order of controls at design time using the Tab Order command (Edit, Arrange, Tab Order) or by dragging the control in the Controls drop down list at the form editor.

At run-time, you can use the following code to change the ZOrder using the following code:

img1.ZOrder(aWindowZOrderTop)

will draw the img1 control on top of all controls. If you want img1 on top of img3, do the following:

img3.ZOrder(aWindowZOrderTop)
img1.ZOrder(aWindowZOrderTop)

How to change the default printer that ATEasy uses for printing - Published on 5/29/2008

5/29/2008

The following example shows how to change the default printer used by ATEasy when printing using ALog.PrintLog method or internal functions such as LogPrint, FilePrint. The example prints the ALog control (log1) to a network printer:

Procedure btnPrint.OnClick(): Void Public Compile ! Occurs
! when the mouse button is pressed and released upon the object.
    sDefaultPrinter: String
    sPrinter: String
    ob: Object
{
    ! Example for Log Printing with printer different than default

    ! Use the following to print while prompting the user to select printer
    !log1.ExecWB(alogOleCmdIdPrint, alogOleCmdExecOptPromptUser)

    ! Use the following code to change the default printer
    ! (that ATEasy uses when printing) programmatically
    ! print to sPrinter to (may be different than current default)
    sPrinter="\\\\geoserver\\Dell Laser Printer 5100cn PCL6"
    ! Get current default printer
    ob=CreateObject("WScript.Shell")
    sDefaultPrinter=ob.RegRead("HKCU\\Software\\Microsoft\\Windows NT\\"
    "CurrentVersion\\Windows\\Device")
    sDefaultPrinter=Left(sDefaultPrinter, Pos(",", sDefaultPrinter))
    ! Set default printer
    ob=CreateObject("WScript.Network")
    ob.SetDefaultPrinter(sPrinter)
    ! Print
    log1.PrintLog()
    ! Restore default printer
    ob.SetDefaultPrinter(sDefaultPrinter)
    ob=Nothing
}

How to obtain ATEasy Single License from Geotest - Published on 4/22/2008

4/22/2008

ATEasy single license (GT800-SL) can be setup from the ATEasy License Setup dialog box. This dialog is displayed either when starting ATEasy with no license or trial license expired or from the About ATEasy menu item under the Help menu.

If you do not have a license, you can activate a 30-day trial version of the ATEasy software. The trial license contains full ATEasy functionality for 30 days. You are allowed one 30-day trial period on the computer on which you install ATEasy.

Follow these steps to setup an ATEasy Single license:

Install ATEasy using the ATEasy Setup program.

Start ATEasy.

Open the ATEasy License Setup dialog box.

Select Install Single License from the License Type list. An ATEasy Computer ID is displayed in the bottom field. The ATEasy Computer ID is used to identify the machine where the license is installed. With the ATEasy Computer ID and the ATEasy Serial Number (located on the outside of the CD case or on the license key), create a new incident using your M@gic (www.geotestinc.com/magic) user account to obtain a license string or file. You will need to paste both Serial Number and computer ID to the incident. You can start using ATEasy by activating the trial version until you receive the license string or file.

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

Select Install Single License from the License Type list.

Type or paste in the ATEasy License String or select the license File. Click OK.

Creating Dynamic Forms Using ATEasy - Published on 12/14/2007

12/14/2007

ATEasy supports creating dynamic forms. Usually the form contents: Controls and menus is created at design time using the ATEasy form editor. Dynamic forms are forms that their content is created at run time. While it possible to create the form with all the possible controls that you expecting to use at design time and then use the control Visible property to show or hide control and Move method to position them, sometimes you may want to create the controls at run-time based on the form logic.

To create a dynamic form you create a form at design time with the fixed controls on it. At run time you call the InsertControl, AForm class method to create and add additional controls:

btnClicked=InsertControl("btnClicked", "AButton", Form.Width/2-80, Form.Height/2-14, 160, 28)

Once the control is created you can link the control events with an event handler procedure (btnClicked.OnClick) using the AddHandler statement as shown here:

AddHandler btnClicked.OnClick, btnClickedOnClick

Call the RemoveHandler statement and the RemoveControl method to and release the handler and delete the control.

For more information on dynamic forms see the Dynamic Form task in the Forms.prg example.

PXI chassis configuration is lost every time the system is powered up. - Published on 12/13/2007

12/13/2007

Problem: Every time my test system boots up, the Geotest PXI chassis configuration that is stored in the PXISYS.ini file gets replaced with an empty file with no configuration data. This forces us to create a new PXISYS.ini file with the correct configuration data each time the system is re-booted.

Solution:
This problem is caused by National Instruments Measurement and Automation Explorer overwritting the Geotest slot description file upon rebooting. If you have NI Measurement and Automation Explorer (NI-MAX) installed, and it is version 4.0 or later, then your configuration file is being overwritten by NI-MAX and NI-VISA . To correct this problem you need perfom one of the following procedures:

1. Download and install HW v3.0 or above. Many of Geotest drivers and products release after August 2008 contains the new HW. The new HW perform the registry fix (described in 2 below) automatically .

2. Modify the Windows registry by applying a registry patch to disable NI-VISA from doing this. The process is as follows:

Create a text file called "DisableBootPxiSysGeneration.reg" and copy/paste the following text to the file:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWARENational InstrumentsNI-PXIRM]
"DisableBootPxiSysGeneration"=dword:00000001
Save the file (in text format).
Double click the file to apply the registry change.
Use PXI/PCI Explorer to verify or assign instruments to the appropriate chassis slot.
Cycle power and verify that the chassis configuration and instrument slots are preserved.

ATEasy v6.0 Service Pack 1 (build 134) - list of changes - Published on 7/20/2007

7/20/2007

ATEasy 6 build 134 contains all fixes and changes since version 6 (build 132).

The following list the changes that were made:

Enhanced support for .NET and new support for .NET namespace

Enhanced support for WinSocket interface interface re-openeing when InterfaceInfo changes, support for terminators

Project new option AutoIncrementFileVersion

LoadOnAccess new option for DLL

AdoDB example - new task that show how to use System.Data for databases using .NET

DotNet example - new task showing how to send email using System.Net.Mail using .NET

Enhanced License Server support with automated setup as service and a way to set the server from the client

New drivers for Signametrix SM2060/55, SMX4030/32, Navatek NT6000, GX5733, GX5641, GX5642, GX2002, GX6377, GX6384, GxChassis, Gx7xxxA smart chassis), Keithley Instruments 2000/1/2/10 DMMs, Keithley Instruments PXI (DAQ and DIO) boards, Sorensen DCS and DLM600 power supplies

New command line options for the setup:

          /s

                  Silent mode

            /SetupType"[Typical, Full, LicenseServer]"

                  Specify one of the setup type, i.e Typical, Full,

                  LicenseServer

                  Default=Typical

                  This command only apply to clean installation

            /TargetDir"Path"

                  Specify the target directory for the installation

                  Default="C:\Program File\ATEasy"

                  This command only apply to clean installation

            /Uninst

                  Uninstall ATEasy

GetLogString - new constant aLogStringAppend to enumALogStringType to return the current append statements string

Enahance support for WinSocket interface (OnInterface, AutoAccept)

New Units in the test property page

Allow passing of Form procedures to DLL/callbacks

Readonly control properties were change to read/write (for example BorderStyle, Sorted, Style, etc)

AUsers.ShowLogInDialog() returns a user token and AUsers.Login() accept a token

CreateObject internal function support for remote host (DCOM) and free treading model

Tolerance test type Plus and Minus values if left empty allow open end

New code completion support for .NET overloaded methods and constructors

Bug fixes

How to configure NI-MAX version 4.1 and above to recognize a Geotest chassis. - Published on 5/3/2007

5/3/2007

Solution:

Note: HW v3.0 and above automated the process described below. You can configure the chassis from the HW PXI/PCI Explorer applet that can be found the Windows Control Panel using the Scan for New Devices and clicking on the Save button.

Download and install the GxChassis package, found in the download section of the Geotest website. Once this package is installed, all the chassis INI files can be found at the following path: C:Program Files\Geotest\GxChassis\INI Files\.

In NI Measurement & Automation Explorer (NI-MAX), right click on "PXI System" and select "Show PXI Buses". Typically, multiple busses will be shown, and the chassis may be associated with any one of these buses (depending on chassis type).

Starting from the first bus listed, right click and select "Identify as a PXI Chassis". Then choose "other chassis" and select the Geotest .INI file that corresponds to your chassis.

In case of an error message ("This chassis has been identified but is not described in the pxisys.ini for this system") right click on "PXI System" and select "Delete All Identifications".

Repeat steps 1 through 3 listed above, using the next bus in sequence, until NI-MAX properly identifies the correct Geotest chassis.

Right click on "PXI System" again, and deselect (uncheck) "Show PXI Buses".

You will now be able to view and configure your chassis and its resources, using NI Measurement & Automation Explorer (NI-MAX) 4.1+.

What is the accuracy of the Delay() function? Is background processing occurs while Delay() is called? - Published on 3/13/2007

3/13/2007

Delay() is accurate to 1msec, however, since the Delay() function allows form events and interrupts to be dispatched, it may not always be accurate to 1msec. You can use the Sleep() function if you would like to completely suspend the thread and get better accuracy , however your form events will not be dispatched and will look frozen until Sleep is returned (if sleep is called in the form thread). The SetThreadPriority() may also be used to improve accuracy. While delay is processing an event is, the delay can only return after the event is executed, so make sure the event processing time is short as possible.

If you still want to process events while you are waiting but want to consume less CPU, use the Tick() function to implement your own delay and allow other processing such as interrupts, form events and other custom processing while doing it. You should call WaitForEvent() function to suspend the thread and consume less CPU while waiting to the next event resulting in a better delay function as in the following example:

lStart=tick()
while tick()-lStart
    ! optional  - do something

    ! suspend to conserve CPU but still allow form events interrupts etc
    WaitForEvent(tick()-lStart)

endwhile

Calculating time diffrerence using DateTime data type - Published on 3/8/2007

3/8/2007

ATEasy's DateTime type values are really a Double data type - the same applies to a DateTime value in a variant (vtDate) type.
The integer part of the double number is the number of days since 12-30-1899. The fractional part is effectively the time-of-day.
The easiest way to convert a date string into our DateTime is to assign the string to a variant and then assign the variant to a DateTime variable, for example:

vr01 = "8/25/2006 17:49"
dt01 = vr01

DateTime values can be compared with the expected meaning. Since they are really Double values, if you subtract them and store the result in a Double, you have the number of days between the two dates. Similarly, adding a Double to a DateTime, adjusts the date and time by that many days plus a fraction of a day.
Here is an example of subtracting two day/time:

vr1:Variant
vr2:Variant

vr1="08/27/06 "
print VarChangeType(vr1, vtDate)
print vr1
vr2="08/28/06 10:48"
print VarChangeType(vr2, vtDate)
print vr2
print vr2-vr1

The example will print:

0
8/27/2006
0
8/28/2006 10:48:00 AM
1.44999999999709 (one day and .449 of 24 hours)

ATEasy is unable to load a DLL error when I start my ATEasy application - Published on 12/15/2006

12/15/2006

ATEasy 6.x and above uses LoadLibraryEx Windows Application Programming Interface (API) function at run time to load the DLLs you described in the ATEasy module (program, system or driver). The function returns a details status which ATEasy displays when it fails. The error will show as "Unable to Load the '%1' DLL file '%2'. Windows API LoadLibraryEx returned error # %3 (0x%4): %5". Prior version of ATEasy returned the error "Unable to load the '%1' DLL file '%2' Error %3 (0x%4): %5".

Here are a list of possible causes and solution to this problem in case the error description (%5) is "The specified DLL or a referenced DLL could not be found" (error #127/0x7F) or "the specified module could not be found" (error #127/0x7F) or "the specified procedure could not be found" (error #126/0x7E):

Check the DLL library file path and make sure the DLL exist. You can check this from ATEasy DLL Properties. The property page display if the file exist or not, if the file exist it will show the exact location where the DLL file name will be used at run-time. If you are using relative (i.e. ..abc.dll) or no path name in the DLL path in ATEasy you need to make sure the DLL will be located in a folder found relative to the EXE file name as displayed in the Project property page. If you are not using a path in the file name (i.e. kernel32.dll) using no You may have several DLLs of the same name make sure the DLL on the disk is the one you think is loaded - Try to temporary change the DLL Library path in ATEasy to a full path name instead of relative path or no path. This procdure is used usally for error # 127 or 0x7F.

The DLL you are using may depends on other DLLs. You can download a tool called DEPENDS.EXE from
http://www.support.microsoft.com/kb/198038 to see what DLLs are used by the DLL you are trying to load. After you download it, run the program and open the DLL you are trying to load from the DEPENDS file menu and it will show a list of DLLs that are used by your DLL. If it's missing it will show it in red the DLL that is missing. This procdure is used usally for error # 126 or 0x7E.

Some DLLs will have initialization code that is called when they are loaded. This code may fail. Follow the DLL manufacturer instruction for setup and preparation before using it or contact the manufacturer for support.

How can i disable the popup menu of the ALog control? - Published on 12/11/2006

12/11/2006

The ALog.ShowContextMenuItem method can be used to hide individual items of the contecxt menu. For example:

log1.ShowContextMenuItem(alogContextMenuItemClear, False)

would hide the Clear from the context menu.

To remove the context menu all together add the following to the Form.OnLoad event:

log1.ShowContextMenuItem(-1, False)

How to use Microsoft Excel to calculate a statistical/mathematical/financial function from ATEasy - Published on 12/7/2006

12/7/2006

The example creates a hidden Excel workbook, fill the data and calculate TINV value and return it to ATEasy.

TINV Excel function used in this example returns the t-value of the Student's t-distribution as a function of the probability and the degrees of freedom.

You can modify the example to calculate and to use any excel mathematical/statistical/financial formula.

ob: Object

ob=CreateObject("Excel.Application")
if ob=Nothing
    MsgBox("Unable to Create Excel.Application. Check if MS Excel is intsalled properly. Aborting...")
    abort
endif
ob.Caption="ATEasy Excel Function Call Using COM"
ob.Visible=TRUE     ! show/activate execl main window

ob.Workbooks.Add()  ! add workbook

ob.Cells.Item(1, 1).Value = 0.054644927
ob.Cells.Item(2, 1).Value = 60.0
ob.Cells.Item(1, 2).Value = "=TINV(A1, A2)"

print ob.Cells.Item(1, 2).Value

ob.Workbooks.Item(1).Close(FALSE)    ! close workbook do not save changes
ob.Quit()
ob=Nothing

Can an ATEasy executable (EXE) handle command line parameters? - Published on 7/21/2006

7/21/2006

Use the App.CommandLine to retrieive these parameters. The on-line help explains how to use the CommandLine property of the AApp class.

For example if you call your exe:

abc.exe a.log

The App.CommandLine will be equal to "a.log" and in you code you can use it:

SaveLog(App.CommandLine)

How can I display a PDF file from ATEasy application using WinExec? - Published on 7/21/2006

7/21/2006

Use WinExec() internal function to open a window with a the PDF document. For example

iStatus=WinExec("\"\\\\MyServerName\\SharedFolder\\Program Files\\" "ATEasy\\Corporate\\Mercuri\\Help\\MERCURI HELP.pdf\"")

Note also that the file name is surrounded with double quotes since the file name may contain space which. A space will cause ATEasy the think the first part (up to the space) is the exe and the second is the command line parameters, so to avoid this we use the quotes .

WinExec will noot generate exception so there is no need for try statement just check as the help says that the returned status or handle is greater than 32.

How do I modify the test log results numbers format to not display numbers in scientific format? - Published on 7/21/2006

7/21/2006

There are several ways to change the formatting of the test results in the log:

1. Use the FormtLogString()to internal functions change the table columns and their contents

2. In OnEndTest event call GetLogString(), modify the string and call SetLogString().

The FormatLogString() automatically switches to Scientific format (i.e. 1.2E+07) if the number cannot be displayed. You can override this by changing the test result:

TestResult=Round(TestResult, -3) ! Will truncate and leave only 3 digits after the decimal point.

The second method is a bit more flexible and it gives you full control over the way the TestResult number is displayed in the log string and than send it back to ATEasy. Once you identify using string manipulation functions the position of the test result in the log string, use the Format() function to convert the number to a string the way you use it and than replace the test result string. Make sure the code you'll put will work with both HTML and Text test logs.

ATEasy v6.0 Detailed List of Changes - Published on 7/21/2006

7/21/2006

Development Environment

Fresh new look for the development environment includes auto hide docking windows, gradient and color customization for menus and toolbars.

Multiple level programs in your project allow you to organize your projects test programs under user defined folders and divide them to categories.

Create folders in your projects to store baggage files of your projects such as documentation, dlls, software components and more. You can open/edit/print these files directly from ATEasy (using Windows shell verbs).

New program Parameters property page allow you to create and define parameters at design time for AProgram of type Numeric, String and enumerated type. Document shortcuts have description and program shortcut have a way to override and change the program UUT name set in the Program.

Procedure property page: new Compile checkbox, to force a procedure to compile even if not referenced.

Run-Time

New class AVirtualKeyboard allow you to control and display the Virtual keyboard on the screen. The virtual keyboard enables touch pane; support for control that require text input using a keyboard that is displayed on the screen and designed for touch panel user interface.

EnableTouchScreen new internal function to configure and enable automatic support touch panel to your application including support for scrollbar sizing, font changes etc.

AForm.AutoScale - new property enables auto sizing and scaling of the form by setting the AForm.Font.

AProgram, ASystem, ADriver new property Type and new eneum enumAAppItemType.

AProgram, ASystem, ADriver new property Parent to return the parent folder.

AProgram.Parameters new property, ADriver.Parameters also extended to support write at run-time.

ADriver.MiscFolder, AProgram.MiscFolder and ASystem.MiscFolder new property used to store the application files.

ADriver.Tag, AProgram.Tag and ASystem.Tag new property used to store user defined string to the module files.

New classes AAppFolder and AAppShortcut used for module based user defined folders and baggage files.

New statement Append statement - allows you to append text to be appended to the log after the test results is printed.

Support for dynamically creating of menus AMenu.InsertMenu new method to dynamically insert a menu, AMenu.Move new method to move a menu item, AMenu.RemoveMenu. This is similar to 5.0 dynamically creating of form controls using AForm.InsertControl and AForm. RemoveControl.

AButton - multi-line and word wrap text support.

New File and directory functions FileGetStatus, FileCopy, DirectoryCreate, DirectoryRename, DirectoryDelete new internal functions, FileFind now returns optional structure structFileStatus.

ParseDateTime and FormatDateTime new internal functions for date time string manipulation.

The statement AddHandler and RemoveHandler now support .NET, COM events, Control and Menu events (any object type that generate events).

ATEasy now support importing of the new .NET 2.0 framework and Lab View 8.0 (up from .NET 1.1 and LabView 7.1).

AButton, ARadioButton, ACheckBox new support for multiple lines text and word wrap for the caption property.

AStatusBarPane new support for Progress bar pane - new properties ProgressMin/Max and Value, asbrpStyleProgressBar new member of enumStatusBarPaneStyle.

enumGetDir has new constants aGetDirApp, aGetDirAppExe, also the aGetDirATEasy now always return the ATEasy folder (and not the EXE when running outside of the IDE).

New internal function, GetCallbackThunkAddress, the function return the ATEasy procedure thunk so it can be called from an external DLL.

ControlsCount and Controls properties are now available only to controls that are containers: ATab, APanel and AGroupbBox (also AForm).

Test Executive

Full support for touch panel user interface:

Modal and Modeless user interface. Modal user interface used mainly for touch panel to replace menus and toolbars with buttons forms to navigate and control the test executive.
The user can define forms designed for touch panel user interface that includes test executive commands or user defined commands to control the test executive"s capabilities via the touch panel in Modal mode.
User groups based user interface, allow you to customize the user interface for production users, test engineers etc. Each group can have its own privileges and user interface (forms, menu, toolbars and options).
Customization of forms, menus, toolbar options and more per users group can be set by the administrator with no programming.

Automatic management and backup, save, delete and naming of log files.

Compatibility issues

ATEasy 6.0 is fully backward compatible with prior versions of ATEasy (3.0-5.0) . Binary files saved in version 6.0 can be loaded using version 5.0 build 94a (but not always with versions prior to 94a). ATEasy 6 can also run EXE created with prior versions.

See Q200075 for a summary and less detailed list of features.

ATEasy v6.0 Main New Features Summary - Published on 7/20/2006

7/20/2006

Run time and Development:

Fresh new look for the development environment includes auto hide docking windows, gradient and color customization for menus and toolbars.

New support for applications that have a large number of programs, we now provide an easy way to organize these programs. Essentially, the user can define folders under the Programs folders and organize its test program in a tree structure according to their functionality or UUT variants.

Create folders within the project modules that can contain "baggage" information. Things like UUT documentation, fixture wiring, TRDs', software components, etc. These can be opened directly from ATEasy regardless of their application type - i.e. Word, Excel. Etc. The advantage to this is that now, all of the specific files needed for an application can be located in one location, facilitating source control, archiving and backup.

New Full feature, virtual on-screen virtual keyboard. This allows full keyboard support for applications that are designed for touch panel. This feature also includes support for an increased scrollbar size for all windows controls, multi line push buttons and automatic sizing/scaling of a form when it font is changed.

The Internal library contains several new functions and class including support for extended directory and file manipulation, date time parsing, dynamic menu and control creation and extended support for .NET/ActiveX events.

New support for .NET 2.0, LabView 8.0, ActiveX/COM event handlers, DLL callback.

Tested under Windows VISTA (b2)

Test Executive Features:

Full support of test executive features using a touch panel user interface:

The user can define forms designed for touch panel user interface that includes test executive commands or user defined commands to control the test executive's capabilities via the touch panel.

Virtual keyboard will automatically popup when the current control requires text entry.

Customize the user interface for different classes of users - i.e. operators, technicians, test engineers, etc. Each group can have its own privileges and user interface (forms, menu, toolbars and options).

Automatic management of log files - i.e. when to backup, when to delete, when to save, how to name log files, etc. Previously, the user had to code these capabilities as part of the logging process.

See Q200076 for additional and more detailed list of features.

Getting Return Code from External Process Started with WinExec - Published on 4/24/2006

4/24/2006

Solution:

WinExec() does not operate synchronously and will not wait until the called process is closed before returning to the calling application. Instead, it will return immediately and return a process handle indicating if the process was successfully created or not. To access the code returned by the application launched with WinExec(), you will need to use code similar to the following:

hProcess=WinExec("...")
if hProcess<21
! error creating the process
return
endif
WaitForSingleObject(hProcess)
GetExitCodeProcess(hProcess, dwCode)

The GetExitCodeProcess function retrieves the termination status of the specified process, and is defined in kerner32.dll. You will need to define it under a kernel32.dll entry within your module libraries. In ATEasy this function will be defined as:

GetExitCodeProcess(hProcess: Val AHandle, pdwCode : VAR DWord) : BOOL

A description of the function is provided below:

GetExitCodeProcess:

BOOL GetExitCodeProcess
(
HANDLE hProcess, // handle to the process
LPDWORD lpExitCode // termination status
);

Parameters:

hProcess [in] - Handle to the process. For Windows NT/2000/XP, the handle must have PROCESS_QUERY_INFORMATION access. For more information, see Process Security and Access Rights.

lpExitCode [out] - Pointer to a variable to receive the process termination status.

Return Values:
If the function succeeds, the return value is nonzero. If the function fails, the return value is zero. To get extended error information, call GetLastError.

Remarks:
If the specified process has not terminated, the termination status returned is STILL_ACTIVE. If the process has terminated, the termination status returned may be one of the following:

The exit value specified in the ExitProcess or TerminateProcess function.

The return value from the main or WinMain function of the process.

The exception value for an unhandled exception that caused the process to terminate.

How do I send email from ATEasy? - Published on 4/18/2006

4/18/2006

Solution:

You can do it by using the Microsoft CDO ActiveX/COM library :

1. Insert the CDO library to your module

2. Define the following variables:

cdocfg: CDO.Configuration
msg: CDO.Message
sMyHTMLMessage: String ! HTML message

3. The following code is an example of how to use the CDO library to send email (may require some changes for error handling message text):

! create configuration
cdocfg=CreateObject("CDO.Configuration")
cdocfg.Fields.Item(cdoSMTPConnectionTimeout).Value=400
cdocfg.Fields.Item(cdoSMTPServer).Value="10.10.1.1" ! server address could be also something like "smtp.primenet.com"
cdocfg.Fields.Item(cdoSendUsingMethod).Value=cdoSendUsingPort
cdocfg.Fields.Update()

! create a message
msg=CreateObject("CDO.Message")
msg.Configuration=cdocfg
msg.From="rony@geotestinc.com"
msg.Subject="Hello world!"
msg.HTMLBody=sMyHTMLMessage
msg.To="\"Ron Y\""

! send the message
Try
msg.Send()
Catch Else
! error message
EndTry

!clean up
mgs=Nothing
cdocfg=Nothing

How do I shut down or restart windows from my ATEasy application? - Published on 3/21/2006

3/21/2006

Solution:

To shut down or restart windows, You need to call a Windows API that is found in USER32.dll. The function is described here:

ExitWindowsEx(uFlags: Val DWord, dwReason: VAL DWord): Bool

Parameters
uFlags - [in] Shutdown type. This parameter must include one of the following values:

EWX_LOGOFF - 0 - Shuts down all processes running in the logon session of the process that called the ExitWindowsEx function. Then it logs the user off. This flag can be used only by processes running in an interactive user's logon session.

EWX_POWEROFF - 0x00000008 - Shuts down the system and turns off the power. The system must support the power-off feature. The calling process must have the SE_SHUTDOWN_NAME privilege. For more information, see the following Remarks section.

EWX_REBOOT - 0x00000002 -  Shuts down the system and then restarts the system. The calling process must have the SE_SHUTDOWN_NAME privilege. For more information, see the following Remarks section.

EWX_SHUTDOWN - 0x00000001 - Shuts down the system to a point at which it is safe to turn off the power. All file buffers have been flushed to disk, and all running processes have stopped. The calling process must have the SE_SHUTDOWN_NAME privilege. For more information, see the following Remarks section. Specifying this flag will not turn off the power even if the system supports the power-off feature. You must specify EWX_POWEROFF to do this.
Windows XP SP1:  If the system supports the power-off feature, specifying this flag turns off the power.

This parameter can optionally include one of the following values:

EWX_FORCE - 0x00000004 -  Windows 2000/NT:  Forces processes to terminate. When this flag is set, the system does not send the WM_QUERYENDSESSION and WM_ENDSESSION messages. This can cause the applications to lose data. Therefore, you should only use this flag in an emergency. Starting with Windows XP, these messages will always be sent.

EWX_FORCEIFHUNG - 0x00000010 - Forces processes to terminate if they do not respond to the WM_QUERYENDSESSION or WM_ENDSESSION message within the timeout interval. For more information, see the Remarks. Windows NT and Windows Me/98/95:  This value is not supported.

dwReason  - [in] Reason for initiating the shutdown. This parameter must be one of the system shutdown reason codes. If this parameter is zero, the SHTDN_REASON_FLAG_PLANNED reason code will not be set and therefore the default action is an undefined shutdown that is logged as "No title for this reason could be found". By default, it is also an unplanned shutdown. Depending on how the system is configured, an unplanned shutdown triggers the creation of a file that contains the system state information, which can delay shutdown. Therefore, do not use zero for this parameter. Windows 2000/NT and Windows Me/98/95:  This parameter is ignored.

Return Values
If the function succeeds, the return value is nonzero. Because the function executes asynchronously, a nonzero return value indicates that the shutdown has been initiated. It does not indicate whether the shutdown will succeed. It is possible that the system, the user, or another application will abort the shutdown.

See Also

See microsoft.com for more information regarding this function.

See the ATEasy Getting Started manual for more information of how to define an call an external DLL function.

List of issues/changes for ATEasy v4.0 build 94 and ATEasy v5.0 build 104 - Published on 12/5/2005

12/5/2005

Here is the list of changes/issues resolved in build 104a/94a. Changes in [ATEasy5] are specific to v5.0 (104a), changes without [ATEasy5] applies to both build 94a and 104a since 92a and 102a was released.

IDE (development environment)

Property page of Precise,Tolerance, or Min/Max test types displays "Out of range" warning when enter a hex value between 0x80000000 - 0xFFFFFFFF.

'Insert Driver' dialog does not display correctly, controls sometime overlap each other

Viewing/Saving ATEasy program in text mode (.pgt) results in REFX values printed/displayed as decimal rather than hex.

ATEasy sometimes crashed when it tries to load/import Function Panel file (.fp) of Version 3.0

Unable to select HiMetric scale mode from AForm's Scale property page.

Auto Type Information tooltips does not display the description of the attached procedure when hovering the mouse over command item.

Go To Definitions Of 'xxx' does not show the command when "if" is preceding the command

DLL procedures are checked twice when using Check All

New option to clear the Build Log before build

Function Panel files (.fp) conversion/import was improved

Compiler error generate an internal error for struct variable.enumfield.constant

Code Completion should not displays enum constants when entering '.' character after variable of type enum

Command is not properly updated when insert/delete its attached procedure's parameter(s)

'Goto Defnition Of' does not work for Struct types in the Code View

Call Completion listbox window's width is not calculated correctly

Problem undo/redo AForm's menu items

Unable to build stand-alone EXE in Windows 95/98/Me.

A breakpoint at the last line of a test only works if it's right after the last line of code.

Find dialog hang when searching for non-exist symbol in active view only and current active view is the local varariables frame.

Escape sequence string support for AComboBox and AListBox controls.

App.ModulePath property has been changed to return the ATEasy folder instead of the application EXE file path when running from the IDE.

Module protection did not protect the documents from viewing / changing in all cases.

Enhanced Font property page of form and controls to include font scripts (e.g. Western, Hebrew etc...).

ATEasy will detect if a wrong version/build of the ATERT.DLL is used.

ATEasy may crashes when loading invalid or corrupted project file

Renaming project file name may crashs ATEasy if File tree view is the current active view of the Workspace window.

Watch window generates 'access violation exception' after entering build-in procedure name (e.g. Sin, Cos, Abs, Round etc...) into the watch list.

Duplicate items in call stack when paused in interrupt handler or Dll call back procedure.

[ATEasy 5] ATEasy crashed when importing IviConfigServer.h header file and ATEasyPreprocessor.h is missing

Run-Time

During Run-Time Error processing, Ignore statement in OnError() cause ATEasy to crash

'Unsupported MSXML2 type' error when inserting Microsoft CML, v5.0 type library

Program's Status property is not reset to NONE before run

ATEasy crashed while running example Excel project

Repeated Ignore of "Unable to open interface for driver" errors which occurred in IOTable caused ATEasy to crash

Redim preserve of array of struct containing field of type Object crash ATEasy

Unable to print enum's constants (i.e. PRINT enumATestStatus.PASS)

Text file (.drt, .pgt) loading is terminated when encounter an unclosed string, e.g. "xyz, as supplied parameter in command

Changing Form.Backcolor does not update the background when AutoRedraw is TRUE

Form.PopupMenu method does not work if the popup menu does not belong to any menubar or the menubar is not visible

Setting the Form.AutoRedraw to True for MDI form will corrupt the display of its client area

Unable to close or save changes in Users dialog after selecting 'Clear User'

Compiler error when references non-public nested menu , e.g. Menu1.Popup1.Item1, while inside a form event or procedure

Omitting the error number from the catch module statements, e.g. CATCH MODULE DMM, generate "Expected end-of-line" compiler error

Array of procedure does not get initialized with its initial value when running in EXE mode

WSReceive() erroneously return 0 if the remote socket was closed instead of -1 as documented in the Help

Form's mouse cursor change does not take effect until the mouse is moved

Unable to load ActiveX library with version >= 10.0

Problem accessing AForm's procedures and variables using array of form

New optional EndEvents keyword for Exit statement

Val(sHexString, 16) function's behavior has been modified, it will now convert sHexString to an unsigned integer (i.e. 0xFFFF is 65,535 instead of -1)

'Unsupported Types' error when loading ActiveX library containing 64-bit integer data type

Generates OnQueryUnload and OnUnload events for MDI child form when its parent MDI form is being destroyed.

ATEasy EXE will detect if a different build is used for ATERT.dll and ATECTL.dll

ATEasy crashed when run TestExec project more than one and m_stRunTime struct is being watched in the Watch view

New aFlagsExit flag was added to enumARuntimeFlags which can be used to indicate whether an Exit EndEvents statement has been executed

Optional EndEvents keyword to be used with Exit statement (i.e. Exit EndEvents)

AProgram's Uut information is not serialized in text mode.

[ATEasy 5] Fixed several bugs related to 'Optimize Short Circuit Boolean Expressions'

[ATEasy 5] Added supports for callback procedures, this feature provides a way for an external instrument driver (i.e., DLL) or Windows API to call ATEasy procedure when a certain event occurs.

[ATEasy 5] Added supports for late binding COM/.NET events using AddHandler and RemoveHandler statements.

Library

AForm's DrawText() does not return the width and height.

AForm/Acontrol's Image property does not return the content if window is not visible or covered

MDI child form's OnQueryUnload and OnUnload events are not generated when its parent MDI form is being destroyed.

Problem Inserting AChart control into design time dialog of Visual C

Using Common Dialog with multiple selection files does not return the selections

APicture.Render() method does not work

AControl. Creating a control from text file (property bag) will use the control name as the caption instead of the Caption/Text stored in the text file

AToolbar with labels displays fixed width buttons instead of variable width buttons base on the button's text

When a modeless form is unloaded, its parent form was not activated

ALabel's appearance always look 3D regardless of the Appearance property setting

Some of ALog's events were never generated.

ALog.Find() method does not work

AForm.DrawText() does not use FillColor as background when FontTransparent is True

AForm.DrawText() method with aformDrawTextVCenter draw mode does not center the text vertically (text is a bit down)

AForm.Circle() method uses the ForeColor as default color instead of the FillColor

AForm.Circle() method ignored lArcStart, lArcEnd

Calling ComSend to send a BString with # of bytes equals 1 fails

Calling ComOpen after ComClose with no delay between cause ComOpen to fail

ComSetup - XOn/Xoff Setup sometime does not work

Form's General property page should not restrict ClientWidth and ClientHeight to 102 and 27 respectively

ATEasy crashed when the focus was changed while inside one of Form's KeyPreview events.

The run-time will detect different version of ActiveX libraries when running EXE.

AListBox control's OnClick() and OnMouseDown() events are not generated for left mouse button

Setting AForm's menu bar dynamically at run-time (e.g. Form.MenuBar=menu2) causes ATEasy to crash on the next run or exit.

MsgBox and InputBox always enable its owner window when close regardless of whether the owner was previously disabled.

[ATEasy 5] Enhanced ACommonDialog control to support directory selection using acdlgOpenOptionsDirectory option.

[ATEasy 5] AListBox control with CheckBox style and contains no item (empty) may cause ATEasy to crash

[ATEasy 5] ATab control's OnPageSelChange() event does not set 'PageNew' parameter correctly

[ATEasy 5] Added supports for .NET assemblies.

[ATEasy 5] Added supports for dynamicly created controls using AForm's InsertControl and RemoveControl methods.

TestExec

When CLEAR LOG is pressed after START, the font and log alignments are not as they should

OnReset called twice after we call the reset statement

Fixed problem related to RunProgram command.

[ATEasy 5] Replaced all occurences of 'Exit' statement with 'Exit EndEvents'

Drivers

SM204X ATEasy Driver Diode Range off by 1

All ATEasy DIO drivers DioGetDriverSummary generate RT error

TE5200 ATEasy driver problem

New and updated DLLs for various Geotest drivers

Setup

When installing a new ATEasy version/build, personalized settings disappear.

Setting form variables and calling form procedures from the creator of the form before the form is displayed. - Published on 9/1/2005

9/1/2005

Solution:

For a modeless form (Load frmVariable, FALSE):

1. Use frmVariable.variableName where the variableName is a form’s public variable.

2. Use a form procedure to set or get the variable’s value. For example:

frmVariable.SetVariableValue(value)
frmVariable.GetVariableValue():type. Note: procedure must be public.

For a modal form (Load frm.Variable, TRUE):

The caller cannot set the variable or call a procedure because the control does not return to the Load’s callee until the form is destroyed.

1. You can use a Module (program, system or driver) Procedure or a variable to retrieve a value and use it in the OnLoad Form Event.

2. You can create the form as modeless (as shown above), set the form’s variables, call the form's procedure and use the Load statement again with TRUE as the mode parameter. See the example below:

Load frmVariable, FALSE
frmVariable.variableName=value
frmVariable.procName()
Load frmVariable, TRUE

Note: This procedure can only be implemented in ATEasy 4.0 (build 94) or ATEasy 5.0 (build 102b and above). You can initialize the form to be hidden and then show it just before the second Load statement (frmVariable.Visible=True). See the example below:

Load frmVariable, FALSE
frmVariable.variableName=value
frmVariable.Visible=True
Load frmVariable, TRUE

This added line (line 3) will prevent the user from accessing the form control before the form is ready.

Acquiring data into a file/database without interrupting the current acquisition process. - Published on 8/26/2005

8/26/2005

Problem:

I am trying to get more functionality from my IOTech DaqLab 2000. I have data acquisition on 32 channels that run at about 1Hz each. This data logging is uninterrupted for days at a time. I would like to be able to look at old data without interrupting the current acquisition. I would prefer one continuous file or a database like Access or Oracle that could be viewed and manipulated while the data is logging without causing any data loss.

Solution:

In ATEasy, you can write a small program that can gather a DAQ’s data and insert it into a text, binary, excel, or database file. You can use IOTech’s DLL functions to gather data and the ATEasy internal library for everything else. The ATEasy Getting Started Manual, which can be downloaded from the Geotest web site, discusses DLL function implementation.

There are several ways to write to a database file. In the ATEasy Getting Started Manual, an example is provided to show you how to use the Microsoft Active Data Object COM Component (see also the AdoDB.prj example). This library supports a long list of databases that includes Microsoft Access (.mdb files), SQL Server and Oracle.

You can also read and write to a database using an ODBC driver or a DLL.

ATEasy 5.0 Main New Features Summary - Published on 11/9/2004

11/9/2004

Solution:

ATEasy 5.0 Main New Features Summary

Enhanced Test Executive with:

Touch Screen user interface; allows operation of test set via touch-screens with a special customized toolbars.
Users and Groups based privileges and customization; the administrator can customize the test executive per user groups without writing code. Each option and each menu command can be hidden or disabled. The toolbar buttons can be also customized per group and its buttons can be hidden or arranged. User can use the administrator set of customization and customize it further if the administrator allowed it.
Complete customization of toolbars menu with or without using users and groups feature.
Many new options including: selection of debugging level for the operator – allows the test engineer to disable selection and running of individual tests or tasks, log failures only.
New commands for better controls of the test executive options and behavior. New test conditions, option to disable menus while program is running, Windows XP style menus and much more.
On-line Help for the test executive to provide detail on how to operate and customize the test executive.

New Fault Library:

Fault Library provides a powerful troubleshooting tool for electronic circuits.
A Fault Editor allows program developers to define Fault Conditions to be analyzed by ATEasy during runtime.
When activated during runtime, the operator can be prompted to replace assemblies or components based on the actual failures (i.e. “Replace U1 and Re-Test”).

Open Architecture Improvements:

Built in support for IVI drivers. ATEasy now includes ATEasy drivers for all the IVI driver classes currently available (DC power supply, Digital multimeter, Function generator & Arb, Oscilloscope, Power meter, RF signal generator, Spectrum analyzer and Switch. ATEasy also support of importing non-class compliant IVI drivers using a new IVI Wizard and support both IVI driver formats: IVI-C and IVI-COM
Support for .NET components .Net. assemblies or assemblies components can be imported to ATEasy and used similar to the way you would use them from Visual Studio .NET languages. This capability provides a truly open architecture by embracing new technologies and is similar to the way COM and DLL extend ATEasy capabilities.
ATEasy can now import functions and type declarations directly from C/C++ header file (.h). This reduces the development cycle and eliminates any errors when calling external DLL library.
LabView VIs – ATEasy users can now use existing LabView code in their test applications. All the user needs to do is selects the VI (Virtual Instrument or LLB (library) file and the ATEasy Insert LabView wizard generates an ATEasy procedure to call the VI.
Lab Windows Function Panels Drivers (.fp) import was improved and generates more accurately ATEasy driver from LabWindows drivers – this feature allows users to use these drivers without the need to re-write them.
ATEasy now includes a Summation Import Wizard that allows import of Summation TestCase programs into ATEasy.

Enhanced Forms Features:

Two new controls were added: Tab Control (ATab) and Panel Control (APanel)
Current controls where enhanced. For example, the AListBox now support a list of checkboxes. Additionally, Controls now have the XP theme look and the AMenu support the new .NET style menus..
ATEasy forms now support automatic form and controls sizing. Similar to .NET controls, each control can be anchored and aligned. This allows users to implement sizable forms with minimal coding to size the controls when the form is sized.

Programming Language Enhancements:

New support for COM events handlers using the AddHandler/RemoveHandler statements. This allows users to interface with COM applications that generate events.
ATEasy now supports callback procedures. ATEasy procedures can be called by an external DLL directly. This feature provides a way for an external instrument driver (i.e. DLL) to call ATEasy procedure when a certain event occurs. Windows API also uses callbacks.
Internal library have new bit manipulation, help, log functions and more. Also new classes properties and methods extend the internal library further.
Support for 64 bit integers.

Other Improvements and Enhancements:

The Integrated Development Environment (IDE) has new dialogs such as Save Modified, new popup Conditions menu and new menu commands. Additionally, many editing features were added or improved.
Many new additional ATEasy drivers.
New examples

And much, much more…

How to Customize log string for the program header - Published on 6/9/2004

6/9/2004

Solution:

ATEasy generates the following test log string when a program is start to run. The output is generated after the Program Init events are called as shown here:

Program  : Program5
UUT  :
Serial #  :
Start time  : 6/9/2004 9:21:46 AM

--------------------------------------------------------------------------------

To customize the test log program start string you need to add some code of the Program Events OnInit() and OnInitTask(). If the change is for all programs in the project you can place ad the same code in the System Events OnInitProgram() and OnInitTask().

The code in OnInit/OnInitProgram should load the your form with the special serial number / uut information and than set the log off to prevent ataesy from output it log string and than, output your own customized log string.

Program.OnInit() or System.OnInitProgram()
{

! display my serial num form
Load frmMySerialNum

! Take control over log printing for this event!
SetLogOff()

! print to log (two ways

! one way is to modify the ateasy log string
! s=GetLogString()
! modify s using Mid., Pos etc
! print s

! second way is to output a completly new string, (shown here is the default log string)

print ";" \
   ""; \
   ""; \
   ""; \
   ""; \
   ""; \
   ""; \
   ""; \
   ""; \
   "

"
}

The code shown above is for HTML test log you can make your program works for HTML and Text by using the Log.PlainText property:

If Log.PlanText
! print text
else
! print HTML
endif

You can figure out the ATEasy default log string by right clicking on the log window and selecting View Source from the menu.

Finally in OnInitTask we have to enable the log again:

Program.OnInitTask()
{
SetLogOn()
}

Using ADO to Access a Database from ATEasy - Published on 6/3/2004

6/3/2004

Solution:

Note: ATEasy 5.x and above provide a more elaborate example (AdoDb.prj) for accessing database from ATEasy.

The following describes how to access database using ADODB Active Data Objects) ActiveX library:

Add ADO (Active Data Objects) type library to your module libraries (You must have VB or Access installed on your machine).

The following code shows how to open a database for R/W (Declare rs as ADODB.Recordset and sSrc and sCon as String):

rs=CreateObject("ADODB.Recordset")

sSrc="SELECT "+m_sField1+", "+ m_sField2+" FROM "+m_sTableName

sCon="Provider=Microsoft.Jet.OLEDB.4.0;Data Source="+m_sDataBaseFile

rs.Open(sSrc, sCon,,adLockPessimistic)

Notes:

m_sField1 and m_sField2 are database field names
m_sTableName is the database table name that contains m_sField1 and m_sField2
m_sDataBaseFile is the path to the database file.

The following code shows how to read a field in the current record:

rs.Fields.Item(m_sField1).Value

The following code shows how to set a field in the current record, then update the record:

rs.Fields.Item(m_sField1).Value=Value

rs.Update()

The following code shows how to move to the next record:

rs.MoveNext

The following code shows how to close the database connection:

rs.Close()

You can browse on the library object and classes if you need more operations. If you need more help on this select the ADODB library from ATEasy under Libraries and press F1.

ATEasy 4.0 build 92 changes - Published on 4/5/2004

4/5/2004

Solution:

We have release a new build of ATEasy 4.0.

The new release includes several bug fixes that were found since build 90 was released and some new features as shown here:

Run-Time

1.   Form.Refresh method did not invalidate the rectangle and only update the window.
2.   Non-public form procedures and events were accessible outside the form even if they are not public.
3.   Error in Catch block need to be sent to outer Try Block instead of the current one.
4.   Path of CompanyLogo.gif in the test log was changed to absolute from the ATEasy folder. This allows proper display of the log file from any folder.
5.   When running from the IDE OnEnd for drivers sometimes did not get called.
6.   Assignment of Driver type Structure that is alias (typedef) to a driver DLL type structure to a literal in a program fails loading of EXE. Executable returned ‘Unknown Error’ when running EXE.
7.   GPIB IO Table timeout with NI board does not take effect unless with set the timeout in NI max properties.
8.   Setting App.StartProgram before the start program gets called did not had any effect.
9.   Tolerance test display +3/+0 instead of +3/-0 in the test log.
10.  Assign a variant array member which is also an array into another variant generated run-time error #310 : 'Unable to assign a value'.
11.  Using function that return a structure field will crash at run-time.
12.  Hour glass is displayed when the EXE is loaded.
13.  Calling the Abort statement twice will terminate the application.
14.  Calling ExitTest statement from OnInitTest will skip OnEndTest.
15.  Nested modal forms may hang if no messages are available in Windows queue.
16.  After Run/Start, calling Form.TextWidth second time loading same Modal form returns 0 instead of the actual width.
17.  Test.Type property can be set at run-time.
18.  Form.Tag, Control.Tag type was changed from string to variant.
19.  Double precision test type Min/Max/Tolerance Pass/Fail status is evaluated within a 1e-15 tolerance rounded result to avoid floating point errors.
20.  Run-time now supports changing the test type at run-time.
21.  Allow assign of array literal with different dim size but same count.
22.  Assign incompatible data type to initial value of indirect data type VARIANT/DOUBLE/DATETIME/CURRENTCY leaked memory.
23.  When calling abort or reset statements ATEasy print ..."Application abort or reset  by user" instead of "Application abort or reset".
24.  MF42CLOC.DLL causes ATEasy to display ??? in various message boxes and in the Control property pages names.
25.  When calling DLL function stack miss-match is now reported if the function is prototype with wrong number of parameters or wrong CDecl/StdCall DLL function definition.
26.  Passing a string to VAR Any passes the address of the address of the string instead of the address of the string.
27.  Passing NULL to DLL procedure’s parameter of type VAL OBJECT generates 'Internal Run-time Error # 28'.
28.  Passing 'NULL' to DLL procedure's parameter of type [VAR] STRING generates compiler error # 620 'Expected l-value'.
29.  Passing 'Nothing' to DLL procedure's parameter of type [VAL/VAR] ANY no longer working (did not pass NULL).
30.  Compiler Error # 650 "Type 'Object' is undefined" when calling DLL proc which has parameter of type [VAL] OBJECT.
31.  Run-time error #310 'Unable to assign a value' when accessing the returning struct's members from a call using Procedure variable.
32.  s=FuncReturnVariantContainsStringArray()[0] caused GP fault.
33.  Print ProcReturnComplexStruct().m_ArrayOfStruct[0].m_lField1 caused GP fault.
34.  Changing TestStatus (i.e. to FAIL) at OnEndTest() event does not have any affect on UUT Status (GetUUTStatus()).
35.  StringArray2D[0]=ByteArray1D generated a GP fault.
36.  Calling DLL procedure with parameter of type VAR BString generated "Memory Access Violation" run-time error.
37.  Assign DateTime to Variant will result in vtDouble instead of vtDate.
38.  Goto a label within  the same TRY block generates run-time error #330 - 'Catch or EndTry executed without Try'.
39.  Unable to 'Ignore' recoverable error inside a CATCH block.
40.  FileRead() should not allow reading more than the size of the Fixed size string.
41.  Log.Append will not display the image unless an absolute file path is stated.
42.  Assignment of array of bytes to string assignement xcaused internal error -33 line -2
43.  MemoryCopy() does not work between array element (string/byte).
44.  FileEOF() always returns zero, even when end of file is reached.
45.  Changing procedure variable to parameter, setting a constant value, and than changing parameter to var or val causes ATEasy to lock.

IDE (integrated Development Environment)

1.   Variables property page. Changing procedure variable parameter from none, setting a constant value, and changing parameter to var or val causes ATEasy to lock.
2.   Debugger. Aborting the application from the IDE when the form.OnLoad() is in process causes ATEasy Crash upon when Call Stack view is open.
3.   Driver shortcut Interface property page. Unable to populate I/O address IO1 with a range of values in the drivers properties/interface section.
4.   Text file format. Constants variables should display their initial value even if it’s the same as the default value.
5.   Paste Bellow command was enabled for the text editor.
6.   Code completion displays function prototype in a different format than text file format.
7.   Paste a procedures to procedure view with no procedures will crash.
8.   Switching to another user with the same access rights should update menus and views with the new access rights.
9.   After loading ATEasy, pressing TaskIt does not necessarily run the task that is shown by the cursor (as gray, not blue).
10.  Do not allow drag anything to enum unless it has long + const
11.  Globals. Internal Page did not display correct value for CONTROL and FORM variables.
12.  ATEasy crashes when the command line is missing the file name after the option flag (e.g. /b).
13.  Changes in the current user’s access rights (because of log in) was not reflected to the IDE only after the IDE was closed and open again.
14.  Setting the initial value of Optional Variant Val Parameter to 'Nothing' will crash ATEasy upon Save.
15.  Converting a number that start with a ‘.’ (i.e. .234) failed when serializing with text file format and from property pages.
16.  Command parameters font is using the code editor font.
17.  Parsing commands built-in arguments sometimes failed.
18.  Changing public attribute of module variable from the variables property page cleared initial value.
19.  Double click on a Form will not open the form if we have a browser window open with Forms selected and the form selected in the object view in list mode.
20.  ATEasy Crash with ProgramIt after setting the active project.
21.  Description in the property page. Tab setting is not the same as in the description view.  Pressing enter in the description of the property page will insert a new line. Word wrap was also enabled.
22.  Under Windows XP the tree/list view will not show the selection if the window does not have focus.
23.  Comparing two drivers that turned out  to be identical display a very big message box.
24.  The new address when changing the address of a driver from the driver shortcut property page does not always save.
25.  Test Property Page. Changing the test type from Min Max to Tolerance or Precise should reuse the values.
26.  Change the test type  from MIN-MAX to TOLERANCE gets caught in an endless loop
27.  Importing FP that uses the new 5.1 specifications crashes ATEasy.
28.  Missing files when opening Drivers.wsp (GP1008.drv, GP1650.prj and GT1648.prj).
29.  When trying to copy constants from one ATEasy DLL driver to another (replacing all existing duplicates), the program hung up and did not respond to Windows.
30.  Clicking on a menu procedure when the properties window is open will cause the document to be modified.
31.  Sorted List sym view did not refresh correctly after deleting an item.
32.  Occasional crash when running Language and aborting out of multi-threading task.
33.  Monitor Window crashes when Clear with Properties Window open.
34.  Bitmaps displayed in menus and toolbar have transparent look when running on XP.
35.  FileCreate/FileOpen mode enum displayed in decimal instead of hexadecimal.
36.  Watch window's display format "All Hexadecimal" caused Bool var to display Hex instead of True/False.
37.  Watching variant of type VT_UI4, VT_UI2 (reference) crashed ATEasy.
38.  Struct displayed in Watch or CallStack windows will crash ATEasy after Redim the struct's field of type BString array.
39.  Redim array which is currently expanded displayed  in global call stack caused GP fault.
40.  Not all of ATEasy Context Menu update handlers are checking user's rights - for example enabled Edit/Save/View doc for Tester.
41.  Breakpoint after the last line of code disappear after refreshing the code view as result of window close or display of different symbol.
42.  Run-Current-Task, etc. are enabled even though there is no program module for the project Start-Program and there is no System module.
43.  Loading text file with version's time beetween [Dec 31 69 16:00:00] and [Dec 31 69 17:00:00] crashed ATEasy.
44.  Internal run-time error #1 when running EXE which contained a module event with local variables and empty code. (i.e. program's OnEndTask()).
45.  Startup dialog hang if the recent workspaces list contains a workspace file from a disabled (Power Off or removed from network) network's computer. (i.e. //UNIT219-01//ATeasy//Workspace.wsp).
46.  Run-time sometimes stops at breakpoint that is no longer exists.
47.  View in Text Format will display current date and user instead of the original one.
48.  Project’s Start program is now displayed in bold in the workspace window.
49.  Build All will now generate warning if a defined DLL function does not exist in the DLL.
50.  License Server was modified to run as a service. Server-client communication was improved. See ReadMe.txt for more information.
51.  Code Completion will not work for non-project modules.
52.  Text format for ATEasy modules doesn't include Stdcall/CDecl attribute for DLL procs.
53.  Changing 'Untitled' Task/Test's title using property page does not update the test/task's Id to a new id based on its name.
54.  Saving new module file as a text file format saved it in a binary format.
55.  Reloading a driver file since it was modified externally causes the system to be marked as changed.
56.  Edit-Find-Replace dlg FindAll flag cannot be remembered correctly - registry says All (True), but ATEasy does not come back with the All option checked.
57.  Find in current document doesn't search in menu items until a menu item has been selected.
58.  Find-Replace All OldName to NewName can get into very tight loop when there already exist two procedures named OldName and NewName and RenamSym fails on proc OldName because proc NewName already exists.
59.  Opening a driver shortcut property pages and changing the driver file name to an invalid file name and switching to Misc. page crashed ATEasy.
60.  Access violation opening test in Tests view. Test is under nested task.
61.  62Sizing of Members list/Parameters Suggestion for code completion is now remembered between sessions of ATEasy and between subsequent displays.
62.  Goto Definition of internal library symbol (i.e. enumATestStatus) in a project without a system (i.e. Language) crashed ATEasy.
63.  Drag and Drop is now allowed from one DLL to another.
64.  Endless "Illegal Type" message box when viewing parameter of type optional VAR ([VAR]). For example, Add method of treeview's nodes collection.
65.  File difference can now use a folder in one of the fields From/To instead of a file.
66.  Changing Project Defines should invalidate all compiled code.
67.  After pressing Ignore in the dafault error handling the status bar continues to display in red the error message.
68.  Changing procedure's local variable of type Fixed string to Val/Var parameter generated endless "Illegal Type" message.
69.  Run/Doit! will remove newly typed text of the Debug window.
70.  I/O address in the ISA Interface property page is not saved.

Test Executive

1.   Hour glass is displayed when filling the tree view when a new program or a profile is selected.
2.   New commands to set wait cursor.
3.   New commands to set the status bar.
4.   Status bar will display driver initialization progress when the test executive is started.
5.   TestExec will run a task with out being checked after test -1 statement
6.   Menu and Toolbar Icons support the XP transparent Style, Also images are now included for all commands
7.   OnEndProgram. Move print of the GetLogString to the beginning to complete the test log before calling other drivers OnEndProgram (e.g. they  might call SaveLog).
8.   After user login, the string for the log header does not updated by the new user name.
9.   Test Executive has a new command to set the CompanyLogo.gif file displayed on the top of the test log.
10.  When loading a program to the tree view program tasks are not get expanded to save loading time.

Examples

1.   Language.prg Example has new test showing how to use DLL CDecl function call. Th example shows call to atof() using MSVCRT.DLL. also added new examples for Variables, Structures and more.

New Drivers

1.   HW.drv does not return the board description.
2.   GT1648.drv - New driver for the GT1648 - analog output.
3.   GX5731.drv - New driver for the GX5731 - digital I/O with 128 channels and 32 customizable channels PXI board from Geotest.
4.   GX1648.drv - New driver for the GX1648 - analog output.
5.   GX1838.drv - New driver for the GX1838 - programmable discrete outputs.
6.   GX5050.drv - New driver for the GX5050 - 50MHz digital I/O.
7.   NvNT5000.drv - New driver for the NX500/NT5000 ROM emulator boards from Navatek.
8.   PiLPxi.drv - driver for System 40 PXI switching board from Pickering Interfaces.

ATEasy 4.0 - What's new - Published on 10/7/2003

10/7/2003

ATEasy version 4.0 contains numerous enhancements to the test development environment. Among the new features included are the ability to import Function Panel (FP) driver files and convert to ATEasy drivers, Integration with Microsoft Source Safe, the ability to show and edit ATEasy documents in text mode and to display file differences side by side. The Test Executive driver was enhanced greatly and uses a new Profile driver that allows you to create and run a profile that is a subset of the application programs, tasks and tests in a user specific/defined order and count. Version 4.0 also contains enhancements to the ATEasy run time engine. New functions were added, for examples, functions to read and write directly to physical memory, which can be useful when writing or creating drivers or prototype to PCI boards. We also improved the speed of the run time engine so that it runs ATEasy application 30% faster than version 3.0. The following lists new features available in ATEasy 4.0:

Open Architecture

Ability to import Function Panel driver files. Function Panel driver file (.fp) is a file of a specific format used by software packages (LabWindows and HP VEE) drivers. The function panel file format is based on the VXIPlug&Play Instrument Driver specifications published by VXIPlug&Play organization (http://www.vxipnp.org). Using the File Open command a Function Panel file (.fp) can be opened and then, converted to ATEasy driver format (.drv). ATEasy will generate a command tree, procedures, DLL function calls, constants and data types as defined in the function panel file and its accompanied C/C++ header file. ATEasy also loads an optional SUB file, which commonly used by IVI drivers.

Source Safe Integration. ATEasy directly interfaces with Microsoft Visual Source Safe. You can 'source control' ATEasy documents/files: Add, Check in, and Check out files directly from ATEasy. It also allows comparing files between versions of ATEasy and showing their versions. Differences are clearly marked and highlighted.

You can edit or view in text mode ATEasy documents, Program, Driver, System and Project, directly from ATEasy.

Command line options allow you to log on to ATEasy as a specific user, as well as allow you to build an application, print a file or load a file to ATEasy.

IDE User Interface

Startup dialog allows opening examples, driver examples and recent workspaces files or create new files or an application using the Application Wizard. This dialog can be programmed to show up at the start up of ATEasy, as well as it is available from File menu command.

Workspace Window has a new Files Tab. The current workspace window is displayed in the Objects Tab while a new tab, Files is showing each current workspace file. This provides a simpler file view of your project file and faster navigation between files.

Workspace window. When ATEasy starts up, the active project is expanded, and Files/Objects tab and selection is restored.

Description button was added to various views. The description view now has a button, displayed on the module view (new), the Forms, Procedures, Tests, and Commands View that can show or hide the view. The button has an indication to show whether the description is empty or not.

Description of objects (sub modules, etc) was enhanced and is more self-explanatory.

Module view. A new view is shown when you click on a module (e.g. Program). The new view displays the module's sub-modules and a larger area containing the module description.

Find and Replace dialogs. They have new options to skip the internal library and whether to re-start the search when the end of file is reached ('All').

New Program is now created with a Task and a Test.

Insert Object Below/After/At menu command now displays the type of object being inserted, e.g. Insert Variable Below.

New context menu to show/hide toolbars and dockable windows.

Display documents and type libraries progress during ATEasy loading a workspace in the status bar.

Selecting colors from the property pages (e.g. chart, status bar) was enhanced and allows using system colors for controls.

ATEasy notifies you if another application or user modified externally the document that you are currently working on.

Save As Text context menu command allows saving the current file in text mode (same file name with text file extension) without prompting.

Variables and their types (and initial values and descriptions) can be typed directly when renamed from the list view. Additional command was added to perform the in-place editing of the name and type of a variable (Ctrl+F2). For example, you can type "i:int=3!index starts at 3"

Application Wizard was enhanced to support the new Profile driver.

Programit! New command lets you execute any program, which may not be the first one.

Go to Definition. New menu command (and context menu) opens a window containing the definition or type of the selected symbol. This is a convenient tool that you can use during coding.

Project has an optional setting (in the project property page) that allows including or excluding unreferenced procedures during build.

Certain List view such as variables can now be sorted by Name, Type or Description (display only) by clicking on its column header.

In the procedures or form view, the procedure combo box provides the Drag and Drop capability. After pulled down the combo list box, you can drag and drop a procedure within the combo list, so that you can re-arrange the procedure list.

The Build menu, Check All includes checking of making sure Dll procedures defined in a module (under Libraries) actually exist in the Dll.

Debugger

Auto Data Tips - ATEasy will display variables values on the code view in a tooltip window during debugging when the application is paused.

When an application paused via break point, one can view each variable/parameter value in the variable/parameter view.

Watch and CallStack/Global windows will retain the values even after the current run terminates.

Run Time Engine

Speed Improvements. Run-time engine runs ATEasy application faster, at least by 30%.

Peek and Poke functions. New functions to read and write directly to the PC physical memory. This is mainly to support PCI/ISA boards driver development.

MemoryCopy function. New function to copy and fill data between two ATEasy variables.

ArgMissing function. New function to indicate whether an optional parameter was passed to a procedure.

DoEvents function. New function to allow form events to be nested. Useful when performing long operation in a form event.

Redim statement. New statement to change the dimension of an array size programmatically.

AClipboard class. Allow you to perform clipboard operations and to transfer data between applications (Cut, Copy, Paste, Clear).

AChart, ASlider, ASwitch controls uses the control area better and optimized more.

EndEvents keyword. New optional keyword to be used with the Run, Task and Test statements.

HTML Log uses CSS style sheet that allows changing the test log format attributes easier, e.g., font, color...

ADriver.InterfaceType can be set during run-time.

Test Executive and Profile

Added support to Text and HTML log format.

New Options dialog allows you to specify the default Log format, Clear and Save log before run.

The main window can be divided to two main panes. The left pane, the Tests Pane displays the program tests while the right pane, the Log pane shows the test Log as shown the previous test executive version.

The Tests pane displays in a tree the available tests of the current selected program or profile. A check box appears next to each Program, Task or Test. The user can select individual tests, tasks and programs from the Tests pane to run from the Tests pane. Program or Task is displayed in bold if they are partial selection (e.g. one test is checked and one is unchecked).

At run-time, these tests are color coded to reflect the test status at run time (black for none, green for Pass and Light Red for Fail and Red for Error).

The left pane bottom area displays the current selected test properties such as the test Name, Type, Required, Result and Status. At run-time it shows the current running test properties.

The Log, Tests and Tests Properties panes may be visible or hidden from the View menu. At list one Tests or Log Pane must be visible.

Window position and size and Log Options are remembered between sessions.

New Profile driver. The profile driver allows the user or the test engineer to create profile files for an application. A profile file contains tests, tasks and programs list that can be executed in that specific order and count.

Test Executive can dynamically supports the new Profile. Adding the profile to your system and the Profile command will show in the test executive menus.

New Examples/Drivers

Hp34401a, FP driver - example for a converted function panel driver.

MultiPad example - example for MDI application that provides text editor similar to NotePad.

HW example - example for Port I/O, Memory I/O and PCI device handling.

Additional drivers (Geotest, Adlink, UEI, PC Instruments and more).

ATEasy 4.0 build 90 – Release Notes - Published on 7/22/2003

7/22/2003

Solution:

IDE/Run-Times New Features/Changes

1.   AApp.Flags - new flags and re-organizing existing flags. The new flags were added to allow the test executive to synchronize the tree view and the execution after the application uses the Run/Task and Test statements.

2.   Call Stack window will display binary/hex values of Bool type variables

3.   You can override an internal function by declaring it. ATEasy will call your function instead of the internal one. You can still call the internal one using Internal.Function Name

4.   Drag and drop inside the procedures combo box was added. Also, the drop down list is stayed dropped after dropping

5.   The debugger will pause after stepping/tracing on the last line and will let you examine local variable before exiting the procedure

6.   Leaving Task and Test ID empty should cause their property page to regenerate new Ids
7.   Source Safe. Check In will always save the file without prompting the user unless it is a read-only file.

8.   Source Safe. Check Out/Undo Check Out will not prompt the user to save the changes. (This is unnecessary since the file will be replaced by source safe.)

9.   Source Safe. If the file is under source control and was not checked out, any attempt to modify it will be ignored, or the user will be prompted to check out the file. (Depends on the setting of the new "Check Out When Edited' option).

10.  Insert At/After was added to drag and drop depends on the position of the mouse cursor

11.  When debugging (e.g. Doit!) the run-time thread is kept until you restart the application again. This allows DLLs to retain their initialization between subsequent DoIt!s. DLLs and Applications will now initialize and load only between different starts.

12.  Insert Command will prompt for code completion for parameters

13.  DLL libraries can be merged using drag and drop

14.  Control, Form, and Menu property pages supports escape sequence strings in Caption and Text properties

15.  Recent page in Startup dialog has a new button called “Other” that allows opening other files that are not listed in the list

16.  During pause, debugged forms remain painted to allow you to examine the run-time form while pausing

17.  Step-Out is now enabled and allows stepping out of a test

18.  Step Over will not activate the application form causing debugging a form using the Step Over to cause flickering

19.  CreateObject/GetObject now supports "LibraryName.ClassName" or "Class" instead of only supporting the registry ProgID

20.  Any type is now supported as a variable type and not only as a parameter to a DLL procedure

Compatibility

1.   It is recommended to rebuild your EXE application before using it on the new run-time engine. This is especially needed when running applications that contain the test executive driver.

Bug/Issues

1.   Compiler. Compiler error was mistakenly reported 'Function has no return statement' when performing CheckIt! on a function

2.   Compiler. The statement "if lAttrib or ~0xA0" did not generate compiler error

3.   Compiler. Checkit! On a module shortcut caused the containing module to be checked instead of the module.

4.   Compiler. Doit! generated compiler error on no-return statement

5.   Compiler. Did not generate error for Val Object type with initial value

6.   Compiler. Did not allow taking address of Const variable even though it allows address of literal constant.

7.   Compiler. Problem with passing Val enumXXX from System to Program.

8.   Compiler. When system procedure with parameter type of public system enum is called via system command, the parse fails the first time, but it is OK on subsequent compilations

9.   Compiler. Structure size and member offset are incorrectly calculated if packing order is greater than 1 when loading type information from a type library.

10.  Compiler. Omitting parameter list when comparing variant to function return value, e.g."IF TestResult < GetTestMax" - will generate wrong PCode that will crash the run-time

11.  Run-Time. Assignment of array of characters to a string could crash ATEasy

12.  Run-Time. ExitTask and Test -1 statements will not work properly in Taskit mode

13.  Run-Time. Calling empty module event crashed ATEasy in stand-alone EXE

14.  Run-Time. Calling System.OnXXX event from a driver will crash if the event does not exist

15.  Run-Time. Passing variant containing array of non-object (LONG[], DOUBLE[], STRING[] etc...) to procedure's parameter of type VAL OBJECT[] (array of type object) could crash ATEasy.

16.  Run-Time. Passing a non-array variant to a procedure's parameter of type VAL array crashed ATEasy.

17.  Run-Time. Test Log tables header for HTML and text displays different strings for Text and HTML: Test-Name and Name.

18.  Run-Time. Changing Projects did not reset the FormatLogString() settings

19.  Run-Time. Late bound call to method which has a parameter which is a safe array fails

20.  Run-Time. Assigning a variant to another did not set the LValue variant type as the right side

21.  Run-Time. Passing array of string to a variant generated run-time error #427

22.  Run-Time. DoIt! of program code followed by Run-Start command did not compile or execute program events

23.  Run-Time. Form's drawing functions (Circle, Rectangle, DrawText etc...) did not work after the first usage.

24.  Run-Time. Passing negative number to Output IO table operation generated sometimes "Out Of Range" message

25.  Run-Time. Print statement in HTML mode truncated string above 1024 characters caused the log to display garbage

26.  Run-Time. Assigning structure literal to element of structure array VAR parameter generated access violation in RT

27.  Run-Time. Return statement in procedure which returns a complex type and which also has structure literal generated run-time error when run from EXE file

28.  Run-Time. Passing address of a variable to a Val parameter of type LONG generated parser error #612 'Type of argument is incompatible'.

29.  Run-Time. Setting default value of optional parameter that its type is resolved to object will crash during Build/Execute.

30.  Run-Time. Passing variable of type object to a parameter of type "[Var] Variant" generated run-time error # 407.

31.  Run-Time. The statement proc=Program.OnInit did not work from the driver

32.  Controls. Changing list item's text using List() property of AListBox or AComboBox reset item data to 0.

33.  Controls. Inserting, deleting or changing item of a sorted AListBox or AComboBox control in design mode using List property page unsorted current items.

34.  Controls. Changing round slider control's ticks spacing to non-auto (interval, division) could crash ATEasy.

35.  Controls. ALog.SaveAs will not work when Visible=FALSE

36.  Commands. Reducing procedures # of parameters will corrupt a command that uses this procedure with a constants/changed parameters

37.  Commands. Creating a command that is assigned to a procedure with two with two enum parameters does not saved the commands parameters (constants) properly

38.  Debugger. A Change in array dimension size followed by a Redim statement was not reflected in Watch/Call Stack window or code completion.

39.  Debugger. Changing display format of the Watch/Call Stack windows did not refresh the value with new format

40.  Debugger. Changing array elements in the Watch window could crash ATEasy

41.  Debugger. Char is displayed as a number in the Watch window

42.  Debugger. Aborting while in error handling OnError caused breakpoints placed in OnAbort to be ignored.

43.  Debugger. Duplicated items were shown in the call stack when paused while displaying a message box/input box.

44.  Debugger. Step Over (F10) the last line of the nested call does not always work. It behaved like Continue (F4) instead of pausing at the next line after the call.

45.  Debugger. Step out from interrupt procedure did not continue stepping at point of interrupt.  Step into when interrupt procedure is fired did not continue stepping at start of interrupt procedure.

46.  Property Page. Fixed string did not retain the its value from the Value property page

47.  Property Page. Terminator in Winsock Interface of a Driver was missing from the property page

48.  Property Page/ActiveX controls. TabStrip ActiveX control. Making changes in its property page (Remove Tab) was not caused the page to be marked as dirty and not saved.

49.  Property Page. Open On Access fro GPIB, VXI and ISA was mistakenly displayed in the driver shortcut property page

50.  Property Page. Document property page File Browse button initializes the current directory instead of the document path directory.

51.  Property Page. Form property pages of READ ONLY document does not disable some of controls.

52.  Property Page. REFX tests use as default 0x0 mask instead of 0xfffffffffffffff.

53.  Property Page. Changing the Form ScaleMode in design time will confuse the form editor

54.  Property Page. Pressing Del when the driver shortcut is selected with the Misc page sometimes crashed ATEasy

55.  Property Page. Selecting new file to replace the currently modified file using file browse dialog (instead of typing the file name) crashed ATEasy.

56.  Property Page. GPIB Primary secondary address spin button behavior was wrong

57.  Property Page. Com method/property/variable or type allowed to change its type from the property page

58.  Code Completion. Syntax coloring problem with '\"' marks the rest of the line as comment

59.  Code Completion. Replacing a string with a ‘.’ did not display the members list box

60.  Code Editor. Selecting a variable or placing the cursor at the end of the variable makes the Go To Definition disabled

61.  Code Editor. Test header did not show the Task number and name when having two level tasks or more

62.  List View. List View edit label box was sometimes too small to type in long variable name, etc

63.  List View. Types such as Enum, Struct edit labeling with F2 display the type incorrectly.

64.  List View. Commands View. Insert After, Undo, Insert Below may crash ATEasy

65.  Undo/Redo. Undo of copy/paste of multiple controls  could crash ATEasy

66.  Copy/Paste. After Copy and Paste of controls, selection of a particular button selects other control

67.  Copy/Paste. Paste into Procedures combo box disregards what is being selected, it always paste at the end

68.  Copy/Paste. Paste Task/Test did not always checked for unique ID.

69.  Find/Replace. Various problems were fixed.

70.  Source Control. Source control status did not correctly displayed status of read-only files

71.  Source Control. All changes will be rolled back after CheckOut or Undo CheckOut.

72.  Source Control. Source control file changed notification did not work under Windows 95/98/Me.

73.  Source Control. File difference combo box does not always offer to use the latest folder/file in the to combo box

74.  Options. Removed unused 'Menu Return' option from the Option dialog.

75.  Document. Menu text format serialization does not serialize the shortcut information

76.  Document. Save In Text Format on binary format document resets the document modified flag

77.  FP Document. Conversion of FP file could crash ATEasy

78.  FP Document. After Converting FP file and running the application ATEasy crashes since the FP author did not enclose a string GPIB0::5::0::INSTR with double quotes.

79.  ATEasy 2 conversion. Converting INS files IO Table with Input IO operation generates an extra argument

80.  ATEasy 2 conversion. ATEasy2 I/O table conversion did not work with Input mode "File"

Test Executive/Profile

1.   Will synchronize the tree view and the execution with the Run/Task/Test/ExitTask/ExitProgram (Task -1) statements

2.   Profile forever count did not work

3.   Test Executive will disabled itself when debugging from the IDE using TaskIt/TestIt/ProgramIt!

4.   Profile Editor Up Down caused endless message boxes to be displayed

5.   Node tags of the Test Executive/Profile stored information using array of variants instead of single string

6.   Redesigned parts of the test executive execution mechanism to provide better performance handling of flow control statements

7.   The Test Executive commands where organized and new commands where added to provide better application control

Drivers

1.   SM2040x - added/modified new ranges, added new function such as pulse width

2.   SM2020 - DMMReadBuferStr spelled incorrect, DMM Measure command uses the DMMReadNorm instead of DMMReadDbl

3.   PCI42x - DLL file name was wrong under NT/2000/XP - users must change the DLL manually if using the driver on these OSs. This is now documented in the driver

4.   HW.drv - better support for PCI and Plug and Play configuration and resource handling

5.   New drivers for NIDAQ (National Instruments), NT5000 (Navatek), various Geotest PXI Instruments and Adlink Data Acquisition.

How to control the vertical scroll bar in the ALog control - Published on 7/22/2003

7/22/2003

Solution:

To hide the scroll bar:

log.Object.Document.Body.Scroll="No"

To show the scroll bar (same as ALog default):

log.Object.Document.Body.Scroll="Yes"

To show the scroll bar only if needed:

log.Object.Document.Body.Scroll="Auto"

Implementing a loop micro-code command by writing directly to the control memory (GX5050/GC5050/GT2550) - Published on 4/17/2003

4/17/2003

Solution:

The following table shows the control memory content in order to create the sequence of loop three times and then Halt.

Note: All 32 channels direction are set to OUT, i.e. bits 28-31 are low.

When writing commands to the control memory all commands need to be spread on four consecutive steps.

Step #	Control Memory value
0	0x00000002
1	0x00000002
2	0x00000002
3	0x00000002
4	0x00000000
5	0x00000000
6	0x00000000
7	0x00000004
8	0x00000004
9	0x00000004
10	0x00000004
11	0x00000000
12	0x000E0000
13	0x000E0000
14	0x000E0000
15	0x01CE0000

Steps 0-3:
Command Sets register A equal to 2 with no conditions in order to loop a total of 3 times we set register A to 2.
The first three steps (0 through 2) hold the Register value (bits 0 through 15). The fourth consecutive step (3)
has the register number (bits 20-21) ORed with the Loop address value.

Steps 4-6:
Command No Operation

Steps 7-11:
Command: Loop on A. Loop steps 4 through 10 the number of times register A is set to.
The first three steps (7 through 9) hold the Loop address value (bits 0 through 16 for a total of 128K).
The fourth consecutive step (10) holds the Operation Code (bits 22 through 24) ORed with the Loop address value.

Step 11:
Command No Operation

Steps 7-11:
Command: Halt. The first three steps (12 through 14) hold the Halt command condition value (bits 17-19).
The fourth consecutive step (15) holds the Operation Code, bits 22 through 24 ORed with Halt command condition value.

Loop command flow chart:

Note: The value of register A at the end of a Loop command is 65535 (0xFFFF).

What is the screw thread for the Geotest switching product's DB78 connector - Published on 4/17/2003

4/17/2003

Solution:

Geotest switching cards use a Positronic DB78 connector. This connector has a jackscrew for fastening a harness or cable. What is the jackscrew thread spec? It is 4-40 thread.

Accelerating the execution of ARM or TRIG commands when using GT2550 board - Published on 4/16/2003

4/16/2003

Solution:

The GT25/50 driver has embedded delays (about 30-40 mS) in order for it to work properly under different operating systems, carrier cards or different computers.

In GTDIO/DIOEasy v3.0 build 12 and above users can accelerate the execution of DioArm or DioTrig procedures when the GT25/50 run in frequencies greater then 200KHz using the DioSetOperationMode procedure. See the Dio on-line books for details on how to use this function.

GX5150 VHI0, VHI1 VREF, VTH0, VTH1 Pins - Published on 4/15/2003

4/15/2003

Solution:

It is not necessary to connect these pins. The GT5930 provides return path for all 32 channels on the wire opposite the signal wire.

How to create a "system modal" form similar to ATEasy 2.x dialogs - Published on 4/10/2003

4/10/2003

Solution:

The System modal dialog style (DS_SYSMODAL) was dropped as it is no longer supported in Win32. According to MSDN documentation:

This style is obsolete and is included for compatibility with 16-bit versions of Windows. If you specify this style, the system creates the dialog box with the WS_EX_TOPMOST style. This style does not prevent the user from accessing other windows on the desktop. Do not combine this style with the DS_CONTROL style.

You can still make a window top-most by using the following USER32.DLL function, in the Form OnLoad event:

SetWindowPos(Form.hWnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOSIZE or SWP_NOMOVE)

Where the parameters are prototype as follows:

DLL User32
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
File = User32.dll

DLL Types
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

DLL Procedures
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Procedure SetWindowPos(hwnd, hwndInsertAfter, x, y, cx, cy, uFlags): Bool
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

hwnd: Val AHandle
hwndInsertAfter: Val AHandle
x: Val Long
y: Val Long
cx: Val Long
cy: Val Long
uFlags: Val DWord

DLL Constants
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
HWND_TOPMOST: AHandle Const = -1
SWP_NOSIZE: Long Const = 1
SWP_NOMOVE: Long Const = 2
SWP_NOZORDER: Long Const = 4

Sample files are available: Q200054.zip

Regenerating Program Tasks and Tests IDs - Published on 3/24/2003

3/24/2003

Solution:

ATEasy will try to leave the Test or Task IDs intact after renaming them. The reason is that an external file or code may reference the ID; changing the ID name will break the code.

If you don't have any external reference to the Task or Test IDs and you would like to generate IDs that are similar to the Task/Test name you can use the attached utility.

To use the utility copy the files to a folder and open the project file (ProgramIds.prj). From the Run menu select Start.

Select the program source file that you wish to convert (language.pgt in this example) and type a new program name that will contain the new program with the new Ids (language-new.pgt). Click on the Convert button.

Files for this Article: Q200053.zip

Setting test requirements (e.g. Min/Max) from an external file - Published on 2/20/2003

2/20/2003

Solution:

The following describe a way to use external requirements files:

Open the external test requirements file in Program.OnInit.

Read the new requirements file.

Set the program test objects properties. You can set the test properties in OnInitTest (e.g., Test.Min=dMin) or for the whole program at once during Program.OnInit by looping and setting the test's objects (e.g., Program.Tests(name or number).Min=dMin).

If you want to set the test requirements for all the program tests at one time, do that after the program is running (e.g. OnInitProgram and not in OnInitSystem) since the run statments will reset any requirements you set.

The external file can be text, binary, an Excel spreadsheet, or a database. Text and binary files can be opened and read using ATEasy's FileXXX internal library functions. Excel spreadsheets or database files can be opened using Excel or ADO COM objects using a type library. For example code, refer to the ATEasy Excel example.

How Do I Call a DLL Created in Microsoft.NET from ATEasy 3.x or 4.x? - Published on 2/3/2003

2/3/2003

Solution:

ATEasy 3.x or 4.x (ATEasy 5.x and above support importing and using .NET assemblies directly) cannot call Microsoft.NET assemblies directly. Even if you create a Microsoft.NET class library with public methods, Microsoft.NET will compile these into Microsoft.NET assembly. This assembly will still have a .DLL extension, but it is NOT a dynamic link library (DLL). For more information on assemblies, see Microsoft.com assemblies.

One way to use the .NET assembly from ATEasy is by wrapping the .NET classes in your .NET library to ActiveX COM objects using a tool that is provided with .NET. This tool works as follows:

1. Register the .NET assembly using the .NET Framework Assembly Registration Utility (RAGASM.EXE) for example:

RGEASM MyLib.dll /tlb

The /tlb option is optional and will create and register a type library with the name MyLib.tlb. The type library can then inserted to the ATEasy sub module Libraries and can be used as other early binding objects.

2. Install the assembly into the Global Assembly Cache (GAC) using the .NET Framework Global Assembly Cache Utility (GACUTIL.EXE) for example:

GACUTIL –I MyLib.dll

3. After these step the .NET components can be used similar to any other COM object from ATEasy. Both methods early and late binding can be used.

Another workaround is to create an actual dynamic link library (DLL) from a Microsoft.NET language. This can be done with Visual Studio.NET. From within Visual Studio.NET, select File » New » Project. You can then select Visual C++ as the Project Type and Win 32 Project as the Template. After you click OK, you can then select Application Settings, rather than Overview. Then select DLL as the Application Type and select Export Symbols as Additional Options

How to use a DCOM component from ATEasy - Published on 12/16/2002

12/16/2002

Solution:

Use the following procedure to use a DCOM component from ATEasy:

1.   Register the server application on the server computer (usually by running it)

2.   Run the component setup to register the server component on the client computer

3.   Run Component Services Windows application (Start, Run, dcomcnfg.exe) on the server computer and select the application from the Component Services, My Computer, DCOM Config and set the security to allow remote computer to access the component

4.   Run Component Services Windows application (Start, Run, dcomcnfg.exe) on the client computer and select the application from the Component Services, My Computer, DCOM Config and set the application computer location

5.   From ATEasy use CreateObjec() or GetObject()  internal functions to create the remote objects as creating local object

Note: Since ATEasy version 6.0, CreateObject() has a new optional parameter (sHostName) that can be used (in addition to the method described here) to create remote objects.

ATEasy's Sleep(), Delay() and WaitForEvent() Functions Usage - Published on 12/6/2002

12/6/2002

Solution:

Sleep suspends the thread from which it was called (meaning it will also suspend UI such as form events, painting, etc.). If you wish to create an interval of time, you may call Delay() instead. However, Delay() consumes CPU time (see knowledge base article Q200030).

If that is a problem, you can use the following code:

Procedure DelayEx(lDelay)
{
lStart=Tick()

loop
   lTime=Tick()
   if lTime-lStart>lDelay than exitloop
   WaitForEvent(lStart+lDelay-Time)
   ! optional - call DoEvent() if you are calling this from a form event
endloop
}

PCI/PXI explorer hangs when opened - Published on 12/3/2002

12/3/2002

Solution:

The problem can be replicate usually on new Dell computers since their mother board contains a PCI device with function #7.

To replicate the problem, you can run the HWTEST application from the Program Files\Geotest\HW from the command prompt:

HWTEST pci

After running it you will see endless list of PCI devices displayed in the command window.

Geotest fixed this issue with HW (hardware access device driver) v2.11. This driver is shipped with every Geotest product that was released after December, 3 2002.

ATEasy 2.x DLG Based Dialog Boxes Appear Narrower in ATEasy 3.0 than in ATEasy 2.x - Published on 10/31/2002

10/31/2002

Solution:

This problem occurs because the Windows Dialog Base Unit (DBU) works differently in Win32 than in Win16.

DBUs are a Windows unit that let you specify control in a portable way that will allow different system to display text without clipping (to prevent the problem that cause fonts to be truncated).

Dialog Base Units (DBU) are used in DlgEasy and by Windows specify control size and position which are later on converted to pixels before being displayed by Windows.

Microsoft recommends to UI designers to add 30% width to controls that display text to prevent font clipping when changing system. If this rule is not followed, font truncating is not guaranteed. In addition, moving from WIN16 to WIN32 DBU translation to pixels was changed by Microsoft and made a bit narrower. However if the 30% rule was used than in most cases migrating dialog (in C or ATEasy) will work. Designing a dialog box in Visual C 1.5 and recompiling it to Visual C 6.0 may cause the same problem.

If font is truncated the only workaround is to resize the dialog controls in DlgEasy before using it from ATEasy 3.0.

Changing ATEasy control properties that affect the control window area does not take effect until you return from the form/control event - Published on 10/31/2002

10/31/2002

Solution:

For example changing the ASwitch control Value property will not take effect (in the control area in the form) until you exit the form event.

Use one of the following methods to force painting:

1.  Call DoEvent() this will cause events to be handled while the form event is handled. (ATEasy 4.0)

2.  Use the control Refresh() method (ATEasy 4.0 build 90 and above).

3.  You can use User32.dll UpdateWindow(hwnd) to force painting (hwnd is the control.hWnd property).

How to make the ATEasy log window update immediately after print during a form event - Published on 10/28/2002

10/28/2002

Solution:

You need to use the Flush() method of the log control. Just call the method after the print statement or append method and the log control will be updated immediately.

CoolBar control in Microsoft Window Common Control 3 not supported with ATEasy - Published on 10/16/2002

10/16/2002

Solution:

ATEasy does not support control that contains other controls (control container using ISimpleFrameSite interface). This interface is not documented by Microsoft and is currently supported only by VB. (Not supported by other application such as: Access or FoxPro MFC or ATL).

ATEasy EXE File Compatibility with Older Run-Time (RT) Engine Builds - Published on 10/16/2002

10/16/2002

Solution:

In general, ATEasy created executables (EXE) files run with the same run-time that was used to build the EXE. The EXE can also run with newer version of the ATEasy run-time.

Upgrading the target computer with the build that that you used to build the EXE along with the EXE file will always work. However, steps have been to reduce incapability between versions of ATEasy, so you will be able to mix different run time and EXE versions.

Since the file format of the ATEasy EXE or files rarely changes, you may not always need to send the run-time engine with your rebuilt EXE file. Starting from ATEasy 3.0 build 54 we made several changes to prevent the need for sending run-time updates.

How to Find the Free Disk Space from an ATEasy Application - Published on 9/27/2002

9/27/2002

Solution:

You need to call the Windows API that resides in a system dll. See the on-line help how to declare and call DLL function.

You can call GetDiskFreeSpace or GetDiskFreeSpaceEx declared in kernel32.dll or SHGetDiskFreeSpace in shell32.dll (check the Microsoft web site for declaration of these functions).

Below is a sample GetDiskFreeSpace declaration in ATEasy:

GetDiskFreeSpace(
lpRootPathName : val string,          ! root path e.g. "c:\\"
lpSectorsPerCluster: var dword,    ! sectors per cluster
pBytesPerSector: var dword,        !bytes per sector
lpNumberOfFreeClusters: var dword,  ! free clusters
lTotalNumberOfClusters: var dword:
) : Bool

Free space is calculated as:

dFreeSpace=lpSectorsPerCluster*1.0*pBytesPerSector*lpNumberOfFreeClusters

the *1.0 in the above code is used to convert to double and to avoid overflow since the result could be >4GB

Make ATEasy Wait until WinExec Application/Process Completes - Published on 9/25/2002

9/25/2002

Solution:

In ATEasy 3.0 build 54b and above, WinExec returns a true handle.

hHandle=WinExec(..)

WaitForSingleObject(nHandle) ! wait until app is completed

….

For ATEasy 3.0 build 54a and below, you must use FindWindow (user32) on the caption of you application or the class of its main window (using spy):

WinExec(...)

while FindWindow(...)
endwhile

How to copy a file from an ATEasy application - Published on 9/25/2002

9/25/2002

Solution:

ATEasy 6.x and above have a FileCopy() function that can be used to copy file. The following provides a way to copy a file using ATEasy 3.x-5.x:

Copy the following to your text file Libraries section:

DLL Kernel32
--------------------------------------------------------------------------------
File = Kernel32.dll

DLL Types
--------------------------------------------------------------------------------

DLL Procedures
--------------------------------------------------------------------------------

Procedure CopyFile(sExitingFileName, sNewFileName, bFaiIfExist): Bool
--------------------------------------------------------------------------------
sExitingFileName: Val String
sNewFileName: Val String
bFaiIfExist: Val Bool

Toggling the DTR line with an RS232 COM port from ATEasy - Published on 9/25/2002

9/25/2002

Solution:

Before starting, you must know the base address for the port, which can be obtained from Windows Device Manager Resource tab. Usually the base address for COM1 is 0x3F8.

The DTR line is connected to Modem Control Register (MCR) bit 0 at an offset of 4 (e.g., 0x3F8 + 4). Setting this bit to 1 makes the line active.

For example:

iBase=0x3F8
ucByte=PortInByte(iBase+4)

! set DTR On
PortOutByte(iBase+4, ucByte or 0x1)
Delay(500)

! set DTR Off
PortOutByte(iBase+4, ucByte and 0xFE)

ATEasy 2.x and 3.x GPIB Secondary Addresses - Published on 9/25/2002

9/25/2002

Solution:

In ATEasy 3.0 and above, Secondary Address 0 is used as a None secondary address. Use 1 to 31 as a Secondary Address for GPIB instruments.

ATEasy 2.x uses 0 as the first Secondary Address. To remain compatible with ATEasy 3.0 and above, add 1 to ATEasy 2.x application Secondary Address (e.g., use 1 instead of 0).

Printing an Image or Form Data from ATEasy - Published on 9/25/2002

9/25/2002

Solution:

The process is comprised of two steps. The first step is to save the chart to a image file. The second step is to print the image file.

1. To save to an image file, use the Image property with the SavePicture() internal library routine.

2. Use one of the following methods to print the saved image file:

Use WinExec() with MSPAINT or any other application that supports printing of picture from the command line (/p).
Use the Log control in HTML mode to insert a picture tag to it with the file saved. Then, use Log.PrintLog. This method is very flexible, as you may add text and/or other drawing elements to your printout.
Use COM libraries such as Word and Excel to send a picture and to print.

High CPU Utilization when Using ATEasy's Delay() - Published on 9/25/2002

9/25/2002

Solution:

Calling Delay() does not put your thread to sleep; events and interrupts continue to be monitored in your thread.

If you don't want to monitor events, you can use Sleep(), which does not use as much CPU.

Is there a way to know if my application is running from the ATEasy development env (IDE)? - Published on 9/25/2002

9/25/2002

Solution:

If app.ModulePath has the string value "ATEasy.EXE", then your application is running from the ATEasy development environment.

PCI/PXI Instruments not working properly when several instruments of the same type are installed on the same Windows NT machine - Published on 9/25/2002

9/25/2002

Solution:

Cause: The Windows NT Hardware Abstraction Layer (HAL) HAL assigned an I/O port address or memory resource to a PCI device that overlaps with an existing PCI device, causing a PCI resource conflict on your system. Under normal operation, the system BIOS is responsible for setting the PCI device resource requirements. When Windows NT loads, the Windows NT HAL sometimes moves the PCI device resources. PCI devices are dynamically configurable. However, the Windows NT HAL sometimes assigns overlapping I/O port addresses or memory resources for the PCI devices.

Resolution: Adding the /PCILOCK switch to the BOOT.INI file forces the Windows NT HAL to use the PCI device resources allocated by the system BIOS. After modifying the BOOT.INI file the system must be rebooted.

Example: The following is a typical Boot.INI file with the /PCILOCK switch

[boot loader]
timeout=3
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)WINNT="Windows NT Workstation
Version 4.00"/PCILOCK
multi(0)disk(0)rdisk(0)partition(1)WINNT="Windows NT Workstation
Version 4.00 [VGA mode]" /basevideo /sos /PCILOCK

ATEasy Licensing Q&A - Published on 9/19/2002

9/19/2002

General

Q. What kind of licensing does ATEasy have?

A. ATEasy has two types of licenses: Single-User and Network. A Single-User license is installed on one computer and allows you to use ATEasy on that computer. A Network license is installed at a network server and allows users to work from any computer connected to that network limited to the number of licenses that have been purchased (concurrent license).

Q. Can I distribute my ATEasy application?

A. Yes. ATEasy applications compiled to EXE file are Royalty-Free. You will have to install the ATEasy run-time on each machine that the executable will run.

Q. Will my license work with any version of ATEasy?

A. Licenses are purchased for a specific version of ATEasy only and will not work with newer versions of that product.

Q. I bought a license for version 3.0, Can I use version 4.0 with that license?

A. No, You cannot. You must purchase a subscription or an upgrade. Subscriptions can only be purchased within 90 days of the original product purchase. Upgrades can be purchased at any time.

Q. I bought a license for version 6.0, Can I use version 4.0 with that license?

A. Yes, You can. A license for specific version support ATEasy v3.0 and newer up to the version of the license purchased. For example if your network license server have a 7.0 license, client can run version 3.x-7.x.

Q. What does one year subscription provides?

A. The one year subscription & support provide one full year of free technical support as well as one full year of free upgrades. With subscriptions you will get a new license if an upgrade to the product is release during that year. In general, we release new major upgrade (that requires new license) at least once a year.

Q. If I did not buy a subscription and a new version has been released, Can I buy subscription to upgrade my license?

A. You can buy subscriptions only within 90 days of the date you originally purchased the product. After that you must buy an upgrade to get license for the new version.

Q. When I buy an upgrade, can I buy a subscription to keep me up-to-date for a year?

A. Yes, You can. Once purchased, you will receive one full year of upgrades and support from the date you have purchased the upgrade.

Single License

Q. What kind of single-user license is available for ATEasy?

A. ATEasy is offered with either a Hardware Key, or a Software Key Licenses. Hardware licenses use a device that plugs to the computer's Parallel or USB ports to provide the license. Software Licenses use a string of characters that are entered into the ATEasy License dialog box (located under the About ATEasy dialog).

Q. Can I move the key from one machine to another?

A. Yes you can. Hardware keys can be moved from one computer to another by unplugging the device and plugging it into another computer. Software keys can be also transferred to another machine (up to three times) by requesting a license transfer from Geotest (by requesting it using your M@gic/support account), this process involved terminating the license (see Q200060) and installing a new license obrtained from Geotest (see Q200089) .

Q. I've purchased several copies of single-user license. Can I buy subscriptions for part of my single-user licenses?

A. Yes you can. However, only the licenses with subscriptions can be upgraded when a new release is available as the upgrade is by serial number.

Network License

Q. What is the minimum number of licenses allowed with network license?

A. 3 or more. You cannot purchase a network license with one of two licenses.

Q. Can I buy subscription for part of my Network licenses?

A. No you cannot. Subscriptions for network licenses must be purchased for all licenses that are included in that network license.

On Windows 9x ATEasy will not notify if file used by ATEasy was saved externaly on a network driver - Published on 9/19/2002

9/19/2002

Solution:

This problem can happen only in ATEasy 4.x and above running on Windows 9x.

This is due to a known windows 98 bug with FindFirstChangeNotification Windows API used by ATEasy that does not return notification when file saved on network drive.

VB Controls or Objects are Slow When Running from the ATEasy IDE - Published on 9/19/2002

9/19/2002

Solution:

Visual Basic 6.0 objects are single threaded by default. VB objects that are run in the ATEasy IDE will run in the IDE's main process thread apartment. ATEasy must then use a proxy when creating a control from the run-time thread, which slows performance (50-100 times).

To increase performance when using VB objects, make sure to change your VB project setting to use the Apartment Threaded threading model.

Customizing the ATEasy Log Header and Footer when printing - Published on 9/19/2002

9/19/2002

Solution:

If you are using ATEasy 5.x and above the PrintLog() internal function and the ALog.PrintLog has parameters to support setting the page header and footer for printing.

For ATEasy 3.x and 4.x users use the following solution:

The ATEasy Log window is based on Internet Explorer (IE). When printing, the ATEasy log window uses the IE page setup options that are stored in the Registry. To change the settings, you can run IE, select Page Setup from the File menu, then edit the header and footer fields as required. You can also do this programmatically -- you'll need to locate the registry entry and write to it on the fly before calling Log.PrintLog().

ATEasy USB License Key Does Not Work in Windows NT 4.0 - Published on 2/28/2001

2/28/2001

Solution:

Windows NT does not support USB devices. Therefore, the USB Rainbow protection key is not supported under Windows NT.

The USB protection key is supported only under Windows 9x/ME and Windows 2000.

How to Create and Use C Structure Bit Fields in ATEasy - Published on 2/12/2001

2/12/2001

Solution:

Bit fields are not part of the ATEasy language. To create a bit field-like structure, you can define a member as an integer and manipilate the field using the Or or And operators to set values in the fields. To clear a field you can use the Not operator.

For example if the C structure was :

Struct Fields { ... DWORD a : 5; DWORD b: 3; ... }

Define the Bit field as dw in ATEasy:

struct Fields { ... dwFields : Dword ... }

Define some constants:

A _MASK: Dword=0x1F A _POS: Dword=0 B_MASK : Dword=0x7 B_POS: Dword=5

To clear b use:

f.dwFiellds =f.dwFiellds & not (B_MASK shl B_POS)

To set b use:

f.dwFiellds =f.dwFiellds & not (B_MASK shl B_POS) or (bNew shl B_POS)

Can I Pass an ATEasy Procedure to a DLL for CallBack? - Published on 2/12/2001

2/12/2001

Solution:

Passing an ATEasy procedure to a callback is supported from version 6.0 and above.

The following workaround provides the same functionality for ATEasy version 3.x-5.x:

1.   Write a DLL with the callback function and pass it to the function that requires callback function.

2.   To pass the address, call the Windows API GetProcAddresss(), then pass the result as long to the function that requires callback function.

3.   The DLL callback function can use another ATEasy thread to perform an action in ATEasy when the call back was called. The thread can be triggered by an ATEasy synchronization object (AEvent), using a global variable or an ATEasy user interrupt.

ATEasy Log Control Hangs or Crashes - Published on 10/13/2000

10/13/2000

Solution:

The ATEasy ALog control may hang or crash if appending too much text.

The ATEasy Log Windows is based on Microsoft Internet Explorer (IE). IE does not provide an easy and fast way to determine the limitation on the IE page size. The limit is highly dependent on IE platform, version, and memory. Usually the log file can be very large (several MB) if Windows have enough memory.

If each program run is saved to a separate log file (default), this will not should be an issue.

ATEasy SNMP Protocol Support - Published on 10/4/2000

10/4/2000

Solution:

The SNMP protocol API comes with Windows NT/2000 and above, and can be accessed from ATEasy using Windows SNMP APIs.

http://msdn.microsoft.com/en-us/library/aa378988.aspx

Additionally, there are third party ActiveX or .NET SNMP components available, including:

PowerTCP SNMP Tool http://www.dart.com/power

Cyberons http://www.netaphor.com

ATEasy Properties or IDE Dockable Window Disappears or is not Positioned Properly - Published on 9/26/2000

9/26/2000

Solution:

This issue is caused by corrupted ATEasy Workspace key the the Windows registry.

This problem can be fixed by editing the Windows Registry which will cause ATEasy IDE to reset all windows position to default:

1.   Exit ATEasy.

2.   Start the Registry Editor (REGEDIT.EXE).

3.   In the Registry editor, select the

HKEY_CURRENT_USER\Software\Geotest\ATEasy\Workspace

4. To delete the whole IDE windows position delete the whole key.
To delete the properties window position and size delete the PropertiesPlacement from the Full key.

Bypassing the Windows NT Logon Process - Published on 9/20/2000

9/20/2000

Solution:

WARNING: Use this procedure only when absolutely necessary. Follow the procedures carefully. If the registry editor is used improperly, you may have to reinstall Windows NT to correct problems. Back-up pertinent data. Geotest - Marvin Test Systems, Inc. provides this information as a courtesy to its users. Geotest is not responsible nor liable for any damage caused by following these procedures.

Windows NT allows you to automate the logon process by storing your password and other pertinent information in the Registry database.

Note: Storing login and password information in the Registry database allows other users to start your computer and use the account you establish to automatically logon. Timing conflicts can also occur. For example, if you have several network transports loaded, enabling automatic logon may make Windows NT attempt to connect to network resources before the network transports are completely loaded.

Use the Registry Editor (REGEDT32.EXE), available as part of Windows NT operating system, to add your logon information, as follows:

1.   Start REGEDT32.EXE and locate the following Registry subkey:
      HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon

2.   Establish your domain name, account name, and password using the values you would normally type when logging on. You should assign the following values:

DefaultDomainName
DefaultUserName
DefaultPassword

Note: The DefaultPassword value may not exist. If it doesn't, from the Edit menu, choose Add Value. In the Value Name field, type:
DefaultPassword

Select REG_SZ for the Data Type. In the String field, type your password. Save your changes.

Also, if no DefaultPassword value string is specified, Windows NT automatically changes the value of the AutoAdminLogon key from 1 (true) to 0 (false), thus disabling the AutoAdminLogon feature.

3.   From the Edit menu, choose Add Value. Enter AutoAdminLogon in the Value
      Name field. Select REG_SZ for the Data Type. Enter 1 in the String field. Save your changes.

4.   Exit REGEDT32.

5.   Exit Windows NT and turn off your computer.

6.   Restart your computer and Windows NT. You should be able to logon automatically.

ATEasy Timers - Published on 7/28/2000

7/28/2000

Solution:

ATEasy has two types of timers:

1. ATimer control

2. INT_TIMERx interrupts

The ATimer is based on the windows WM_TIMER message (not an accurate timer). Windows documentation describes the WM_TIMER message as a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue.

The INT_TIMERx interrupts are based on the Window MultiMedia Timers (see the Windows SDK for timeSetEvent API). The multimedia timers provide accuracy up to 1 ms. ATEasy's ability to deliver 1 ms interrupts depends on the time required to execute a single PCode command. Since interrupts cannot be called in the middle of a PCode command in that thread, this time may be long if the thread calling a DLL function takes a long time before it completes.

The following list alternatives to the above mentioned timers:

Create an ATEasy thread and use the Sleep() function to form a delay between events. Call SetThreadPriority() to ensure more accurate timer.

Write a DLL and use the multimedia timer timeSetEvent. This method is accurate, but requires a callback function that must be implemented in a DLL. This method could be more accurate if implemented in its own thread.

Write a DLL and use the Windows SetWaitableTimer. This method is accurate (better than 1 ms), but requires a callback function must be implemented in a DLL in its own thread.

Use hardware to implement the handler functionality.

Can't obtain a license from ATEasy License Server - Published on 7/11/2000

7/11/2000

Solution:

The following list reasons why license cannot be obtained from an ATEasy Network License server:

1. ATEasy v6.0 (build 136 and above) support automatic installation of the license server in the server. It installs the server as a service in the server computer and have more reliable and flexible way of communication with the workstations.
2. The License server must be running and have enough licenses installed to accommodate requests from the workstations.
3. The workstation ATEasy version must be equal or smaller than the license installed in the license server. If the workstation have an ATEasy 4.x and the server license is for ATEasy 4.x and above it will work. For example You can not have 7.0 client and a 4.0 license.
4. ATEasy workstations must have a direct and a reliable connection to the license server at all time. Same IP subnet is recommended for both server and workstation.

Cannot Call an ATEasy Program Procedure from a Driver or a System - Published on 6/20/2000

6/20/2000

Solution:

Calling a program procedure from a driver or a system is prohibited by design. Drivers or systems should be designed so that they are independent the active program's implementation, which can be changed when the application is running.

Program events, however, can be called by a driver or system using, for example, Program.OnInit().

The following procedure provides a workaround using procedure variable:

1.   Program pass in the procedure to a procedure variable stored in a driver or a system module.
2.   The driver or system can now call the program procedure using the procedure variable.

The following procedure provides a workaround using interrupts:

1.   Program installs an interrupt
2.   When a driver needs to call the program procedure, it sets the interrupt
3.   The program interrupt handler can then call a driver function to retrieve the parameters, or can use driver public variables to pass parameters

Modifying ATEasy Code During Debugging - Published on 5/31/2000

5/31/2000

Solution:

ATEasy Code that was already parsed will not re-parsed to include the new code changes in the code editor. Code that was not yet parsed by the ATEasy's Just In Time compiler is parsed when called and the latest code changes will take effect.

When the application is started, ATEasy first compiles the application module events and the procedures and commands referenced by these events. When a program is run ateasy first compile its events. Tasks tests are compiled before they are about to be executed (one task at a time). When a DoIt! is executed only the highlighted code and the referenced procedures and commands are compiled.

Since module events are always parsed when the application is started, code changes in module events will only take effect when the application is started but not during debugging.

Removing ATEasy License from a Machine - Published on 5/31/2000

5/31/2000

Solution:

Use the following procedure to remove an ATEasy license from a machine:

1.   Open the ATEasy About dialog box from the Help menu.

2.   Press Ctrl + Alt + Shift + K. A confirmation dialog box is displayed.

3.   Click Yes.

4.   Write down the confirmation code and send to customer support for verification. A temporary file containing this information is also generated in the temp directory. It is recommended to take a screen capture and send to Geotest for approval the confirmation code to avoid mistakes while copying the confirmation code from the screen.

Reasons why ATEasy Save Command Fails - Published on 5/19/2000

5/19/2000

Solution:

A Save Document operation may fail under any one of the following conditions:

The file's security permissions or attributes are set to Read Only

Another application or instance of ATEasy is using the file

A user on another machine is accessing the file

ATEasy Form.Visible, and .WindowState Values During OnLoad Event - Published on 3/28/2000

3/28/2000

Solution:

During the form loading the properties have the following values:,

Form.Visible = False
Form.WindowState = Normal

After the OnLoad is return these properties are restored as set in design mode.

This behavior is similar to Microsoft Visual Basic's forms behavior.

ATEasy Application Module Events Sequence - Published on 3/30/1999

3/30/1999

Solution:

The following list represents the sequence in which ATEasy application module events execute:

system: OnInit
drivers: OnInit (from start to end)
system: OnInitSystem
system: OnInitProgram
drivers: OnInitProgram
program: OnInit
system: OnInitTask
drivers: OnInitTask
program: OnInitTask
system: OnInitTest
drivers: OnInitTest
program:OnInitTest
program:OnEndTest
drivers: OnEndTest
system: OnEndTest
program:OnEndTask
drivers: OnEndTask
system: OnEndTask
program:OnEnd
drivers:OnEndProgram
system:OnEndProgram
system: OnEndSystem
drivers: OnEnd
system: OnEnd

Note drivers are called : for InitXXX from top to bottom for EndXXX from bottom to start)

Abort Sequence:
system: OnAbort
program: OnAbort
drivers: OnAbort
system: OnAbort

Reset sequence: first call abort sequence if running that execute reset procedure than zero variables, then:
program: OnReset
drivers: OnReset
system: OnReset

Error sequence:
source module: OnError
program: OnError
drivers: OnError
system: OnError

See Also: ATEasy ModuleEvents.prj located in the ATEasy examples folder.