A Guide to Converting IOtech 488.2 API to MCC 488.2 API
GPIB-488.2 Porting Guide
Project 495
IOtech
25971 Cannon Road
Cleveland, OH 44146-1833
*372219A-01*
372219A-01
(440) 439-4091
Fax: (440) 439-4093
sales@iotech.com
productsupport@iotech.com
www.iotech.com
Contents
CH 1 - Introduction to the GPIB Porting Guide
CH 2 - API Cross-Reference
CH 3 - IOtech to Associated MCC APIs
Overview …… 1-1
Major Conceptual Differences between IOtech and MCC Routines …… 1-2
API Replacement, the Four Levels of Effort …… 1-3
How to Use the Guide …… 1-4
Terms … 1-4
Comparing IOtech GPIB with MCC GPIB 488.2 Commands …… 1-5
Part 1 – IOtech to MCC …… 2-1
Part 2 – MCC to IOtech …… 2-8
For detailed information refer to the GPIB Porting Guide folder at www.iotech.com.
The folder is located on our Tech Manuals Download Page. It includes this porting guide
and the following documentation:
oPersonal488 User's Manual for Windows 95/98/Me/NT/2000
p/n 495-0903 (for IOtech API)
oGPIB-488 Programming Reference Manual
p/n 371930C-01 (for MCC 488.2 commands)
oGPIB-488 Code Examples
GPIB 488.2 Porting Guide978492Contents
Introduction to the GPIB Porting Guide 1
Overview …… 1-1
Major Conceptual Differences between IOtech and MCC Routines …… 1-2
API Replacement, the Four Levels of Effort …… 1-3
How to Use the Guide …… 1-4
Terms … 1-4
Comparing IOtech GPIB with MCC GPIB 488.2 Commands …… 1-5
Overview
This guide is to be used by individuals who need to port from the IOtech API to the MCC 488.2
API. The reason for this is that IOtech 488 devices have reached an End of Life phase and we
therefore recommend replacing the IOtech API with that used by MCC (Measurement
Computing Corporation).
Chapter 2 consists of tables which allow you to look up, either an IOtech or MCC API, and
cross reference it to its associated counterpart. Chapter 3 consists of command syntax and
usage notes.
For each API command a level of effort value icon is provided. These indicate the relative
effort needed to convert an IOtech function to so it can use the MCC API call. We have
identified four levels of effort. These are as follows:
Direct Replacement – The MCC API command is directly related to the
associated IOtech API. The MCC API can be easily substituted for the IOtech
API after the conceptual issues have been addressed.
Minor Modification – Simple modifications to the IOtech code are required
to achieve the same functionality, between the associated MCC and IOtech
command.
Major Modification – Substantial modifications to the IOtech code are
required to achieve the same functionality, between the associated MCC and
IOtech command. Modifications may include data type changes and/or calls
to multiple MCC APIs.
No Equivalent Command – Indicates one of the following two
possibilities.
(a) There is no mechanism to convert to, or to achieve equivalent or similar
functionality, between the IOtech function call and the MCC API. Digital
commands are an example of this category.
(b) Similar functionality can only be achieved by coding efforts, of such
magnitude, that they are beyond the scope of this document.
GPIB 488.2 Porting Guide978492Introduction 1-1
Major Conceptual Differences between IOtech and MCC Routines
Handle-Based vs. Address-Based
Many of the IOtech API calls are handle-based. All devices, when opened successfully via
IOtech API command, are assigned a handle which subsequent calls to the device made
reference to. With the IOtech API it was also possible to assign a name to the device. The
device name could be used to open or close a configured device at a later time; the device name
could also be used to make a duplicate copy (or clone) of a configured device. This functionality
does not exist within the MCC API. The reason lies in the fact that MCC API calls are device address based.
Single vs. Multiple Devices
In general, IOtech API calls tend to deal with an individual device, whereas many MCC API
calls can deal with multiple devices via an address array. The ‘Minor Modification’ section of
this document provides detailed information regarding this difference.
Error Status Returns
IOtech API calls automatically return an error status. MCC API calls do not. With MCC’s
488.2 GPIB system, it is the responsibility of the programmer to evaluate the error status register,
after a function call is made, and then take the appropriate action to address any error.Sample
code, for error status checking, is included in the GPIB 488 Projects folder on our web-site,
under Code Examples.
Digital Control
Another difference between IOtech and MCC API pertains to digital control. A user-accessible
digital port exists on the IOtech Personal 488 GPIB card. Because there is no similar MCC 488
board, none of the digital IOtech API commands have an associated MCC command.
Command Terminations
IOtech API includes functionality that deals specifically with send and receive command
termination. The MCC API includes no such send/receive termination commands; however, for
many of the MCC function calls, termination can be set as a parameter.
1-2 Introduction 978492GPIB 488.2 Porting Guide
API Replacement, the Four Levels of Effort
Direct Replacement
IOtech: lol(Handle)
MCC: Send(Board)
The MCC API command is directly related to the associated IOtech API and
can therefore be easily substituted for the IOtech API. However, conceptual issues
must be dealt with. For example, Handles do not exist within the MCC API;
instead, the address of the controller is passed to the function.
Minor Modification
IOtech: ClearList(Handle, Array of device names)
MCC: DevClearList(Board, Array of device address)
The IOtech device handle [of the GPIB controller] becomes the controller board
address in the MCC call. There is no device name in the MCC API, so an array of
device address is passed to the function call. NOTE: with all address list arrays in
the MCC API, the array terminator ‘NOADDR’ is used to signify the end of the list.
See the MCC GPIB manual for more information.
Major Modification
IOtech: Abort(Handle) MCC: ResetSys(Board, Array of device address)
SendIFC(Board)
Equivalent functionality of the IOtech Abort command is achieved by calling the
MCC ResetSys command with an array of device addresses to be reset and then
calling the MCC SendIFC command.
No Equivalent Command
IOtech: KeepDevice(Handle)
MCC: No Equivalent Command
The MCC API has no concept of Devices and their associated settings as a complete
entity. As such, a device cannot be stored for later use, or duplicated for use with
other similar devices. If this functionality is required, the programmer must
implement it.
GPIB 488.2 Porting Guide978492Introduction 1-3
How to Use the Guide
Before beginning any API conversions, you will need, in addition to this guide, the following:
o Your API code
o IOtech’s Personal488 User’s Manual (495-0903)
o MCC’s GPIB-488 Programming Reference Manual (371930C-01)
Both documents are available, in PDF format, from the IOtech website.
To make the conversions:
1) From your API routine, identify your current IOtech commands; for example,
CheckListener
2) From chapter 2 of this porting guide, find the associated MCC commands; for
example, FindLstn
3) From GPIB-488 Programming Reference Manual, look up the detailed information,
i.e., Syntax, Parameters, Returns, Usage Notes, and Examples.
4) Substitute the IOtech routines with MCC routines.
Terms
The following term definitions were obtained from the MCC document, GPIB-488
Programming Reference Manual, p/n 371930C-01.
GPIB - General Purpose Interface Bus
System controller - The system controller has the unique ability to retrieve active control of
the bus or to enable devices to be remotely programmed. It takes control of the bus by issuing
an IFC (Interface Clear) message for at least 200 µsec. It also can put devices into the remote
state by asserting the REN (Remote Enable) line.
There is always one system controller in a GPIB system. The system controller is designated at
system initialization either through the use of hardware switches or by some type of
configuration software, and is not changed. The system controller can be the same controller as
the one which is the current active controller or an entirely different one. Note that if a
controller is both a system controller and the active controller and it passes control to another
controller, the system controller capability is not passed along with it.
Active controller - The active controller is the controller which has the ability to mediate all
communications which occur over the bus. In other words, the active controller designates
(addresses) which device is to talk and which devices are to listen. The active controller is also
capable of relinquishing its position as active controller and designating another controller to
become the active controller.
Device - A device is any IEEE-488 instrument which is not a system controller or active
controller. It can be idle or act as a talker and/or listener when addressed or unaddressed by the
active controller.
1-4 Introduction 978492GPIB 488.2 Porting Guide
Listener - A listener is any device which is able to receive data when properly addressed. There
can be up to 14 active listeners on the bus concurrently. Some devices can also be a talker or
controller; however, only one of these functions can be performed at a time.
Talker - A talker is a device which can transmit data over the bus when properly addressed.
Only one device can transmit at a time. Some devices can also be a listener or controller;
however, only one of these functions can be performed at a time.
Comparing IOtech GPIB with MCC GPIB 488.2 Commands
Chapter 2 of this guide consists of tables which list commands in alphabetical order. The first
table is for looking up IOtech commands and cross-referencing them to associated MCC GPIB
488.2 commands. For example, when looking up IOtech’s CheckListener we will see that
FindLstn is the associated MCC command.
A second set of tables is for looking up MCC commands and cross-referencing them to
associated IOtech commands.
MCC 488.2 addresses contain two bytes packed into a word. The low byte is the primary
address and the high byte is the secondary address. If secondary addressing is not used, then the
high byte should be zero.
High Byte: Secondary Address (0, or 96-126)
Low Byte: Primary Address: (0-30)
MCC 488.2 routines use a board address as the first argument (typically zero), instead of a
handle.
For both IOtech and MCC commands, this porting guide includes Syntax and Usage Notes. It
also includes an example in C language, for MCC 488.2 routines.
In the following text we will look briefly at IOtech’s CheckListener command and MCC’s
related FindLstn command.
IOtech
CheckListener: INT WINAPI CheckListener(DevHandleT devHandle,
BYTE primary, BYTE secondary);
devHandle refers to either an IEEE 488 hardware interface or an external device.
If devHandle refers to an external device, the CheckListener command acts
on the hardware interface to which the external device is attached.
primary is the primary bus address to check for a Listener (00 to 30)
secondary is the secondary bus address to check for a Listener (00 to 31).
For no secondary address, a -1 must be specified
Bus States
GPIB 488.2 Porting Guide978492Introduction 1-5
: ATN•UNL, LAG, (check for NDAC asserted)
MCC
FindLstn: FindLstn(int board, short addresslist[],
short resultlist[], int limit)
board is an integer which identifies the GPIB board to be used for this operation.
In most applications, this value is 0.
addresslist is an array of GPIB addresses, terminated by the value NOADDR.
limit is an integer which specifies how many address entries can be placed into the resultlist
array. Set to the size of the resultlist array.
resultlist will contain the addresses of all detected listeners.
Usage Notes
CheckListener, no longer to be used, checked for the existence of a device on the IEEE 488
bus at the specified address.
FindListn
finds all listeners on the GPIB. The addresses specified by addresslist are
tested to see if a listening device is present. If a listener is found at a primary address, its
address is placed in resultlist. If no listeners are detected at a primary address, then all
secondary addresses associated with that primary address are tested. If any listeners are
detected, their addresses are placed in resultlist. You can use this routine to determine
how many devices on the network are capable of listening. Once these devices are detected,
they can be identified by their response to identification request messages.
The following would be used to check for listening devices present at GPIB primary addresses
6 and 7, on Board 0.
Example:
short addresslist[3] = {6,7,NOADDR};
short resultlist[4];
FindLstn(0, addresslist, resultlist, 4);
1-6 Introduction 978492GPIB 488.2 Porting Guide
API Cross-Reference 2
Part 1 – IOtech to MCC, page 2-1
Part 2 – MCC to IOtech, page 2-8
IOtech to MCC GPIB 488.2 Cross-Reference
IOtech GPIB
API Reference
1 Abort SendIFC
2 Arm
3 AutoRemote
4 BusAddress
5 CheckListener
Also see:
FindListeners
6 Clear DevClear
ClearList DevClearList
7 Close DevClear
8 ControlLine TestSRQ
9 DigArm;
DigArmSetup;
DigRead;
DigSetup;
DigWrite
MCC GPIB 488.2
Library Routine
ResetSys
NO EQUIVALENT
Manual via
EnableRemote
NO EQUIVALENT
FindLstn
EnableLocal
Limited Functionality)
(
NO EQUIVALENT
Comments
Abort – Causes the Interface Clear (IFC).
Forces all IEEE488 devices to a quiescent state.
Arm – supports acSRQ and acDigMatch
AutoRemote – Enables or disables automatic
assertion of Remote Enable (REN)
BusAddress – Sets the IEEE 488 bus address.
Default fro Driver488 is 21.
CheckListener – Checks for the existence of a
device on the IEEE 488 bus at the specified address.
Clear – Causes the Device Clear (DCL) bus
command to be issued to a specific interface; or
causes a Selected Device Clear (SDC) command to
be issued to an external device.
ClearList – Causes the Selected Device Clear (SDC)
command to be issued to a list of external devices.
Close – waits for I/O to complete; flushes buffers for
the device; invalidates the device handle.
ControlLine - returns the status of the IEEE 488 bus
control lines as an 8-bit unsigned value
These commands do not apply.
10 Disarm
NO EQUIVALENT
Disarm - prevents Driver488 from invoking an event
handler.
EnterX - reads data from the I/O adapter. If an external
device is specified, then Driver488 is addressed to Listen,
and that device is addressed to Talk. If an interface is
specified, then Driver488 must already be configured to
receive data and the external device must be configured to
Talk, either as a result of an immediately preceding EnterX
command or as a result of one of the Send commands.
EnterX terminates reception on either the specified count of
bytes transferred, or the specified or default terminator being
detected. Terminator characters, if any, are stripped from the
received data before the EnterX command returns to the
calling application.
FindListeners - finds all of the devices configured to Listen at
the specified primary address on the IEEE 488 bus.
GetError - user-called after another function returns an error
indication. The device handle sent to the function that
returned the error indication is sent to GetError as its
devHandle parameter. GetError finds the error associated
with that device and returns the error code associated with
that error.
GetErrorList - user-called, after another function identifying a
list of device handles, returns an error indication. The device
handle list sent to the function that returned the error
indication, is sent to GetErrorList. GetErrorList finds the
device that returned the error indication, returning the handle
through errHandle, and returns the error code associated with
that error.
Hello - verifies communication with Driver488; reads software
rev. number.
16 KeepDevice
17 Listen
Also See:
MyListenAddr
NO EQUIVALENT
EnableRemote
SendSetup
KeepDevice - updates existing device; creates a new device
in the Registry. Example use: change device bus address;
make it a permanent change. Unless KeepDevice is used,
all temporary Driver488 devices are forgotten when
Driver488 is closed. To remove the permanent device, use
the RemoveDevice command.
Listen - addresses an external device to Listen.
2-2 API Cross-Reference 986992GPIB 488.2 Porting Guide
IOtech to MCC GPIB 488.2 Cross-Reference
IOtech GPIB
API Reference
MCC GPIB 488.2
Library Routine
Comments
18 Local EnableLocal
LocalList EnableLocal
19 Lol SendLLO
SetRWLS
20 MakeDevice
NO EQUIVALENT
Local - used in System Controller mode, issued to an
interface device; causes Driver488 to unassert the Remote
Enable (REN) line. This causes devices on the bus to return
to manual operation. A Local command addressed to an
external device, places the device in the local mode via the
Go To Local (GTL) bus command.
Like Local, but with list of devices.
Lol - causes Driver488 to issue an IEEE 488 LocalLockout
(LLO). Bus devices that support this command are thereby
inhibited from being controlled manually from their
front panels.
MakeDevice - creates a new temporary Driver488 device
that is an identical copy of an already existing Driver488
external device. The new device is attached to the same I/O
adapter of the existing device and has the same bus
address, terminators, timeouts, and other characteristics.
The newly created device is temporary and is removed
when Driver488 is closed. KeepDevice may be used to
make the device permanent. To change the default values
assigned to the device, it is necessary to call the appropriate
configuration functions such as BusAddress, IOAddress,
and TimeOut.
MakeNewDevice
21 MyListenAddr
Also see:
Listen
22 MyTalkAddr
OnDigEvent;
23
OnDigEventVDM
OnEvent
OnEventVDM
NO EQUIVALENT
EnableRemote
NO EQUIVALENT
NO EQUIVALENT
NO EQUIVALENT
NO EQUIVALENT
MakeNewDevice - similar to MakeDevice, except new
device is based on the parameters specified, instead of
copying an existing device.
MyListenAddr - addresses the interface to Listen.
The MyTalkAddr command addresses the interface to Talk.
Digital commands. No equivalent MCC API commands.
OnEvent - causes a message upon occurrence of an Armed
event. The message will have a type of:
WM_IEEE488EVENT
OnEventVDM - allows a call back to a user-specified function
in an application.
OpenName - opens the specified interface or external device
and returns a device handle for use in accessing that device.
OutputX - sends data to an interface or external device. The
Remote Enable (REN) line is first asserted if Driver488 is the
System Controller and AutoRemote is enabled. Then, if a
device address (with optional secondary address) is
specified, Driver488 is addressed to Talk and the specified
device is addressed to Listen. If no address is specified,
then Driver488 must already be configured to send data,
either as a result of a preceding OutputX command, or as
the result of a Send command. Terminators are
automatically appended to the output data as specified.
PPoll (Parallel Poll) – simultaneously request status
information from many bus devices. If a device requires
service then it responds to a Parallel Poll by asserting one of
the eight IEEE 488 bus data lines (DIO1 through DIO8, with
DIO1 being the least significant). In this manner, up to eight
devices may simultaneously be polled by the controller.
More than one device can share any particular DIO line. In
this case, it is necessary to perform further Serial Polling
(SPoll) to determine which device actually requires service.
PPollConfig - configures the Parallel Poll response of a
specified bus device. Not all devices support Parallel Polling
and, among those that do, not all support the software
control of their Parallel Poll response. Some devices are
configured by internal switches.
PPollDisable PPollUnconfig
PPollDisableList PPollUnconfig
PPollUnconfig PPollUnconfig
PPollDisable - disables the Parallel Poll response of a
selected bus device.
Like PPollDisable, but uses a list for devices.
PPollUnconfig - disables the Parallel Poll response of all bus
devices.
2-4 API Cross-Reference 986992GPIB 488.2 Porting Guide
IOtech to MCC GPIB 488.2 Cross-Reference
IOtech GPIB
API Reference
27 Remote EnableRemote
MCC GPIB 488.2
Library Routine
Comments
Remote - asserts the Remote Enable (REN) bus
management line. If an external device is specified, then
Remote will also address that device to Listen, placing it
in the Remote state.
RemoteList EnableRemote
28 RemoveDevice
NO EQUIVALENT
29 Reset ResetSys
30 SendCmd
SendCmds
Also see:
OutputX
SendData
31 SendData
Also see:
OutputX
SendCmd
SendEoi
Send
SendList
SendDataBytes
RemoteList - like Remote; but uses list.
RemoveDevice - removes the specific temporary [or
permanent Driver488 device] that was created with
MakeDevice [or the startup configuration]. This
command also removes a device that was made
permanent through a KeepDevice command.
Reset - provides a warm start of the interface. Related to
Disarm and Abort.
SendCmd - sends a specified string of bytes with
Attention (ATN) asserted, causing the
data to be interpreted as IEEE 488 command bytes.
SendData - provides byte-by-byte control of data
transfers. Can specify exactly which operations
Driver488 executes.
32 SendEoi
NO EQUIVALENT
SendEoi - provides byte-by-byte control of data transfers.
Can specify exactly which operations Driver488 executes.
Driver488 asserts EOI during the transfer of the final byte.
SPoll - In Active Controller mode, SPoll performs a Serial
Poll of the specified device and responds with a number
from 0 to 255 representing the decimal equivalent of the
eight-bit device response. If rsv (DIO7, decimal value 64) is
set, then that device is signaling that it requires service. The
meanings of the other bits are device-specific.
Serial Polls are normally performed in response to assertion
of the Service Request (SRQ) bus signal by some bus
device.
As with SPoll, but uses list.
34 Status ReadStatusByte
35 Talk
Also see:
MyTalkAddr
ReceiveSetup
36 Term
TermQuery
NO EQUIVALENT
NO EQUIVALENT
Status - returns various items detailing the current state of
Driver488. They are returned in a data structure.
Talk - addresses an external device to Talk.
Term - sets the end-of-line (EOL) terminators for input from,
and output to, I/O adapter devices. These terminators are
sent at the end of output data and expected at the end of
input data, in the manner of CR LF as used with printer data.
During output, Term appends the bus output terminator to
the data before sending it to the I/O adapter device.
Conversely, when Driver488 receives the bus input
terminator, it recognizes the end of a transfer and returns
the data to the calling application. The terminators never
appear in the data transferred to or from the calling
application. The default terminators for both input and
output are set by the startup configuration and are normally
CR LF EOI, which is appropriate for most bus devices.
TermQuery - queries the terminators setting. Terminators
are defined by the TermT structure.
TimeOut
TimeOutQuery
NO EQUIVALENT
NO EQUIVALENT
TimeOut - sets the number of milliseconds that Driver488
waits for a transfer before declaring a timeout error. The
timeout value sets a limit on the total time allowed for an
operation. For example, when using the Enter command all
expected data must be received within the specified timeout
period or a timeout error will occur.
TimeOutQuery - queries the timeout setting,
given in milliseconds.
2-6 API Cross-Reference 986992GPIB 488.2 Porting Guide
IOtech to MCC GPIB 488.2 Cross-Reference
IOtech GPIB
API Reference
MCC GPIB 488.2
Library Routine
Comments
37 Trigger Trigger
TriggerList TriggerList
38 UnListen DevClear
39 UnTalk DevClear
Trigger - issues a Group Execute Trigger (GET) bus
command to the specified device. If no interface
devices are specified, then GET only affects those
devices that are already in the Listen state [as a result
of a previous Output or Send command].
TriggerList - as Trigger, but uses a list.
UnListen - unaddresses an external device that was
addressed to Listen.
UnTalk - unaddresses an external device that was
addressed to Talk.
AllSpoll performs a serial poll on all specified
devices.
DevClear – clears one device
DevClearList – Clears specified devices
EnableLocal – Places specified devices in local
mode.
EnableRemote uses short addresslist to identify the
remote devices
FindLstn – Finds all Listeners on the GPIB
FindRQS – Identifies the device requesting service.
PassControl – Makes another specified device the
Active Controller.
Performs a parallel poll.
Configures a device for parallel polls.
Unconfigures devices for parallel polls.
RcvRespMsg – Reads data from a previously
addressed device.
ReadStatusByte – Serial poll a single device and
read its status byte.
Receive - Reads data from a GPIB device
2-8 API Cross-Reference 986992GPIB 488.2 Porting Guide
MCC to IOtech GPIB 488.2 Cross-Reference
MCC GPIB 488.2
Library Routine
15 ReceiveSetup Talk
16 ResetSys Reset
IOtech GPIB
API Reference
Comments
ReceiveSetup - Addresses a GPIB Interface Board as
a listener and a GPIB device as a Talker, in
preparation for data transmission. Compare to
SendSetup.
RestSys – Initializes GPIB System.
Abort
17 Send SendData
Send – Sends data to only 1 GPIB device.
OutputX
Output
OutputN
OutputMore
OutputNMore
18 SendCmds SendCmd
19 SendDataBytes OutputX
SendData
20 SendIFC Abort
21 SendList OutputX
SendCmds sends GPIB commands.
SendDataBytes – sends data to previously addressed
devices
SendIFC – Clears GPIB bus by asserting IFC
(Interface Clear) line.
SendList - Sends data to multiple GPIB devices.
SendData
22 SendLLO Lol
23 SendSetup Listen
MyTalkAddr
Talk
24 SetRWLS Lol
25 TestSRQ ControlLine
SendLLO – Sends Local Lockout (LLO) message to all
GPIB devices.
SendSetup - Addresses a GPIB Board as a Talker
and specified GPIB devices as Listeners. Compare to
Receive Setup.
Puts all devices in Remote state with Local Lockout
and addresses specified as Listeners.
2-10 API Cross-Reference 986992GPIB 488.2 Porting Guide
IOtech to Associated MCC APIs Alphabetical Listing 3
This chapter includes the IOtech routines which were previously used for Driver488/W95 and Driver488/WNT. It
also includes the associated MCC GPIB 488.2 commands which are now to be used in place of the IOtech
commands. Syntax examples provided are in the C language.
For detailed information refer to the GPIB Porting Guide folder at www.iotech.com. The folder is located on our
Tech Manuals Download Page. It includes this porting guide and the following documentation:
o Personal488 User's Manual for Windows 95/98/Me/NT/2000
Abort, no longer to be used, caused the Interface Clear (IFC) bus management line to be
asserted for at least 100µs. It forced all IEEE 488 device interfaces into a quiescent state.
SendIFC is used as part of the GPIB initialization procedure. When the system controller
asserts the IFC line, it unlistens and untalks all GPIB devices, forcing them to an idle state. The
system controller also becomes the Controller-In-Charge (CIC). In the following example we
clear the GPIB bus from Board 0.
Example:
SendIFC(0);
ResetSys initializes the GPIB bus and all specified devices. First, the system controller asserts
the REN (Remote Enable) line and then the IFC (Interface Clear) line. This action unlistens and
untalks all of the attached GPIB devices and causes the system controller to become the
Controller-In-Charge (CIC).
The Device Clear (DCL) message is then sent to all of the connected devices. This forces the
devices to return to their default states and ensures that they can receive the Reset (RST)
message. A reset message (RST) is then sent to all of the devices specified by addresslist. This
resets the devices to specific parameters.
In the following example we are resetting GPIB devices which are connected to GPIB board 0
and assigned GPIB bus addresses of 6 and 7.
Example: short addresslist[3] = {6, 7, NOADDR};ResetSys(0, addresslist);
The Arm command allowed Driver488 to signal to the user-specified function when one or
more specified conditions occurred. Arm set a flag for each implementation of the userindicated conditions. Arm conditions were often combined using the bitwise OR operator.
Similar functionality can only be achieved by coding efforts, of such magnitude, that they are
beyond the scope of this document.
AutoRemote INT WINAPI AutoRemote(DevHandleT devHandle,
BOOL flag);
EnableRemote EnableRemote(int board, short addresslist[])
Usage Notes
AutoRemote, no longer to be used, enabled [or disabled] the automatic assertion of the Remote
Enable (REN) line by Output. When AutoRemote was enabled, Output automatically
asserted REN before transferring any data. When AutoRemote was disabled, there was no
change to the REN line. AutoRemote was on by default.
EnableRemote - When this routine is executed, the system controller asserts the Remote
Enable (REN) line and the Controller addresses the specified devices as listeners.
The command issued in the following example places devices at GPIB addresses 6 and 7
(connected to GPIB board) in remote mode.
Example:
short addresslist[3] = {6,7,NOADDR};
EnableRemote(0, addresslist);
3-2 IOtech to Associated MCC APIs986992GPIB 488.2 Porting Guide
Loading...
+ 44 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.