ilrd returns garbage in addition to message when string overload version is used

[TonyB developer]

In developing a project with VB.net I found a disparity between using the ilrd() function for the LangInt.dll version 1.0.1532.22842
When calling the function and passing a string in (whether initialized to "" or a bunch of spaces) I found that reads would have extra garbage data after the expected message.
Using the function by passing a byte array would result in only the expected message.

I used the same message requests for both messages.
I tried with 2 different GPIB instruments.
I tried enabling EOS
I tried explicitly disabling or enabling DMA

None seemed to affect it.

Generally the garbage data was data from a previously recieved message.

It seems like a bug to me, but maybe there is something I can do to make sure the buffer is cleared before the message comes in.

[TonyB developer]

In one particular case I got "mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" as the garbage that was returned with the full message consisting of the decimal bytes below (the expected string from the instrument was "42VVVVV")

52 50 86 86 86 86 86 10 109 115 99 111 114 108 105 98 44 32 86 101 114 115 105 111 110 61 50 46 48 46 48 46 48
44 32 67 117 108 116 117 114 101 61 110 101 117 116 114 97 108 44 32 80 117 98 108 105 99 75 101 121 84 111 107
101 110 61 98 55 55 97 53 99 53 54 49 57 51 52 101 48 56 57 0

[pBerg]

Howdy Tony,

I'd like to verify that the commands you send to the instrument are valid and that the instrument responds to said commands in a way that you expect. To accomplish this, let's simplify things a bit and use the VISA Interactive Control (VISAIC) to perform this verification and communicate with your instrument. You can access the VISAIC within Measurement & Automation Explorer (MAX) by navigating to Tools»NI-VISA»VISAIC.

[TonyB developer]

Thank you for responding!
I checked the responses with the VISAIC as you suggested and the data seems to return from the instrument properly.
I also decided to run NI-Spy while running by VB program to compare what it sees with what is returned on the string.

The data in the string is:
+2.24369E+00NVDC,+146029.918880SECS,+43730RDNG#,00EXTCHAN\nKeyToken=b77a5c561934e089


With actual bytes of:

043 050 046 050 052 051 054 057 069 043 048 048 078 086 068 067 044 043 049 052 054 048 050 057 046 057 049 056 056 056 048 083 069
067 083 044 043 052 051 055 051 048 082 068 078 071 035 044 048 048 069 088 084 067 072 065 078 010 075 101 121 084 111 107 101 110
061 098 055 055 097 053 099 053 054 049 057 051 052 101 048 056 057 000

But the NI-Spy and the VISAIC show that the following is what is returned

+2.24366E+00NVDC,+146635.696260SECS,+63401RDNG#,00EXTCHAN\n

[pBerg]

Howdy Tony,

It looks like your communication isn't configured to stop at the \n termination character. You could fix this by doing some basic string manipulation in VB to search for \n in the string then return everything to the left of the \n. I don't know the VB function off the top of my head, but it should be quick to find.

[TonyB developer]

so the /n (0x0a) character is not a valid character in the GPIB communications? The reason I ask is because if a response actually could contain a /n character but I search and discard everything after that, then I could be discarding real data.

One instrument I'm using is the Keithley 3706 which uses a scripting language in the message (instead of just commands) which can return any type of or combination of characters.

I also still do not understand why there would be garbage data returned in the string. Why would the dll return data that is not part of the message at all? It just seems like memory is being copied that is out of range. This only occurs when using the string version of the overload, so it does not seem consistent.

[TonyB developer]

As an update, I have also verified that this occurs whether using the ilrd or ibrd version of the overload with the string parameter.

[pBerg]

Howdy Tony,

It still sounds like something misconfigured regarding termination. Within Measurement & Automation Explorer (MAX), navigate to your GPIB interface's Properties under Devices and Interfaces. You probably want to check the "Terminate Read on EOS" option and configure the EOS byte. Refer to the NI-488.2 help for more information on EOS byte and the other GPIB options in MAX as well as ibeos.

[TonyB developer]

Hello PBerg

I tried configuring the MAX as you said, but the junk data still comes through. I had also tried various uses of ibeos and ibdev to set it to terminate on a character 10, but I was still getting the garbage data even then.

Also, isn't the EOT supposed to also perform that function? Because setting EOS to chr(0x0a) would also mean that this character could never be transmitted in the message (or data would be lost) which is part of my question above. Is 0x0a not a valid character that can be sent?

In either case I still do not quite understand why the driver would access data beyond what was transmitted. If it was not terminating, wouldn't the message time out (instead of complete)?

In using NI-Spy and watching the return values from an ibrd call (the ibsta status bit values) both the CMPL(I/O completed) and END (which indicate that END or EOS were detected) are set. This would seem to indicate that the driver is terminating the read properly, but that somewhere between terminating that read and passing back the data to the buffer, something else happens.