SPD3303X-E SCPI Interface issues - Page 1
Forum section: electronics / testgear

author: SpiderKenny
author_rank: Newbie
timestamp: June 06, 2019, 02:21:27 pm
content: HiI have an SPD3303X-E and I'm trying to write some code for it.I have written code for SCPI devices before (such as my Rigol DS2202E) without any trouble. I'm connecting over TCP/IP to port 5025, so I'm using SCPIP RAW not VXI-11The problem I am finding is that many of the commands listed in the QuickStart manual don't work. I think I may have missed something.For example, if I send "*IDN?" then I get the correct response: "Siglent Technologies,SPD3303X-E,SPD3XHBC3R0662,1.01.01.02.05,V3.0"And if I send "*READLL?" I get the correct response too: "4,13.90,0.00,0.00,20.06,0.00,0.00,18.00,1.70,32.00,3.20"But if I send things like "OUTPut CH1,ON" then the power supply just beeps, and reading the error code with "SYSTem:ERRor?" results in: "ERROR: 3 Command keywords were not recognized"Is there some other step I need before sending some of these commands?

author: finos
author_rank: Contributor
timestamp: June 06, 2019, 02:26:36 pm
content: Try putty with telnet mode with 5025 port.Output CH1, ONBe careful with the spacies and formatting.Try any other scpi command as a test

author: H.O
author_rank: Frequent Contributor
timestamp: June 06, 2019, 04:21:42 pm
content: I don't have one of these but aren't you missing a colon in there.I would think it should be OUTP:CH1,ON or something like that.

author: SpiderKenny
author_rank: Newbie
timestamp: June 07, 2019, 08:48:36 am
content: Quote from: H.O on June 06, 2019, 04:21:42 pmThanks!Well, not according to manual - but that is probably wrong.I've tried all these combinations, but none are working so far..:OUTPut CH1,ONOUTP CH1,ONOUTPut:CH1,0CH1:OUTPut ONMaybe I'll just switch over to using the VXI-11 protocol instead - because I can Wireshark that from my PC and sniff it.I tried using ptty and nc (netcat) but got the same results.Here's a picture of the manual page:

author: tautech
author_rank: Super Contributor
timestamp: June 07, 2019, 08:49:14 am
content: https://www.siglentamerica.com/operating-tip/spd-programming-tips/

author: finos
author_rank: Contributor
timestamp: June 12, 2019, 06:07:21 pm
content: Is there any way to disable the beeper every time that I send a cmd to it?

author: tautech
author_rank: Super Contributor
timestamp: June 13, 2019, 09:12:02 pm
content: Quote from: finos on June 12, 2019, 06:07:21 pmI've checked with the Apps engineer in Ohio and this is his reply:The SPD beeps if the commands are not correct.Probably best to have a look at the code.Can we examine your SCPI code please ?

author: finos
author_rank: Contributor
timestamp: June 13, 2019, 09:38:21 pm
content: Quote from: tautech on June 13, 2019, 09:12:02 pmYes I've read that... But the return is correctIn my case it beepsWhen I open the socketOn receive of every commandOn disconnect of the socketTommorow I will send the code. For me now it's 2am... See ysla all

author: tautech
author_rank: Super Contributor
timestamp: June 13, 2019, 09:48:21 pm
content: Quote from: finos on June 13, 2019, 09:38:21 pmJust checking........your firmware version please ?

author: finos
author_rank: Contributor
timestamp: June 14, 2019, 09:08:27 pm
content: sofw version is 1.01.01.02.05hd version is 3.0

author: finos
author_rank: Contributor
timestamp: July 25, 2019, 10:09:48 pm
content: Can the siglent handle 2 simultaneous connections querying data?

author: rf-loop
author_rank: Super Contributor
timestamp: July 26, 2019, 07:24:11 am
content: Quote from: SpiderKenny on June 06, 2019, 02:21:27 pmI do not know if this is your problem but least it need check carefully:When you send string there need care syntax. Siglent SPD programming tips tell this:Quote from: Siglent SPD programming tipsAnd here is one:Quote from: Siglent SPD programming tips\n is LF (LineFeed) (0x0A)\r is CR (Carriage Return) (0x0D)So do not terminate command string how ever. Just LF alone.Cisco/Appendix: ASCII Character Set and Hexadecimal Valueshttps://www.cisco.com/c/en/us/td/docs/ios/12_4/cfg_fund/command/reference/cfnapph.html(I have not any SPD for test this)

author: HendriXML
author_rank: Super Contributor
timestamp: October 27, 2019, 11:09:36 pm
content: I didn't want to create a new thread, but one issue I'm having with this PSU is that, when channel 1 and 2 are disabled in fast succession.The last command does not change the actual status of the channel. Which means it stays ON, no error beeps. If I wait between calls then it's ok.Code:OUTPut CH1,OFFOUTPut CH2,OFFThe strange thing is that the statusCode:SYSTem:STATus?Result: 0x5Shows that channel 2 is "off", but in reality the button is lighted and I get a voltage readoutA wait time of 100 ms has occasional misfunctioningA wait time of 300 ms seems to be OK, but that's not what I call solid interfacing

author: tautech
author_rank: Super Contributor
timestamp: October 27, 2019, 11:19:45 pm
content: Quote from: HendriXML on October 27, 2019, 11:09:36 pmTrying to remember where I've seen mention of a wait between commands....maybe it was from you in some other thread ?The grey matter is letting me down ATM so I might come back with another post or edit.

author: tautech
author_rank: Super Contributor
timestamp: October 28, 2019, 10:01:29 am
content: Quote from: HendriXML on October 27, 2019, 11:09:36 pmOK had a quick look at the Quick start guide and there might be a way around this.http://siglentna.com/wp-content/uploads/dlm_uploads/2017/10/SPD3303X_QuickStart_QS0503X-E01B.pdfP353.1 Syntax ConventionsA vertical bar ( | ) separates parameter choices. For example, {CH1|CH2}in the above command indicates that you can specify a channel. The bar is not sent with the command string.So using an example from the start of that chapter we come up with this:[{CH1|CH2}:]OUTPut, OFFI'm no programmer so this could be wrong but maybe it's worth a try ?Further down on P40 in 8. OUTPutOUTPut {CH1|CH2|CH3},{ON|OFF}One should work as expected.

author: HendriXML
author_rank: Super Contributor
timestamp: October 28, 2019, 10:40:59 am
content: Quote from: tautech on October 28, 2019, 10:01:29 am[{CH1|CH2}:]OUTPut, OFFThis command form, which should probably have been[{CH1|CH2}:]OUTPut OFFBoth of them do not work.In other Siglent devices (and some commands for the SPD3303X) the channel is indeed at the front, so this syntax would be more logical. With the SPD3303X the command format is thus not consistent.But I don't think the bug is related to the syntax. The command does change the memory state, but not the actual electronic one. Having those differ from each other exposes very unwanted behaviour, which should have high priority to fix IMO. That it occurs even at 100 ms command separation is an indication there's something is not thought out entirely through. (Maybe there're things that should be queued/synchronized differently, etc...)

author: zerto
author_rank: Contributor
timestamp: November 09, 2019, 12:19:16 pm
content: Hi all,I do not own a SPD3303-X but a SPD1305X and I have the same problem as described here. Reading the thread helped me a lot to find a solution for the SPD1305X and may be it will work for you as well.The important thing is that *some* commands like OUTP (and MODE:SET for the SPD1305X) should be sent *without* \n (linefeed). And some other commands requires to have a delay before sending another one. I do not know if there is an exact delay to use and I am using different one for different commands. Whenever your run your script, if the unit is generating a beep, that means something is wrong: try to locate which command is generating the beep and add a delay and/or try removing the \n at the end of the command string.Here is a script that is working well on my SPD1305X, no beep at all when running it; it is a golang program and even if your are not using the go language it should be easy to read: please check carrefully how some commands are send using \n at the end and some don't.Code:package mainimport "net"import "fmt"import "bufio"import "log"import "strings"import "time"func send(conn net.Conn, cmd string, waitreply bool, delay time.Duration) {// Print the command on the console and ensure that a linefeed is printed// even if the command string does not have onefmt.Printf("> %v\n", strings.TrimSpace(cmd))// Send the command string exactly as passed to the function// do not add a \n here ! this is importantfmt.Fprintf(conn, cmd)// if a delay is requiredtime.Sleep(delay)// if there is a response to readif waitreply {response, _ := bufio.NewReader(conn).ReadString('\n')fmt.Printf("< %v\n", strings.TrimSpace(response))}}func main() {conn, err := net.Dial("tcp", "spd1305x:5025") // replace spd1305x by your unit IP addressif err != nil {log.Fatal(err)}defer conn.Close()// Get the identification stringsend(conn, "*IDN?\n", true, 0)// Get the current status of the unitsend(conn, "SYST:STAT?\n", true, 0)// Unlock the unit (if ever it is needed)send(conn, "*UNLOCK\n", false, 100*time.Millisecond)// Set the 4 wire mode, Note: I do not know if this is available on the SPD3305Xsend(conn, "MODE:SET 2W", false, 100*time.Millisecond)// Set out to 5vsend(conn, "VOLT 5.0\n", false, 0)// Max current to 100mAsend(conn, "CURR 0.1\n", false, 0)// Enable output (only one output anyway on the SPD1305X)// this is the important thing: do not send a linefeed at the end of the command string// and add a delay to let the output settlesend(conn, "OUTP CH1,ON", false, 2000*time.Millisecond)// Check if the last command generate an errorsend(conn, "SYST:ERR?\n", true, 0)// Check what is the selected voltagesend(conn, "VOLT?\n", true, 0)// Check the actual output voltagesend(conn, "MEAS:VOLT?\n", true, 0)// Check the actual output currentsend(conn, "MEAS:CURR?\n", true, 0)// Check the actual output powersend(conn, "MEAS:POWE?\n", true, 0)// Turn off the output// again: no \n at the end of the command string// no delay needed here as the script is endingsend(conn, "OUTP CH1,OFF", false, 0)// Check if the last command generate an errorsend(conn, "SYST:ERR?\n", true, 0)// Lock the unit and quitsend(conn, "*LOCK\n", false, 0)}Here is what should be displayed on your console when running this program:When trying this on your SPD3305X, you should probably not send the MODE:SET command> *IDN?< Siglent Technologies,SPD1305X,XXXXXXXXXX,2.01.01.07R1,V1.0> SYST:STAT?< 0x20> *UNLOCK> MODE:SET 2W> VOLT 5.0> CURR 0.1> OUTP CH1,ON> SYST:ERR?< 0 No Error> VOLT?< 5.000> MEAS:VOLT?< 5.000> MEAS:CURR?< 0.025> MEAS:POWE?< 0.125> OUTP CH1,OFF> SYST:ERR?< 0 No Error> *LOCKWhen running it I had a 220 resistor attached so the results are fine.Please confirm from your side !

author: HendriXML
author_rank: Super Contributor
timestamp: November 09, 2019, 01:35:00 pm
content: Quote from: zerto on November 09, 2019, 12:19:16 pmThanks for the response.The problem I encountered is mainly time related, in one paper Siglent advices a 100 ms delay between commands is suggested.https://siglentna.com/operating-tip/spd-programming-tips/?pdf=7932but from what I experienced 300 ms would be better.The memory state of the device is always updated with success (no beep either), it is the actual state that sometimes does not change.Siglent should solve this bug, having to wait between command is not a solid solution. Scripts don't always run ina lineair way.

author: zerto
author_rank: Contributor
timestamp: November 09, 2019, 03:02:07 pm
content: Quote from: HendriXML on November 09, 2019, 01:35:00 pmThanks for the advice on 300msec, I agree this is not robust code ! but this is not the only issue.I saw the paper already and it gave me the solution, if you look at the code from this paper there is a line:Code:inst.write_termination=” #Modify default termination characterChecking the visa doc, this is a line terminating character, so in the case of OUTP, the code is *not* using \n to terminate the line. And bingo ! when removing the \n for this command (and for the MODE:SET command as well) makes my script to run without errors.

author: HendriXML
author_rank: Super Contributor
timestamp: November 09, 2019, 04:15:41 pm
content: I use the VISA libraries / protocol. That way the line terminator stuff seems to be handled automatically. (There's however an visa attribute for it, which I don't use).For most devices that's probably preferable. Switching between tcp/ip and usb, is than as easy as switching resource names.What I didn't understand is why answers have a termination character in them though. Without diving into the protocol depths, I just remove them. But I would expect that no termination character, should mean .. no termination character.Streaming stuff and wait for special bytes/characters etc. is a bit old school IMO. Just as VISA requires one to know how many bytes the device will return. That's not really gracefull.

author: sequoia
author_rank: Unknown
timestamp: June 15, 2020, 03:15:08 am
content: Seems like Siglent has abandoned this product line (SPD3303X-E)? As it's now over six months later, and there is still no updated firmware that fixes these bugs..Looking the specifications, SCPI commands must be terminated with NL (line-feed), but clearly at least "OUTPut" command is broken since if command is terminated with NL, unit gives error...At current state SPD3303X-E (and probably SPD3303X ?) don't live up to advertised specifications ("supports SCPI")...

author: tubularnut
author_rank: Regular Contributor
timestamp: June 15, 2020, 07:31:24 pm
content: I was about to try and interface my SPD3303X-E to HKJ's multimeter logging program, when I managed to blow it up (not related to the program).Currently over in Germany being repaired under warranty, when it comes back I will continue the attempt.

author: sequoia
author_rank: Unknown
timestamp: June 15, 2020, 08:24:35 pm
content: This seemed a good PSU on paper, hoped it would live up to the promises, so decided to give it a try when Amazon had this on free "next day" delivery....(and other PSUs that I was looking would have meant unspecified shipping date/delivery date...)But seems like might be better send this back (for full refund) before 30 day return period is up, since just noticed it can't meet the specs for "CH1/CH2 Series mode". Manual states:Code:Output rating 0~32V/0~6.4ABut at about 6.2A CC limit kicks in... (at 6.209-6.210A according to my DC load). Seems like series mode must be using relays to switch in some "shunt" resistors to balance the power draw, that was not taken into account in the manual/specs?

author: tautech
author_rank: Super Contributor
timestamp: June 15, 2020, 09:07:18 pm
content: Quote from: sequoia on June 15, 2020, 08:24:35 pmTake careful note of the rating for Series mode, it reads: 0 to around 32V and 0 to around 6.4A !Relays are linking the outputs for Series mode, just as they do for Parallel mode.In Series mode, Ch1 controls become the master.

author: sequoia
author_rank: Unknown
timestamp: June 16, 2020, 04:09:19 am
content: Quote from: tautech on June 15, 2020, 09:07:18 pmGranted it has ~ not -, but being off about 3% is bit much unless its a mistake/typo (and usually the "error" is the other way i.e. promise 30V/3A while in reality supply goes up to 32V/3.2A...)Well, looks more like typo, since SPD3303S manual lists:Code:Output ratings 0~30V/0~6A (Max: 32V, 6.4A)Which would seems correct for SPD3303X-E as well? As doesn't look like power supply/channels were improved from SPD3303S to SPD3303X-E, just the front panel was upgraded and connectivity (LAN added)?Minor detail overall, but reading manuals gave impression that SPD3303X-E has improved output vs. SPD3303S.Otherwise, I kind of like this power supply, features/price ratio is good. Without issues with the "SCPI" support this could be great...

author: tautech
author_rank: Super Contributor
timestamp: June 16, 2020, 05:15:54 am
content: Quote from: sequoia on June 16, 2020, 04:09:19 amIIRC Siglent had to pull back max output voltages to meet some new universal voltage requirement for PSU's, it was a couple of years back or more and I don't remember what part of the world it even applied to but as they market worldwide all products had to fall into line as it's too difficult to spec something for marketplaces that require this new spec.Someone else might remember about this in more detail.Yes it's been a while since new FW has been released for these so hopefully there's something not far away.Life's super busy here ATM but bump me in a few weeks and I'll hunt out what's happening regarding FW.

author: KE5FX
author_rank: Super Contributor
timestamp: June 16, 2020, 06:37:03 am
content: Quote from: HendriXML on November 09, 2019, 01:35:00 pmToo late to help the original poster, but for the benefit of anyone else with similar problems: get into the habit of adding ;*OPC? to every SCPI command you transmit, turning it into a query that will block until the command has finished executing. Otherwise you are just asking for a one-way trip to timing hell.If you catch yourself doing things likesend("OUT CH1,6");Sleep(100);send("OUT CH2,12");Sleep(100);... you're definitely doing it wrong, even if that's what the manufacturer told you to do.

author: sequoia
author_rank: Unknown
timestamp: June 16, 2020, 07:23:37 am
content: Quote from: KE5FX on June 16, 2020, 06:37:03 amThat is a good tip! Often seen SCPI programs/scripts that don't even use *OPC? ....Unfortunately lot of devices just claim to support "SCPI" while in reality they don't conform to the SCPI specification.Like is the case with this SPD3303X-E, it seems to support only a handful of "SCPI like" commands.I did quick test, and seems like it supports only one of the 13 mandatory commands for SCPI instruments (*IDN?)....

author: HendriXML
author_rank: Super Contributor
timestamp: June 16, 2020, 08:02:34 am
content: Quote from: KE5FX on June 16, 2020, 06:37:03 amI'm not sure wether it would help (it's been a while). Like I said the software state is changed by the commands, the hardware syncing seems to need a delay. I know this because I did send a query to the device right after to check its software state. The trick would haven been to do that until it would match the required one. But that surprisingly fails.Speaking of "definitely wrong" to bypass faulty behavior sounds a bit condescending, especially when no information is given about what really goes faulty. I agree it is wrong tohaveto add delays, but if itstheonly way, it can't be wrong at the users side.

author: tv84
author_rank: Super Contributor
timestamp: June 16, 2020, 09:23:56 am
content: Quote from: KE5FX on June 16, 2020, 06:37:03 amYou should/can also use *ESR?. I don't have experimented with which is safer to use.

author: KE5FX
author_rank: Super Contributor
timestamp: June 16, 2020, 12:58:24 pm
content: Quote from: HendriXML on June 16, 2020, 08:02:34 am*OPC? meansOPerationComplete. If it returns before the operation is complete -- meaning before the hardware actually carries out the foregoing command(s) -- it's a firmware bug, and should be reported as such.Not condescending, and not a matter of opinion, but part of thestandard.It's true that there's an equivalent ESR bit, but unless you need to poll some other status bits, I'm unaware of any benefit to issuing *OPC;*ESR? rather than just *OPC?

author: tv84
author_rank: Super Contributor
timestamp: June 16, 2020, 12:59:44 pm
content: Quote from: KE5FX on June 16, 2020, 12:56:05 pmI could analyse in greater detail but I don't think it's worth it.One thing is certain, Rigol usesonly*ESR?verification when executing their calibration scripts.Edit: Reading the standards page that you referenced, it's perfectly clear that we are talking about different bits in the Standard Event Register.OPC - deals with bit 0 (previous instructions concluded)ESR - deals with bit 3 and 4 (error in previous instruction)So they are complementary instructions.

author: KE5FX
author_rank: Super Contributor
timestamp: June 16, 2020, 01:19:43 pm
content: Quote from: tv84 on June 16, 2020, 12:59:44 pmThey don't do a good job of describing it, but bit 0 of the *ESR? query will go high when all operations are complete, including an *OPC command. Rohde & Schwarz'sapp noteis a lot clearer (see page 12).

author: HendriXML
author_rank: Super Contributor
timestamp: February 07, 2021, 04:17:36 pm
content: I think I missed the above discussion...Does the above mean that checking the ESR status solves the timing issue? That would be great!I would also like to read the channel 3 output status.Using SYSTem:STATus? only gives the status of CH1 and CH2, not CH3If someone has a solution for that, that would be great too!

author: rfclown
author_rank: Frequent Contributor
timestamp: February 07, 2021, 05:42:51 pm
content: Old thread, but thought I'd put something in here that I had to figure out to communicate SCPI over ethernet with a Siglent scope (don't remember model, 4 channel). I communicate with instruments using LabVIEW's VISA Read and Write vis. I discovered that I had to put the VISA vis in synchronous mode. It isn't even a wired option of the vi. You have to right click on the "VISA Write" or "VISA Read" vi and select either "Do I/O Synchronously" or ""Do I/O Asynchronously". Asynchronous is the default, and the Siglent scope didn't like it. In all my years of remote instrument control with LabVIEW (about 30 years) I've never run across this one. I didn't know it existed. I've got old HP gear that I have to use a different GPIB "mode" from the default, but never heard of the synchronous thing.It was in the Siglent manual to use synchrounous. This was at work, so I don't have the scope or the manual in front of me to double check this. I am really disappointed in the remote operation of the scope. I've worked with many different instruments, and reading the waveform is the least straight forward of anything I've come across (getting all the parameters correct for scaling and such). If it comes time to buy a similar type scope for home, this would be my biggest negative on the Siglent. I've been ok with the basic manual operation of it.

author: HendriXML
author_rank: Super Contributor
timestamp: February 07, 2021, 06:08:31 pm
content: If done quite a lot scpi stuff with a SDS1104X-E scope. I think I might have used 90% of the commands (just a guess) without real issues.When it came down to reading the waveform this:WaveAce 1000/2000 Remote Control Command Referencedocument was very useful.I've used my own tool/scripts and NI Visa stuff version 20.Older version of the library:https://github.com/HendriXML/XMLScripts-Common-VISA/blob/master/VISA%20Siglent%20Scopes.xmlI'm not familiar with LabVIEW but nice things can be done with the mentioned scope using scpi..The powersupply I'm less enthusiastic about in this regard.. But maybe if the mentioned problems are solved, the level may rise.

author: C.J.S.
author_rank: Contributor
timestamp: November 06, 2021, 11:13:18 pm
content: Quote from: sequoia on June 15, 2020, 03:15:08 amFYI, earlier this year FW 1.01.01.02.07R2 was released for SPD3303X and SPD3303X-E, and in my experience SCPI support in this latest FW version is much improved compared to FW 1.01.01.02.05. I say this because when I use HKJ's "Test Controller" program to send SCPI commands to my SPD3303X-E with FW 1.01.01.02.07R2, the PSU responds correctly, while with FW 1.01.01.02.05 the PSU does not respond and gives an error beep on many SCPI commands.For example when I send command "OUTP CH1,ON" to SPD3303X-E with FW 1.01.01.02.07R2, channel 1 is turned ON, while with FW 1.01.01.02.05 the channel stays OFF and the PSU gives an error beep.Quote from: tubularnut on June 15, 2020, 07:31:24 pmFYI, a few days ago I managed to make a working device definition for control of SPD3303X and SPD3303X-E from HKJ's "Test Controller" program. This definition file is working well in combination with FW 1.01.01.02.07R2, but does not work with FW 1.01.01.02.05 or earlier. The definition file can be downloaded fromthis post.

author: Jack24044
author_rank: Contributor
timestamp: June 12, 2024, 08:08:45 pm
content: Hi, I tested those commands using putty telnet on IP address and port 5025.They do work.SPD3303X-E,1.01.01.03.11R1,V6.2Regards,Jack