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.