maximum viRead data length over TCP/IP

[SteveL]

I am using VB6 to control an instrument under development using VISA over TCP/IP (VXI-11). My code communicates with the Visa32.dll through the VISA COM GlobMgr.dll, although I don't think this is relevant to this question as I am using NI-Spy to capture the Visa32.dll calls.

My question is: Is there a defined upper limit for the length of data returned by the viRead function over TCP/IP?

My code is reading binary measurement data containing a stream of IEEE-754 single precision floating point values from the instrument. The data length depends on the measurement configuration and the theoretical maximum is around 256 kBytes. The viRead function is called with a 'count' value of 256100 and the 'retcount' value for the current measurement configuration is 20526. The binary data viewed in the NI Spy buffer capture looks to be good for about the first 8 kBytes, but then becomes corrupted in a way that suggests the buffer is running into an area of memory used either by the operating system or the NI software (there are text references to both in the corrupted area). When my application attempts to interpret the floating point values it eventually throws an exception with a NAN (Not A Number) value.

The problem can be reproduced in MAX. A WireShark capture on the Ethernet interface shows that the data sent by the instrument is not corrupted. The problem does not occur when performing the same viRead function over GPIB.

Windows XP, SP2.
VB6, SP6
NI-VISA 4.4
NI-MAX 4.5

[John.P]

Hi Steve,

I am afraid I do not have a hard and fast answer for you about this.  My guess is that it is something to do with the packets over the TCP/IP connection.  Packets normally have a maximum size of 1.5k Bytes so obviously the message is been broken up into multiple packets.  As to why the data is intact for the first 8k and then becomes corrupted I am not sure.

My suggestion would be to make multiple calls the instrument, requesting a much smaller amount of data on each call.

Have you attempted this? What was the result?

You appear to have isolated the problem to VISA as the data from the instrument is intact, but do you have another instrument you could test this on, are the results the same?

Best regards,

John

[SteveL]

Hi John,

Thanks for your reply. We tried several of our instruments (and two PCs) with the same results. We also tried another vendor's instrument with a large binary transfer and did not see the problem. However, when we examined the Wireshark capture for that transfer we noticed that the instrument was sending the data in smaller blocks at the RPC level. Since our corruptions were occuring at around 8 kB, we modified the code in our instrument to split the data in the RPC calls into 4 kB blocks and the problem disappeared. We have since done extensive testing without data corruption.

The evidence did suggest a problem with VISA, but we were reluctant to believe this as the NI implementation is a mature product and it seems unlikely that the problem wouldn't have been seen before and fixed. If there is a problem, it may be with the way that VISA allocates buffer space in memory, but that doesn't stack up with the fact that we don't see the problem over GPIB. In any event, we are happy with our work around which appears to be reliable and does not appreciably affect performance.

Best regards,

Steve

[John.P]

Hi Steve,

Thanks for posting the solution to your issue.

I am gald you managed to get the communictaion working.

Good luck with your application.

Best regards,

John