MERLIN 5500/3300 DIAGNOSTIC FACILITIES ...................................................................................

1 INTRODUCTION ............................................................................................................................... 2

2 MERLIN AND 5500/3300 DIAGNOSTICS ...................................................................................... 2

2.1 COMMAND STRUCTURE FOR TESTER, COMMANDN.OUT AND SERVICE TERMINAL ...................... 3
2.2 TESTER ................................................................................................................................ 5
2.2.1 Downloading Commands........................................................................................................ 5
2.2.2 Loop Back Test........................................................................................................................ 7
2.3 SPYREADER.EXE ................................................................................................................... 8
2.4 COMMAND1.OUT AND COMMAND2.OUT ROLLING LOG FILES FOR DEBUGGING ........................... 9
2.5 COMMAND OUTPUT VIA CONTROLLER SERVICE PORT ........................................................... 10
2.6 DEBUG.OUT ........................................................................................................................ 11
2.7 STATUS LOG ....................................................................................................................... 12
2.8 LED INDICATOR ON CONTROLLER AND FIRMWARE SELFTEST ................................................. 13
2.9 SELF TEST FIRMWARE FROM MERLIN .................................................................................... 14
Merlin 5500/3300 Diagnostic Facilities

1 Introduction
When the Merlin software is used with 5500 or 3300 electronics there are a number of
features that can be used by manufacturing and field service. It is the purpose of this
document to outline these facilities and if more information is available, to indicate where
that can be obtained.

2 Merlin and 5500/3300 Diagnostics

Command1.out
Merlin Console 5500/3300 Diagnostic
&
Statuslog
Capabilities
Command2.out
Merlin with Merlin
core
.
Debug.out

Digilink
Tester card Looptest.exe
PC

Self-test 5500
EM FRAME
Firmware Controller Frame/controller
cable

Diagnostic
LED Service HANDSET
port Frame
display
Controller

Terminal
running
Hyperlink
Merlin and the 5500/3300 Controller supply several features that allow the capture and
diagnosis of communications problems.
Tester.exe
Rolling command logging files command1.out and command2.out
Service terminal on the back of the controller
Looptest.exe
Debug.out file
Status log
LED indicator display on the controller.
Self test firmware

The first four of these generate output of the command sent to the controller and the response of
the controller to the command. The data captured is also formatted so that it can be read through
Spyreader.exe. This program can translate the commands according to the controller spec and
produce a detailed breakdown of each command and the accompanying response.

The next two are log files, the first, indicating exceptions in communication between Merlin and
the controller and the second, any changes in frame status.

The last three features indicate the status of the firmware and communication to Merlin.

2.1 Command Structure for Tester, Commandn.out and Service terminal

The format of the command is the same for the first three debugging tools. The following is a
description of the command structure taken from the controller specification:
Each command recognized by the Merlin Controller has the following structure:
Command Number, Query/Status, Number of Parameters, Parameters
The controller echoes all commands back to the low speed Digilink after command completion.
Elements of the command may be modified before they are returned. These modifications are
described below. There are two basic numeric formats used for all command elements:
Integer - 32 Bit 2's complement Binary Number

Float - IEEE compatible single precision floating point format.

Any deviations from these formats will be defined explicitly in the command description. The
command structure consists of the following:
Command Number - (Integer) specifies the function to be performed. These functions will be
described in the following sections. Some commands have a variable number of arguments.
Number of Parameters - (Integer) specifies the number of parameters in the command in 32
bit words.

Query/Status - (Integer) When the command is received by the controller this word contains a
Boolean to specify whether the command function is a Query of the current parameters or a
command which modifies the parameters. FALSE (0) specifies command mode, TRUE (non-
0) specifies query mode. When the controller echoes the command, this word specifies the
execution/completion status of the command. The following values may be returned.
Response status
Return value Description
 0 No Errors
1 Parameter Out of Bounds - Modified
2 Parameter Out of Bounds - Command Ignored
3 Unimplemented Command - Ignored
4 Format Error - Command Ignored
5 Unrecognized Command - Ignored
6 Command Header Format Error - Command
7 Mismatch in Number of Parameters
8 State Sequence Error
9 No Query Allowed
10 Query Only Allowed
11 Error in number of parameters.
12 Required Hardware is not installed
13 No Transducer Connected
14 Required Resources are Busy

If a return value is >1, the command has not been executed. If the return value = 1, then one of
the parameters was out of bounds and was limited to the maximum or minimum value. This
value is returned in the command echo in place of the parameter originally sent.
Parameters - 0 or more 32 bit words. They are command dependent and are described in detail
in the controller specification under each command.
Example: The Frame Status Query command and response would appear in this manner
according to these guidelines
Command (0) or Query (1)

Number of Parameters

Command: 70F 1 1 0

Response: 70F 0 1 4680

Heading included for

Command Number
output file. Not part Response Status Parameters Status of frame is
of actual command returned in response for this
function
FRAME STATUS QUERY (FUNCTION:70FH)
Bit Mapped
Bit 0: Handset Tension Jog Key Active
Bit 1: Handset Compression Jog Key Active
Bit 2: 1st Level Tensile Travel Limit Active
Bit 3: 1st Level Compressive Travel Limit Active
Bit 4: 2nd Level Tensile Travel Limit Active
Bit 5: 2nd Level Compressive Travel Limit Active
Bit 6: Frame Relay Power OK
Bit 7: Emergency Stop OK (Not Active)
Bit 8: Drive Enabled
Bit 9: Power Amp OK
Bit 10: Motor Temperature OK
Bit 11: Screw Encoder Installed
Bit 12: Top Grip Closed
Bit 13: Bottom Grip Closed
Bit 14: Interlock OK
Bit 15: PIP Closed
Bit 16: Close Grip Request
Bit 17: Digilink Watchdog
Bit 18: Control Panel Watchdog

NOTES: Command Implemented

This same command will be used throughout this document to demonstrate each of the
debugging tools.

2.2 Tester

Tester.exe is a hardware diagnostic program that is automatically installed with Merlin

5500/3300 and allows you to determine if the Digilink is working correctly. The controller
specification provides for many commands that query the frame status or enable and disable
certain features. Tester.exe is a simple way to download an individual command to verify the
controller is receiving the correct information.
It directly communicates with the controller without running Merlin by sending commands
through the Digilink and receiving a response back from the commands.
It is capable of downloading single commands or a file of commands to the controller. The
response is returned in hexadecimal format. Based on what the response is you can tell if the
communication through the Digilink has occurred successfully.
To do this you need to run tester.exe utility. This can be found in Instron/Service.
The computer must be connected to the frame and the firmware downloaded.
The commands are taken from the 5500/3300 Controller Specification, which provides valid
Digilink commands. All commands for tester.exe must be structured according to the
Controller Specification. In other words, the Controller spec lists the parameters the
command must contain under the command description.
The purpose of this program is to allow you to determine if problems occurring are a result of
a problem with how the Digilink is communicating.

2.2.1 Downloading Commands

One example would be using the Frame Status Query described earlier to verify the working state
of the frame.

1. Make sure the controller is on and correctly connected to the frame.

2. Through the Windows Explorer locate the file called Tester.exe in the Instron\Service
directory and launch it by double clicking on it. The following screen will appear (Fig.1):

Fig. 1
2.1. Note: Tester will likely give you an warning that it cannot find a file called startup.txt.
This is normal, simply click OK.
3. Under the Controller Menu Item, select Send Command.
4. This will bring up a dialog titled Send Digilink Command. You have a choice of sending an
individual command or a file containing several commands. Enter the command for Frame
Status Query and click Send Command.
5. The controller response will appear as depicted in Fig. 2 (Note: Hexadecimal notation 0x
must be used for the command number):

Fig. 2
6. Now the operator has two options for translation of the response. The first the manual
method where the operator would take the parameter value returned in the response and
manually break it down according to the controller command specification. This approach is
tiresome and somewhat tricky.

2.2.2 Loop Back Test

Tester.exe is also capable of running a Loop Back Test to test the Digilink communication. This
requires a special loopback plug. The description of this test can be accessed at
http://kn.instron.com/service/software/em/loopback.htm
The loopback test enables the computer to send signals out through the Digilink card and then
read the signals back through the loopback plug. This should prove that the Digilink interface card
is able to communicate.

The parts to make up the loopback plug are:

18-5-263 15 way connector

18-5-257 Backshell

The loopback plug is made using a 15 way D-type socket with the following pins linked:

2 to 3; 5 to 6; 9 to 10; and 12 to 13

The loopback function is accessed through the Controller drop down menu.
2.3 Spyreader.exe

Spyreader is a utility program written at SATEC designed to take the commands and responses
issued from the service port on the back of the 5500/3300 and translate them into a more
readable format according to the controller specification. Spyreader can be found in the
Instron\Service directory.
Spyreader uses the controller specification to interpret the commands and their responses. It
breaks down each command parameter according to the structure specified in the spec. The
service port formats its output in a way that can be saved to a file via HyperTerminal. Spyreader
takes this file and breaks each command down. The code for the command logging adopted this
format to utilize the translation capability. That way, no one needs to go through the spec, find the
command, and decipher the parameters. Spyreader will do it for you.

In order to utilize Spyreader,

1) A text file must be created given the command and response from the controller.
2) Open Notepad or other text editor and enter the command preceded by Cmd: on
the first line and the response preceded by Resp:. Do not include the hexidecimal
notation 0x prefaced to the command number or the response.
3) The file will look like this:

Cmd: 70f 1 1 0
Resp: 70f 0 1 4680

4) Save the file to disk.

5) Find the folder containing Spyreader.exe and its accompanying files in Windows
Explorer. Double click on Spyreader.exe to open it.
6) From the File menu, select Open and Translate Spy File, selecting the file you just
created (Fig.3).

Fig.3
 7) This will open the file and translate the contents according to the controller
specifications.

For this example, the output will look as shown in Figure 4:

2.4 Command1.out and Command2.out rolling log files for debugging

The command logging files command1.out and command2.out are continuously generated by
Merlin while the software is running. These two files capture the most recent 100 to 200
commands to preserve a snapshot of the controller processing status around the time of a failure.
Each individual command and corresponding response is written to command2.out. When the
number of commands reaches 100, command2.out is renamed command1.out and a new
command2.out is generated starting with the next command. This allows for a reasonable window
of commands to investigate without generating a large text file. Command1.out is deleted and
command2.out renamed to command1.out after every one hundred commands limiting the size of
each file to 5Kb.

Merlin now creates two log files, command1.out and command2.out, that maintain a rolling
account of the last 200 commands and their responses.
These files are overwritten each time Merlin restarts. Any pre-existing data in them is cleared.
 If a crash occurs and the commands need to be examined, these files must be copied from
the system or renamed before Merlin is restarted. Otherwise, the information will be lost.
After each test the files Instron\com\comand1.out and command2.out may be opened and
viewed with Notepad. The files should contain up to 100 command and response lines to and
from the 5500/3300 controller.
Spyreader is used for reading sections of the commandn.out files. The command1.out and
command2.out files conform to the necessary format for Spyreader translation. Both of these
files can be opened exactly like the file given in the example for Tester.exe.

A sample screen of command1.out viewed through spyreader

2.5 Command Output via Controller Service Port

It is possible to monitor the commands from the controller via the service port, although the
addition of the command logging may replace its use in many cases. The main benefits of the
service port is lack of a limiting factor in regards to the number of commands captured and a
method of getting the commands directly from the controller rather than relying on Digilink. It is
also the only manner in which the commands can be monitored on older versions of Merlin.
However, the drawbacks include the need for a null modem cable and the use of a port
monitoring software such as HyperTerminal.
First, a null modem cable is needed to connect the service port to a serial port on the
back of the computer (this could be the computer running Merlin or a second computer being
used as a dumb terminal). Next, the port monitoring software needs to be configured to the
following standards on the selected port and then save the port configuration:

9600 Baud
8 data bits
 Even parity
1stop bit

Finally, the win.ini file of the Merlin computer needs one of the following lines added under a
section called [Instron]:

ControllerDiagnosticsReports=0x80 0 2 1 1 Output commands only

ControllerDiagnosticsReports=0x80 0 2 1 2 Output responses only
ControllerDiagnosticsReports=0x80 0 3 1 1 2 Output both

Save the Win.ini and restart the computer. Bring up the Hyperterminal and select the
configuration. Now start Merlin and watch the port software. You should see the commands and
responses appearing in much the same fashion as described for command logging.

2.6 Debug.out

Debug.out is a diagnostics file generated at the point where commands are sent to the
5500/3300 controller by Merlin. Debug.out used by the developers. Most of the output to it is
only in debug mode and is only available to developers. The mutex and bad commands are
the only things left that actually output to the file in the release code.
The file is created after the first communication discrepancy and information is outputted to
this file any time there is a discrepancy in communication. This is done by adding to the file
echos of a command that fails or is outside of acceptable parameters.
Examples of such discrepancies are
1) retries of commands that failed on the initial attempt
2) commands with bad parameters
3) loss of the Mutex.
This file is only created and appended, never overwritten or deleted unless done manually.
It can be accessed through Instron/com/debug.out. It has no size limitation.
The commands being logged are issued from Merlin. The debug.out file only deals with
those commands. It is not possible for the file to deal with commands originating from the
controller.
This file is an ASCII output file. To view its contents, simply open the file in Wordpad. You will
see a series of text lines similiar to the following:

Example:

Fri Mar 16 13:50:28 2001 Mismatch Error

Fri Mar 16 14:15:27 2001 Mismatch Error
Fri Mar 16 14:19:44 2001 Write Mutex Timeout!
Fri Mar 16 14:19:47 2001 Write Mutex Timeout!
Fri Mar 16 14:19:50 2001 Write Mutex Timeout!
Fri Mar 16 14:19:52 2001 Write Mutex Timeout!
Fri Mar 16 14:19:52 2001
myEcho[0]: 768
buff[0]: 768
myEcho[1]: 0
buff[1]: 0
myEcho[2]: 1
buff[2]: 1
myEcho[3]: 7
buff[3]: 7
echoed[0]: 768
echoed[1]: 0
echoed[2]: 1
echoed[3]: 7
Fri Mar 16 14:19:52 2001 inControllerIO = TRUE (enter)
Fri Mar 16 14:35:01 2001 Mismatch Error
Mon Mar 19 08:02:39 2001 Write Mutex Timeout!
Mon Mar 19 08:03:16 2001 Mismatch Error
Mon Mar 19 08:15:04 2001 Mismatch Error

Looking at these statements, you can see several things are logged. Three errors are evident
here.

The first is the Mismatch Error. A command was passed to the controller and the echo returned
did not match. The software would then attempt to reissue the command.

The Write Mutex Timeout error occurs if a mutex cannot be grabbed to allow for threadsafe
communication. The mutex is used to isolate the thread and prevent other applications from
interrupting the transmission of commands. The mutex is a shared memory location that signals
whether a block of shared memory is currently locked by something else. In Merlin, the mutex
protects the memory used for the transmission and receiving of data. The mutex timeout occurs if
Merlin tries to transmit a command at the same time Digiserv is processing information from the
controller. It forces each application to take turns using the shared memory location and prevents
another process from grabbing it until the original completes its operation.

The final error beginning with myEcho is the output of a failed command and its echo. The
parameters of the command (represented by buff[] ) are displayed one per line as well as the
corresponding portion of the echoed command. The echo comparison is a sanity check. If the
controller returns an echo that does not match the command, then something in the command is
corrupted or incorrect. Possible causes are non-normalized parameters (this would be a code
issue), possible corrupted data bits, or parameters that are outside the appropriate range.

2.7 Status log

Accessible by the Load frame icon or directory choice.
A record of the 100 most recent activities that the occurred with the frame on that version of
Merlin. This is stored in the file instron/com/status.log.
Includes frame errors that lead to disabling, calibrations, balancing, crosshead movement.
2.8 LED indicator on controller and firmware selftest

Each of the numbers from 8-0 indicate specific routines being checked out with the firmware
of the controller.
After powering on the system, an initial self test is run. After the test if the LED display does
not go to 2 or less than a fault has occurred on the DSP board.
After this initial self test, the computer then downloads a more detailed self test package. This
self test firmware identifies what boards are in the 5500/3300 card cage and tests each one.
Information on the LED self test and the firmware self test can be found on the Knowledge
net at http://kn.instron.com/service/software/em/5500self.htm

Self Test 7-Segment Test Description

Number indication display
1 8 TI processor register test. Tests internal registers in the processor.
2 7 Boot Prom checksum test. Does a checksum of the prom.
6 CRC test.
3,4,5 Does a checksum of the code loaded into the ram
6 5 Memory test.
4 Miscellaneous DSP processor tests.
Test various functions internal to the DSP processor
7, 8, 9 Address instructions tests (3 tests).
10, 11, 12 Arithmetic instructions tests (3 tests).
13 Timers test.
14 DMA test.
3 Communications tests. Test the iusc communications chip.
15 Iusc register test.Verifies addressing and r/w capability of iusc chip.
16 Iusc oscillator test.
17 Iusc local loopback test.
2 Communications Driver. The controller is communicating with the
 digilink.The DSP is in the communication driver's 'start-up' state, waiting
for a download package.
1 Communication to the computer has been established.
0 The downloading of firmware is occurring.

2.9 Self test firmware from Merlin

Self test firmware is transferred to the memory of the 5500/3300 controller. The self test firmware
identifies the boards in the 5500/3300 card cage and carries out a self test of each.
If any self test fails it will report this back with an error message to the computer. Once this self
test is completed the computer will download the firmware.

When the down loadable self test fails an error code is reported back to the computer and
displayed as an error number on the computer screen. The message will read something like

Error 2914 Controller Selftest Failure

Error Code 26744

This error code can be decoded to work out which board has passed and failed the self test. The
Merlin Diagnostic Error report is in the form of a 5 digit number:

PTTFF

where,

P = program number,

Currently 2=diagnostic program 1=bootprom.

TT = tests run,

In hex, this is the bitmap returned by controller command 080h.

FF = tests failed,

In hex, this is the bitmap returned by controller command 083h

Contains the cumulative self-test results for the boot test and any downloaded self-test
applications for all tests performed. Each bit corresponds to a test result (0=PASS, 1=FAIL).

Bit 0: Boot Test Result

Bit 1: DSP Test Result (Slot 1)

Bit 2: Slot 2 Test Result (Load)

Bit 3: Slot 3 Test Result (Strain 2)

Bit 4: Slot 4 Test Result (Strain 1)

Bit 5: Slot 5 Test Result (Analogue/Digital I/O)

Bit 6: System Test Result

Example:

Error 2914 Controller Selftest Failure

Error Code 26744

PTTFF

02h = Diagnostic Program

67h = (0110 0111) Tests Run: Boot, DSP, Load, Analogue/Digital I/O, System

Bit No. 7654 3210

MSB LSB

44h = (0100 0100) Tests Failed : Load, System

Bit No. 7654 3210

MSB LSB
Once this self test has been completed and all is OK then the computer will then download the
firmware for controlling the machine. Then the rest of the application software is loaded.