Korad KA3005P 0.0.2 segfault about smuview HOT 19 CLOSED

The segfault issue is a duplicate of #6 and is fixed in commit 52bef77.
I will release Version 0.0.3 this weekend, to fix this also in the binaries.

About the button issues, I'm not totally sure:

• Do you mean the button of the device or the button in the SmuView GUI? Could you please explain this issue in more detail?
• When you are talking about the button in the GUI. Could you provide some log output ("-l 5" argument).

The channel count in the list box refers to the number of data channels the device provides (in your case a V and an I channel), not the number of the power supply output channels. Your output channels are called "channel groups" in sigrok / SmuView.

from smuview.

Duplicate of #6

from smuview.

Thanks for the fast feedback!

I'm again testing with 0.0.1 (the build instructions seem to be all over the place in the sigrok wiki :( )

Do you mean the button of the device or the button in the SmuView GUI? Could you please explain this issue in more detail?

When the SmuView is connected to SmuView the buttons on the PSU itself do not work, but I think this is by design (well, having the on/off switch work would be nice, but I assume that's just how it's implemented in the PSU firmware by Korad)

What I actually wanted to report: In the SmuView the ON/OFF and OCP button do not work all the time. The OVP button seems to work fine tough. So you can press the On/OFF button and it might not turn on or off. You can also have the PSU being on, the graph showing that a voltage is present on the output but the button shows off.
Behavior appears to be random and not stick to off->on or on->off transition. Maybe this is visible in the log. out.log

The channel count in the list box refers to the number of data channels the device provides (in your case a V and an I channel), not the number of the power supply output channels.
Jesus, who came up with that? When I see a PSU and a channel count besides it I assume that it is the number of individual controllable channels, no matter how many settings I can control on that individual channel.

Some more notes:

• I have a 1366x768 screen and the window does not want to resize to fit my screen (the window is actually larger than my screen)
• when I enter values for V or I via the number pad, they are instantly output, which means if I want to input 12 it will output 1, then 12. Please add some kind of confirmation button and don't output it instantly.
• the V and I input fields do not always react on "," or "." if you want to enter a number which has a fractional part. It seems that I have to enter the digits very fast to be accepted for the input field. out2.log
• The dial knobs in the gui are super finicky, you can easily adjust from 1 to 30V just with a small jerk on the mouse with it being instantly output. Could you add some kind of confirm button or remove the dial knobs? Like a accept and reset button with the changes being highlighted? This is just crying for usage errors.

from smuview.

the build instructions seem to be all over the place in the sigrok wiki :(

You can find straight forward build instructions here: https://sigrok.org/wiki/Linux#Building_.28manually.29
For SmuView you only need libserialport and libsigrok.

In the SmuView the ON/OFF and OCP button do not work all the time. [...] So you can press the On/OFF button and it might not turn on or off.
Behavior appears to be random and not stick to off->on or on->off transition. Maybe this is visible in the log. out.log

I can see in the log file, that the sigrok driver sends the wrong commands to the device. I'll have a look at the driver next week, but i have no Korad psu, therefore no way to test/debug.

Jesus, who came up with that? When I see a PSU and a channel count besides it I assume that it is the number of individual controllable channels, no matter how many settings I can control on that individual channel.

sigrok supports a wide variety of device types (logic analyzers, scopes, multimeters, power supplies, ...) and therefore the naming scheme makes total sense, especially form a data acquisition point of view (which is more imported for many device types than controlling).

Some more notes:

* I have a 1366x768 screen and the window does not want to resize to fit my screen (the window is actually larger than my screen)

Yes, I have to come up with a more efficient way of using the available space.

* when I enter values for V or I via the number pad, they are instantly output, which means if I want to input 12 it will output 1, then 12. Please add some kind of confirmation button and don't output it instantly.

* the V and I input fields do not always react on "," or "." if you want to enter a number which has a fractional part. It seems that I have to enter the digits very fast to be accepted for the input field. [out2.log](https://github.com/knarfS/smuview/files/3024615/out2.log)

I'll see what I can do here.

* The dial knobs in the gui are super finicky, you can easily adjust from 1 to 30V just with a small jerk on the mouse with it being instantly output. [...]

The knobs are very handy when you use them with the mouse wheel to adjust the value.

from smuview.

* when I enter values for V or I via the number pad, they are instantly output, which means if I want to input 12 it will output 1, then 12. Please add some kind of confirmation button and don't output it instantly.

* the V and I input fields do not always react on "," or "." if you want to enter a number which has a fractional part. It seems that I have to enter the digits very fast to be accepted for the input field.

This two issues are fixed with commit 78d8ee7

from smuview.

segfault fixed in release 0.0.3

from smuview.

Maybe i have a bug fix for the "button issue".
Here is an AppImage for testing: https://www.dropbox.com/s/uz9zb4i0w0ch3z6/SmuView-0.0.3-git-9c668b9-x86_64.AppImage

The buttons (On/Off, OVP, OCP) should work now reliable.
In addition, any state changes of the power supply are now transmitted. That means, if the OCP/OVP disables the output, the state of the output button in SmuView should also change. Also you should see the actual regulation (CV/CC) of the supply (The GUI elements for CV/CC will change in the future).

from smuview.

Thanks for the fast changes!

• input of values for V and I via number pad work well with enter/return as confirmation
• I'd still vote for a confirmation of the V and I values. Not necessarily needed if the output is disabled. But if the output is enabled it is instantly changed, which may lead to user errors :/ Especially when someone inputs an number and wants do discard it or used the mouse pointer without caution.
• using the knobs with the mouse wheel work nice (didn't notice that before), but you can do the same with the input box for the numbers. I personally still don't like the round knobs which you can manipulate with your mouse pointer (probably will lead to user errors)
• on/off, ovp and ocp buttons appear to work reliable
• I cannot set values for ovp/ocp (boxes greyed out, I assume they are the same value for the main V and I value)
• what are the OVP/OTP/OCP/UVC indicators and CC/CV dropdown menu near the main on/off button for? Seem kinda redundant to me (in this use case, probably easier to do it that way than dynamic)
• When I switch on OCP and then the main on/off button and the actual current is higher than the set one, the OCP triggers as it should. But the main on/off button is still on, while the PSU is actuall off and will stay off because of OCP protection (probably the same for OVP, but did not test it).

Maybe add such development builds to the release page. Downloading something from Dropbox sounds kinda sketchy to me and I've run it in a VM. ^^"

I'm personally not fully happy with the UI. E.g. not sure the power panel is opened by default. I'd prefer a dynamic UI with the most important tools by default (display for V/I set and actual, ovp/ocp/output enable button and that's it (and maybe a timeline as you have). Other views can be opened if needed.

from smuview.

input of values for V and I via number pad work well with enter/return as confirmation

Nice!

I'd still vote for a confirmation of the V and I values. Not necessarily needed if the output is disabled. But if the output is enabled it is instantly changed, which may lead to user errors :/ Especially when someone inputs an number and wants do discard it or used the mouse pointer without caution.

You have to press enter or leave the input box to confirm. Imo way better than the instant change like in version 0.0.2, but I have to think about it.
Or are you talking about the knobs?

using the knobs with the mouse wheel work nice (didn't notice that before), but you can do the same with the input box for the numbers. I personally still don't like the round knobs which you can manipulate with your mouse pointer (probably will lead to user errors)

Using the mouse wheel with the input box doesn't have an instant effect on the value. You have to press enter or leave the input box.
But using the mouse wheel with the knob does change the set value instantly, which i think is very handy to fine tune the set values, like an physical knob on your power supply.

I'm thinking about to replace the knob with an other UI element, like a slider or something similar. That would save some space, you would have a linear mouse movement and the mouse wheel still works.

on/off, ovp and ocp buttons appear to work reliable

Great! I will make a pull request with this fix. It will probably take some time until the fix is in upstream.
Maybe you could add another log (-l 5) with multiple changes of the output state, so I can also check the fix. Just to be sure ;)

I cannot set values for ovp/ocp (boxes greyed out, I assume they are the same value for the main V and I value)

Yes, setting OVP/OCP/UVP thresholds is not supported for the Korad supplies.
Some power supplies support user thresholds, some don't. But i wanted to keep the UI similar for all power supplies, therefore the inputs are just deactivated. Maybe I'll hide some of the more obscure settings (f.e. UVP or even thresholds) if not supported by the device?

what are the OVP/OTP/OCP/UVC indicators and CC/CV dropdown menu near the main on/off button for? Seem kinda redundant to me (in this use case, probably easier to do it that way than dynamic)

The OVP/OTP/OCP/UVC LEDs are for the corresponding events (The Korad supplies don't have notifications for those events). With the OVP/OCP/UVP controls at the bottom you can control the behavior of those events (enable/disable and set thresholds).
The CC/CV dropdown will be removed for power supplies and replaced with two LEDs, like a real supply would have.

When I switch on OCP and then the main on/off button and the actual current is higher than the set one, the OCP triggers as it should. But the main on/off button is still on, while the PSU is actuall off and will stay off because of OCP protection (probably the same for OVP, but did not test it).

That's a feature I added to the sigrok driver in this AppImage, but couldn't test it. Could you please attach a log (-l 5) for an OCP event? It would be really nice if the Korad driver sends a notification for those state changes.

Maybe add such development builds to the release page. Downloading something from Dropbox sounds kinda sketchy to me and I've run it in a VM. ^^"

I didn't want to add an new release (create a new tag, etc.) and this AppImage contains an untested, inofficial modification of libsigrok. Not really suited for a release imo and too much of a hassle ;) And attaching here didn't work either (10MB limit). Therefore the dropbox link. I have no place to upload those temporary releases elsewhere.
If you want you can check the changes here: https://github.com/knarfS/libsigrok/commits/patches

I'm personally not fully happy with the UI. E.g. not sure the power panel is opened by default. I'd prefer a dynamic UI with the most important tools by default (display for V/I set and actual, ovp/ocp/output enable button and that's it (and maybe a timeline as you have). Other views can be opened if needed.

Me neither ;) Fortunately the UI consists mainly out of "views" and is therefore already very flexible. So changing the default views is no big deal. One idea is, that when you once set up your preferred views, you could save them in a session file and load the session (automatically or manually). But atm there no such thing as storing the session, though it's on my TODO list.

from smuview.

You have to press enter or leave the input box to confirm. Imo way better than the instant change like in version 0.0.2, but I have to think about it.
Or are you talking about the knobs?

Talking about the input box. Afaik you can also click somewhere else in the UI after entering the numbers (without enter/return). This behavior could represent a "wanted to change but decided against it" from the user. But just a minor thing, I'm also not a UI/UX expert :)

I'll probably post a log later, it's on my todo list, at the moment I'm short on time.

from smuview.

With your development build:

ocp_with_output_short.log
Enable OCP, then switched on output while the output of the PSU is shorted -> GUI still states output enabled but PSU is actually off.

ocp_then_short_gui_off.log
Enable OCP in GUI, then switch on output, then short output of psu via jumper -> psu switches off and GUI indicates output is off.

ovp_ocp1.log
Connected 12V LED to output of the PSU, set PSU to 12v and 0.2A
Switched on, current draw is ~0.1A. Enabled OCP and increased voltage until current reached 0.2A and OCP triggered, main on/off button in the GUI switched off as it should. Good

Set voltage to 10v and current to 0.1, (switched on?), reduced current to get into current limiting mode (with ~9v), then switched on OVP and increased current, now it does not go above 10V? Seems I can't trigger OVP, trying again in the next log file.

Sidenote:
When I have the PSU and then connect the GUI, the GUI does not query the PSU for OVP enabled? (might be the same for OCP, but I noticed it with OVP enabled)

ocp_ovp2.log
Still with LED on output.
Set to 5V, 0.1A, enabled OCP, then output enable, increased voltage until it triggers OCP, this works good.

Set to 12V, 0.05A (or 10v 0.004 A), enabled OVP, (enabled output?) increased current, but it just reaches the maximum voltage and goes into CV mode, I cannot increase the current and tridder OVP.

On the PSU without GUI:
When I used the PSU standalone I can trigger OVP as it should work
Set PSU to 10V and 0.004A, enable OVP and switch on output. Increase current until voltage reaches 10V, now OVP triggers and output is off.

from smuview.

New test release: https://www.dropbox.com/s/qmxbgh3b0b1803z/SmuView-0.0.3-git-5180dc1-x86_64.AppImage

Enable OCP, then switched on output while the output of the PSU is shorted -> GUI still states output enabled but PSU is actually off.

Should be fixed now.

When I have the PSU and then connect the GUI, the GUI does not query the PSU for OVP enabled? (might be the same for OCP, but I noticed it with OVP enabled)

Was the output switched off? I've read, that there is some strange behavior of the status byte when the output is switched off. To confirm this, please connect SmuView, switch the output off and then toggle the OCP and OVP over the GUI and attach the log.

Set voltage to 10v and current to 0.1, (switched on?), reduced current to get into current limiting mode (with ~9v), then switched on OVP and increased current, now it does not go above 10V? Seems I can't trigger OVP, trying again in the next log file.
[...]
Set to 12V, 0.05A (or 10v 0.004 A), enabled OVP, (enabled output?) increased current, but it just reaches the maximum voltage and goes into CV mode, I cannot increase the current and tridder OVP.
[...]
When I used the PSU standalone I can trigger OVP as it should work

Yes, I can see this behavior in the log files: OVP is enabled, but it doesn't trigger. Maybe a bug in the PSU itself? I'm afraid I can't do much about this one...

The rest looks good to me, or did I miss something else?

from smuview.

Ok, testing with 5180dc1

Enable OCP, then switched on output while the output of the PSU is shorted -> GUI still states output enabled but PSU is actually off.

Should be fixed now.

works as it should now, see
1_on_while_output_shorted.log

When I have the PSU and then connect the GUI, the GUI does not query the PSU for OVP enabled? > > (might be the same for OCP, but I noticed it with OVP enabled)

Was the output switched off? I've read, that there is some strange behavior of the status byte when the
output is switched off. To confirm this, please connect SmuView, switch the output off and then toggle the OCP and OVP over the GUI and attach the log.

OCP was enabled, output off, connected GUI -> OCP in GUI enabled after connecting
2_ocp_enabled_and_then_connected_via_gui.log

OVP was enabled, output off, connected to GUI -> OVP not enabled in GUI after connecting
2_ovp_enabled_and_then_connected_via_gui.log

output enabled with short on output, connected to GUI -> works as expected, GUI shows output enabled
2_connected_while_output_on.log

OCP and OVP on, output off, connected to GUI -> only OCP on in GUI, OVP is again off in GUI while on on the PSU
2_ocp_and_ovp_then_connected_via_gui.log

Trying to trigger OVP again:
Set PSU to 10V, 0.010A, connected an automotive LED which runs in CC mode with ~8-9V.
When I operate the PSU itself, switch on output and then increase the current, OVP will trigger at 10V. Doing the same in the GUI just leads it to switch to CV mode which sticks at 10V when I try to increase the current.
3_10v_0-010a_led.log

But not sure where this error might be located (meaning in your software or the PSUs USB interface)

from smuview.

Sorry for the late response. Could you please attach a log with:
Connect to SmuView, output off and then toggle OVP and OCP on and off several times.

from smuview.

sure, tested again with 5180dc1

Output, OCP, OVP off, then connected to GUI, toggled on-off a few times
1.log

Power on with OCP and current set very low (, <0.140A, nothing connected to output) is hardly possible, but this is actually a bug on the PSU itself and seems to be related to the output capacitors. When trying to enable output two times with little to now delay in between it actually turns on the second time (failing the first time).

Output, OCP and OVP on, then connected to GUI.
2.log

Again, tried turn on with low amperage setting which eventually worked (bug in the PSU, not GUI)

When the output is on and I try to disable OVP, it disables it on the PSU, but the GUI jumps back to OVP enabled. Then switched off OCP and both jumped to off in the GUI. Seems reproducible.

from smuview.

New test release:
https://www.dropbox.com/s/9gxsyax7vhox5s1/SmuView-0.0.3-git-b6183c9-x86_64.AppImage

OVP was enabled, output off, connected to GUI -> OVP not enabled in GUI after connecting

That is maybe working now...

Trying to trigger OVP again:
[...]
Doing the same in the GUI just leads it to switch to CV mode which sticks at 10V when I try to increase the current.

But not sure where this error might be located (meaning in your software or the PSUs USB interface)

As far as I can tell from the logs, it's a problem with the power supply firmware.

Output, OCP, OVP off, then connected to GUI, toggled on-off a few times
1.log

Here, everything looks good!

Output, OCP and OVP on, then connected to GUI.
2.log
[...]
When the output is on and I try to disable OVP, it disables it on the PSU, but the GUI jumps back to OVP enabled. Then switched off OCP and both jumped to off in the GUI. Seems reproducible.

This one is odd. Toggling OVP isn't working correctly and is somehow dependent on OCP. Looks also like a problem in the psu firmware.
Maybe a working OVP is dependent on the output/OCP/OVP state when connecting? Maybe the OVP trigger problem from above is related?
But that has to be investigated by someone with that power supply ;)

from smuview.

I like the sliders for the voltage! :D Scrolling can be a bit slow, but this should be the best solution I can think off (preventing user errors).

Maybe you can reduce the three gauges for V and I each (display on the top, input box with up/down arrow and slider on bottom) to just one or two (slider with grading and the actual value above, left and right of the value arrows for increment/decrement)? Maybe you can find an experienced UI/UX designer

OVP and OCP on, output off, then connected to GUI.
1_ovp_ocp_trouble.log

OVP and OCP are on in the GUI as they should, but when I try to disable OVP the LED on the PSU goes off, but the OVP button in the GUI jumps back to on. When I now disable OCP, both jump to off. So I can disable OVP but it shows incorrect in the GUI.

from smuview.

I like the sliders for the voltage! :D Scrolling can be a bit slow, but this should be the best solution I can think off (preventing user errors).

Thanks :) I will spend the "send values to the device"-part its own thread, so that should work a little bit smoother (sometimes in the future).

Maybe you can reduce the three gauges for V and I each (display on the top, input box with up/down arrow and slider on bottom) to just one or two (slider with grading and the actual value above, left and right of the value arrows for increment/decrement)?

Atm I'm thinking about removing the value display (or make it smaller). The input box is great for entering a desired value fast, the slider is great for adjusting the value manually.

Maybe you can find an experienced UI/UX designer

Yeah, I'm open to some help for the GUI. Not my strongest part :)

OVP and OCP on, output off, then connected to GUI.
1_ovp_ocp_trouble.log

OVP and OCP are on in the GUI as they should, but when I try to disable OVP the LED on the PSU goes off, but the OVP button in the GUI jumps back to on. When I now disable OCP, both jump to off. So I can disable OVP but it shows incorrect in the GUI.

Yes, I can see this clearly in the logfile (also in some of the previous logs).
Problem is: After sending an update of the OVP state (search for "korad-kaxxxxp: Sending 'OVP" in the logs) to the device, the status byte returned by the device (search for "korad-kaxxxxp: Status: CH1:") doesn't always show the changed OVP state. Sometimes everything works as expected (1.log from your previous post), sometimes the OVP state in the status byte is only updated when OCP changes.
Looks like some quirk in the psu firmware. Unfortunately there is not much I can do about this, without a deeper investigation with the device next to me...

But if everything else is working as it should (?), I'll make a pull request to the sigrok project with my changes.

from smuview.

Most of the issues should be fixed in libsigrok since 16.12.2019 and are now available in the SmuView 0.0.4 binaries.

from smuview.