05-01-2009 05:08 PM
I am working on avoiding obsolesence for my company's VXI based automated test system. Our current system uses the fiber optic MXI-3 connection between the VXI chassis and the PC. The fiber optic slot 0 controller and pc card are no longer in production. As a replacement we are trying out the VXI-USB system. After installing the VXI-USB system I am having several issues with the existing code (c/c++):
1) The existing code used pointer dereferencing to write to and read from the A16 and A24 address spaces. However, now those lines result in access violations. Is that expected?
2) I replaced the pointer dereferencing lines with VXIpeek() and VXIpoke(), but I do not get the expected behaviour in many cases. My project is also complicated by the fact that what resides in our VXI chassis are proprietary modules with no documentation. Would pointer dereferencing versus peek() and poke() possibly result in different byte orders?
3) Anything else I should know about the USB system vs the MXI-3 system?
I have several other questions, but first I am stuck on step 1. Ideally, I need to know how to make the existing code work or what code changes are necessary. I can also provide the code if needed. Thanks!
-Jeff
05-04-2009 11:09 PM
Dear Jeff,
1) That is expected. Please look at the KnowledgeBase article below:
http://digital.ni.com/public.nsf/allkb/D2A93CECA7BC864886256349004CCA1E
2) I'm not sure if you're using NI-VXI or NI-VISA. Please note that if you're using NI-VISA the command is actually viPeek and viPoke. Also note that using NI-VISA is recommended over NI-VXI. I'm not sure how much further I can help you if documentation is proprietary about your modules.
3) This is also a really good article:
http://digital.ni.com/public.nsf/websearch/305EF2551F679CD986256C1000810524?OpenDocument
Regards,
Sammy Z.
05-06-2009 10:26 AM
Hi Sammy,
Thank you for the reply, the articles were very useful. I will revise my statement about proprietary hardware - it is "in house" hardware from several engineers ago and was very poorly documented. The existing software uses the VXI API so I was working with the VXI API for easy updating to the source code. Here is my current problem:
Direct Replacement of old code (that used pointer dereferencing), now using VXIpeek() and VXIpoke():
Problem - inconsistent and incorrect results - unknown reason
A16accessParams = 1;
A16PCAddress = (UINT16*) MapVXIAddress(A16accessParams, 0xC000, timeout, &window, &returnValue);
printf("\nReseting Module in slot 2\n");targetAddress = (UINT32) 0xC084;
returnValue = VXIout (A16accessParams, targetAddress, 2, (UINT16)(0x0003));
returnValue = VXIout (A16accessParams, targetAddress, 2, (UINT16)(0x8000));
peekPokeAddress = A16PCAddress + (64 * 2 + 32)/2;
VXIpeek(peekPokeAddress, 2, &value); // On our module, this is a two byte register that indicates read / write readiness of registers from 0xC090 to 0xC09E// (This returns inconsistent and incorrect values)
peekPokeAddress = A16PCAddress + (64 * 2 + 16)/2;
VXIpoke(peekPokeAddress, 1, 0x11); // This is a stop command to the first of eight channels on out module, the channel should echo the command and supply// version data through 0xC091 as follows: 0x11, <version>, 0x91
peekPokeAddress = A16PCAddress + (64 * 2 + 32)/2;
VXIpeek(peekPokeAddress, 2, &value); // Read / Write ready registers returns incorrect values
peekPokeAddress = A16PCAddress + (64 * 2 + 16)/2;
VXIpeek(A16PCAddress + (64 * 2 + 16)/2, 1, &value); // Attempted read of the reply returns the wrong value on each read
VXIpeek(A16PCAddress + (64 * 2 + 16)/2, 1, &value); // same wrong valueVXIpeek(A16PCAddress + (64 * 2 + 16)/2, 1, &value); // same wrong value
peekPokeAddress = A16PCAddress + (64 * 2 + 32)/2;
VXIpeek(peekPokeAddress, 2, &value); // Read / Write ready registers returns incorrect values
Code I created that works (but uses high level VXIin() and VXIout() API calls):
A16accessParams = 1;
printf("\nReseting Module in slot 2\n");targetAddress = (UINT32) 0xC084;
returnValue = VXIout (A16accessParams, targetAddress, 2, (UINT16)(0x0003));
returnValue = VXIout (A16accessParams, targetAddress, 2, (UINT16)(0x8000));
returnValue = VXIin(A16accessParams, 0xC0A0, 2, &value); // On our module, this is a two byte register that indicates read / write readiness of registers from 0xC090 to 0xC09E
// (This returns expected values)
returnValue = VXIout(A16accessParams, 0xC090, 1, 0x11); // This is a stop command to the first of eight channels on out module, the channel should echo the command and supply
// version data through 0xC091 as follows: 0x11, <version>, 0x91
returnValue = VXIin(A16accessParams, 0xC0A0, 2, &value); // Read / Write ready registers shows that channel 1 has data correctly
returnValue = VXIin(A16accessParams, 0xC091, 1, &value); // Reads value of 0x11 correctly
returnValue = VXIin(A16accessParams, 0xC091, 1, &value); // Reads version value correctly
returnValue = VXIin(A16accessParams, 0xC091, 1, &value); // Read value of 0x91 correctly
returnValue = VXIin(A16accessParams, 0xC0A0, 2, &value); // Read/Write ready register shows channel 1 is empty of data now
The peek and poke routine should function the same as the VXIin() VXIout() routine, correct? Any thoughts on what I am missing? (note: I get no bus error or invalid returns from any of the API calls in either example)
Thanks and Regards,
Jeff
05-06-2009 05:01 PM
Interesting follow-up note: Everything in VISA works fine. I can use peek() and poke() no problem.
So still the unsolved question - Why don't my calls to VXIpeek() and VXIpoke() work with the USB setup?
But I can at least go ahead with VISA.
-Jeff
05-07-2009 07:30 PM
Hi Jeff,
VISA has shown to be more reliable that VXI commands.
I'm glad that the VISA commands and high level VXI commands are working.
I can't pinpoint anything being wrong, but I'll look further into it and see if I can find anything.
Regards,
Sammy Z.