Products > Test Equipment
SPD3303X-E SCPI Interface issues
<< < (4/8) > >>
HendriXML:

--- Quote from: tautech on October 28, 2019, 10:01:29 am ---
--- Quote from: HendriXML 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: ---OUTPut CH1,OFF
OUTPut CH2,OFF

--- End code ---
The strange thing is that the status

--- Code: ---SYSTem:STATus?
Result: 0x5

--- End code ---
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

--- End quote ---
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.

--- End quote ---
[{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...)
zerto:
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 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)
}

--- End code ---

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 !
HendriXML:

--- Quote from: zerto 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: ---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)
}

--- End code ---

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 !

--- End quote ---
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.
zerto:

--- Quote from: HendriXML on November 09, 2019, 01:35:00 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.

--- End quote ---
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: ---inst.write_termination=” #Modify default termination character

--- End code ---
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.
HendriXML:
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.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod