11-17-2011 11:44 AM - edited 11-17-2011 11:54 AM
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.
11-17-2011 11:56 AM - edited 11-17-2011 11:58 AM
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
11-17-2011 12:04 PM
The point on writing SCPI-RAW server code is:
(1)the device must launch TCP 5025 listener task, that's all !
11-20-2011 07:46 AM
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!
11-21-2011 01:47 AM
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!
11-21-2011 02:33 AM
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.)
11-21-2011 08:08 AM
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.
11-22-2011 09:49 AM
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!
11-29-2011 08:52 AM
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)
Capture data(VXI-11)
11-29-2011 07:45 PM
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.