Generic GPIB interface proposal

[Gerry Swislow <certif!gerry@photon.mit.edu>]

Hi Folks,

To follow up on the beamlines control meeting discussion
on a generic GPIB interface, here is a list of 'process
variables' that could be used to describe such an
interface.

The generic interface would be designed for a single
talker or listener to communicate with the controller.
Service request (SRQ) and parallel poll features need
not be implemented. Secondary addressing and take- and
pass-control functions are also not needed.


gpib.ADDR       The device address.  (There could be a
		different gpib.XADDR for each type of
		transaction, but that seems unnecessary)

gpib.MSG        The place for the application to put bytes
		that are to be written and get bytes that
		have been read.  Note:  the driver should
		consider these bytes as binary data.  Even
		null bytes are allowed.  (There could be a
		WMSG and an RMSG, but that doesn't seem
		needed.)

gpib.SPR        The serial-poll response byte.

gpib.CNTL       An enumerated list of 'Multiline Interface
		Messages', as in GTL, SDC, GET, DCL, LLO, ...
		These are addressed commands.

gpib.CNT        When reading, the number of bytes requested.
		If zero, read until an EOI or the EOS
		terminator.  When writing, the number of
		bytes to be written.  (There could be a
		WCNT and RCNT  ...)

gpib.ACNT       The number of bytes actually transferred in
		a read or write, including any terminator.

gpib.EOS        The terminator (end-of-string) to use on
		reads.  If -1, do not terminate the read
		on EOS.  Otherwise terminate read on this
		EOS character.  Reads are always terminated
		if the EOI line is asserted by the device.

gpib.EOT        If there is a limit on the number of bytes
		that can be sent by the application to
		the GPIB driver in a single message anywhere
		along the line, then it is necessary to
		write portions of a big message without
		asserting EOT until the last byte of a
		multipart message is sent.  If gpib.EOT
		is not set, then don't assert EOT with
		the last byte of the current write.
		gpib.EOT should default to being set, and
		should be reset after each gpib.PROC
		(below) action.

gpib.TMO        A timeout value for GPIB reads and any
		other transaction.  If the timeout expires,
		gpib.ERR should be set appropriately.
		(Not part of the GPIB protocol.)

gpib.ERR        Contains an error code, such as
		GPIB_LISTENER_TIMEOUT, etc., unless there
		is some other EPICS mechanism for passing
		error codes.  Set to zero after a normal
		transaction.

gpib.PROC       An enumerated list of actions to take.  Writing a
		value to this PV is what initiates the data transfer.
		Possible values are:

		    READ  - addresses device to talk, reads
			bytes, sends UNT (untalk).

		    WRITE - addresses device to listen, writes,
			sends UNL (unlisten).

		    SERIAL_POLL - addresses device, sends SPE
			(serial poll enable), read status
			byte, sends SPD (serial poll disable)
			and UNT.

		    SEND_MSG - addresses device, sends multiline
			message, such as SDC, LLO, etc.

		 The next three would allow an application to
		 have 'board' level control of the GPIB interface,
		 making it possible for an application to perform
		 transfers using multiple listeners, for example.
		 Addressing would be done by the application
		 in the message transferred by CMD.

		    CMD - sends MSG with ATN high.

		    C_READ - reads bytes, doesn't do addressing
			or UNT.

		    C_WRITE - writes bytes, doesn't do addressing
			or UNL.

		I'm not sure what is normal for initiating
		an action that depends on several process
		variables.  There could as easily be a
		different gpib.GOxxx for each of the above
		actions.

gpib.REN        Asserts remote enable.

gpib.IFC        Asserts interface clear. (Dangerous to use, of
		course, but may be necessary for certain pathological
		devices.)


This scheme requires that one application doesn't write
to sensitive process variables while another
application is setting up a transaction.  That will have
to be up to the application programmer, since EPICS is not
able to enforce that kind of access restriction.
Perhaps, though, there could be a gpib.BUSY that when set
prevents any of the other PVs to be modified.  There could
be a timer on gpib.BUSY that clears it after some
reasonable interval after the last write, in case the
process that set it died and didn't clean up.

At the meeting, John Winans said it is not practical to
implement EOS using the National Instruments VME GPIB
controller.  Rather than not implementing EOS, I think it
would be better to not support that controller with an
EPICS driver.

Gerry Swislow
Certified Scientific Software                gerry@photon.mit.edu
PO Box 390640                                    617-576-1610:tel
Cambridge, MA  02139                             617-497-4242:fax