Service Manuals, User Guides, Schematic Diagrams or docs for : Anritsu regDriver.aspx
<< Back | HomeMost service manuals and schematics are PDF files, so You will need Adobre Acrobat Reader to view : Acrobat Download Some of the files are DjVu format. Readers and resources available here : DjVu Resources
For the compressed files, most common are zip and rar. Please, extract files with Your favorite compression software ( WinZip, WinRAR ... ) before viewing. If a document has multiple parts, You should download all, before extracting.
Good luck. Repair on Your own risk. Make sure You know what You are doing.
Image preview - the first page of the document
>> Download regDriver.aspx documenatation <<
Text preview - extract from the document
Communicating with Anritsu's
IEEE-488.2 Non-Compliant Instruments
Application Note
IEEE - 488.2 Non-Compliance
Introduction
The purpose of this application note is to recognize the difficulties associated with remotely
controlling some of Anritsu's instruments via the GPIB bus. This note will define the exact cause
of the difficulties and then describe a way to reliably communicate with these troublesome models.
Problem Statement
GPIB Bus Command Termination
Most Anritsu instruments can be remotely One method of signaling the end of a
controlled by a computer using the GPIB bus. command is to add one additional special
The GPIB bus has been a mainstay in the Test character, known as the EOS (End of
& Measurement world since 1965 and was Statement) character. The most common EOS
standardized by publication of the IEEE-488 is "new line", otherwise known as "line feed"
specification in 1975. There have been two or ASCII 0x0A. The receiving instrument can
major enhancements to this standard, with the simply continue to accept bytes until it receives
latest being IEEE-488.2 in 1987. the designated EOS character, and then act on
all of the preceding bytes. The EOS technique
The GPIB bus is used to send a series of is the easiest to implement by both the
8-bit bytes between instruments or between transmitting and receiving devices, but it is
a computer and an instrument. Most often the slightly inefficient because an extra character
bytes transmitted are standard ASCII letters must be transmitted with each command. The
and numbers. For example, if a computer wants EOS technique can also become a problem if
to set the frequency in a signal generator to the data to be passed over the GPIB bus
12345 Hz, the computer might send the includes the EOS byte. For example, reading a
command "FREQ 12345". Upon receipt of this long series of binary bytes from an A-to-D
command, the signal generator will immediately converter may eventually hit upon all possible
switch to the new 12345 frequency. That binary values, including the special EOS value.
sounds simple enough, but how did the This would cause the transmission to be
instrument know when it had received the prematurely terminated.
entire command? Why didn't it switch to a new
frequency of 123 after receiving the characters The alternative to using a special termination
"FREQ 123"? How did it know to wait until the character is to use a termination signal outside
"5" was received? This raises the whole issue the normal path of the data bytes. The GPIB
of command termination on the GPIB bus. bus is defined as 24 parallel lines, of which 8
lines carry the data bytes. One of the remaining
16 lines is the EOI (End or Identify) line.
Non-Compliance
The EOI line is always in one of two states; The fundamental problem that people have
asserted (ground) or unasserted (+5 volts). in controlling a few Anritsu instruments arises
Normally EOI is unasserted. However, a GPIB from the fact that those instruments do not
transmitter may elect to signal the end of a fully comply with the IEEE-488.2 standard.
command string by asserting the EOI line at In particular, the instruments ignore the EOI
the same time as it is transmitting the last byte line. Consequently, they are unable to receive
of the command. The EOI termination method a command terminated using method (2),
is more difficult for the sender and receiver the most commonly used method. Such
because 9 lines must be controlled or monitored non-compliant instruments are, however, able
(8 data lines plus EOI). By not sending the to reliably receive commands using methods
EOS character, the transmissions are slightly (1) and (3) because in both cases a line feed
faster and there are no concerns about the is transmitted.
data bytes matching a special EOS value.
A typical user will connect their computer to
The IEEE-488.2 standard mandates that an Anritsu instrument along with maybe a few
GPIB commands must be terminated in one other instruments, start up a GPIB utility such
of three ways: as National Instruments' MAX (Measurement
and Automation Explorer), and attempt to
1. Line feed as the EOS character, with no EOI.
communicate with the instruments. Most often
2. EOI during the last command character everything works exactly as expected.
and no line feed. Unfortunately, a few Anritsu instruments will
not work as expected. The utility will recognize
3. Both line feed and EOI, meaning EOI is
that the instrument is on the bus at a particular
asserted during the line feed.
address and the instrument will go into Remote
mode and accept characters. But the
The IEEE-488.2 standard clearly states that instrument will never execute the command.
a compliant device that is receiving commands
from the GPIB bus must be able to accept
A non-compliant instrument will properly
commands no matter which of the three
receive and store away every character of the
termination methods are used. Similarly, a
command and will continue to do so until it
compliant device transmitting commands on
receives the terminating line feed that it is
the GPIB bus must use one of these three
expecting. The transmitter, on the other hand,
termination methods and any one of the
sends all the characters, asserting EOI on the
three methods is equally acceptable.
last character, but because EOI was ignored
by the non-compliant instrument, the instrument
A customer desiring to control one of our ends up waiting forever for a line feed and the
instruments via the GPIB bus can use any one customer ends up frustrated.
of many different programming languages or
manual utilities. These tools allow the customer
The typical user of our instruments
to send and receive GPIB commands to a
understands the GPIB bus enough to know
device that is presumably compliant with the
that ASCII characters are transmitted back
IEEE-488.2 standard. Most, if not all, of these
and forth, but they often don't understand the
tools default to use of termination method (2)
concept of termination methods. Even if the
because it is the most efficient and eliminates
user does understand termination methods, the
potential data conflicts. Some, but not all, of the
Remote Control Manuals for the few non-
tools can be customized to allow the use of
compliant instruments still may not be helpful.
termination methods (1) and (3).
The manual for every Anritsu instrument designed in the past decade will claim that it is fully
compliant with the IEEE-488.2 standard and in most cases, that is correct. Some non-compliant
instruments will claim they are fully compliant with IEEE-488.2, but a few pages deeper in the
manual will describe how the instrument really only accepts termination methods (1) and (3).
Some non-compliant instruments will claim they are fully compliant with IEEE-488.2 and proceed
to describe how all three termination methods are accepted, but actual use of the instrument shows
that method (2) is not accepted.
The following are a few instruments currently known to be non-compliant: MF9619, MP1555,
MP1763, MP1764, MN63, and the MP1570.
The natural question of, "WHY are these instruments non-compliant?" is beyond the scope of
this paper and would be better addressed to the Anritsu divisions responsible for designing
the instruments.
Solution
While frustrating at first, these few non-compliant instruments are perfectly reliable and will
flawlessly receive, execute, and respond to GPIB commands as long as the commands are
terminated with a line feed. The manner in which you append the line feed depends on the tool
you are using for communication.
NI-488.2 Communicator
National Instruments is the largest manufacturer of GPIB cards in the US. Every card comes with
a software utility called MAX (Measurement & Automation Explorer) as shown in Figure 1.
(Figure 1)
(Figure 2)
(Figure 3)
VISAic
The upper left corner of MAX has a button VISA (Virtual Instrumentation Systems
labeled "Communicate with Instrument". Architecture) is a driver software architecture
When this button is clicked, the "NI-488.2 developed by National Instruments to unify
Communicator" application pops up as shown instrumentation software. VISAic (VISA
in Figure 2. This is the utility our customers Interactive Control) is a predecessor to
most commonly use to manually control our NI-488.2 Communicator and can be invoked
instruments. For any device that fully complies from MAX as shown in Figure 3.
with IEEE-488.2, this is a very easy utility to
send and receive GPIB commands. The first screen to appear when VISAic is
invoked will be similar to Figure 4. VISAic
The termination method employed by NI-488.2 automatically scans your entire computer for all
Communicator is EOI-only, method (2), thus forms of I/O, typically finding a couple RS-232
Communicator will not communicate with our ports, a printer port, and any instruments that
few non-compliant instruments. Furthermore, may be connected to your GPIB bus. In the
there is no way to force Communicator to send following example, one GPIB device is found
a line feed. and that device has an address of 13.
(In January 2001, National Instruments
acknowledged that this was a bug and
promised that some later version of
Communicator would allow line feeds.)
Fortunately, MAX includes another GPIB
tool which can send line feeds.
(Figure 4)
(Figure 5)
(Figure 6)
To communicate with a particular device, By setting the VI_ATTR_TERMCHAR_EN
such as the one shown in Figure 4 with a attribute to true, you are enabling the
GPIB address of 13, the user double-clicks the termination of character reception when a
"GPIB1::13::INSTR" line. After doing so, the particular termination character is received.
screen as shown in Figure 5 appears.
One other attribute, VI_ATTR_TERMCHAR,
The blue "Template" tab exposes all of defines the EOS character, but since it defaults
the attributes of the GPIB interface, only to the desired line feed (0x0A), it need not
one of which must be changed to deal with be changed.
Anritsu's few non-compliant instruments. The
viSetAttribute tab contains a pull-down list of After the attributes are properly set, click on the
Attributes that can be selected, including the blue "Basic I/O" tab, and then select the viWrite
VI_ATTR_TERMCHAR_EN attribute. This tab. The VISAic screen will appear as Figure 6.
attribute defaults to VI_FALSE and must be
changed to VI_TRUE. In the input text field named Buffer, type in
the command you wish to transmit to the
Our non-compliant instruments are equally instrument. A very common command to use
non-compliant whether transmitting or receiving is "*IDN?" which is defined in the IEEE-488.2
on the GPIB bus. The instruments ignore the standard as an identification request. When the
EOI when receiving a command, thus the instrument receives this command, it should
computer must append the line feed termination respond with a character string identifying the
character. Similarly, when the instrument is instrument's manufacturer and model number.
responding to a query, the instrument does not The screenshot above shows the crucial
assert EOI on the last character and instead command termination character.
appends a new line character (sometimes a
carriage return character precedes the Following the "*IDN?" characters are the two
terminating line feed). In its default mode, characters "\n". Veteran C++ programmers will
VISAic presumes the instrument will be recognize these two characters, backslash
ending its transmissions with EOI. followed by lower case "n", as meaning new line.
(Figure 7)
(Figure 8)
When VISAic transmits the characters entered
(Figure 9)
into the Buffer field, it interprets the two "\n"
characters as a single new line (0x0A)
character. (C++ and VISAic also interpret "\t" LabVIEW
as a tab character and "\r" as a carriage return
When sending commands to a non-compliant
character.) After entering the desired command
instrument using the LabVIEW language,
and new line into Buffer, the string is transmitted
the line feed character is appended to the
to the instrument by clicking on the Execute
command string as "\n" as shown in the Figure
button. The screenshot shown previously was
8 graphic.
saved immediately after clicking on Execute
and the Return Count field shows the number
of characters transmitted. Note that 6, not 7, LabVIEW string constants default to "Normal
characters were transmitted, indicating that the Display" mode in which the "\n" pair would be
"\n" pair was indeed transmitted as a single new transmitted as two characters.
line character.
If you right-click on the string constant,
To read the response from the instrument, as shown in Figure 9, a pop-up menu will
click on the viRead tab and then click the allow you to change the string from "Normal
Execute button. The screen will appear as Display" to "\' Codes Display" in which the
Figure 7 with the identification string from "\n" pair is interpreted as the single desired
the connected instrument. new line character.
Note that the string received from the instrument Summary
is shown to have a "\n" (new line) as the
final character. The difficulties communicating with a few
non-compliant Anritsu instruments can very
easily be resolved by simply appending a new
line character to every command and by
allowing responses from the instrument to be
terminated by a new line. Once these two rules
are understood and followed, the non-compliant
instruments are just as reliable and
communicative as our compliant instruments.
ANRITSU COMPANY
1155 East Collins Boulevard
Richardson, TX 75081
http://www.us.anritsu.com
SALES & SUPPORT
UNITED STATES
Tel: 1-800-ANRITSU
Fax: 972-671-1877
CANADA
Tel: 1-800-ANRITSU
Fax: 613-828-5400
SOUTH AMERICA
Tel: 55-21-527-6922
Fax: 55-21-537-1456
JAPAN
Tel: 81-3-3446-1111
Fax: 81-3-3442-0235
ASIA-PACIFIC
Tel: 65-282-2400
Fax: 65-282-2533
EUROPE
Tel: 44-(0)-1582-433433
Fax: 44-(0)-1582-731303
Copyright ◦ Jabse Service Manual Search 2024 ◦ Jabse Pravopis ◦ onTap.bg ◦ Other service manual resources online : Fixya ◦ eServiceinfo