From your description, it sounds as if your VXIcpu-030 is damaged and needs to be repaired. Unfortunately, because this controller is so old, support for repairs is limited. I suggest you upgrade to a VXIpc-770. The VXIpc-770 is a single slot embedded VXIbus controller that supports Windows, VXWorks, and Linux.
Porting NI-VXI applications from the VXIcpu-030 with VxWorks to the VXIpc series with VxWorks should be very straightforward. For many applications that rely on the NI-VXI API, the code won't need to change at all. Those using special features of the '030 may require more changes.
1. Endianness (byte order). The VXIcpu-030 was big-endian (Motorola), the VXIpc series is little-endian (Intel). This will affect users who make use of pointers to data structures and do not account for possible endianness changes. The NI-VXI and NI-VISA libraries include many functions that automatically convert between the two styles.
2. Memory mapping. The VXIcpu-030 directly mapped VXI address spaces into the controller's native 32-bit address space. This is no longer done, and the user needs to explicitly map regions of memory from VXI into their address space using the appropriate NI-VXI or NI-VISA API call.
3. Bus error and VXI interrupt handling. This is similar to #2: on the -030, bus errors from VXI accesses and VXI interrupts were passed back as native bus errors and interrupts on the controller. However, Intel does not support this, and the user must use the NI-VXI or NI-VISA API to enable and handle these events.
4. The Wind River VME API. The '030 supported some of Wind River's VME API for VxWorks, functions like sysBusToLocalAdrs(), sysIntEnable(), sysIntDisable(), vxMemProbe(), etc. Now we support these functions only through the standard NI-VXI or NI-VISA API calls like MapVXIAddress(), EnableVXIint(), DisableVXIint(), VXIin(), etc.
Also worthy of note: consider the recent improvements in performance of non-real-time OS's before committing to VxWorks for a VXIpc system that is replacing an '030. Ten years ago when the '030 was probably spec'd into most systems, it was reasonably fast and up-to-date, and running VxWorks on it was the only answer for some applications. Come forward to 2003, and some of our Windows VXIpc offerings might be able to solve problems that required a real-time OS ten years ago. Of course, Windows won't be real-time but the overall system performance may be better enough to compensate for this in some types of applications where hard real-time performance was not strictly necessary.
The length of this list may sound scary, but really that's just about it for possible issues, and most of them won't apply for most users. In general, porting an NI-VXI application from the '030 to the VXIpc with VxWorks can just be a recompile.
For more information on the VXIpc-770, please review the following webpage
David Shatila Applications engineer National Instruments www.ni.com/support