Scope Measurements

[paul_a_cardinale]

I want to make measurements from my cheap oscilloscope.   So I use code like this to send the query and get the response:

If the delay is too short, I get gobbledygook.  But how much time I need depends on the particular measurement being made.  I could just set the delay to the longest needed for the slowest measurement; but I'd rather not do that.

Does anybody have any tricks up their sleave?

[mcduff]

Does the Scope have registers?

Typically in this case, you set up a Service Request on the Event? (can't remember) Register.  When the measurement is complete, it flips the bit in the register. You can then read the data. 

Not sure if sending a *WAI command after the measurement command would also work. (It pauses the instrument from processing any subsequent commands until all currently running, overlapped commands (such as a measurement, sweep, or frequency change) are completely finished.)

[LV_Tim]

All the responses from a scope end with a termination character (usually 0xA), to make use of them you need to set a the visa properties:

TermChar En = True

TermChar = 0xA

Timeout = 10000(ms)
You can now performance visa read without the delay but with a length longer than the expected packet. So now the visa read will now stop at either the term char, timeout or read length.

[cstorey]

mcduff's is correct, if the instrument has status registers then checking those is better than stalling dataflow. 

Here's the NI doc that goes over all of the possible approaches; l

• Long Timeout
• Serial Poll
• Service Request
• Query Status

https://www.ni.com/en/support/documentation/supplemental/06/using-instrument-status-registers-and-se...

Easiest is to set a very long instrument timeout on the bus.  More complicated if you query the status register and dissect the response and decide how to handle the situation (complete, error, timeout, etc..).

Craig

[mcduff]

---

@LV_Tim wrote:

All the responses from a scope end with a termination character (usually 0xA), to make use of them you need to set a the visa properties:

TermChar En = True

TermChar = 0xA

Timeout = 10000(ms)
You can now performance visa read without the delay but with a length longer than the expected packet. So now the visa read will now stop at either the term char, timeout or read length.

---

I don't think this would work. This does not stall the READ operation, it just reads the data until at termination character is reached. The @OP said if he performs the read too soon he gets gibberish.

[Kyle97330]

---

@paul_a_cardinale wrote:

I want to make measurements from my cheap oscilloscope.   So I use code like this to send the query and get the response:

If the delay is too short, I get gobbledygook. 

---

This is one of my pet peeves about what the "Read" function means.

There seems to be some sort of belief out there that a VISA read is an "active" request of some kind, like you're reaching out to the instrument and yelling, "GIVE ME AN ANSWER NOW!".

In reality, VISA read is a passive observation of the receive buffer on your PC, ending either when it sees a termination character, the requested byte count, or a timeout.  The instrument itself is not being interrogated for a reply actively.  Asking for a read before the instrument has started sending it is not "rude" or "harassment", does not have a chance of "interrupting" the process, or anything else along those lines.

However, some instruments (mostly cheap ones, and you do say this is your "cheap oscilloscope"), actually can have problems when you send too many commands in rapid succession.  If this is the case, then sending commands like "*OPC?" might not actually help things, because that can in fact just be making the problem worse if the device is already malfunctioning because it can't handle repeated queries in quick succession.

As such, what you need to do is likely 2 things combined to get the optimal behavior out of the instrument:

1. Move the wait command to before the write, not between the write and the read.

2. Instead of using a constant 100 ms or some other "magic number", add a register of some kind that keeps track of the time since your last VISA operation (write or read), and offsets the wait timer based off that.  This is because if your main program does not need to send a command to your instrument for a while, there is no need to add a 100 ms delay to the command, but there is a need to add it if your main program needs to send multiple commands in quick succession.