writing a string via gpib stops on "00"

[PAB1979]

Hello,

I am using Measurement Studio and VB6 to save and restore calibration data from and to a VNA via a PCMCIA-GPIB card.

Reading the data works fine, I simply save it into a string(say "data"). The problem is writing the data back to the VNA. The code I use is just:

cwgpib1.write "inpucalc01" & data & ";"

where "inpucalc01" is the command to the VNA to accept incoming data and "data" contains the string I read before.

When I spy the result with NI-Spy, the transmission always stops, when there is a "00" in the string and therefore the VNA shows an error message.

I already tried to send every byte of the string separately  using a loop but the VNA won't accept that method, since after every writing process in the loop some kind of termination-symbol is appended (even with "append EOS on write turned off").

I have no idea how to solve that problem and appreciate any ideas.

Many thanks!

Philipp

[Norbert_B]

Philipp,

have you already tried to conconate the string just before the command-call? how does that string look like? Does it contain any '00'?

regards,
Norbert B.

[PAB1979]

Hi Nobert,

Thanks for your answer, I'm not a native english speaker and I'm not totally sure, what you mean by "to conconate the string".

Anyway, what I did is spying the transferred data with a tool called NI-Spy, with which you can log the transferred gpib data as binary. The data that I try to send back to the network analyzer looks exactly the same as the formerly received data, only that it always stops at "00". Perhaps this is what you meant??

And to answer your question, as I understand it: Yes, the formerly received string from the network analyzer, contains "00"s.

regards,

Philipp

[Norbert_B]

Philipp,

to conconate strings means to "attach" them one after another into a new string.
Regarding the "00": The communication is most often set to terminate on a special symbol. In general "0x00" (ASCII) is a very common symbol for this. So if your string contains a "zerobyte" (or NUL as it is also called), the communication should terminate. Maybe you should check that setting.

If your data contains many zeros as numbers, that would be "0x30" (ASCII). This should not have any impact on the writing except the termination sequence is set to two following zeros, meaning a hex-stream of "30 30".

hope this helps,
Norbert