Author Topic: SPD3303X-E SCPI Interface issues  (Read 9086 times)

0 Members and 1 Guest are viewing this topic.

Offline SpiderKennyTopic starter

  • Newbie
  • Posts: 4
  • Country: gb
SPD3303X-E SCPI Interface issues
« on: June 06, 2019, 02:21:27 pm »
Hi
I 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-11

The 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?
 

Offline finos

  • Contributor
  • Posts: 28
  • Country: gr
Re: SPD3303X-E SCPI Interface issues
« Reply #1 on: June 06, 2019, 02:26:36 pm »
Try putty with telnet mode with 5025 port.

Output CH1, ON

Be careful with the spacies and formatting.
Try any other scpi command as a test
 

Offline H.O

  • Frequent Contributor
  • **
  • Posts: 835
  • Country: se
Re: SPD3303X-E SCPI Interface issues
« Reply #2 on: June 06, 2019, 04:21:42 pm »
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.
 

Offline SpiderKennyTopic starter

  • Newbie
  • Posts: 4
  • Country: gb
Re: SPD3303X-E SCPI Interface issues
« Reply #3 on: June 07, 2019, 08:48:36 am »
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.
Thanks!
Well, not according to manual - but that is probably wrong.
I've tried all these combinations, but none are working so far..:
OUTPut CH1,ON
OUTP CH1,ON
OUTPut:CH1,0
CH1:OUTPut ON

Maybe 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:
 

Online tautech

  • Super Contributor
  • ***
  • Posts: 28963
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Avid Rabid Hobbyist.
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 

Offline finos

  • Contributor
  • Posts: 28
  • Country: gr
Re: SPD3303X-E SCPI Interface issues
« Reply #5 on: June 12, 2019, 06:07:21 pm »
Is there any way to disable the beeper every time that I send a cmd to it?

 

Online tautech

  • Super Contributor
  • ***
  • Posts: 28963
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Re: SPD3303X-E SCPI Interface issues
« Reply #6 on: June 13, 2019, 09:12:02 pm »
Is there any way to disable the beeper every time that I send a cmd to it?
I'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 ?
Avid Rabid Hobbyist.
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 

Offline finos

  • Contributor
  • Posts: 28
  • Country: gr
Re: SPD3303X-E SCPI Interface issues
« Reply #7 on: June 13, 2019, 09:38:21 pm »
Is there any way to disable the beeper every time that I send a cmd to it?
I'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 ?
Yes I've read that... But the return is correct

In my case it beeps
When I open the socket
On receive of every command
On disconnect of the socket

Tommorow I will send the code. For me now it's 2am... See ysla all[emoji16]
 
The following users thanked this post: tautech

Online tautech

  • Super Contributor
  • ***
  • Posts: 28963
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Re: SPD3303X-E SCPI Interface issues
« Reply #8 on: June 13, 2019, 09:48:21 pm »
Is there any way to disable the beeper every time that I send a cmd to it?
I'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 ?
Yes I've read that... But the return is correct

In my case it beeps
When I open the socket
On receive of every command
On disconnect of the socket

Tommorow I will send the code. For me now it's 2am... See ysla all[emoji16]
Just checking........your firmware version please ?
Avid Rabid Hobbyist.
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 

Offline finos

  • Contributor
  • Posts: 28
  • Country: gr
Re: SPD3303X-E SCPI Interface issues
« Reply #9 on: June 14, 2019, 09:08:27 pm »
so
fw version is 1.01.01.02.05
hd version is 3.0
 
The following users thanked this post: tautech

Offline finos

  • Contributor
  • Posts: 28
  • Country: gr
Re: SPD3303X-E SCPI Interface issues
« Reply #10 on: July 25, 2019, 10:09:48 pm »
Can the siglent handle 2 simultaneous connections querying data?
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 4130
  • Country: fi
  • Born in Finland with DLL21 in hand
Re: SPD3303X-E SCPI Interface issues
« Reply #11 on: July 26, 2019, 07:24:11 am »
Hi
I 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-11

The 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?

I 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 tips
"There are two areas that differ from some other instrumentation:"

And here is one:

Quote from: Siglent SPD programming tips
The SPD requires “\n” termination only. Additional characters will cause a failure.

\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 Values
https://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)
« Last Edit: July 26, 2019, 07:32:35 am by rf-loop »
BEV of course. Cars with smoke exhaust pipes - go to museum. In Finland quite all electric power is made using nuclear, wind, solar and water.

Wises must compel the mad barbarians to stop their crimes against humanity. Where have the (strong)wises gone?
 

Offline HendriXML

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
Re: SPD3303X-E SCPI Interface issues
« Reply #12 on: October 27, 2019, 11:09:36 pm »
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: [Select]
OUTPut CH1,OFF
OUTPut CH2,OFF
The strange thing is that the status
Code: [Select]
SYSTem:STATus?
Result: 0x5
Shows that channel 2 is "off", but in reality the button is lighted and I get a voltage readout

A wait time of 100 ms has occasional misfunctioning
A wait time of 300 ms seems to be OK, but that's not what I call solid interfacing
« Last Edit: October 27, 2019, 11:23:14 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Online tautech

  • Super Contributor
  • ***
  • Posts: 28963
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Re: SPD3303X-E SCPI Interface issues
« Reply #13 on: October 27, 2019, 11:19:45 pm »
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.
Trying 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.  :-\
Avid Rabid Hobbyist.
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 

Online tautech

  • Super Contributor
  • ***
  • Posts: 28963
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Re: SPD3303X-E SCPI Interface issues
« Reply #14 on: October 28, 2019, 10:01:29 am »
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: [Select]
OUTPut CH1,OFF
OUTPut CH2,OFF
The strange thing is that the status
Code: [Select]
SYSTem:STATus?
Result: 0x5
Shows that channel 2 is "off", but in reality the button is lighted and I get a voltage readout

A wait time of 100 ms has occasional misfunctioning
A wait time of 300 ms seems to be OK, but that's not what I call solid interfacing
OK 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.pdf
P35
3.1 Syntax Conventions
A 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, OFF

I'm no programmer so this could be wrong but maybe it's worth a try ?

Further down on P40 in 8. OUTPut
OUTPut {CH1|CH2|CH3},{ON|OFF}

One should work as expected.
Avid Rabid Hobbyist.
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 

Offline HendriXML

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
Re: SPD3303X-E SCPI Interface issues
« Reply #15 on: October 28, 2019, 10:40:59 am »
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: [Select]
OUTPut CH1,OFF
OUTPut CH2,OFF
The strange thing is that the status
Code: [Select]
SYSTem:STATus?
Result: 0x5
Shows that channel 2 is "off", but in reality the button is lighted and I get a voltage readout

A wait time of 100 ms has occasional misfunctioning
A wait time of 300 ms seems to be OK, but that's not what I call solid interfacing
OK 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.pdf
P35
3.1 Syntax Conventions
A 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, OFF

I'm no programmer so this could be wrong but maybe it's worth a try ?

Further down on P40 in 8. OUTPut
OUTPut {CH1|CH2|CH3},{ON|OFF}

One should work as expected.
[{CH1|CH2}:]OUTPut, OFF
This command form, which should probably have been
[{CH1|CH2}:]OUTPut OFF
Both 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...)
« Last Edit: October 28, 2019, 10:52:25 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 
The following users thanked this post: tautech

Offline zerto

  • Contributor
  • Posts: 13
  • Country: fr
Re: SPD3303X-E SCPI Interface issues
« Reply #16 on: November 09, 2019, 12:19:16 pm »
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: [Select]
package main

import "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 one
fmt.Printf("> %v\n", strings.TrimSpace(cmd))
// Send the command string exactly as passed to the function
// do not add a \n here ! this is important
fmt.Fprintf(conn, cmd)
// if a delay is required
time.Sleep(delay)
// if there is a response to read
if 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 address
if err != nil {
log.Fatal(err)
}
defer conn.Close()

// Get the identification string
send(conn, "*IDN?\n", true, 0)
// Get the current status of the unit
send(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 SPD3305X
send(conn, "MODE:SET 2W", false, 100*time.Millisecond)
// Set out to 5v
send(conn, "VOLT 5.0\n", false, 0)
// Max current to 100mA
send(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 settle
send(conn, "OUTP CH1,ON", false, 2000*time.Millisecond)
// Check if the last command generate an error
send(conn, "SYST:ERR?\n", true, 0)
// Check what is the selected voltage
send(conn, "VOLT?\n", true, 0)
// Check the actual output voltage
send(conn, "MEAS:VOLT?\n", true, 0)
// Check the actual output current
send(conn, "MEAS:CURR?\n", true, 0)
// Check the actual output power
send(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 ending
send(conn, "OUTP CH1,OFF", false, 0)
// Check if the last command generate an error
send(conn, "SYST:ERR?\n", true, 0)
// Lock the unit and quit
send(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
> *LOCK


When running it I had a 220 resistor attached so the results are fine.

Please confirm from your side !
« Last Edit: November 09, 2019, 12:21:20 pm by zerto »
 

Offline HendriXML

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
Re: SPD3303X-E SCPI Interface issues
« Reply #17 on: November 09, 2019, 01:35:00 pm »
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: [Select]
package main

import "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 one
fmt.Printf("> %v\n", strings.TrimSpace(cmd))
// Send the command string exactly as passed to the function
// do not add a \n here ! this is important
fmt.Fprintf(conn, cmd)
// if a delay is required
time.Sleep(delay)
// if there is a response to read
if 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 address
if err != nil {
log.Fatal(err)
}
defer conn.Close()

// Get the identification string
send(conn, "*IDN?\n", true, 0)
// Get the current status of the unit
send(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 SPD3305X
send(conn, "MODE:SET 2W", false, 100*time.Millisecond)
// Set out to 5v
send(conn, "VOLT 5.0\n", false, 0)
// Max current to 100mA
send(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 settle
send(conn, "OUTP CH1,ON", false, 2000*time.Millisecond)
// Check if the last command generate an error
send(conn, "SYST:ERR?\n", true, 0)
// Check what is the selected voltage
send(conn, "VOLT?\n", true, 0)
// Check the actual output voltage
send(conn, "MEAS:VOLT?\n", true, 0)
// Check the actual output current
send(conn, "MEAS:CURR?\n", true, 0)
// Check the actual output power
send(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 ending
send(conn, "OUTP CH1,OFF", false, 0)
// Check if the last command generate an error
send(conn, "SYST:ERR?\n", true, 0)
// Lock the unit and quit
send(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
> *LOCK


When running it I had a 220 resistor attached so the results are fine.

Please confirm from your side !
Thanks 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=7932 but 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.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline zerto

  • Contributor
  • Posts: 13
  • Country: fr
Re: SPD3303X-E SCPI Interface issues
« Reply #18 on: November 09, 2019, 03:02:07 pm »
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=7932 but from what I experienced 300 ms would be better.
Thanks 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: [Select]
inst.write_termination=” #Modify default termination character
Checking 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.
 

Offline HendriXML

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
Re: SPD3303X-E SCPI Interface issues
« Reply #19 on: November 09, 2019, 04:15:41 pm »
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.
« Last Edit: November 09, 2019, 04:23:54 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline sequoia

  • Supporter
  • ****
  • Posts: 154
  • Country: us
Re: SPD3303X-E SCPI Interface issues
« Reply #20 on: June 15, 2020, 03:15:08 am »
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")...

 

Offline tubularnut

  • Regular Contributor
  • *
  • Posts: 225
  • Country: gb
Re: SPD3303X-E SCPI Interface issues
« Reply #21 on: June 15, 2020, 07:31:24 pm »
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.
 

Offline sequoia

  • Supporter
  • ****
  • Posts: 154
  • Country: us
Re: SPD3303X-E SCPI Interface issues
« Reply #22 on: June 15, 2020, 08:24:35 pm »
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: [Select]
Output rating 0~32V/0~6.4A

But 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?


 

Online tautech

  • Super Contributor
  • ***
  • Posts: 28963
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Re: SPD3303X-E SCPI Interface issues
« Reply #23 on: June 15, 2020, 09:07:18 pm »
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: [Select]
Output rating 0~32V/0~6.4A

But 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?
Take 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.
 
Avid Rabid Hobbyist.
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 

Offline sequoia

  • Supporter
  • ****
  • Posts: 154
  • Country: us
Re: SPD3303X-E SCPI Interface issues
« Reply #24 on: June 16, 2020, 04:09:19 am »
[...]
Manual states:
Code: [Select]
Output rating 0~32V/0~6.4A

But 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?
Take careful note of the rating for Series mode, it reads: 0 to around 32V and 0 to around 6.4A !

Granted 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: [Select]
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...

« Last Edit: June 16, 2020, 04:39:11 am by sequoia »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf