LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VISA error with TCP-IP BK precision 2190E

Dear all,

I have a weird error.

I can do query *IDN? in NI MAX with TCP-IP connection.

I gave an alias for this unit in NI-Max.

No I try with LabVIEW.

There is no need of \n at the end of the command. Tested in NI max and in USB mode.

querry: *IDN? answer: Vendor,2190E,512E18239,6.01.01.19\n

 

Now there is the problem:

In LabVIEW, I try to connect to the Oscilloscope send the *IDN? string and I got the error:

-1073807343

with description:

VISA:  (Hex 0xBFFF0011) Insufficient location information or the device or resource is not present in the system.

 

If I click run again on the VI I receive the expected answer.

 

The other problem I have is if I add close visa session at the end of the VI (see picture), no matter how many time I try it, I always receive the same error.

 

Is there a way to fix that?

 

here is the picture of the code:

image.pngAny helpful comment will be appreciate, but those who experienced this situation and was able to fix it are the most wanted.

PS: I tried every suggestion on other post similar to this one.

LabVIEW version 2018 NI VISA 18

Benoit

0 Kudos
Message 1 of 10
(2,585 Views)

I add another test that prove the problem might be a bug of LabVIEW:

If I use the Instrument I/O Assistant, The problem do not occur in the assistant. But as soon as I try to run the "VI" that the assistant create, I have the same error appearing.

 

I have the same behavior if I try to add close session to the VI created by the assistant. (open front panel)

 

I tried with LabVIEW 2017 and still the same behavior... It's pointing to VISA issue rater than LabVIEW.

 

Benoit

0 Kudos
Message 2 of 10
(2,574 Views)

WTF!!!

I can prove that it is a bug.

here is the code in the picture bellow.

the first result of the *IDN? report nothing and i get an error.

Since it is a dynamic call, the VI is close after the call.image.png

The the session is still in memory and the second call works.

Is someone that is an alliance partner of NI that can report this bug. Other LabVIEW developer are not taken seriously.

 

Benoit

0 Kudos
Message 3 of 10
(2,561 Views)

if its a tcp-ip communication you can try using the dedicated tcp-ip vis and tools in LabVIEW. IF you click on help, find examples and type in "tcp" you will find some examples on how to use the tcp-ip subvis

0 Kudos
Message 4 of 10
(2,557 Views)

Thanks for the suggestion, but it is not acceptable since I'll have to develop a low level TCP-IP protocol to replace the VISA driver... I wont spend 1 year of development and validation to avoid a LabVIEW/VISA bug.

Benoit

0 Kudos
Message 5 of 10
(2,551 Views)

TCP wont be much different than VISA as a lot of the functions are automated and prebuild. Anyway, my second suggestion is, and I know it sounds a bit obvious but after opening your visa port to provide 2-3 sec delay for the port to initialize. I noticed that problem when I was using visa to talk to a micro stepper device and ever since I am always providing a 3000ms delay after my visa open or visa configure. If you provide that delay you will notice that it does get rid off the problem of needing to run the vi twice to get the expected result.

Message 6 of 10
(2,528 Views)

I tried the delay approach.

As you can see in me dynamic call, I have no delay. and it works.

Benoit

0 Kudos
Message 7 of 10
(2,504 Views)

@bseguin wrote:

Thanks for the suggestion, but it is not acceptable since I'll have to develop a low level TCP-IP protocol to replace the VISA driver... I wont spend 1 year of development and validation


From your *IDN? example, it doesn't look you're going to use any exotic or low level VISA - will you really need it for something more complex? For mere command passing, I found VISA or TCP almost interchangeable, save perhaps differences in reading till a terminator character, which can be worked out. To the point, I have this .vim lying around - it accepts as input either a VISA resource or an open TCP session.

On the other hand, are you 100% positive that the quirk is not at your scope side? I have had one story sort of like that some time ago. Have you tried with a different TCP instrument?  A convenient test may be with a serial device connected to an ethernet-serial converter.

Enrico

 

0 Kudos
Message 8 of 10
(2,487 Views)

There is multiple work around. I chose to just add the dynamic call before my initialization and then all function are working. Going TCP-IP is not a solution, since I want to use Visa for HAL "Hardware abstraction layer" reason. By using Visa i can use USB/Serial/TCP-IP connection without having to change my VI.

Now What I was not able to do:

-Try with another TCP-IP instrument: I do not have one on hand.

-Try with a TCP-IP to serial:  I do not have one on hand.

So, Is anyone of you can try with the latest Visa driver and latest LabVIEW to replicate the problem? so we can send that to NI? (I do not want to just find a work around, but I want to fix the source of the problem.)

Thanks

Benoit

0 Kudos
Message 9 of 10
(2,481 Views)

I don't have an installation at hand with 18 and TCP instruments, sorry...

0 Kudos
Message 10 of 10
(2,477 Views)