Consecutive VISA commands issue

[Quiztus2]

I have no experience using VISA. I've noticed that my OWON SDS1022 oscilloscope has trouble processing my STOP command if there's a time delay of less than 50 ms to a previous START command. Is this expectable

 

behavior? Conversely, querying the device's ID works immediately.
SDS1000_Oscilloscopes_SCPI_Protocol 

[GerdW]

Hi Quiztus,

---

@Quiztus2 wrote:

I've noticed that my OWON SDS1022 oscilloscope has trouble processing my STOP command if there's a time delay of less than 50 ms to a previous START command. Is this expectable behavior?

---

Yes: I guess the scope is quite busy when starting to execute your START command!

(You should ask the scope manufacturer for such specific questions about behavious (aka "the firmware") of the scope…)

[Quiztus2]

I had no luck with answes from the manufacturer so far. Do you have experience with 488.2 status register? Would this be usecase for this?

[GerdW]

Hi Quiztus,

---

@Quiztus2 wrote:

Do you have experience with 488.2 status register? Would this be usecase for this?

---

This would only be useful for GPIB communication.

When I was using GPIB-connected devices I needed the status register very seldomly (or was it never?). Most often I could send a command and read the response.

And it most often helps (GPIB or other communication busses) to send commands at a limited rate (aka "delay between commands"). There are commands that take longer than others: a "device reset" may need several seconds, while a simple "set parameter" will be done within 2ms! And to "start acquisition" seems to be more demanding (apply all relevant parameters, arm triggers, enable inputs and amplifiers, …) than a "stop acquisition" (aka "break") in your specific use case…

[crossrulz]

---

@Quiztus2 wrote:

I have no experience using VISA. I've noticed that my OWON SDS1022 oscilloscope has trouble processing my STOP command if there's a time delay of less than 50 ms to a previous START command. Is this expectable behavior?

---

It is not unheard of.  It completely depends on the instrument.  Some instruments have a very limited communication buffer, so you cannot send too many commands at once or things will get dropped.  Others have limited processing capability and have trouble processing commands while still doing something due to the previous command, which is the situation I think you are running into.

Any good modern instrument nowadays will not have these issues, at least that I have ran into.  Go 10 years ago, these were more common issues.  I even had a situation with a Tektronix TDS3000 series scope where I had to put in a 500ms delay because the processing from one command what overwriting subsequent command settings.

[Minions · Accepted solution]

One alternative is to send the *OPC? query.  This will be loaded into the queue inside the instrument and will not return a response until the command prior to the *OPC? query is completed.  The response will always be "1" and as such is really irrelevant other than to create a delay for sending the next command.

Remember, some commands like self-test *TST might take several seconds and cause a timeout during the VISA Read part of the *OPC? query.

[Quiztus2]

Although a complete set of 488.2 commands is listed in the documentation, only *RST and *IDN? work. I will now have to settle for a simple wait after the start.

[Yamaeda]

Typically you do a Write of a Command and then a Read of the result. After that you can send the next command. One common mistake is to not send the correct End, many manufacturers wants a newline '\n' in the end of each command, some wants semicolon ';', check what applies to your gear.

[JÞB]

Generally speaking,  once a Data Acquisition Device. "Starts" an Acquisition that is what they do! Aquire data!

Your Oscilloscope is following that process. Interrupting data acquisition is "Rude"

[Quiztus2]

Personally, I find these Wait solutions ugly. Here a screenshot from a multiple channel fetch vi from Rigol DS1054 VISA driver. 

200 ms delay between reading of channel 1 and 2.