Inconsistency among new VISA controls

[Atlantex]

I am building an instrument driver using VISA functions to talk to an Ethernet-based device. I am running VISA 2.6.0 under LabVIEW 6.1. My instrument driver is based on the NI template. The NI template uses the Old VISA commands that accept and pass on a VISA refnum. Some of the new VISA controls (that appear on the function pallette) accept and pass on VISA resource names, so still require refnum's. Subsequently, I can't wire some of the VISA controls together. For instance, if I call VISA open with a VISA resource name (ie. TCPIP::...::SOCKET), I can't wire it to a TCP/IP Property Node since the property node accepts a refnum for its input. Can anyone tell me how to resolve this or how to find the Old VISA functions (t
hey do not appear on my function pallette).

Thanks,

-John-

[Dan_Mondrik]

John:

I'm not sure what you mean by "TCP/IP Property Node". I think you might mean the VISA Property Node to get TCP/IP specific properties.

Make sure the VISA class is the same for all refnum controls and indicators, even the template ones - in your case, probably TCP/IP Socket. You can set this by right-clicking on the control/indicator and selecting the appropriate VISA Class>>I/O Session.

Dan Mondrik
Senior Software Engineer, NI-VISA
National Instruments

[Atlantex]

Yes, you are correct that I meant VISA Property Node.

The VISA class is the same for all refnum controls and indicators (actually, I am using VISA Resource Names per the help windows for the new VISA functions).

I am having problems with the following connections, specifically:

1. From the output of VISA Property Node to the input of VISA Flush Buffer
2. From the output of VISA Read to my dup VISA Resource Name.

The order of connections is:

VISA Resource Name -> VISA Open -> VISA Property Node -> VISA Flush Buffer -> VISA Write -> VISA Read -> dup VISA Resource Name

If I remove the VISA Flush Buffer function, I can get everything to wire up correctly. It appears that the VISA Flush Buffer requires a 16 bit integer for an input (accor
ding to the error message), contrary to what the help for the function states.

Does this make any sense?

Thanks,

-John-

[Dan_Mondrik]

John:

Your problem with VISA Flush Buffer uncovered a bug. If you are feeling lucky, you can modify your visarc file (in the LabVIEW\resource directory for version 6.1) to add this line under the TCP/IP Socket section, along with the other methods:
method: "VISA Flush I/O Buffer" noInvoke

Warning: If you copy your VI from your machine and load it on any other machine without this change, LabVIEW will probably refuse to compile your VI. So it's not an extensible solution for you for now. (We will fix this in a future version.)

Another possibility is to change the VISA class to TCP/IP Instr, which should work unless you are trying to query the TCP/IP Port property, which is not a property of that class (just Socket). The TCP/IP
Instr class does have VISA Flush as a valid method.

As far as VISA Read not wiring to your dup name, make sure that both the control and the dup are of the same class - if so, this should not be a problem. If you still have trouble getting this to work, feel free to send in your broken-wire version to our tech support team and they can troubleshoot further.

Good luck,
Dan Mondrik

[Atlantex]

Hmmm...

Option 1 (changing visarc) doesn't sound all that portable.

Option 2 (changing the VISA class) could work, except that I know nothing of how the TCP/IP Instr class talks to the device (ie. is there a standard socket). Can you point me in a direction there?

The issue with the Read not connecting clears up as soon as I remove the Flush. Maybe the Flush function was casting the input (and subsequently the output) of the Read function?

Thanks,

-John-

[Dan_Mondrik]

John:

With the read/flush wiring problem, I think you're right. Since the flush wouldn't accept the Socket class, it probably used some default (such as Instr) and then it wouldn't wire to your dup indicator.

As for using the TCP/IP INSTR class, I'll let you in on a secret. LabVIEW doesn't (currently) enforce that the session actually uses that protocol. (I dont' anticipate that behavior changing any time soon.) It's just a compile-time selection of the appropriate methods and properties. So your refnum of that TCP/IP Instr class can actually open a TCP/IP Socket resource. Make sense?

Dan

[Atlantex]

Dan,

I'm not exactly sure what you mean by your second paragraph as I am unfamiliar with the TCP/IP INSTR class. Are you saying that there is an accepted protocol for that class, but that LabVIEW doesn't check it?

Assuming that this is the case, it's still not obvious to me how LabVIEW opens a connection to a TCP INSTR class device. With a TCP SOCKET device, I specify the IP address and socket of the target. How do I do that with a TCP INSTR class device?

My intent in all of this was to create a standard VISA instrument driver. I think that I may be better off for now just using the straight TCP/IP functions rather than VISA reads/writes, and updating the instrument driver later when the VISA TCP/IP drivers
are updated.

I am new to LabVIEW programming and instrument driver creation, so any thoughts on the pluses/minuses of this approach are greatly appreciated.

Thanks,

-John-

[Dan_Mondrik]

John:

When you are designing your VI, the class that you choose when you right-click the control determines which properties and methods LV will allow you to connect that VISA refnum to. That class you choose from that right-click menu is ignored at runtime.

At runtime when you open the resource TCPIP::hostname::port::SOCKET, NI-VISA opens a connection to the IP address and port number you specify. It does not use the LAN Instrument protocol.

What I tried to hint before is that LabVIEW does not notice this difference. It will just work.

Whether you want to use TCP/IP is up to you. NI will of course continue to support all the code out there that uses the traditional TCP/IP and UDP functions
(the latter is something NI-VISA does not support).

Assuming that you get the class selection to work, then the only factor that should affect your decision, in my opinion, is whether your VI's look close enough to standard instrument driver VI's. Even though you wouldn't have a VISA refnum if you choose the traditional icons, they still use a type of refnum, so from a higher level it should neither look nor behave differently. It's completely your call.

Hope this helps,
Dan Mondrik