Korad KA3005P I/O Commands

[UPI]

I was doing some quick testing of external I/O commands on the Korad KA3005P. Everything appears to react as expected except the STATUS command.

STATUS?
Description?Returns the POWER SUPPLY status.
Contents 8 bits in the following format
Bit Item Description
0 CH1 0=CC mode, 1=CV mode
1 CH2 0=CC mode, 1=CV mode
2, 3 Tracking 00=Independent, 01=Tracking series,11=Tracking parallel
4 Beep 0=Off, 1=On
5 Lock 0=Lock, 1=Unlock
6 Output 0=Off, 1=On
7 N/A N/A

All I get in return is "Q".

*IDN? returns the version as KORADKA3005PV1.3

Has anyone played around with controlling the supply externally? Any pitfalls etc?

Thanks

[Bored@Work]

I was doing some quick testing of external I/O commands on the Korad KA3005P. Everything appears to react as expected except the STATUS command.

STATUS?
Description?Returns the POWER SUPPLY status.
Contents 8 bits in the following format
Bit Item Description
0 CH1 0=CC mode, 1=CV mode
1 CH2 0=CC mode, 1=CV mode
2, 3 Tracking 00=Independent, 01=Tracking series,11=Tracking parallel
4 Beep 0=Off, 1=On
5 Lock 0=Lock, 1=Unlock
6 Output 0=Off, 1=On
7 N/A N/A

All I get in return is "Q".

Looks reasonable.

Q = 01010001

-> 1:   CH1 CV
-> 0:   CH2 CC
-> 00: Tracking independent
-> 1:   Beep on
-> 0:   Lock
-> 1:   Output on
-> 0:   N/A

[UPI]

It returns a "Q" no matter what I have BEEP set to using "BEEP0" or "BEEP1".

It also returns nothing if the output is not enabled with "OUT1". In other words, "STATUS?" does nothing unless the output is enabled.

[UPI]

If I put it into CC mode be setting it to 5V at 10ma then short the leads, I get a status of "P". That matches the expected return value.

I cannot seem to get it to report the status of beep or lock. It always returns "Q" or "P" no matter how I have the two set.

It also only returns a space whenever the output is disabled.

Maybe I am overlooking something in the order of operations or something? It's not really a big deal as I should be able to work around these issues.

[UPI]

So, it appears that the Korad does not properly report the status of beep or lock. Beep and lock always report as a zero.

[UPI]

After much confusion (apparently we have lead poisoning), it appears that the only thing we can't get to work properly is beep controlled through external I/O. It may be something we are doing wrong.

The remote mode times out after about 20 seconds after the last command and then the front panel is active again.

Commands are all caps.

I don't know much about the use and activity of beep.

My head hurts and I have to get back to real work.

See attachment.

[UPI]

OK, I can turn beep off from external I/O but the status still shows it to be on. I cannot turn beep back on through external I/O. If you type just "BEEP", it also disables it.

If you let the remote control time out, the beep comes back on.

Beeps occur on commands received or buttons pressed unless you disable it.

Can I get that hour I wasted back somehow?

OY!

[plutonian]

I can't query my KA3005P with the USB, and I don't have a RS-232 around. I know PS, Cable and computer port  are working because the software works just fine. Does somebody know how to get putty, screen or even hyperterminal to work.

Right now I'm just getting a black screen and not a single character back, the PS is beeping after the first key entry though.

Thanks.
 

[UPI]

I couldn't get Hyperterminal to work, but the Arduino program's Serial Monitor works just fine. If I remember correctly, you set it to 9600 CR/LF.

Edit: Does not use CR/LF!

[timb]

plutonian, did you ever get this working? I purchased one of these from SRA last work and it's working great other than not being able to access it via a serial terminal. If I connect the USB to my Raspberry Pi, it loads up the kernel modules just fine and shows up as a tty entry in /dev. I've tried connecting with the Arduino serial terminal, minicom and screen. Always 9600 8/N/1. The first key I press makes the unit beep, but I don't see anything.

I've also tried it plugged into my MacBook Air (driver is built in) via Parley and screen, still no dice. As a last resort I installed Windows XP in a VM and loaded up the actual software which works perfectly; next I tried HyperTerminal and PuTTY with no luck.

Thinking it might be a USB issue I pulled out a PL23** USB-to-Serial adapter and tried that on the Mac, RPi and Windows XP VM to no avail. Finally, as a last resort I rigged up a level shifter so I could connect the raw serial output directly to the UART GPIO pins on my Pi. Nope.

I *know* the unit is getting something, because like I said, it beeps after the first key press.

Any ideas? I really want to write a control program for Linux, but to do that I need to be able to connect.

[timb]

Bumping for Monday. I really want to write some Linux/OS X software for this, but I need to be able to talk to it first. Anyone? 

[UPI]

I was using the Arduino IDE just fine.
My brother wrote code to talk to the Korad for an auto calibration project that is working well. I will see if he has a minute to throw something together for you.

[Wilmotron]

Hello. I'm the aforementioned brother.

The KORAD actually takes no line ending. If you have one set in your serial terminal, unset it. Sending a line ending will result in an unrecognized command, which is kindly responded to with nothing. It also has a nasty habit of cutting input commands in half. This is either a poor implementation or a poor specification; I'm not sure which. Either way, I've found it most effective to `do { try to set it } while (it's not reporting the correct voltage/amperage/setting)` for settings that have arbitrary user input like voltages. For example, when giving it VSET1:05.50, it could possibly set it to 0V, 5V or 5.5V if the malicious instruction falls between or outside significant digits before you're finished talking to it.  Instead, keep sending it the VSET1 command until VSET1? returns the desired voltage. Hey, at least it'll never pump more voltage than you tell it to, since it's a straight truncation.

Also, keep in mind that it doesn't return a line ending, either, so you'll have to know what's being returned and count bytes or simply wait.

Hope this helps. It's a tricky machine to communicate with. Who needs to waste all that serial bandwidth with newlines, right?

edit: Also, it doesn't echo.

[timb]

Thanks man! I'll give this a go tonight and report back. What sort of controller chip is in thing? I seem to recall reading somewhere it was an ATmel chip of some type, but I can't find the information now.

[timb]

  Well, I got it working! Turns out my trouble was two fold. First, I had been setting my terminal to append \n\r (CR/LF) to the end of commands based on UPI's suggestion a few posts up. (You may want to edit that in case others stumble upon this post in Google like I did.)

Secondly, I was checking for signs of life with the STATUS? command, which doesn't do anything unless the output is turned on.

So, I plugged it in to my Mac, opened up Parley (a serial terminal app) set it to not append anything and sent it VSET1:5.50 and, sure enough, it worked!

Now, I know earlier in the post UPI mentioned that the BEEP command doesn't work and I did get the same results. However, the STATUS? command *is* reflecting the status of beeper as toggled on the front panel. It is not, however, reporting the status of the lock command.

At first I was confused that STATUS? was throwing single ASCII characters back at me, but then I realized STATUS? just reported as an 8-bit byte and my terminal program was interpreting that as an ASCII character. (Afterwards I remember that was actually what this thread was originally about!)

So now I'll be able to control the unit from my Raspberry Pi, so thanks for that! I'll be writing a little program in Python (with a GUI) that will give you a simple front-panel interface to allow you to see and set the voltage/current, in addition to feeding it a CSV/TSV file of voltages/currents to play back. The plan is to make the file input compatible with the log files from QtDMM, so you can record voltage measurements with any inexpensive QtDMM compatible multimeter and play them back on your Korad programmable power supply! Pretty neat, eh?

Oh yeah, one further question. Is it possible to control the OVP/OCP setting over serial? I didn't see a command for that in the communication protocol PDF.

Edit: I know it's possible for at least OCP, as there's a button for it in the OEM software. Worst case scenario I'll just use some serial sniffing software I found in the VM.

[timb]

Sweet, I've gotten a script to reliably change the voltage. I followed your advice and set a loop to set the voltage, read it and loop back if it doesn't match the expected voltage. It's working very reliably now!

I also spent a few minutes banging my head against a wall at the output of STATUS?...

I get that it's supposed to report back a byte value and that the terminal is interpreting it as an ASCII character (Q, in this case), but when I converted it to binary it wasn't matching up at all with what the status should be. (For example, Q is 01010001, right? Well the first bit there is 0, but it should be 1 because the unit was in CV mode.)

After staring at it for 5 minutes, I realized the binary output must be little endian, which means the MSB is last. Duhhhh.

If you read the byte from right to left, it matches up perfectly with the actual status.

[jav]

Oh yeah, one further question. Is it possible to control the OVP/OCP setting over serial? I didn't see a command for that in the communication protocol PDF.

Edit: I know it's possible for at least OCP, as there's a button for it in the OEM software. Worst case scenario I'll just use some serial sniffing software I found in the VM.

I reverse-engineered the communications of the OEM software, and it doesn't use any of the documented commands. It has its own protocol, that I implemented in some Linux code. If someone is interested I can describe it.

[george graves]

I'd love to know how you did that?  Did you sniff the USB?  Please do tell.....

[jav]

I'd love to know how you did that?  Did you sniff the USB?  Please do tell.....

Yes, I sniffed the USB. I couldn't manage to get the documented commands working so I wondered how the OEM application worked.

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.

[davidcie]

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.

[neslekkim]

Does this psu have serial? I have an Tenma, that looks exactly like the Korad's, but no external connectors I think?

[Mike Warren]

Does this psu have serial? I have an Tenma, that looks exactly like the Korad's, but no external connectors I think?

It has USB serial. Shows up in Windows as a Nuvoton Virtual COM port.

[neslekkim]

Ok, so even the front is similar, they are not the same then, no usb on mine
Tenma 72-10495 is my modelnr.. oh well..

[davidcie]

Shows up in Windows as a Nuvoton Virtual COM port.

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

[Mike Warren]

Sorry, no. I've never tried.

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.

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

[stmdude]

Never mind. I'm an idiot..  (Didn't send the full 24 bytes)

If anyone is wondering, it _is_ CRC-8, and the seed is 0x00

[0x2a]

In case anyone is interested I have written a GUI based on C++/Qt called LabPowerQt for devices using this kind of protocol. It works quite good so far but is still missing the programming feature of the original software.

My main target platform is Linux / OS X as the original software is not available for this platform but I have also created a Windows installer. Releases can be found on github as well
You can see how I am "talking" to the device in the source code.

[djrecipe]

Hey guys, I have been using the Korad KA3005P power supply to test some proprietary data acquisition hardware at home.

I have found that enabling Over-Current Protection or Over-Voltage Protection usually causes the STATUS? command to return 63 (all 1s).

If OCP and OVP are disabled on my unit, then STATUS? returns the proper bits.

Lastly, I've found that the BEEP0 or BEEP1 command does nothing, or at least I'm not sure what it accomplishes.

I have written a very simple WPF/C# windows program for controlling the Korad KA3005P, with a little bit of adaptation you could probably use it to control your model and suit your needs.