Beruflich Dokumente
Kultur Dokumente
1 INTRODUCTION ............................................................................................................................... 2
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.
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.
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
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
This same command will be used throughout this document to demonstrate each of the
debugging tools.
2.2 Tester
One example would be using the Frame Status Query described earlier to verify the working state
of the frame.
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.
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.
Cmd: 70f 1 1 0
Resp: 70f 0 1 4680
Fig.3
7) This will open the file and translate the contents according to the controller
specifications.
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.
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]:
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:
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.
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 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
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,
TT = tests run,
FF = tests failed,
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).
Example:
PTTFF
67h = (0110 0111) Tests Run: Boot, DSP, Load, Analogue/Digital I/O, System
MSB LSB
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.