viMove 0xBFFF003E (VI_ERROR_IO)

[M.J]

Hi Robert,

I believe that the below Knowledgebase article can help you move forward with tow potential workarounds.

Mention in the below article: "The newer rev. B MITE was updated to follow the PCI specification requiring continual retries. This exposed a potential deadlock between the SyncMXI and PCI protocols". From my understanding this is what you are facing.

http://digital.ni.com/public.nsf/allkb/3688705B6D2A405486256E9F005953F6?OpenDocument

I hope this helps.

[bbwpdad]

This does describe my issue.  I will try both solutions but I beleive there are problems with both:

1. I can modify my driver to use viMoveIn and viMoveOut instead of viIn and viOut but what about other drivers?
2. If I disable SyncMXI, my driver will become unaceptably slow.

Are there plans to correct this issue and if so what is the timeline?

Robert

[Erik-S]

Hi Robert,

Unfortunately at this point, NI is no longer developing for VXI, so a fix is unlikely. There are other companies that still develop for VXI that you may want to look into for a solution to the issue you are seeing.

-Erik S

[bbwpdad]

Erik,

Your reply causes me some concern.  As far as I know most of the NI VXI control products are not listed as "Not recomended for new designs".  Should we not be recomending NI control products to our customers?

Robert

[M.J]

Hi Robert,

It is correct that we sell the NI VXI controlers which are still recommended for VXI applications. However past hardware recognition and set up, National Instruments has limited resources and support available for software implementation. Based on the information we currently have, it seems like we have exhausted those resources.

Have you had the chance to try either of the options previously mentioned? Is the outcome as you expected? For option 1, what other drivers are you referring to?

[reichenbach]

you could try replacing the PCI-MXI-2 and VXI-MXI-2 with the same hardware revision or an older/newer revision.

www.artisantg.com has many different versions/revisions of these in stock. just let them know what part number you have: should start with 183345... and 182685... or 182687... and then ask to demo a few different revs to troubleshoot.

[bbwpdad]

I have tried both solutions.

1. Switched all viOut/ViIn to viMoveOut/viMoveIn.  ~17% slower.  This solution would work if our driver is the only driver but we cannot guarantee that other drivers are not doing viIn and viOut.  There are often multiple modules from multiple vendors in the VXI chassis.  Our driver is register based and we use viMoves to speed up the driver.  If a customer has multiple threads talking with two different resources that both perform single and DMA access, this error will occur.
2. Disable SyncMXI.  ~50% slower.

If I bought a new car that shut down if you drive over 30MPH and the

I understand that these support (or lack of support) decisions are made at a different level than you may be at but I am surprised to hear that NI will not allocate resources to support hardware that is still sold.  This is a known issue that causes PC lockups with the latest revision assemblies and may only require a driver update to prevent this deadlock.

Do any othe NI VXI controllers have this issue?

Robert

[M.J]

Hi Robert,

Moving forward, you can post on NI Idea Exchange (http://forums.ni.com/t5/NI-Idea-Exchange/ct-p/ideas). On the Idea Exchange you will be able to provide recommendation on fixes for the VXI product line.

[Dennis_Knutson]

NI is not the only vendor with limited support for VXI. Vendors such as Tek and Agilent used to have a full line of instruments and controllers. In some cases, the products were sold off to other vendors and in other cases, the products were just dropped. I used VXI when it was first introduced but the design never really fulfilled the promises made and have been supplanted by more modern technology such as PXI.