Korad KA3005P I/O Commands

[davidcie]

But if you look at the reply from Jav, it looks like the supply expects a string of bytes rather than a terminal type of input.

Yes, although he was writing about alternative ways to control the output - alternative to the documented commands briefly discussed on page 1 of this thread. Will try to PM jav / timb and ask them directly, they seem to be one of the few who accomplished the feat

[mozzis]

Used SerialMon (http://www.serialmon.com/) which is donateware, to sniff the transactions with the provided software. In my (just purchased) version, they are using the documented commands. Commands output CANNOT include a CR or LF as others have mentioned here. I can select OCP or OVP with OVP1, OVP0 and OCP1, OCP0.
My Korad PS has two connectors on the back; one is a USB host socket, the other is a 9-pin serial. Using the .Net SerialPort class, the USB port works the best; I can enable handshaking and I don't seem to have problems with truncated output or partial input. To use the 9-pin, I had to turn off all handshaking.

[rr100]

Did you manage to talk to it via terminal on Windows by any chance?

For some reason it didn't work for me either with putty. However it does work with RealTerm (find it on sourceforge). Enable the service it asks for after finishing the install (don't know what it does but it doesn't work without it) and then (after setting speed, com port, click connect under "Port") use the 5th tab (Send) and put the command in the one-line box and then do "Send ASCII". That's the only way it works for me.

[davidcie]

rr100, thanks for your input! In the end I switched to using the Ruby class someone wrote that includes support for most of the commands. Somehow it seems that Ruby's implementation of serial communication is liked by the PSU a lot more than PuTTY's...

[rr100]

Any progress on some python code that anybody can share? I know about https://gist.github.com/k-nowicki/5379272

I could code what I want (is just basic logging and maybe at most some event-driven changes), there are just a few commands after all but I'm sure I'll make some unsafe mess. Anybody who learned how to program this millennia and has some code to share?

[Andreas]

Did any of you guys ever managed to get this thing to communicate on Windows? I've tried several programs (PuTTY, MTTTY, HyperTerminal and some) always using the correct port settings but haven't seen a single reply from the power supply. I also can't seem to be able to find the line ending option in PuTTY. (Yes, the funny Korad program works so this is definitely a software problem.)

Would like to know I'm not fruitlessly waisting my time if none of the many Windows terminal programs work with this unit, and Parley is the only option.

I have tested using hyperterminal, COM-Port via FTDI-Dongle.
The trick is not to enter single characters but whole command strings with copy + paste into the hyperterminal window.
There seems to be a very short character timeout in the KORAD.

With best regards

Andreas

[davidcie]

I have tested using hyperterminal, COM-Port via FTDI-Dongle.
The trick is not to enter single characters but whole command strings with copy + paste into the hyperterminal window.
There seems to be a very short character timeout in the KORAD.

Thanks Andreas! I've since switched to using the simple Ruby implementation that seems the PSU seems to like a lot more than PuTTY. It almost seems like it was specifically programmed to not work with PuTTY

[nuno]

I have this working with a test TCL script in windows (will probably also work in linux by changing the com port name). Mine is a Velleman, id "VELLEMANPS3005DV2.0" like in the sigrok doc in http://sigrok.org/wiki/Velleman_PS3005D . It does, however, seem to deviate a tiny little from the doc there; the answer to the ISET1? command always has an 'M' character at the end, like "1.500M". Anyone else seeing this? I'm using the serial port, not the USB one.

[nuno]

Another detail is that you have to a wait a little (20 - 30ms) after issuing the output ON command and before issuing another command, or the subsequent command will not work. The micro on the PSU probably takes a little time to execute the command, taking longer to return to his main loop.

[rr100]

always has an 'M' character at the end, like "1.500M". Anyone else seeing this? I'm using the serial port, not the USB one.

YES! I see the same (well I have a K at the end). Using the USB port->raspi.
I don't see it all the time, if I power cycle the supply is gone, then after I run *IDN? is back until next power cycle.

[Bored@Work]

always has an 'M' character at the end, like "1.500M". Anyone else seeing this? I'm using the serial port, not the USB one.

YES! I see the same (well I have a K at the end). Using the USB port->raspi.
I don't see it all the time, if I power cycle the supply is gone, then after I run *IDN? is back until next power cycle.

  It is rather obvious what the bug likely is.

The output length of the ISET1? command is wrong, sending/reading 6 characters, although the result only contains 5 characters. The last superfluous 6th character just happens to be the character in the buffer from a previous command output.

The 6th character of the ID string "VELLEMANPS3005DV2.0" is an M. The 6th character of the ID string "KORADKA3005PV1.3" is a K. Do an *IDN? before ISET1? and you have an M or K in the buffer as the 6th character.

[nuno]

Yup, that's right bored. Just tested and the bug is that the answer to the ISET1? command always has 6 bytes instead of 5. No command returns more than 5 bytes (I think), so when the *IDN? is issued, it sets a visible character on the 6th byte of the PSU micro's internal buffer and it starts getting returned.

(PSU is power cycled then test starts)
C:\projs\rs125e\battery\PS3005D-Charger>tclsh
% set s [open {\\.\com6} r+]
file870d28
% fconfigure $s -translation binary -blocking 0 -buffersize 64 -buffering full
% fconfigure $s -mode 9600,n,8,1
% puts -nonewline $s ISET1? ; flush $s
% set r [read $s]
0.160
% string length $r
6
% puts -nonewline $s VSET1? ; flush $s
% set r [read $s]
04.93
% string length $r
5
% puts -nonewline $s *IDN? ; flush $s
% read $s
VELLEMANPS3005DV2.0
% puts -nonewline $s VSET1? ; flush $s
% read $s
04.93
% puts -nonewline $s ISET1? ; flush $s
% read $s
0.160M
% close $s
%

Seems to be only this command. At least it's an impactless bug, I wish all product bugs were like this...

On the ISET1? implementation I just read 5 bytes for the relevant result and then read an extra 1 byte with a timeout discarding any result; this will make it continue to work even if they fix the bug in the future.

[rr100]

COOL! I didn't even realize the outputs are fixed length, this is actually better.

[rr100]

Another one.
What is Tracking 00=Independent, 01=Tracking series,11=Tracking parallel ?

[rr100]

And two more:

- I try to make sure I don't get random garbage from the buffer, or previous command. So I flush the buffer before any command. Well, of course it doesn't work if the garbage did not arrive yet! For example if you do just:

1. ISET1?
2. read only 5 bytes (one remains in the buffer)
3. flush buffer
4. do something else
5. read buffer

You will get at step 5 (also) the remaining byte!!! Because at step 3 the byte did not arrive yet!

So I learned to sleep before 3.

- I think this was mentioned before but you can't manipulate the PS from the physical buttons anymore for some seconds after you spoke to it via computer. Don't like it at all, I wanted to make just a simple commanda line logger (including some calculated values: W, Wh, mAh) but is blocking the buttons! Any workaround? I don't want to but if there's no workaround I'll have to add also some simple controls like voltage/current up/down.

[nuno]

It's easier if you just read and throw out that extra buggy byte, with a short timeout (let's say 20ms between bytes). If they ever fix it on the PSU, it will still work (will always timeout, you get a 20ms time penalty).

You're making a battery charger too?

[rr100]

Anyone interested in making this together ... granted, I do program like I've been time-traveled here since 30 years ago (and given access to a computer and google) but I do run into so many simple issues I could write a book already after 1-2 weeks of part-time programming.

Anyone interested at all? Is all pyton (raspi but not at all specific) - nothing blocking that I couldn't do myself but more people contributing and more people USING it would be nice...

[rr100]

Well, I guess I can at least share what I've done until now.

https://github.com/vb0/korad/

From README

=========================
THIS IS HIGHLY EXPERIMENTAL
USE AT YOUR OWN RISK
WORK IN PROGRESS
This will control a KA3005P lab power supply
The device is hard coded (this is my default usb->serial device on raspi): /dev/ttyACM0
I've used quite a few modules (maybe too many), the only one a bit off-the-beaten-track should be https://github.com/magmax/python-readchar
Usage:
run kcontrol.py
It will output every 1.x seconds or so (there are some "hard" coded timers that can be easily changed) something like:
44mA 5.00V 0.22000W 0.25496mWh 0.050993mAh 4.3s SET:700mA 5.00V
As the power supply is locked for many seconds after any serial command I have added the following rudimentary controls:
v V lower v is voltage "-0.01", V, as in shift+v is +"0.01"
i I current down and up
o O output off/on
q quit

[linux-works]

just bought the 3005p psu and have a remote control question.

how fast can the psu change values when directed over serial or usb?

from what I can tell, just playing with bash or python, you can send commands to the unit in simple ascii but you do have to leave off any line term chars (no hex 0x0A or 0x0D chars) and the replies, when they are a query, come back also as ascii strings that are not 10/13 terminated (may be zero byte termed, not sure).

when I do send a change command to the psu, it takes several seconds, beeps and then the value takes effect.  is it really taking this long to process and execute commands?  I have a project where I need to step thru a lot of test voltages (in a for-loop) and if it takes many seconds to 'take' for each change command, that makes this psu too slow for my needs.

anyone have any experience in how fast you can send volt-change commands to the unit?

[rr100]

For sure you can do at least 1 change/s, maybe considerably more. Of course it'll slow down if you ASK for what is already set as everything goes over the same serial.

Beeping means it doesn't like something, it isn't normal. Probably some end-of-line or other unexpected character.

However even if you change the parameters quickly from your program it doesn't mean they'll be changed in reality that quickly (I mean for example a voltage drop can take quite long without a significant load as I don't think it has any reasonable clamping circuit).

[linux-works]

good to know that beeping is not normal.  what I have tried, so far, is to do simple:

echo -n "VSET1:05.00" > /dev/ttyACM0

kind of things and its possible that a 0-byte is getting sent.  I know no other whitespace is being sent, but maybe the 0 byte is bothering it.  I plan to move to python later but still not 100% sure it won't include a 0 byte in strings that I send to serial.

given that you do need to check if the change 'took', I think that does add extra round-trip time to the whole process.  I would have to query this psu or a meter connected to it before I can be sure the voltage took effect and I can get status from the DUT.

1 second is kind of a long time, though.  I wonder if the HP e36xx (which I also have access to) will run that much faster as I step thru output voltage values.  anyone use both of those models that could comment?

[rr100]

Running:

Code: [Select]

while :
do
        echo -n "VSET1:05.00" > /dev/ttyACM0
        sleep $1
        echo -n "VSET1:01.00" > /dev/ttyACM0
        sleep $1
done

it seems that this is the best it can do: $1 = 0.015 (seconds but I'm running on a raspberry pi so there might be some other delays). Going to 0.01 (or to any low value) still works but the scope is showing that sometimes one change was missed (probably the micro is busy doing something else that looking on the serial if there's no buffer or maybe the buffer is full if there is buffer).

Other than that I think it is quite fast after all, more than 10 "double" (5->1V and back 1->5) changes per second if I read the scope correctly. One picture is without load and the second one is with something like 22 ohm load.

[h_smith]

I received this signed version of the virtual serial port driver from Korad and thought I would pass it along.

For whatever reason I was getting a Error Code 10 when attempting to use a couple Dell Laptops with the USB driver. Has anyone else seen that issue? When connected to my desktop there was no issue.

Note: Rename the attachment from a .txt to .rar as I could not attach a .rar file.

[sima]

Shows up in Windows as a Nuvoton Virtual COM port.

Did you manage to talk to it via terminal on Windows by any chance?

Don't know if this as been answered, I got it to work on Windows using CoolTerm by using Connection>Send String.

[stmdude]

It uses fixed length 24-byte messages and responses. Looks like they're used for all Korad power supplies and are able to control all channels.

Message format (9600 8N1):

0xAA 0x20 vh1 vl1 ah1 al1 vh2 vl2 ah2 al2 0 0 0 0 1 out 1 0 prot mode 0 0 0 crc

volts first output = (vh1*256 + vl1) / 100
amps first output = (ah1*256 + al1) / 1000
volts second output = (vh2*256 + vl2) / 100
amps second output = (ah2*256 + al2) / 1000
out = 1 to enable output, 0 to disable
prot = protection type (0 = ovp, 1 = ocp)
mode = 0 independent, = 1 serial, = 2 parallel, = 3 symmetric
crc is the sum of all previous bytes

In the reply, volts and amps are actual values, not the programmed ones.

Holy thread necromancy, batman!   ( I checked, an jav has been online recently )

This is very interesting to me. However, I'm having trouble getting it to work. Are you sure the last byte is a CRC-8?  If so, would you know if they're using a seed value for the calculation?