AnsweredAssumed Answered


Question asked by VRFuser on Jan 13, 1997
send q VRf-Pass_Control vrf ww

from: Greg Goebel / HP-MXD / 970-679-3030 / FAX 970-679-5971
to:   VRf-Stephen C. Chen
date: Tuesday, 14 January 1997 1125 MST

> VRf - GPIB pass control
> Situation:
> I am trying to load the screen of an instrument (HP35670A) to PC as a HPGL
> file, but have to pass control to the instrument.  I am using a GPIB board
> from National on a WIN-NT 4.0 station.
> Is there a way I can use I/O -> advanced I/O -> Interface Operation
> to pass command and pass control from PC to instrument? 
> Thanks
> Steven C. Chen
> Aeptec Microsystems, Inc.
> 15800 Crabbs Branch Way, Suite 300
> Rockville, Maryland 20855
> Tel: 301-670-6770 X509   Fax: 301-670-9884


Two items: 

% You may not need to pass control to do this.  Please see first article

% If you do need to pass control, it can be done, if just barely.  Please
   see second article below.

If you have more questions, let us know.

[%%] regards -- gvg

--------------------------------- cut here ----------------------------------


* One of the features introduced in VEE 3.0 was the ability to release the
HPIB ATN line under program control.  This leads to the obvious question:  so
who cares?

The ability to release ATN under program control is only used in two

% When you want to have one device talk to two or more listeners; in 12
   years of support I've only been asked how to do this once.

% When you want to perform a print or a plot directly from an instrument to
   a printer or plotter over HPIB.  This is the requirement that that does in
   fact come up every now and then. 

Under normal circumstances, all VEE HPIB transactions suppose that VEE is
either the talker or listener and a single remote device is the corresponding
listener or talker; the bus transactions that VEE generates with instrument
drivers or Direct I/O all are designed according to this assumption.

The two circumstances outlined above, however, require that VEE set up a
remote device as a talker and one or more remote devices as listeners.  The
standard VEE HPIB transactions won't allow this, but you can (as of VEE 3.0)
use the Interface Operations object to create the proper HPIB transactions.

For example, I have a 54600 scope; I can send it a "PRINT?" query, and when I
then address it to talk, it will dump its display (in HP standard printer
graphics format) to the HPIB ... with the assumption that there is a printer
out there listening so it can print the data.

My 54600 has an HPIB address of 13; I have a ThinkJet printer with an address
of 1.  I can direct the 54600 to dump its display to the ThinkJet by using
direct I/O to send the "PRINT?" command, and then by using an interface
operations object to perform the following HPIB transactions:

   TALK 13

This can be done with the following program (see the file xprscope.vee
for the source):

             | Start |
   |   54600 (54600A @ 713)   |
   |                          |
   | Interface Op's hpib7 @ 7 |
   | SEND UNL                 |
   | SEND UNT                 |
   | SEND LISTEN 1            |
   | SEND TALK 13             |
   | SEND DATA ""             |

Note how ATN is released with the Interface Operations transaction:


This was the transaction that was missing in earlier versions of VEE.


--------------------------------- cut here ----------------------------------

* For a more complicated example, consider passing control over HPIB.  The
HPIB protocol allows for more than one controller on the bus, though only one
can be active at any time; the current active controller can "pass control"
to another controller to allow it to become the current controller.  The new
active controller can then pass control on to another controller, or pass it
back to the first controller.  HPIB also defines a "system controller" that
can unconditionally regain control by asserting the IFC line on the HPIB,
forcing any other active controller to go to the inactive state.

It is possible (though not very intuitive) to pass control using VEE for
Windows (with some restrictions).  All you have to do is use the interface
operations dialog to address the inactive controller to talk, and then send
the TCT (take control) HPIB command byte to it; for example, if the inactive
controller is at HPIB address 5, then you can use this to pass control to it
(see xpassctl.vee for the source):

                 | Start |
   |      Interface Op's: hpib7@7      |
   | SEND UNL                          |
   | SEND UNT                          |
   | SEND TALK 5                       |
   | SEND CMD 9                        |<-- TCT byte

The active controller can then pass control back to VEE, or VEE can execute
an ABORT to assert the HPIB IFC (interface clear) line to regain control:

                 | Start |
   |      Interface Op's: hpib7@7      |
   | EXECUTE ABORT                     |
   |                                   |
   |                                   |
   |                                   |

There is no way for VEE to check to see if it is not active controller; you
can perform operations that require active controller operation and see if
you get an error message, but unfortunately the error unconditionally returns
control to the VEE system ... it appears to assert IFC.  However, you can
have the remote system assert an SRQ when it is finished; VEE can use an
Interface Event object to wait for the SRQ.

Note that the 82335 card cannot assert IFC (while National Instruments or
8234X cards can) and so an 82335 cannot unconditionally regain control in
this way.  However, the remote controller can pass control back to VEE, but
it has to know the HPIB address of the card that VEE is using; this is
*always* 21 for an NI (you can't change it, even if you set the NI
configuration utility to another address), normally 21 for an 8234X HPIB
card, and normally 30 for an 82335 card (you can change the address in these
two cases through SICL.INI).

Note also that this discussion assumes that VEE is running on a system
controller; this is a good assumption, because at present it is impractical
for it to run on a non-system controller.

Running on a non-system controller implies slave operation, and this cannot
be done at present, since VEE has no way of checking whether it is system or
active controller (save by trapping) errors, and (more importantly) there is
no way for it to read or write data while it is not active controller.  These
deficiencies may be addressed in a future version.

* Note that as of VEE 3.0, I/O transaction objects have the ability to lock
and unlock interfaces to guarantee mutual exclusion in a multiprocessing
environment, using the EXECUTE LOCK and EXECUTE UNLOCK transactions.