Why is my instrument sending the response for the last command sent to it?

[optoelectro]

Hi so I'm trying to program this SR720 LCR meter via a USB/GPIB interface. I can communicate with the machine and it's almost doing what I want, but has this strange quirk, and I suspect I'm missing something basic. The manual can be found here.

It responds to common GPIB commands like *IDN? (identify the instrument) and *IFC (device clear), so I'll be using those. The one I want to use myself is xall?, which just requests the data currently measured.

The problem is that it seems like the machine always "lags" one command late. For example, if I query *IDN? with NI MAX, it returns what it should. However, if I then query xall?, it still returns the same thing as *IDN?, until I do xall? again, and then it returns what it should:

-> *IDN?
<- StanfordResearchSystems,SR720,08087,1.03
-> xall?
<- StanfordResearchSystems,SR720,08087,1.03
-> xall?
<- G1C7.0992E-08,G1R3.1788E02,99

Likewise if you go in the other direction:

-> xall?
<- G1C7.0992E-08,G1R3.1788E02,99
-> *IDN?
<- G1C7.0992E-08,G1R3.1790E02,99
-> *IDN?
<- StanfordResearchSystems,SR720,08087,1.03

As you can see, it's "lagging" one command.

The manual says:

Similarly, the SR715/720 has a 256 character
output buffer to store output until the host
computer is ready to receive it. If the output buffer
fills up it is cleared and an error reported. The
GPIB output buffer may be cleared by using the
Device Clear universal command.

So I thought I'd try the device clear command (*IFC) before entering a new command, but it doesn't seem to work:

-> *IDN?
<- StanfordResearchSystems,SR720,08087,1.03
-> *IFC
-> xall?
<- StanfordResearchSystems,SR720,08087,1.03
-> xall?
<- G1C7.0997E-08,G1R3.1761E02,99

Does anyone have any idea what might be going on? The manual says to use line feed as the terminating character, so I am, but it doesn't seem to matter.

[crossrulz · Accepted solution]

Do you have any waits between your write and read?  Did you try doing a read before seding your command?

[optoelectro]

Hi, so you were certainly right about that -- I added a 200ms delay between the xall? write and the read, and now it works! Thank you!

But I have one other problem that is very strange, and I can't explain... It seems to be regarding line feeds, and it seems like my program might be adding them automatically?

In my sub-VI where I simply write xall?, wait 200ms, then read, if I run that and look at the I/O monitor, it says that "xall?\n" has been sent (even though I'm not sending a line feed manually!).

 Alright, but, in my main VI, all I do is write "freq 1", which should set the frequency to the value associated with the argument 1 (120 Hz I believe), and then call the xall? sub-VI to get the measurement.

However, if I don't manually add the line feed, the subVI returns a value of I1C9.9999E20,I1R9.9999E20,99, which is basically infinite. If you look at the IO monitor, it say that it's writing just "freq 1" (with no line feed!). So it's strange that it adds it automatically for the xall? but not for freq 1.

If I manually make it send the message "freq 1\n", that's what shows up in the IO monitor, and the sub-VI returns the right value! (G1C6.9219E-08,G1R3.2471E01,99, for example.)

What makes even less sense to me is that if I instead try concatenating "freq 1" with a newline constant (all without quotes), and sending that, it doesn't work either.

Why is it appending \n to one part but not the other?

thanks!

[crossrulz]

---

@optoelectro wrote:

Why is it appending \n to one part but not the other?

---

Going to have to see some code to diagnose that one.

[optoelectro]

---

@crossrulz wrote:

---

@optoelectro wrote:

Why is it appending \n to one part but not the other?

---

Going to have to see some code to diagnose that one.

---

Okay, this was a while ago, but I'm back at this code and think I've figured it out.

I was using Labview and NI MAX at the same time, to try and "diagnose" some stuff. At this point I had modified my code such that all the commands sent to the machine had "\n" at the end of the command, which made it work.

However, after sending some commands in NI MAX, and then going back to my program, when running my program, the machine would give "syntax error" messages.

What I figured out is that, if I haven't started NI MAX, I need that \n at the end of commands so that the machine will accept it as the end of the command and process it. However, once I've started NI MAX, its default is to have the checkbox "Send end on writes" checked (which you need if you're going to talk to this machine through just the NI MAX test panel!):

This checkbox seems to apply to the whole system, so essentially once I start NI MAX and send a few commands in the test panel, it will append a \n to the end of *any* command sent over the GPIB. So my program will send, for example, FREQ?\n\n (note: TWO \n's), which will cause an error.

So, if I have that box checked, hit apply, and send a command with NI MAX to make it work, it now applies to the system. So *now*, from LV, I'd have to send the commands *without* a \n to have them work.

But, if I have it that way and I haven't started NI MAX (so that auto \n hasn't come into effect), they won't work, because they won't have any \n.

Anyway, this is probably obvious to others, but I hope it can help someone as foolish as I am.

[optoelectro]

Actually, scratch that. This is insane, I really have no idea what's going on. I'm going to make a thread dedicated to this problem.