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.

[rolfk]

---

@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.  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?

---

You don't say anything about the actual device except that it is cheap. Is it serial, GPIB, TCP/IP? Does it use text commands and responses or binary? If text, does it have a termination character you need to send with each command and which it will respond with at the end of each response? If it is binary, does it have fixed sized messages or messages with a fixed size header that specifies the rest of the message?

If it is text without termination characters, or binary without at least a fixed size header, you don't have a cheap device but simply trash and you should treat it as such. There is a container for such stuff!

But most likely it is text and does use a termination character, or in case of a GPIB device probably the EOI handshake and VISA Read absolutely can deal with that in a way, that use of any explicit delays is simply a huge mistake!

Post a link to the Programmer Reference Manual or copy the section that describes the basic principles of the protocol.

[JÞB]

---

@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.  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?

---

RTFM?  As a close second, try telling us more about the device. "Cheap O'Scope" is almost assuredly accurate but, doesn't help us help you.

Save a k$ on equipment price, spend 5xk$ in labor for driver development and 25xk$ rewriting for a plug-n-play driver when "Scopes-R-Us" obsoletes the "Cheap O(scope) tm".

Better Idea: update you resume!  Your skinflint management is probably cost cutting on payroll too!

[JÞB]

---

@paul_a_cardinale wrote:

.... I use code like this to send the query and get the response:

If the delay is too short, I get gobbledygook.  

---

Hey,  I just took another look at your picture.   Do you see the clock glyph on VISA Write and missing on VISA Read?  As shown the Write returns when String to Write is transfered to the buffer, NOT when the transfer to the PHY layer bus is complete.  With modern HW this is almost always best performing for throughput.  So, it is the default behavior!  In rare occasions, it can be undesirable!  Generally leading developers down the "Magic Delay Fairie" Path to avoid gobbledygook returns from following Read operations.   This type of trouble is more prominent when using outdated data busses like 77baud TTY and carrier pigeons. 😀

[paul_a_cardinale]

---

@JÞB wrote:

---

@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.  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?

---

RTFM?  As a close second, try telling us more about the device. "Cheap O'Scope" is almost assuredly accurate but, doesn't help us help you.

Save a k$ on equipment price, spend 5xk$ in labor for driver development and 25xk$ rewriting for a plug-n-play driver when "Scopes-R-Us" obsoletes the "Cheap O(scope) tm".

Better Idea: update you resume!  Your skinflint management is probably cost cutting on payroll too!

---

I'm retired.  I have plenty of time; but didn't want to blow a lot of money on a scope, so I got a really cheap one.  For the most part it serves me well.  There's no LV driver for it, so I've been building one little by little.  I continue to dabble in LV stuff to try to reduce the rate at which by brain declines.