SCPI best practices - Page 1
Forum section: electronics / testgear

author: uliano
author_rank: Regular Contributor
timestamp: December 12, 2024, 12:57:44 pm
content: I'm having hard time to understand the SCPI interactions.I "write" some command (for example to set a parameter or to switch to a mode) to the instrument and it does not answer anything. I have no idea if the command succeeded or not other than querying the instrument (for the parameter value or the current mode).when sending sequences of commands I had *more than occasional* "command failures" that could be eventually amended by inserting a long enough delay between commands.This delay is always (at least in my units, mostly Siglent) undocumented and differs not only among instruments but even between commands of the same unit.Am I missing something?How do you deal with this other than experimentally finding the "right" delay for each command?(there should have been the*OPC?query that I expected returning 1 onlyAFTERprevious command had been completed but it doesn't seem to cure, onlytime.sleep(the_right_amount)after each write has any success for me)

author: tszaboo
author_rank: Super Contributor
timestamp: December 12, 2024, 01:50:52 pm
content: I don't think you are missing a lot.Some commands allow setting and querying at the same time.The timeout, or better defined delay, depends on the command and instrument state. If you set a DMM to read values with 100ms aperture time, it will only answer after 100ms. If you set autozero on it will take twice as long. It's not easy, larger companies have dedicated test engineers who write and optimize these tests, and make test setups. A good engineer might be able to do the same test 100x faster, if the right budget is given in time and equipment.

author: eTobey
author_rank: Super Contributor
timestamp: December 12, 2024, 01:58:04 pm
content: That is the joy of programming. Sometimes you just have to try over and over again. But you could also write a program, that finds out, how much the delay has to be.Writing a program to write a program.I have some SCPI stuff in my "homepage" link on my profile.

author: Fungus
author_rank: Super Contributor
timestamp: December 12, 2024, 01:58:31 pm
content: Quote from: uliano on December 12, 2024, 12:57:44 pmSome commands need you to wait for completion. You can do this by sending "*WAI".Chapter 2.3 of theRigol DHO800 programming manualexplains it.(nb. the '*' commands are universal - should be the same on all devices).

author: uliano
author_rank: Regular Contributor
timestamp: December 12, 2024, 03:10:42 pm
content: Quote from: Fungus on December 12, 2024, 01:58:31 pmit would have required SO LITTLE to implement that should have been made mandatory, unfortunately it's ignored by Siglent

author: Fungus
author_rank: Super Contributor
timestamp: December 12, 2024, 03:53:38 pm
content: Quote from: uliano on December 12, 2024, 03:10:42 pmInteresting... I thought that one would be universal. It's really basic and necessary.

author: paul@yahrprobert.com
author_rank: Regular Contributor
timestamp: December 12, 2024, 04:57:56 pm
content: I find this R&S document to be helpful:https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_application/application_notes/1gp79/1GP79_1E_SCPI_Programming_Guide_SigGens.pdfOne technique is to tack on a ;OPC? query to the end of your command. But that can fail by timeout. Or in the case of old Tektronix scopes you just can't do that at all. So then you send a separate *OPC command, not a query, and run a loop querying *ESR? until bit 0 is a 1.SCPI programming is a mess!

author: uliano
author_rank: Regular Contributor
timestamp: December 12, 2024, 06:40:53 pm
content: Quote from: paul@yahrprobert.com on December 12, 2024, 04:57:56 pmscanning the command list *OPC? drew immediatly my attention and therefore I interleaved every write with a query('*OPC?'), alas it dind't work: I didn't experience any timeout but many writes had no effect... until I replaced every query('*OPC?'), with time.sleep(some_time).however, the documentation contradicts my experience:Siglent:The *OPC (Operation Complete) command sets the OPC bit (bit0) in the standard Event Status Register (ESR). This commandhas no other effect on the operation of the device because theinstrument starts parsing a command or query only after it hascompletely processed the previous command or query. The*OPC? query always responds with the ASCII character 1because the device only responds to the query when the previouscommand has been entirely executed.No other access to ESR is mentionedTTi:*OPC? Query Operation Complete status. The response is always 1<RMT> and will beavailable immediately the command is executed because all commands aresequential.Here at least I can query ESR and test the suggested approachQuotewhat is really puzzling me is that it seems a mess "by design".

author: tautech
author_rank: Super Contributor
timestamp: December 12, 2024, 07:54:54 pm
content: @ulianoWhich model ?The App notes and Operating tips should provide guidance:https://www.siglenteu.com/resources/BTW, some programming manuals have been updated so be sure that you're working from the latest version.

author: HKJ
author_rank: Super Contributor
timestamp: December 12, 2024, 08:47:27 pm
content: Any command ending with a ? will send a answer back, other commands will not.

author: uliano
author_rank: Regular Contributor
timestamp: December 13, 2024, 08:39:00 am
content: SDG 1000X, SDM3065Xfrom app notes:def SocketQuery(Sock, cmd):try:Sock.sendall(cmd)time.sleep(1)except socket.error:print('Send failed')sys.exit()reply = Sock.recv(4096)return replydef SocketSend(Sock, cmd):try:cmd = cmd + '\n'Sock.sendall(cmd.encode('latin1'))time.sleep(1)except socket.error:print('Send failed.')sys.exit()that 1s wait no matter what command you're issuing seems like overkill, to just set one parameter for example 0.1s or even less is enough.so the alternatives are 2:keep 1s and bloat the measurement timeor try to optimize by pausing a different time for different commandsif the semantic of "*OPC?" had been implemented as per manual description mentioned in the above post it would have been enough to follow each command by *OPC? thaw would have waited till the previous command was over and then only then returned 1unfortunately it doesn't work like so, it seems that *OPC? is executed before completion of the previous command, in I queue many commands (eg. setting different paramenter) interleaved by *OPC? I observe tha only some parameter get changed if I don't insert some delay in between (and then *OPC? becomes completely useless)

author: uliano
author_rank: Regular Contributor
timestamp: December 13, 2024, 08:41:28 am
content: Quote from: HKJ on December 12, 2024, 08:47:27 pmthe problem is how to find a way to be sure that the command (without ?) has completed.

author: tszaboo
author_rank: Super Contributor
timestamp: December 13, 2024, 11:42:13 am
content: Quote from: uliano on December 13, 2024, 08:39:00 amYou could use non-blocking receive. You check the receive buffer after a while and look for newline characters.Same rules apply than an embedded systems communications. If you use the best practices from there you could make your setup faster.If that's your goal. Sometimes it's just easier to get a cup of coffee while the test is running.

author: uliano
author_rank: Regular Contributor
timestamp: December 13, 2024, 12:02:08 pm
content: The problem with SCPI, if I'm on the the right track, is that after a write of a command ()without "?") you don't get anything back not even a "\n".and, here I'm guessing, if I send another command before the previous has completed it gets ignored or misinterpreted.

author: Rerouter
author_rank: Super Contributor
timestamp: December 13, 2024, 12:08:48 pm
content: It depends on the piece of equipment, when I was testing the limits of the SDS1204X-E, I believe the command buffer was 1MB before it started missing commands, so I could hit it with a few hundred commands and it would execute and reply in sequence, I don't recall anything being out of sequence, but i don't recall trying to use other commands why it ran a long capture or similar, things like reading out a channels voltage could be streamed at quite the rate.(I was fuzzing the command interface for unknown commands)

author: HKJ
author_rank: Super Contributor
timestamp: December 13, 2024, 12:20:17 pm
content: Quote from: uliano on December 13, 2024, 12:02:08 pmCorrectQuote from: uliano on December 13, 2024, 12:02:08 pmUsually not, but it is very device depend.It can get rather complicated sometimes: Some devices may processed a command in background while other commands are processed in foreground. I have had some fun with that on some DMM's, I request a change to AC, but during the next couple of commands the meter is NOT in AC mode.In TestController it is possible to use delays or *OPC (The advanced version), to handle this individually for each device.

author: uliano
author_rank: Regular Contributor
timestamp: December 13, 2024, 01:59:21 pm
content: Quote from: HKJ on December 13, 2024, 12:20:17 pmvery close to my (limited) experience, and it is also command-dependent (or, possibly, some command are just exectuted fast enough).Quoteyou mean "*OPC?" and wait for "1" as response or there is other uses of "*OPC" ?It is really frustrating as it wouldn't have been much complex (for instrument designers) to implement some mechanism to enfoce a true sequential process.

author: HKJ
author_rank: Super Contributor
timestamp: December 13, 2024, 02:16:28 pm
content: Quote from: uliano on December 13, 2024, 01:59:21 pmAnother use:Send a *OPC, then poll the device with *ESR?This way there is no risk for timeout on the controller side, because the *ESR? is basically processed immediately.Quote from: uliano on December 13, 2024, 01:59:21 pmIt is not always a sequential process is a good solution. What would be nice is some minimum buffer requirements or a command to return remaining buffer space.

author: uliano
author_rank: Regular Contributor
timestamp: December 13, 2024, 04:07:30 pm
content: Quote from: HKJ on December 13, 2024, 02:16:28 pmmy siglents don't implement *ESR :'(QuoteI'm not saying -always- I'm saying that it should be possible to enforce the sequence -when needed-(and it would have just been enough to implement a working *OPC? and not a fake one returning regardless of previous command completion)