GPIB error -420 with LabVIEW and 232CV-A

[MrScott]

I am using the NI GPIB-232VA-A allow a PC serial port to talk to a GPIB instrument (a HP-8714 VNA). I am now getting command through on a fairly regular basis, but I almost always get a -420 "query unterminated" error on the front of the VNA after it completes the command. I have tried virtually every combination of settings on the 232VA-A, but still get the error. What could be wrong? What else can I try? I am now stuck!! Thanks for any help or suggestions.

[Noel]

The -420 "query unterminated" error typically indicates the instrument was addressed to talk but the command sent to it was not a query command. So, just to rule out the obvious, if your command is indeed not a query (i.e., doesn't end in a "?"), then your application should only include a write operation. If there is a Read operation which follows the write operation -- remove it.

[MrScott]

Thanks very much for answering. I am new to GPIB commands etc., and your answer makes very good sense. I don't think that I am sending anything more than the command however. I have watched what I am sending via the PC over its serial port to the GPIB-232CV-A, and it doesn't seem like I am sending anything extra. I am wondering if the 232CV is doing something (or not doing something) that causes the instrument to give an error. I have tried most of its possible settings, but still often get that error.

[Noel]

If you attach your VI, I can take a look at it.

Are you only sending one command? If so and you are using LV 7 and are on Windows, you might want to try using Instrument IO Assistant.

[ScottieB]

Hello,

Different instruments expect different things, so be sure to check your VNA manual on this. Say the command you are sending is "*IDN?"; some instruments actually expect a carriage return (\r), a linefeed (\n), or both. Below is an example of an instrument that would require \n to terminate commands sent to it. Remember that "\n" stands for the single hex code 0x0a and not for the two characters "\" and "n". Whatever language you are programming in will need to interpret this code so that you're sending the correct data.

To do this write, the wrt command can take an extra parameter which is the byte count. So, your write command to address 5 might look something like this:
"wrt #6 5\n*IDN?\n\n"

The #6 specifies that we will be writing 6 total ch
aracters: *, I, D, N, ?, and \n. The 5 is the GPIB address to write to, and following that is a \n that separates the command from the string. Next, we have our 6 characters followed by the final terminating \n. Remember that BASIC programming languages will automatically add the final \n onto its PRINT statements, so this is not needed if you're programming in BASIC.

Hope this helps.

Scott B.
National Instruments
Applications Engineering

[MrScott]

Thanks for your suggestions.
This command works: *IDN?;\n with no errors.
But the following has the noted results:
*RST doesn't work
*RST; works but gives error -420
*RST;\n works but gives error -420
*RST;\n\n works but gives error -420
*RST;\n\r works but gives error -420
*RST\n\r works but gives error -420
So it would seem I can get a query to work but not a command. I keep thinking that the GPIB-232CV-A is sending (or not sending) some other character which is confusing the network analyzer. I have the 232CV set for TIMEOUT termination, as after trying the other settings, this gave the most consistent result. I have tried lots of other end characters for other commands, but I always get the error. I can not find anything i
n the instruments manual that any special character (or not) is needed for a command versus a query other than the "?" . THanks for any other suggestions.
Regards, Scott

[Noel]

My guess is the instrument is somehow being addressed to talk. I recommend monitoring the bus traffic using NI-Spy. After you send the "*RST\n" (or one of the combinations that works but returns an error) command is there a call to ibrd()?

[Plasmar]

We were having the exact same problem talking to an 8920. I finally fixed it by inserting a semicolon AFTER the carriage return EXCEPT on a ? query then no semicolon. We were not sending multiple commands down as one long string but it must have been fast enough the 8920 was processing it that way.