From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

VXI-11 Server Example

The RPC port mapper function (program = 100000, vers = 2, proc# = 3) on UDP 111 (broadcast) is used for VXI-11 discovery. This is normally used by NI-MAX when it seaches for available LXI devices or used by VISA viFindResource() function.

 

The same RPC port mapper function on TCP 111 (p2p connection) is used for initiation of a VXI-11 instrument connection. This is normally used by NI-VISA when you call viOpen() with a specific IP address given.  The actual VXI-11's Core Channel port# is acquired by the first port-mapper call which will answer the actual VXI-11 core port#  in the RPC reply packet (for example, 1024, 10001, etc... up to to instrument implementation.)

 

Once you obtained the VXI-11 Core port#, you can connect the VXI-11 instrument with the acquired port# on TCP. The first call on this port will be the "create_link" procedure (program = 0x0607b1, vers = 1, proc# = 10). This RPC header can be analyzed very clearly by the latest version of WireShark in detail. It just has a simple RPC header on a TCP traffic send/receive, so I believe you can write fake VXI-11 server code regenerating the same behaviour. Once you have written a good fake code, the client VISA call (from LabVIEW) will believe that it is connecting a real VXI-11 device !

 

As for SCPI-RAW implementation, the server code can be written by using the LabVIEW's TCP socket library, by Microsoft C/C++ using WinSock library, or C# using .NET library. You can choose any.  I do not recommend using VISA because is is designed for "client" use. What you are going to write is server-side code.

Message 21 of 37
(9,663 Views)

The points on writing VXI-11 server code are:

 

(1)the device must launch UDP 111 daemon to process RPC port mapper procedures

(2)the device must launch TCP 111 listener to process RPC port mapper procedures

(3)the device must launch VXI-11 Core listener (TCP any port#) to process VXI-11 Core Channel procedures

(3)the device must launch VXI-11 Async listener (TCP any port#) to process VXI-11 Async Channel procedures

Message 22 of 37
(9,652 Views)

The point on writing SCPI-RAW server code is:

(1)the device must launch TCP 5025 listener task, that's all !

Message 23 of 37
(9,646 Views)

Thanks Makoto! I am very appreciate for your help!

 

The informations are very useful,but I only simulated a VXI-11 call message  from LabVIEW with TCP funtions so far,I need to konw more about TCP/IP protocol,there a lots of works to do.

 

I will report here few days later.

 

Best wishes!

0 Kudos
Message 24 of 37
(9,613 Views)

I listen to the port 111 and make the MAX treat the PXI controller as a LXI instrument using "TCP:168.172.xxx.xxx::5025::Socket",but the problem is that I cannot get the source port which the host computer is using so I cannot reply messages to the host computer for quire command  like "*IDN?\n",I can found the source port and destination port from the TCP handshake data,but not from LabVIEW,it seems the functions on LabVIEW are high level functions and can not get the RAW data.

I got the same problem when sending VXI-11 data from LabVIEW.

Do I need some additional toolkits or DLL to capture the TCP handshake data to get the source port in using since the source port is dynamic.

 

Appreciate for your time!

0 Kudos
Message 25 of 37
(9,604 Views)

I feel bit strange, the visa address "TCP:168.172.xxx.xxx::5025::Socket" is a SCPI-RAW connection, not VXI-11. Is it a mistake of "TCP:168.172.xxx.xxx::INSTR" ? Or you mean NI-MAX's "search instrument" operation?

 

As for TCP IP low level programming at server side, I dont know how LabVIEW can program lower detail handling on TCP and UDP. I think a protocol processing code like RPC and VXI-11 is better and easier if writing in C (using WinSock), and create a wrapper DLL for use with LabVIEW as call-library functions.

 

However, as for RPC and VXI-11 protocol codes when writing in hands, what required are normal UDP daemon and TCP listening (and responding) programs. It is very similar to writing DNS code (in UDP) or Telnet code (in TCP). So I believe it is possible to write them in LabVIEW. (Sorry but I am not familiar with LabVIEW programming.)

Message 26 of 37
(9,600 Views)

I am trying a SCPI-RAW connection first since it is much easier,mybe my description is not clear enought.

 

I manual entry the raw socket in the MAX,and listen port 5025,it didnot report a error when I open the VISA test Panel,I also capture the right packets from Wireshark.

 

There is a library  packet_sniffer_project.zip which can wrap various ethernet packet in LabVIEW using WinPcap,it is useful for my project,I will try it later.

 

I am no familiar with network protocol,still have a long way to go.

 

Thanks Makoto,I will report later.

 

 

 

 

0 Kudos
Message 27 of 37
(9,606 Views)

I managed to sent back message to VISA Test Panel on MAX from PXI controller using SCPI-RAW connection,so at least I have one solution for for my PXI controller to be found as a LXI instrument.

I went to a wrong way few days ago,otherwise  I can get it more earlier.

To summary,as Mokoto mention above

 

The point on writing SCPI-RAW server code is:

(1)the device must launch TCP 5025 listener task, that's all !

 

you can use the LabVIEW example named "Data Server.vi"(Program Files\National Instruments\LabVIEW x.x\examples\comm\TCP.llb\Data Server.vi),change the linsten port to 5025,and open VISA test panel on the other PC,after the connect is creat,the Data Server.vi can write to TCP depend on the SCPI command it read.

 

I will try writing VXI-11 server code later.

 

Thanks Mokoto,I am very appreciate for your help,have a nice day!

 

0 Kudos
Message 28 of 37
(9,586 Views)

I managed to write VXI-11 Client code using TCP functions in LabVIEW these days but not VXI-11 server code,the problem is that when I listen to the TCP port 111,the host PC can create TCP connection with my PXI controller,then the host PC sent a Portmap message immediately after handshake,and the server code in PXI controller can not response in time,after few seconds,the  MAX popup a timeout dialog and the connection closed. After that,the server code sents the Portmap Reply message  to the host PC.but it is too late.

I use VISA test panel in MAX as VXI-11 client,and modified the TCP listen example as VXI-11 server code,see the attachments.

I am wondering if there are some lowlevel functions can make TCP response faster,or I  use the TCP function in a wrong way?

Capture data (Portmap Fail)

VXI11-Pormap-fail.png

Capture data(VXI-11)

VXI-11.png

0 Kudos
Message 29 of 37
(9,551 Views)

Sorry but I cant figure out the LabVIEW program (attached vi) logic in detail, but it may be a multi-threading issue. As I see the Wireshark (failed) log, the Portmap reply (from 169.254.254.253, V2 GETPORT REPLY) that was sent from your LabVIEW code after VISA timeout (as marked FIN ACK) looks like correct.

 

Try to check if your LabVIEW's TCP-write function (for portmap reply) is already invoked when VISA viOpen (from MAX) is waiting for the reply (until timeout expires). If TCP-write is already invoked but Wireshark does not display the reply packet log, try to check what your LabVIEW code is doing after TCP-write call. Your LabVIEW code looks like it is continuously checking STOP button to be pressed in the FOR loop, with full-CPU thread time. If so the TCP-write function may not send TCP packet because it could not acquire the CPU time. If this is the case, your program should free up the CPU time.

 

 

0 Kudos
Message 30 of 37
(9,543 Views)