Products > Test Equipment

SPD3303X-E SCPI Interface issues

<< < (6/8) > >>

tautech:

--- Quote from: sequoia on June 16, 2020, 04:09:19 am ---
--- Quote from: tautech on June 15, 2020, 09:07:18 pm ---
--- Quote from: sequoia on June 15, 2020, 08:24:35 pm ---[...]
Manual states:

--- Code: ---Output rating 0~32V/0~6.4A

--- End code ---

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?

--- End quote ---
Take careful note of the rating for Series mode, it reads: 0 to around 32V and 0 to around 6.4A !

--- End quote ---

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: ---[b]Output ratings 0~30V/0~6A (Max: 32V, 6.4A)[/b]

--- End code ---

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

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

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

--- End quote ---

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:

--- Quote from: KE5FX on June 16, 2020, 06:37:03 am ---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.

--- End quote ---

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:

--- Quote from: KE5FX on June 16, 2020, 06:37:03 am ---
--- 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.
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.

--- End quote ---

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.

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

--- Quote from: KE5FX on June 16, 2020, 06:37:03 am ---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.

--- End quote ---

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod