EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  <20012002  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  1996  1997  1998  1999  2000  <20012002  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: Experiences with MXI-2
From: Ned Arnold <[email protected]>
To: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Cc: [email protected], [email protected]
Date: Thu, 12 Apr 2001 08:38:00 -0500 (CDT)
Background Information: The original MXI modules are no longer available 
from National Instruments (APS has over 80 of these installed). We have 
confirmed that the newer MXI-2 modules DO function with the Resource 
Manager (drvEpvxi.c) included in base ... almost.


As I was installing the MXI-2 boards, I ran into a couple of glitches that
you all may want/need to know about ...

1) On the original MXI cards, there was a jumper (or a modification on the 
   really early ones) that disabled the MXI parity checking. This was 
   required in some installations because certain modules left unused
   data lines floating which would sometimes change during the read cycle,
   generating a parity error.
   
   The MXI-2 board does not have a jumper for this option. The MXI parity
   can be disabled by altering the configuration EEPROM or writing to a 
   control register in the A24 address space. I chose the latter so we
   wouldn't have to keep track of differently configured modules.
   
   If you want the parity disabled, I have a small program that can be
   run during ioc boot. This will be incorporated into a "mxiConfig" routine
   sometime later.


2) The original MXI cards had a jumper that defined whether the module was
   the MXI System Controller. The MXI System Controller is responsible for 
   generating a bus timeout if a MXI access does not complete. 
   
   The MXI-2 module does not have this jumper. It "auto-detects" this status
   automagically by sensing something on the MXI cable. The problem is, if
   you don't have a MXI cable attached to the MXI-2 module in the CPU
   crate, it assumes it is NOT the MXI system controller and the system
   hangs hard when the Resource Manager probes for MXI devices. This is NOT
   configurable in a register, so I have not come up with a good solution
   yet. I am in contact with National Instrument support on this dilemma.
   

3) The Resource Manager in the latest release of base does not work with the
   PowerPC/MXI-2 combination. I am currently booting out of my own directory
   with an older version of drvEpvxi.c (which works). I am confident that
   Andrew will resolve this soon.
   
   
   	Ned
   	




Navigate by Date:
Prev: some problem when tailor the vxWorks kernel shen guobao
Next: RE: CA clients on vxWorks Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  <20012002  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: some problem when tailor the vxWorks kernel shen guobao
Next: CAN questions John Maclean
Index: 1994  1995  1996  1997  1998  1999  2000  <20012002  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 ·