SRS Labs SR510 - Manual (Page 25)

21
Trouble-Shooting Interface
Problems
If you are having difficulty getting your computer to
communicate with the SR510 look to the sections
on the RS232 and GPIB interfaces for some tips
specific to your particular interface.
An ASCII terminal is a valuable aid for debugging
interface problems. You can use it to:
1) become familiar with the SR510's command
structure,
2) see GPIB bus transactions by using the GPIB
echo mode,
3) eavesdrop on transactions when using the
RS232 interface,
4) substitute a human for the SR510 by using a
null modem cable ( to make the DTE a DCE )
and attaching the terminal to the port to which
you would normally have connected the
SR510. This allows you to test your program's
responses to inputs which you provide from
the terminal.
Common Hardware Problems include:
1) The RS232 or GPIB cables are not properly
attached.
2) The configuration switches for the RS232
characteristics or GPIB address are not set
correctly (Make sure the RS232 echo is off
when using the RS232 interface with a
computer. The GPIB with RS232 echo mode
should be off when not debugging the GPIB
interface.)
3) Your computer requires an RS232 control line
to be asserted, but your cable does not pass it
between the SR510 and the computer, or,
your computer is not asserting the DTR line on
the RS232.
Common Software Problems include:
1) You have sent the wrong command to ask for
data from the SR510. Your program will wait
forever for a response which is not going to
come. This may not be your fault; we have
seen Microsoft's Interpreted Basic on the IBM
PC occasionally send a curly bracket (ASCII
253) when it was supposed to have sent a
carriage return (ASCII 13).
2) Your computer's baud rate has been changed
and no longer matches the SR510's baud rate.
3) The initial command sent to the SR510 was
invalid due to a garbage character left in the
command queue from power-up, or, the first
character in you computer's UART is garbage,
also due to power-up. It is good practice to
send a few carriage returns to the SR510
when your program begins, and have your
program clear-out its UART at the start of your
program.
4) The SR510 is not sending the correct 'end-of-
record' marker for your computer. For
example, it appears that Microsoft's Rev 3.2
FORTRAN on the IBM PC under DOS 2.1
requires two carriage returns for an end-of-
record marker. The J command can be used
to set the SR510 end-of-record marker to 2
carriage returns. [The end-of-record marker is
that sequence which indicates that the
response is complete. From the keyboard, a
single carriage return is the end-of-record
marker.]
5) Answers are coming back from the SR510 too
fast, overwriting the end-of-record markers,
and causing the computer to hang waiting for
a complete response. In this case, the W
command can be used to slow down the
response time of the SR510 preventing
overwriting.
6) Answers are coming back from the SR510 too
slowly due to the W6 default setting for the
character interval time. Use the W command
to speed up the transmission from the SR510.
This can cause problems for the GPIB
interface if the echo mode is on (switch 6 of
SW21).
The SR510 with the RS232 Interface
The RS232 is a popular serial interface standard
for bit serial communication. Despite the
existence of the standard there are many
permutations of control lines, baud rates, and data
formats. If you do not have a lot of experience
interfacing RS232 equipment you should read
Appendix B for a description of the RS232 and
interfacing tips.