How to speed up VISA LAN instruments?

[Martin1454]

Currently I'm working on a project where I'm using a lof of Keysight instruments (Power supplies, loads, DMMs) 

In the old system we used GPIB and I could see in NI IO trace that a read current command would take around 6ms from a power load.

In the new system we are using LAN connection for all instruments, and communicate with VISA, and here a read current command from a power load takes around 100mS. In the datasheet, I cant see that the instrument should be able to measure way faster, so I think its my VISA settings that slows it down. 

Right now, I have disabled Nagle's algorithm, have a queue length of 50, timeout of 2000 and send END (Wrt) enabled - I dont have "supress end" and "termination character" enabled. Data is returned as string, and it does not allow DMA or asynchronos timeouts. I also don't use "keep alive" packages.

What can I do to try to speed it up? - I'm using an older NI measurement studio with VBA to communicate. 

[cymrieg]

Are you using a Visa socket or instr connection?

TCPIP::"IP Address"::hislip0::INSTR   <- fastest if supported

TCPIP::"IP Address"::INSTR   

TCPIP::"IP Address"::5025::socket

Although the raw socket should be the fastest; no protocol overhead, problem is Visa does not know if the instrument is done sending data back. VXI-11 has more protocol overhead but at least Visa client knows how much data is coming back from instrument and so can return quicker. If you are using socket then make sure you have term char on and its linefeed. Then a socket knows the client knows the instruments is done sending. This last one is if you are not using binary transfers of course. If you are using binary transfers (quickest) then you really need to use VXI-11 or preferably hislip (if supported)

[Martin1454]

All of the instruments I'm running is setup using "TCPIP::"IP Address"::hislip0::INSTR"

binary transfers - Where do I set that setting / see it? Is it the part where I have "Data is returned as string"?

[cymrieg]

Binary mode is really only going to help if transferring "largish" chuncks of data.

There is a command to tell instrument to transfer data as binary (sreal(single), or dreal (double)). Then in C Visa you use the same read command and disable the lf terminator as it might crop up in the middle of the binary data. If using .NET or COM Visa then there are usually commands to read binary blocks which handles returning floats or double.

For the C Visa read the first part of the data will look something like this: #ABCCdddddddd...........lf

# is start of binary data

next char is how may of the next bytes make up the length of data after this. Eg in this case B would be a 2 indicating that CC is the length of data coming. Then you need to break it up into groups of 4 (single) or 8 (double) for cc numbers. So you could request with the read

1. - 1 byte (#) throw it away
2. - 1 byte length size
3. - request bytes returned in number 2 (above)
4. -request amount of data returned in 3 and break up into blocks of 4 or 8 (depends on what you set the instrument to)

You can also request the whole thing in one request if you know how much data should be returned. Binary data is always complete when a Lf is returned at the end. But I have seen cases where the lf is part of the binary data so you really need to tell Visa read how many chars to read.

As you can see this is not optimal for smaller transfers.

[Martin1454]

Hmmm.... Yeah, and the issue is I mostly only get small data amounts, but the latency between the small data is too high.