what versions of NI-VISA are compatible with CVI 7.1.1

[MJF]

I am stuck using CVI version 7.1.1 due to a customer requirement and need to use VISA functions in a new application. I do not have access to the original driver disk so I don't know exactly which version of VISA to use with this version of CVI.

I was under the assumption that I could download the latest version (4.6.2) and it would be backwards compatible but it does not work for me on two different PCs. In both cases, I get a general protection fault if I try to execute an application that uses any of the VISA functions. Both PCs use Windows XP.

So I need to know which version of VISA is compatible with Win XP and CVI 7.1.1 and will not give me a GPF.

To further complicate things, I also need to know which versions of NI-FGEN, NI-RFSG, NI-HSDIO, and NI-DAQ will work with my setup. I am using PXI-5404, PXI-5651, and PXI-6562 hardware.

[MJF]

The attached screen shot shows the GPF error message I am getting.

I have tested this application on three separate machines with the exact same result. One of them has VISA 4.5 installed, the others 4.6. All of them have CVI 7.1.1 and TestStand 3.1

I get the error if I try to run this application and it has ANY VISA function in it. As soon as I remove them, it runs OK.

All I am trying to do is use the VISA functions to access an RS-232 port. I have done this before without running into any kind of problems.

I need a solution to this problem.

For what it is worth, the calls I am making so far are (if I include any of them and try to run, it gives a GPF):

 status = viOpenDefaultRM (&rsrcMgr); 
 status = viOpen (rsrcMgr, comPortDescriptor, VI_NULL, VI_NULL, &comPort);
 
 status = viSetAttribute (comPort, VI_ATTR_WR_BUF_OPER_MODE, VI_FLUSH_ON_ACCESS);
 status = viSetAttribute (comPort, VI_ATTR_RD_BUF_OPER_MODE, VI_FLUSH_ON_ACCESS);
 status = viSetAttribute (comPort, VI_ATTR_ASRL_BAUD, baudRate);
 status = viSetAttribute (comPort, VI_ATTR_ASRL_DATA_BITS, dataBits);
 status = viSetAttribute (comPort, VI_ATTR_ASRL_PARITY, parity);
 status = viSetAttribute (comPort, VI_ATTR_ASRL_STOP_BITS, stopBits);
 status = viSetAttribute (comPort, VI_ATTR_ASRL_FLOW_CNTRL, flowControl);
 status = viSetAttribute (comPort, VI_ATTR_ASRL_DISCARD_NULL, VI_FALSE);
 status = viSetAttribute (comPort, VI_ATTR_ASRL_END_IN, VI_ASRL_END_NONE); 
 status = viSetAttribute (comPort, VI_ATTR_ASRL_END_OUT, VI_ASRL_END_NONE);

[MJF]

Adding more info on this problem.

Make this 4 total PCs that exhibit the GPF. Two have VISA 4.5 and two have VISA 4.6.2 (CVI is licensed via network server icense checkout).

The GPF ONLY occurs if I try to debug the application. If I create a release version and run it, the GPF does not occur and the VISA functions operate correctly according to NI-Spy.

I am beginning to think this may be related to the CVI Run-time engine and not to VISA. The RTE on all of these PCs were updated when the VISA versions were updated.

Making things much worse and causing me a lot of pain, I attempted to do a complete uninstall of CVI and all associated drivers from one of these systems so I could do a re-install and this left that PC completely unable to access the LAN.

I seriously need help here, I can't continue to develop applications if I can't debug them. I don't know if this is due to a recent spate of OS and application updates or something else but we have had several forced upgrades and bug-fixes applied on all PCs here. (Lots of MS Office security fixes and patches).

[MJF]

Does anyone have any clue here?

This is killing me. I can't debug anything while this problem exists.

[RobertoBozzolo]

Hi Martin, I cannot offer any clue since I never use VISA in my applications. Since you are using VISA to perform serial communications, have you considered to switch to RS232 library instead of VISA for serial access? I know this is not the ecat answer to your question but could permit you to proceed with your work.

[Anna_K.]

Hello, 

VISA 4.5 and 4.6 are both compatible with CVI 7.1 so that should not be the problem. I do not see a viClose in your code, are you closing the reference to both the instrument and the defaultRM?

Can you try running one of the VISA examples for CVI and tell me if you get the same error? Give this a run: C:\Users\Public\Documents\National Instruments\NI-VISA\Examples\C\Serial

(  this will be a different directory on a non-windows 7 machine, you can find it in Start>> Program Files >> National Instruments >> VISA >> Examples )

Thanks,

Anna K.

[nickb]

Hey Martin - 

I just put CVI 7.1.1, VISA 4.6 and TestStand 3.1 on an XP test machine and tried to run some VISA examples, and saw none of the crashes you are reporting.  Is there anything else I may need to install to get into the same state you're in?  

Also - that address in the message popup is curious - if from CVI you select Run»Loaded Modules, do you find that address in the range of any of your loaded modules?

NickB

National Instruments

[MJF]

I prefer to use VISA because if I then change to another interface type in future (like TCPIP) it makes the migration far simpler.

I also REALLY dislike the old legacy RS232 library (and the old GPIB library too).

[MJF]

Anna,

I have viClose functions in my code, I just did not include them in what I posted (and what is there is simply the initialization stuff I was trying to get working before I wrote the actual communications stuff to talk to the instrument).

The crash occurs as soon as I try to debug the program, it never even gets to the any of this code. If I exclude all of the VISA functions, it compiles and works. If I put any of them back in (does not matter which one), it crashes.

All of the machines in question have Win XP, CVI 7.1.1, VISA 4.5 or 4.6, and TestStand 3.1, some also have LabView 7.1, 8.2 and 8.5

I will try the example tomorrow morning. I have been busy with other things all day today and am about to call it a day when I am done here.

[MJF]

To be honest Nick, there is a lot of software installed on all 4 machines. I don't have much of a clue what may be common because one of them is a stand-alone machine off the network that has a stand-alone license. That machine is pretty bare-bones.

The only thing I can think of that might be at issue here is some customer supplied software. The customer has produced a bunch of wrapper functions for instruments, TestStand sequence models and DLLs for use on their test system that they supply to us for the hardware we manufacture for them. This customer is why I am stuck with CVI 7.1.1 (that and a very LabView heavy political climate for internal use).

I don't know if I can provide you with the customer SDK to see if that might be the cause. I will have to look into that. (Customer is Lockheed-Martin and the software is for their LM-Star test station). We may have to talk about that off-line to see if I can get you a copy of it to try.

I will see if I can figure out what that address range is associated with when I try to run the example code tomorrow morning that Anna asked me to try.