>>
AS NI-VISA does not support port mapper services at all my VXI-11 instruments must use TCP raw sockets to open the interrupt channel to the NI-VISA PC computer server that is waiting for SRQ event after this event has been enabled?
<<
Yes, your instrument must start connection for DEVICE_INTR channel using RAW SOCKET (STREAM). As you can't use ONC RPC clnt_create(), and you should use the traditional BSD functions such as socket(AF_INET, SOCK_STREAM) and then connect(). But it is ***not*** meant that your instrument falls into "no-protocol" raw TCPIP interface. Your instrument is still VXI-11.
>>
Currently our VXI-11 instrument developer is using RPC call libraries and is calling the RPC clnt_create(host, prognum, versnum, "tcp") to create a client that will post SRQ interrupts to NI-VISA TCP server but seems that as you say is not working with NI-VISA.
<<
Your instrument can't call clnt_create() for start the DEVICE_INTR connection, because clnt_create() function requires that the server-side (in this case, VISA) has to provide the Port Mapper services. Use socket() and connect().
>>
1.Step 1
The PC IP address and TCP PortNumber# is passed to VXI-11 instrument by NI-VISA when SRQ is enabled trough a create_intr_chan RPC call.
2. Step2
The VXI-11 instrument tries to create a TCP client on the instrument side by using the RPC client create function with the [ hostaddress( PC IP address), prognum# , progversion# and "tcp"] as input parameters.
3. Step3
The Port Mapper on the NI-VISA server side would be required to map the prognum# coming from this RPC call to the TCP PortNumber#.
<<
The Step1 is right, but the Step2 is not. When starting DEVICE_INTR connection, the instrument, from inside the create_intr_chan() routine, should use socket() and connect(). When connecting, that target IP address and Port# must be the same values that are given by Device_RemoteFunc parameter on create_intr_chan() call. Plus, mind that no data shall be sent to the host PC at the point of time. Your instrument shall start connection without sending any data, therefore don't call sendto() then. It is normally guaranteed that the VISA software is already "accepting" on the specified port# before invoking create_intr_chan(). Normally connect() call from your instrument must succeed. But if it has failed, the instrument create_intr_chan() shall return 6 (channel not established) as error status code.
Immediately after create_intr_chan() call, your instrument will be invoked on device_enable_srq() to enable it. Then keep backup of the given handle<40> string, for the case the instrument will call device_intr_srq().
This approach does not require that the VISA software has to provide Port Mapper. But when your instrument notifies an SRQ through device_intr_srq() function, your instrument must construct an emulated RPC header struct by hands. (The DEVICE_INTR is still VXI-11 based, not a raw socket.) In fact, a Remote Procedure Call is a pair of sendto() and recvfrom() operation. Therefore, when SRQ is asserted, your instrument must call sendto() with RPCHDR and recvfrom() for the response sent back from VISA that will have REPLYHDR.
Then each traffic has a struct of RPC header in the beginning part. On an RPC call through TCP/IP, the following headers are given before the opaque data entity, for RPC call and RPC reply respectively. Each data field must be of Network-Byte-Order (= big endian).
typedef struct rcphdr
{
uint32_t length; /*with MSB must be set*/
uint32_t xid; /* Transaction Identifier */
uint32_t msg_type; /* Message Type */
uint32_t rpcvers; /* RPC Version No. */
uint32_t prog; /* Program No. */
uint32_t vers; /* Program Version No. */
uint32_t proc; /* Procedure No. */
uint32_t auth[4]; /*authentication data*/
} RPCHDR;
typedef struct replyhdr
{
uint32_t length;
uint32_t xid;
uint32_t msg_type;
uint32_t reply_status;
uint32_t auth_type;
uint32_t auth_len;
uint32_t accepted_status;
} REPLYHDR;
As for authentication data, they can be all zero as probably your instrument does not implement authentication on DEVICE_INTR messages.
The sendto()/recvfrom() call on device_intr_srq() is slightly simple. I believe you can implement these structs on your raw socket calls through the DEVICE_INTR channel. Any network SPY software can be used to view these traffic. For a good reference, I recommend you to take a look with an actual LXI instrument.
