EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: VXI support
From: Jeff Hill <[email protected]>
To: Ric Claus <[email protected]>
Cc: [email protected], Thomas Dean <[email protected]>
Date: Thu, 02 May 1996 09:48:07 -0600
Ric Claus wrote:
> 
> VXI gurus,
> 
>   I'm starting to develop driver and device support for a bunch of in-house VXI
> modules.  These are register based modules which occupy space in both A16 and A24
> space.  Some of them have DSPs on them which will need to be loaded with code and
> coefficient tables.  I've been using drvAt5Vxi.c as a model.  My VXI slot 0
> processor is a National Instruments VXIcpu-030.  There is no MXI in the system.
> I'm using EPICS 3.12.2.
> 
>   First off, are there any new developments that I should be aware of?  

A bug related to mixing dynamic and static addressing in
the same system has been discovered by Tom Dean (also of SLAC). I
just finished fixing the problem. It was introduced when I added support
for blocked address devices at LBL's request (and at no expense to LBL). 
The fix is in CVS under epics_R3_12_2_patch_3 at APS.

> Second,
> documentation for VXI support seems to be rather scarce, with only Jeff Hill's
> man pages to go on.  Is there any other documentation around?  

No. I need to upgrade the documentation to include a description of the 
address window config and the API which allows association of make/model
names with their corresponding binary codes.

> There seems to
> be a lot of stuff #if'ed out in the code, so I'm wondering if this is a finished
> product.

Most of the #if's in the code selectively compile in NI CPU030 support. There are 
also a few #if 0's and these are commenting out untested code implementing 
esoteric features of the VXI spec.

The code was originally developed at LANL for the GTA project (circa 1988-1990). 
Writing a VXI resource manager with MXI support is a big job. We implemented
what we needed. This appears to also have been sufficient for the VXI installations 
at APS and LBL. 

> 
>   SLAC does not appear to have a VXI manufacturer ID and so the boards are being
> loaded with code 0xf00 which is defined as "user custom".  Will EPICS VXI support
> work with this?  Does it care?

There are routines which allows a string to be associated with each binary make/model
each code by your application. These calls are not in the man pages. There
are many examples in the drv directory.

Here are the function prototypes from drvEpvxi.h

EPVXISTAT       epvxiRegisterModelName(
        unsigned int    make,
        unsigned int    model,
        char            *pmodel_name
);
 
EPVXISTAT       epvxiRegisterMakeName(
        unsigned int    make,
        char            *pmake_name
);

> 
>   There is a non-VXI device in the crate (an Allen Bradley 6008-SV1R Scanner
> module) on an HP E1407A VME-VXI adapter.  How do I tell the EPICS resource
> manager about it?  

Configure the resource managers logical address window so that it does not overlap 
any of your VME devices. The following configures a 32 device window starting
at logical address 128:

EPICS_VXI_LA_COUNT = (char) 0x20
EPICS_VXI_LA_BASE = (char) 0x80

The following define a window in A24/A32 where the resource manager is
allowed to place A24/A32 devices.

EPICS_VXI_A24_SIZE = 1024
EPICS_VXI_A24_BASE = 0
EPICS_VXI_A32_SIZE = 1024
EPICS_VXI_A32_BASE = 0    

> Does it care?
> 

Yes. Including VME devices that dont follow the VXI spec in the resource manager's
window will confuse the resource manager.

>   drvAt5Vxi seems to require drvEpvxi (which I guess replaces epvxiLib?). 

The source files drvEpvxi.c and drvEpvxiMsg.c implement the 
epvxiXXX() library routines and the resource manager.

> It
> also requires the resource manager to have run before its init routine will
> complete.  How is this guaranteed?

This can be guaranteed by the order that drivers are listed in drvSup.ascii.

The library routines use external variables that are initialized to zero by
the loader. If the resource manger doesnt run then the values of certain variables
will remain zero and therefore - when it is important - the library routines should
detect that the resource manager hasnt run. This case isnt frequently tested 
however because most sites initialize the system in the proper order.

Jeff
______________________________________________________________________
Jeffrey O. Hill                 Internet        [email protected]
LANL MS H820                    Voice           505 665 1831
Los Alamos, NM 87545 USA        FAX             505 665 5107

References:
VXI support Ric Claus

Navigate by Date:
Prev: Re: A bad thing happens when I build base/ Bill Brown
Next: simple questions Mark M . Ito
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: VXI support Ric Claus
Next: HP VXI Modules W. Stephen Syrett
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·