how do I specify an IP address as the visa resource name

[_S_G]

I'm trying to talk to an Agilent 34220A and found instrument drivers for this on ni.com.  However, I am not connected to my device using GPIB or USB.  The instrument is on a network and has an IP address (10.7.0.47).  Can this IP address be directly used as a VISA resource name?  If not, what format should I use?  I know the instrument is working because when I open this address in Internet Explorer, I am able to control the device.

[smercurio_fc]

Yes. From the LabVIEW Help:

TCPIP[board]::host address[::LAN device name][::INSTR]

Example: TCPIP0::1.2.3.4

Not to be blunt, but, errr... shouldn't a LabVIEW Architect know this?

[Darin.K]

Here is what I used for my scope.

MAX link

[_S_G]

smercurio, if the solution was as easy as you suggested, I wouldn't have posted my question on this forum.

I finally got it to work, but in an unexpected way.  Here's a more detailed description, and you can decide for yourself if the question warranted posting.

When I used any of the following, communication failed.

TCPIP0::host address

TCPIP0::host address::inst0::INSTR

TCPIP::host address::inst0

Communication worked when I used

TCPIP0::host address::INSTR

Keep in mind that according to the specification from the LabVIEW Help, the [board] is optional and has a default value of 0, [::LAN device name] is optional and has a default value of inst0, and the [::INSTR] is also optional.  Yet the first 3 cases don't work, and the last one does.  I still don't know why this is the case, but I discovered this only through trial and error.

[Dennis_Knutson]

What format was listed in VISA Resource Control for you to select from?

[smercurio_fc]

---

S G wrote:

smercurio, if the solution was as easy as you suggested, I wouldn't have posted my question on this forum.

I finally got it to work, but in an unexpected way.  Here's a more detailed description, and you can decide for yourself if the question warranted posting.

...

---

Well, that's a little different, now. You have to admit that your original post made no mention of what you had tried, and all that you had asked was a general question whose answer could be found in the LabVIEW Help. This is what I found somewhat surprising.

[rolfk]

I had never problems to use TCPIP::host address::SOCKET but that was for raw communication and I have since long time refrained from using VISA for TCPIP raw connections because in a 24 hour/7 day setup it did not always perform reliably for network connections. Using the build in LabVIEW primitives instead for raw TCP/IP communication allowed me much better to get the communication working and working reliable.

And I have a feeling that TCPIP::host adress would work for an Instrument resource that is connected to the default network card.

Rolf Kalbermatter

Message Edited by rolfk on 07-23-2009 07:35 AM

[pincpanter]

Hello Rolf,

what problems did you find using VISA for raw TCP?

I also got into troubles some times ago: the polling rate was slowing down more and more with time, so I had to change some parts of the software: now it seems to work good (at least, good enough for me).

I used VISA because the instrument could be connected through Ethernet or serial with the same protocol, and I wanted to used the same vi's. Of course, I needed to make some minor changes in case of Ethernet connection.

[rolfk]

Well it is quite some time ago and with older versions of VISA so I'm pretty sure it got better in the meantime. Problems I had were several such that at high network load the communication started to get unreliable without error indication whereas doing the same with LabVIEW did either work or return errors.

Another issue I had, probably due to dynamic DHCP IP adressing was that at times the resource simply lost the connection to the remote side without any error indication. I could continue to send data to now end without any error indication at all. Reconnection for each data packet was not practical since there was quite some status traffic going on, and I had simply relied on the proper error indication to close and reconnect in error cases only. I had been choosing VISA TCPIP at that point becasue the applciation had slowly evolved from all RS-232 devices to some using TCP/IP including to other LabVIEW applications that were automating a particular task of the labor automation system.

Reimplementing the entire communication to use the native TCP/IP nodes instead was no trivial task either but with a bit of trial and error I got a fully reliable connection in that way.

Rolf Kalbermatter

[pincpanter]

Thanks for the info, Rolf.

Definitely not the same problems I noticed. I also used an old VISA version (3.1).

In one case I found that simply reading a VISA general property while initializing the resource caused the communication to be impossible (no response received)!!

S G, sorry for hijacking your thread, I will not get further into it.

Good G-ob to all!