VXI and VME

cancel
Showing results for 
Search instead for 
Did you mean: 

VXI-MXI-2 boards not compatible with legacy system

I have a deployed system (15 systems with 2 VXI-MXI-2 boards per system).  These systems have been running since 2001.

My client complained of newly procured VXI-MXI-2 boards causing the VXI controller to fault rendering the system useless.

In testing at my facility I have found the system controller is halting at a System Error OddAddressError when a newer board is placed in the last slot of the first chassis.  If it is the slot-0 of the slave chassis all boards work equally well.

I have discovered I can rectify the issue by using a shorter cable between the master and slave VXI chassis.  This only occurs with recent/replacement boards.  My functional legacy boards work with any length cable.

The same error occurs when the newer boards are positioned in the last slot of the master chassis with NO MXI cable attached.

All MXI cables are custom ordered NI built cables.  They are a 3 part assembly passing through two bulkheads with a total length of appx. 50'.

 

0 Kudos
Message 1 of 5
(5,345 Views)

As a follow up, I have been testing with 2 newer cards P/N 183345L-01L Rev 2.1.  My hope was I could simply have my client purchase the cards in pairs and rectify the system fault.

This pair fails to boot more often than it succeeds irrespective of cable length.  When it does boot I have experienced:

           - a flood interrupt errors on my VME PPC boards

           - no bus traffic at all between VXI-MXI-2 boards

           - a fully functional system. 

The fully functional condition is the rarest of all but it has happened.

 

My intuition leans toward BUS timing, I am experimenting with various clock solutions to see if i can wiggle the bug.

I will admit that my VXI BUS controller is an Agilent E1406A.  I had to move to an agilent controller in 2009 during a hardware refresh because the NI product(s) did not fully implement the VXI standard.

 

I will continue to fight the good fight and post any relevant news.  If anyone out there has any experience or insight into my situation please post.

0 Kudos
Message 2 of 5
(5,329 Views)

As you're using the Agilent bus controller, it could be difficult to understand the issue.  NI VXI system components are not tested in this configuration, and the bus controller could handle the bus differently than an NI controller does.  Could you elaborate on this point:

 

"I had to move to an agilent controller in 2009 during a hardware refresh because the NI product(s) did not fully implement the VXI standard."

 

Were you running into a particular issue?  What part of the standard does the NI controller not implement that is needed for this application?

------------------------------------------------------------------------------------------

Jon F.
Technical Support Engineer
National Instruments
0 Kudos
Message 3 of 5
(5,310 Views)

That was a long time ago but as I recall it was the routing of interrupts to respective handlers in remote chassis' across the MXI BUS.  The Agilent supported an interrupt table that I wrote a cute GUI to configure via GPIB.  This allowed my client to source and program replacement controllers.   

Irrespective of the cause my solution has been working since 2009 with the Agilent controller and NI VXI-MXI-2 extenders.  As the part numbers of the VXI-MXI-2 have morphed I started to get interrupt errors and now can't boot at all.  I can run a legacy board in the main chassis and new card in the slave chassis.  I can run a new card in  the master chassis and a legacy card in the remote chassis but only with a short MXI-2 cable.

2 new VXI-MXI-2 cards does not work in standard configuration (switch and jumper settings).

If NI has a VXI controller that is programmable per the standard I would be willing to test that as a solution.  This legacy system is going away but that will take another 5 years to roll-out my replacement system.  

 

I admit I am nervous about using NI.  When I initially attempted to use an ALL NI solution and discovered the lack compliance with the standard they didn't want to give me back my $100k.  I have strongly advocated for any other vendor since then.

 

Any thoughts or ideas are appreciated.

 

I HAVE gotten two of the newer boards to work (one in each chassis) by setting both to internal BUS clock and both set to drive the MXI clock out.  This is a horrible idea I was exercising as a test (flail).  The system still only boots about 40% of the time.  That is up from 0% but still not a solution I can offer my client.

0 Kudos
Message 4 of 5
(5,308 Views)

I have gotten my boot probability up to about 75%.

The only change is moving the VXI-MXI2 to the first available slot ( slot 6 ) in the master chassis.  My typical configuration is to have this in the last slot of the chassis.  This doesn't make a lot of sense to me but there is definitely a causal relationship between boot probability and slot.

 

Still hoping for any ideas that will get me back to a deterministic boot process.

 

Cheers 

0 Kudos
Message 5 of 5
(5,280 Views)