SPD3303X-E SCPI Interface issues

[tautech]

[...]
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]

[b]Output ratings 0~30V/0~6A (Max: 32V, 6.4A)[/b]

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

IIRC 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.

[KE5FX]

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.

Too 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 like

send("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.

[sequoia]

Too 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.

That 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?)....

[HendriXML]

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.

Too 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 like

send("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.

I'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 to have to add delays, but if its the only way, it can't be wrong at the users side.

[tv84]

Too 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.

You should/can also use *ESR?.  I don't have experimented with which is safer to use.

[KE5FX]

I'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 to have to add delays, but if its the only way, it can't be wrong at the users side.

*OPC? means OPeration Complete.  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 the standard.

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?

[tv84]

It's true that there's an equivalent ESR bit, but I'm unaware of any benefit to issuing *OPC;*ESR? rather than just *OPC?

I could analyse in greater detail but I don't think it's worth it.

One thing is certain, Rigol uses only *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.

[KE5FX]

OPC - deals with bit 0   (previous instructions concluded)
ESR - deals with bit 3 and 4  (error in previous instruction)

So they are complementary instructions.

They 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's app note is a lot clearer (see page 12).

[HendriXML]

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 CH3

If someone has a solution for that, that would be great too!

[rfclown]

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.

[HendriXML]

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 Reference
document 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.xml

I'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.

[C.J.S.]

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")...

FYI, 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.

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).

FYI, 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 from this post.

[Jack24044]

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.2
Regards,
Jack