Upgrade of CVI / Win: now receiving VISA error: insufficient location information...

[Wolfgang]

Dear all,

I'm facing the following issue:

We have replaced our old lab computer by a new model and used the opportunity to also move to a more current operating system (from Win XP to Win 7 64 bit) and to the current version of CVI (2013 SP2), its runtime engine, and all the device drivers (latest 2014 versions of VISA...).

One of our data acquisition software (written many years ago in CVI 2009, 32 bit) now on startup shows an error message:

VISA error: insufficient location information or the device or resource is not present in the system.

Unfortunately, for me this information is not detailed enough: we do have six boards from NI, the same we have used before. MAX shows all the boards, so at first glance it is not so obvious to me what to learn from this error message, or how to continue...

Any advice is welcome

[Miello]

Hi Wolfgang

It sounds like the problem lies in the written software. Does this software use visa aliases? They are reseted by a system upgrade and if you use them, you have to set them from anew.

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

Otherwise look at the source code of the software and see if there are any invalid function calls or constants. From 32bit to 64bit the CVI code changed a bit, mainly pointers, so you have to adjust those.

http://zone.ni.com/reference/en-XX/help/370051Y-01/cvi/programmerref/porting32bitto64bit/

Best

Miello

[mkossmann]

Did you allready run NI IO-Trace  to log the VISA calls of that program ? Looking into the logs will show you which VISA call ( to which board) returns the error code and you might get an idea what's going wrong there.

[Wolfgang]

Thanks - I got so used to a working system that I forgot about those basics

Actually this sheds some light onto my question - without answering it yet...:

What the software is doing at program startup is searching all available serial ports, using viFindNext, opens and queries the port, closes it, and then continues with the next one.

Now the somewhat surprising result: it works for ASRL 3 (COM 1 of a NI 16 port board) up to ASRL 9 (COM 6); however ASRL 10 throws the above mentioned error, whereas ASRL 11 (COM 😎 to ASRL 19 (COM 16) work well.

Does it mean that port 7 has died?

[mkossmann]

What shows the windows device manager about that port ?  If it's not visible at all , it's probably a real hardware defect . If it shows problems , trying to reinstall the windows driver might help.

[Wolfgang]

Hi,

I am sorry for the late reply... today I tried your suggestion but without gaining much insight; Windows device manager shows all ports, and for all ports it claims that the device is working properly.

I will try two more things tomorrow

[Wolfgang]

O.K., after disconnecting all serial devices, just keeping the NI serial boards installed and still receiving the same error I looked a bit more carefully (I could have been more careful earlier, of course...) and realized that the problematic port is assigned to LPT 1.

Well, my new computer does not have LPT 1. MAX, for example, knows this and shows a red x.

So, this explains everything - does it?

After viFindRsrc ( resource_manager_handle, "ASRL[0-9]*::?*INSTR", &find_handle, &return_count, instrument_descriptor );

my software checks the port type (COM (RS232/RS485) or LPT) for each port and this worked in the past because LPT 1 was present.

The routine is like this:

VISATestSerialPortAvailable ( ... )

for ( index = 2; index <= return_count; index ++ )
{
    status = viFindNext ( find_handle, instrument_descriptor );
    if ( status == VI_SUCCESS )

    {

        VISATestSerialPortAvailable ( ... );

    }

In the VISATestSerialPortAvailable ( ... ) routine the first command is viOpen which fails with the above mentioned error - this makes sense, if the port is not available, but the question is, why does viFindRsrc find the nonexisting port?

[Wolfgang]

Here is the respective screen shot of MAX...

[Wolfgang]

One last note: Windows device manager does not list a LPT, so I consider my observation a bug in VISA (the latest version).

My software and MAX are showing the same result, they find a resource but cannot open it.

[Wolfgang · Accepted solution]

After opening a support request our kind local support informed me today that this is a known issue, CAR 242354, supposedly fixed in VISA 15.

Kudos to her