AnsweredAssumed Answered

VRf-VEE_Pass_Control

Question asked by VRFuser on Jun 11, 1996
send q VRf-VEE_Pass_Control vrf kwong@gandalf.sp.trw.com

from: Greg Goebel / HP-MXD
      gvg@lvld.hp.com / 970-679-2305 / FAX 970-679-5971
to:   Kit Hayashibara / VRf
date: Wednesday, 12 June 1996 1419 MDT

> Hi everyone,

As a suggestion, you might put a header on your message to specify who
"everyone" is supposed to be.

> I have a need to control an Electronic Calibration Unit for
> a network analyzer. This Ecal unit needs to be in control of
> the HPIB bus to run the network analyzer. I have been able
> to successfully run it in Rocky Mountain Basic. I need to be
> able to run it from Veetest. So far I haven't found any
> "pass-control" options in the "I/O" menu.
> Is "pass-control" possible in Veetest?
>
> Thanks,
> Kit Hayashibara
> kwong@gandalf.sp.trw.com

Sir/Madam:

It is just barely possible.  Please see the document below for details.

Please stay in touch.

[%%] regards -- gvg




[9.3] INTERFACE OPERATIONS OBJECT 

The Interface Operations object can be used to specify various interface-level
operations that can come in handy in a pinch.

You can select this object from the "I/O" menu's "Advanced I/O > Interface
Operations" object; you get a dialog asking for the desired interface
-- say, "hpib7" -- and then get the object:

   +-----------------------------------+
   |      Interface Op's: hpib7@7      |
   +-----------------------------------+
   |                                   |
   |                                   |
   |                                   |
   +-----------------------------------+

This works much like other transaction objects; click on the work area, (under
the title bar) and you get a dialog to specify your first transaction:

   +------------------------------------------------+
   |              I/O Bus Transaction               |
   +------------------------------------------------+
   | [ SEND ] [ COMMAND: ] [ 0    ]                 |
   |                                                |
   |                                                |
   |     [   OK   ]                  [ Cancel ]     |
   +------------------------------------------------+

There are two classes of I/O bus transactions:  SEND (as shown) and EXECUTE.
SEND allows you to perform low-level HPIB transactions with a remote device, as
defined by the COMMAND field; click on this and you get a dialog:

   +---------------------------------------+
   |        Select I/O Send Command        |
   +--------+---------------------+--------+
   |        | COMMAND:            |        |
   |        | DATA:               |        |
   |        | TALK:               |        |
   |        | LISTEN:             |        |
   |        | SECONDARY:          |        |
   |        | UNLISTEN            |        |
   |        | UNTALK              |        |
   |        | MY LISTEN ADDR      |        |
   |        | MY TALK ADDR        |        |
   |        | MESSAGE:            |        |
   +--------+---------------------+--------+
   | COMMAND:                              |
   +---------------------------------------+
   |     [   OK   ]         [ Cancel ]     |
   +---------------------------------------+

These are low-level HPIB commands whose definitions are beyond the scope of
this document; please see a reference text on HPIB protocols for details.  Note
that the entries that end with a ":" require parameters, and that there is a
field in the transaction dialog for those parameters.

* If you select EXECUTE operations, you get a transaction dialog like this:

   +------------------------------------------------+
   |              I/O Bus Transaction               |
   +------------------------------------------------+
   | [ EXECUTE ] [ CLEAR ]                          |
   |                                                |
   |                                                |
   |     [   OK   ]                  [ Cancel ]     |
   +------------------------------------------------+

The CLEAR allows you to perform interface or bus (not device specific)
operations on the HPIB interface; click on this field and you get the full
set of selections:

   +---------------------------------------+
   |       Select I/O Execute Command      |
   +--------+---------------------+--------+
   |        | ABORT               |        |
   |        | CLEAR               |        |
   |        | TRIGGER             |        |
   |        | REMOTE              |        |
   |        | LOCAL               |        |
   |        | LOCAL LOCKOUT       |        |
   |        |                     |        |
   |        |                     |        |
   +--------+---------------------+--------+
   | CLEAR                                 |
   +---------------------------------------+
   |     [   OK   ]         [ Cancel ]     |
   +---------------------------------------+

Again, a real understanding of these operations requires a detail knowledge of
HPIB.

* However, you can make practical use of the Interface Operations object even
without much knowledge of HPIB protocols.  For example, suppose you are dealing
with an instrument driver and occasionally get the HPIB in an uncertain state.
You could use the Interface Operations object to clear the bus; all you have
to do is create a thread in your program that looks like this:

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

This executes operations that stops (ABORTs) all HPIB operations, and then
puts the interface into a CLEAR state.  Other operations as needed for the
particular system could be added as Interface Operation transactions, or
with a Direct-I/O object or objects.

* 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:

                 +-------+
                 | Start |
                 +---+---+
                     |
   +-----------------+-----------------+
   |      Interface Op's: hpib8@8      |
   +-----------------------------------+
   | 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: hpib8@8      |
   +-----------------------------------+
   | 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.

[%%]

Outcomes