Open-source firmware and software for the programmable power supply

[prasimix]

The error queue contains items that include a numerical and textual description of the error or event.
The <Error/event_number> is a unique integer in the range [-32768, 32767]. All positive numbers are instrument-dependent. All negative numbers are reserved by the SCPI standard with certain standard error/event codes. The value, zero, is also reserved to indicate that no error or event has occurred.
The second parameter of the full response is a quoted string containing an <Error/event_description>. Each <Error/event_number> has a unique and fixed <Error/event_description> associated with it. An example:

-113, "Undefined header"

The maximum string length of <Error/event_description> plus <Device-dependent_info> is 255 characters.

As errors and events are detected, they are placed in a queue. This queue is first in, first out. If the queue overflows, the last error/event in the queue is replaced with error:

-350,"Queue overflow"

Any time the queue overflows, the least recent errors/events remain in the queue, and the most recent error/event is discarded. Reading an error/event from the head of the queue removes that error/event from the queue, and opens a position at the tail of the queue for a new error/event, if one is subsequently detected.

If the error queue is not empty, bit 2 of the Instrument Summary Status Register is set. A query returns only the oldest error code and associated error description information from the error queue. To return all error codes and associated description information, use repetitive queries until an error value of zero is returned, or until bit 2 of the status register is 0.
The error queue is cleared when any of the following occur (IEEE 488.2, section 11.4.3.4):

• Upon power up
• Upon receipt of a *CLS command
• Upon reading the last error message from the queue

Currently the following SCPI commands are supported for working with error queue:

*CLS
*RST
SYSTem:ERRor[:NEXT]?
SYSTem:ERRor:COUNt?

SYSTem:ERRor[:NEXT]? queries and clears the error messages in the error queue, while *CLS clears complete queue. We can check that on the following way:

*cls
syst:err?
0,"No error"

Another example is a over-range error:

volt 66
syst:Err?
-222,"Data out of range"

If we tried to execute command while the PSU is in the stand-by mode that following error will occur:

syst:pow off
syst:pow?
0
outp on
syst:err?
-200,"Execution error"

... etc.
In general the firmware takes care of many things and all prohibited parameters or command sequences will generate an error that can be queried using the above mentioned commands.

[prasimix]

A complete support for multiple configuration profiles is now added. That is accompanied with another important feature: support for various types of channels. At the beginning it was possible to define only one or two channel with identical characteristic (i.e. voltage and current range that are hard-coded on the the post-regulator PCB). Now it is possible to mix e.g. 0-50V/0-3A and 0-40V/0-5A channels. Since such channel's features are now parametrized that will give more freedom to support many "3rd-party" PSU. Also the number of channels is no longer limited to two and firmware in that way is going beyond capability of our current Arduino Shield. So, a real scenario now is to have two "symmetrical" channels (e.g. 0-50V/0-3A) and one dedicated for low-voltage loads (e.g. 0-10V/0-5A) or three or four channels each with different capabilities.
Let's see what is possible to do with profiles. Two "common SCPI commands" are dedicated for saving and restoring device profile that could contain various working parameters: *SAV and *RCL
the *SAV command stores the current instrument state in the specified storage location. Any state previously stored in the same location is overwritten without generating any errors. The PSU has nine storage locations in non-volatile memory available to user to store current PSU states. The following channel and system parameters will be stored in the non-volatile memory:

• Calibration status (CALibration:STATe)
• Output enable state (OUTPut[:STATe])
• Remote sense state (OUTPut:SENSe)
• Output voltage ([SOURce[<n>]]:VOLTage)
• Output voltage step ([SOURce[<n>]]:VOLTage:STEP)
• OVP status ([SOURce[<n>]]:VOLTage:PROTection:STATe)
• OVP delay ([SOURce[<n>]]:VOLTage:PROTection:DELay)
• Output current ([SOURce[<n>]]:CURRent)
• Output current step ([SOURce[<n>]]:CURRent:STEP)
• OCP status ([SOURce[<n>]]:CURRent:PROTection:STATe)
• OCP delay ([SOURce[<n>]]:CURRent:PROTection:DELay)
• OPP level ([SOURce[<n>]]:VOLTage:PROTection[:LEVel])
• OPP status ([SOURce[<n>]]:POWer:PROTection:STATe)
• OPP delay ([SOURce[<n>]]:POWer:PROTection:DELay)
• OTP level ([SOURce[<n>]]:TEMPerature:PROTection[:HIGH][:LEVel])
• OTP status ([SOURce[<n>]]:TEMPerature:PROTection[:HIGH]:STATus)
• OTP delay ([SOURce[<n>]]:TEMPerature:PROTection[:HIGH]:DELay)
• Power on state (SYSTem:POWer)
• Simulator load (SIMUlator:LOAD)

For example if we'd like to store current profile parameters on location 2 the following command is required:

*SAV 2

The purpose of *RCL command is quite opposite: load profile parameters from the selected location and activate them. It is not possible to recall the PSU state from a storage location that is empty or was deleted. When firmware is activated for the first time, storage locations 1 through 9 are empty (location 0 has the power-on state).
The PSU uses location 0 to automatically hold the state of the PSU at power down.
If we want to restore profile from location 2 the following command has to be used:

*RCL 2

Support for the MEMory SCPI subsystem is also added. The MEMory subsystem works with PSU state files that are saved to (*SAV) and recalled from (*RCL) non-volatile storage locations numbered 0 through 9. The storage location 0 (named “Power down state”) is used to store the current PSU parameters.

MEMory:STATe:CATalog? query requests a list of defined names in the MEMory:STATe subsystem.

MEM:STAT:CAT?
"Power down state", "All outputs on", "dual 15V/300mA", "Power protection at 100W", "--Not used--", "--Not used--", "--Not used--", "--Not used--", "--Not used--", "--Not used--"

MEMory:STATe:DELete when used with a profile number deletes the contents of the specified storage location. The MEMory:STATe:DELete:ALL deletes the contents of storage locations 1 through 9. An example of deleting profile on the location 2:

MEM:STAT:DEL 2

MEMory:STATe:NAME associates a name with a *SAV/*RCL register number. May assign same name to different locations and state names are unaffected by *RST. Deleting a storage location's contents MEMory:STATe:DELete resets associated name to “---Not used---”:

MEM:STAT:DEF, 2, "All outputs on"
MEM:STAT:DEF? 2
"All outputs on"

MEMory:STATe:RECall:AUTO disables or enables the automatic recall of a specific stored PSU state selected using the MEMory:STATe:RECall:SELect command when power is turned on.  Select ON will automatically recall one of the ten stored states or the “power-down” state (location 0) when power is turned on. If OFF is selected that will issue a reset (*RST) when power is turned on.

MEMory:STATe:RECall:SELect can be used to select which PSU state will be used at power on if the automatic recall mode is enabled (see above mentioned MEMory:STATe:RECall:AUTO ON command). If the automatic recall mode is disabled (MEMory:STATe:RECall:AUTO OFF), then a reset is issued when power is turned on. If we want that profile on location 6 become active after power up that will require the following command:

MEM:STAT:REC:SEL 6

Finally we have MEMory:STATe:VALid that queries the specified storage location to determine if a valid state is currently stored in this location.  For example if we'd like to check if a valid profile exists on the location 6 the following command has to be used:

MEM:STAT:VAL?
1

[kia]

Hi every one I found an old Russian PSU schematic and built one for my self.The schematic is [url]build4electronics.com/psu-1-0/[/url.

[prasimix]

A small update about current progress. Finalization of the first version (M1) is going well, and the SCPI reference guide is more or less finished. It requires some minor tweaks. Anyone interesting could use it to check now the final list of functionality scheduled for this firmware release (Section 4-6) and additional command set is also announced in Section 11.
In parallel with testing firmware on real hardware on both AVR and ARM MCU, we also testing software simulator on both Windows and Linux. Simulator is successfully compiled on OS X and we'd probably test it with Raspberry PI with some Linux distribution running on it.
As already announced simulator could be used for test all implemented functionality and some SCPI commands examples are also added into the Reference guide (Section 10).

Web pages that mirrors information from the reference guide are also ready and will be available soon. Firmware M1 version source code should be available on the Github in the coming week or two, and a preliminary draft of the reference guide could be found here (I cannot attach it here because of its size of 3MB).

[timofonic]

Very nice! You are doing a lot of nice progress, congratulations!

[KuchateK]

Fantastic project, thank you for sharing.

Can you tell me how big is your source code and how much flash does it occupy on the microcontroller? I'm wondering if SCPI can be implemented on smaller microcontroller.

[prasimix]

Fantastic project, thank you for sharing.

Can you tell me how big is your source code and how much flash does it occupy on the microcontroller? I'm wondering if SCPI can be implemented on smaller microcontroller.

Unfortunately no. We started naively with ATmega32u4 that is used in Arduino Leonardo, and that was sufficient for what you can usually found in simple DIY power supply projects. We run out of memory when trying to add Ethernet library not to mention all machinery required for decent SCPI support. Here is the current situation:

Due: Sketch uses 106,080 bytes (20%) of program storage space. Maximum is 524,288 bytes.
Mega: Sketch uses 96,014 bytes (37%) of program storage space. Maximum is 253,952 bytes.
Global variables use 5,885 bytes (71%) of dynamic memory, leaving 2,307 bytes for local variables. Maximum is 8,192 bytes.

Please note that consumption of SRAM in Mega is not entirely optimized yet, so we expect further decrease after optimization.

[prasimix]

The complete SCPI manual pages are now available on line, and we postpone a little bit M1 release primarily because of curiosity to check how GUI part of the controller software will looks like. The SDL (Simple Directmedia layer) is chosen for development because it officially supports Windows, Mac OS X, Linux, iOS, and Android.
The idea was to add GUI to the current SCPI software simulator and that in one moment user could select between "simulator mode" or communication with the real hardware. In that way current simulator will be promoted to the remote controller application.
Simulator mode will provide user interface for SCPI programming but also working with simulated TFT display that exists on the real PSU. When connection to the real PSU is selected everything what is happened on the front panel will be remotely visible on the remote controller application.
The GUI can be invoked using the SIMUlator:GUI command when a new window with the PSU front panel image will be opened:



Currently only LED indicators and reset "button" (actually a hole that enable access to the microswitch on the real PSU) are functional. We added also another simulator specific feature: displaying connected load. The example shown below display connection of the 8R2 load that put channel 1 into CC mode of operation. For that we'll require to execute the following SCPI commands:

SIMU:LOAD 8.2
SIMU:LOAD:STAT ON

[prasimix]

Finally the first milestone (M1) is completed and its source code is published on the GitHub.
It is accompanied with the reference guide for supported supported SCPI command set that can be used in this stage for remote control of the bench power supply using serial (via USB) or Ethernet connection.

The firmware also includes software simulator that can be compiled and run at least on Windows, Linux and OS-X. We tested it on all of them (e.g. Linux version is tested on 64-bit Ubuntu and Ubuntu MATE for Raspberry Pi 2). Windows installation is available on the mentioned GitHub start page or at the bottom of this page.

How to use software simulator is described in the Section 9 of the SCPI reference guide, and some examples of usage are listed in Section 10.

I wish to send a huge THANK YOU in advance to all of you who will be so kind to invest few minutes and check how M1 source code is structured and test software simulator regardless of the fact that in this milestone the whole thing is still a little bit boring with just sending and receiving text commands. But it is a prelude for more interesting M2 when support for local console (TFT with touchscreen) will be introduced and when that same functionality could be also tested using the software simulation.

[Macbeth]

Amazing amount of work on this one! I admit I would be far less belt'n'braces in my approach, e.g. instead of adhering to all that archaic SCPI status register stuff I would have implemented the bare minimum and hard coded lots of responses and then got on with it. (Does anyone actually use stuff like those QUESTIONABLE status bits?)

But with this there is no excuse not to have a fully compliant SCPI implementation on any open source hardware design, well except for code space 

[prasimix]

Don't know how many of you are aware of what's going on with ESP8266. I'm quite pleased and impressed with its features and price. It was also nice to learned that it could be also visible/programmable via Arduino IDE that we are using for developing this firmware. More information about Arduino IDE support can be found here.

Just for a test, we tried to compiled firmware for that Wi-Fi SoC and with success . Of course, that still doesn't mean that it could be used as a direct replacement for Arduino boards, but some of you maybe will got an idea about what one of the possible future path/branch could be .

[prasimix]

I want to thanks to everyone who were already downloaded the M1 firmware and invite all other to try it and post here comments and suggestions.

Firmware in version M1 still do not allows that some of the PSU parameters can be set and read using the SCPI commands nor using the local console that is not supported at all in this version. That issue is addressed to some extent by using few configuration files with parameters that could be altered during the compilation time. This post describe the content of the following configuration files:

• conf.h
• conf_advanced.h
• conf_channel.h
• conf_user.h

We would not like to recommend changing any of the parameters defined in the first three of above mentioned files. Instead of that conf_user.h should be used to override existing values with a new one.
conf.h
Basic firmware parameters are defined in conf.h. That includes definition of SPI peripherals installed on Arduino shield board but also used channel’s types defined with their programmable voltage and current ranges. The over-temperature protection (OTP) default values for the MAIN sensor are also defined here.
The SERIAL_SPEED is the only parameter that is used for serial communication configuration. Default is 9600 baud and it can be changed to any of the following speed: 300, 1200, 2400, 4800, 19200, 38400, 57600, 74880, 115200, 230400 or 250000.

conf_advanced.h
This header file contains most of the parameters that are used for firmware configuration. That also includes the power supply’s identification used in *IDN? query (PSU_SERIAL, MANUFACTURER and FIRMWARE), DAC and ADC parameters, calibration parameters and over-temperature protection (OTP) values.
SCPI parser input buffer length (SCPI_PARSER_INPUT_BUFFER_LENGTH) is by default set to 48 and it can be increased to e.g. up to 255 but please note that will consume twice as much SRAM memory with each increment because two buffers was implemented: one for serial and one for Ethernet communication. That can generate problem during compilation on Arduino Mega in first place because it has only 8 Kb of SRAM.
The following three constants requires additional attention:

• CONF_WAIT_SERIAL – defines does serial communication is required to start firmware execution. It’s disabled by default. Keep in mind that if you enable it then nothing will happened when power is switched on without USB cable connected and a serial console (e.g. Arduino Serial Monitor) is up and running.
• CONF_DEBUG – determines if additional debug messages will be send to the serial console as an assistance in the development process since no real-time debugger is available in Arduino IDE. All debug messages started with ** and some examples are shown on picture below. This constant that is currently enabled by default could be disabled to decrease compiled sketch size.
• CONF_DEBUG_LATEST – represents additional condition for generating debug messages and it’s usually used as an assistance in debugging code that is recently added when additional reporting is required.

conf_channel.h
Channel specific information such as pin mapping used for each channel is defined in conf_channel.h. Additionally all possible variations of channel’s capabilities are listed here. Original file contain three voltage ranges (up to 30, 40 and 50 V) and two current ranges (up to 3.12 and 5 A) that has to match capabilities of the post-regulator board for proper operation. If one wants different voltage and current ranges e.g 0 – 25 V or 0 – 2 A it can be done here simply by adding new channel profile following the defined structure.
Together with mentioned voltage and current ranges that are represents with three values (MINimum, DEFault and MAXimum), channel profile contains information about voltage and current STEP change (see SOURce[<n>]]:VOLTage:STEP and [SOURce[<n>]]:CURRent:STEP), calibration LEVels (see CALibration:VOLTage:LEVel and CALibration:CURRent:LEVel), OVP and OCP parameters.
Finally over-power protection (OPP) profiles are also defined here as a mix of above mentioned voltage and current profiles.

conf_user.h
An example how to override channel’s profiles defined in conf.h is added into conf_user.h:

Code: [Select]

#pragma once
// Example: redefine channels
/*
#undef CHANNELS
#define CHANNELS \
    CHANNEL(1, CH_PINS_1, CH_PARAMS_50V_3A), \
    CHANNEL(2, CH_PINS_2, CH_PARAMS_30V_3A)
*/
Procedure is simple: parameter that we want to change first needs to be undefined (#undef) when a new definition follows using the #define operator.
Above mentioned change can be checked with *IDN? or APPL? query:

*IDN?
EEZ,PSU 1/50/03-1/30/03 (Simulator),123456789,M1

APPL? CH1
CH1:50.00 V/3.12 A, 0.00, 0.00

APPL? CH2
CH1:30.00 V/3.12 A, 0.00, 0.00

[prasimix]

We are working on adding support for local console that is in our case 3.2" TFT color display with touch screen. The touch screen functionality is provided using XPT2046 controller and UTouch library is used to communicate with it via Arduino IDE. And it works ... and after next power up is stops to work,... etc.  . We spent two days before we finally realized that initiation function UTouch::InitTouch(byte orientation) missing an important first time control byte setup! So if anyone else currently experience similar erratic behavior it has to add the following code at the end of above mentioned function:

Code: [Select]

    cbi(P_CS, B_CS);
    touch_WriteData(0x90); // command for reading X position, but only bit 0 and bit 1 are relevant and have to be set to zero (see table 8. in datasheet)!
    sbi(P_CS, B_CS);

The XPT2046 datasheet seems to have also some minor errors so I'm sending a version with my correction in the attachment.

[prasimix]

We spent (or wasted) considerable amount of time guessing what going wrong with touch screen control. Possibly we just discover hot water by finding that working with touch screen is not straight forward. Maybe the problem laying in unfortunate match of resistive sensor and touch controller (XPT2046). At the beginning a Utouch library is taken for granted as "the solution" for small displays and comes with Arduino support that we need.
But, after some time my colleague realized that utouch missed many things and that simply blaming hardware is not fair. Actually it's possible to completely change situation from frustrating and completely unusable to precise and predicable solution. He started with tweaking existing utouch, and finally gave up completely from it and in addition deploy tactics that David Beer presented here (thank you very much).
I prepared two short demos, first one with simple filtering and second one with new approach:

[prasimix]

Finally all required coding, testing and tweaking required for programming output parameters are finished and I made a short video about that. This first video covers all 3 input modes: Slider, Step and Keypad. The first two also have interactive/non-interactive option that gives us 5 possible input modes.
The 40 V/5 A prototype is used controlled with Arduino Due. As you can see many options are still missing but the biggest obstacle - having usable screen-touch control is resolved. As you can see I didn't use stylus during the whole presentation just my finger (that is maturely thick). Now we can continue more comfortably to add everything that is already available over remote console (using SCPI commands) to the local interface and I'll try to cover progress with more videos.
Your comments are highly welcomed.

[kolesar007]

Prasimix thats looks very nice, cant wait to try it by my self.

[void_error]

Sorry for the late reply...

Here's a few things I think would improve the usability of the interface:

• Slider mode would be nicer if you had maybe 3 colored rectangles at the top and/or bottom so the user knows the "track" where to slide the finger up or down, if there's room for text in those rectangles it could indicate the increment sensitivity, or alternatively you could come up with some suggestive icons
• Seeing the LCD update rate is quite fast the voltage/current reading could change color depending in the mode the PSU is in, CV/CC
• A "Save Preset" button can be quite handy to save different V/I settings
• Color scheme: black/dark grey background - color coded icons, in my opinion green on blue doesn't look that good. White text seems ok.

These are my thoughts so far, if I have more ideas I'll let you know.

[prasimix]

Sorry for the late reply...

Here's a few things I think would improve the usability of the interface:

• Slider mode would be nicer if you had maybe 3 colored rectangles at the top and/or bottom so the user knows the "track" where to slide the finger up or down, if there's room for text in those rectangles it could indicate the increment sensitivity, or alternatively you could come up with some suggestive icons
• Seeing the LCD update rate is quite fast the voltage/current reading could change color depending in the mode the PSU is in, CV/CC
• A "Save Preset" button can be quite handy to save different V/I settings
• Color scheme: black/dark grey background - color coded icons, in my opinion green on blue doesn't look that good. White text seems ok.

These are my thoughts so far, if I have more ideas I'll let you know.

Sorry for late response, I had a lots of stuff to do these days. Thanks for your input, and can say that 2) and 4) could be easily adjusted in line with one's taste thru EEZ Studio. I postpone first "sneak preview" of EEZ Studio until some additional functionally become available. The 3) is available but currently accessible only using SCPI commands (MEMory subsystem). Of course that we'll make it accessible also using local display.
I have some difficulty understanding 1). Could you please elaborate it a little bit more?

[prasimix]

An important feature is added in M2 firmware that allows us to support various types of power boards and control boards (Arduino shields). That was required since we have now two designs that we are planning to support in the future. This functionality will enables us and 3rd party to add support for new revisions.

The power board variant is defined in conf.h. A mix and match of various variants is allowed. For example default configuration defines two rev.4 boards:

Code: [Select]

/// Channels configuration.
///
#define CHANNELS \
    CHANNEL(1, CH_BOARD_REVISION_R4B43A_PARAMS, CH_PINS_1, CH_PARAMS_40V_5A), \
    CHANNEL(2, CH_BOARD_REVISION_R4B43A_PARAMS, CH_PINS_2, CH_PARAMS_40V_5A) \
If I'd like to mix rev.4 board with 0-50 V/3 A (Ch#1) capability with newest one with 0-40 V / 5 A (Ch#2) capability I need to use the following declarations:

Code: [Select]

#define CHANNELS \
    CHANNEL(1, CH_BOARD_REVISION_R4B43A_PARAMS, CH_PINS_1, CH_PARAMS_50V_3A), \
    CHANNEL(2, CH_BOARD_REVISION_R5B6B_PARAMS, CH_PINS_2, CH_PARAMS_40V_5A) \
The Arduino shield is defined in conf_user_revision.h:

Code: [Select]

/// Selected EEZ PSU revision, possible values are:
/// EEZ_PSU_REVISION_R1B9 or EEZ_PSU_REVISION_R2B6
#define EEZ_PSU_SELECTED_REVISION EEZ_PSU_REVISION_R2B6
Additionally a new set of SCPI commands are added that helps identifying what is declared in firmware.

SYSTem:CHANnel

SYSTem:CHANnel[:COUNt]? returns the number of output channels.
SYSTem:CHANnel:MODel? returns the channel model identification, for example:

SYST:CHAN:MOD?
"Power_r5B6b"

For output voltage, current and power capability you can use SYSTem:CHANnel:INFOrmation:VOLTage?, SYSTem:CHANnel:INFOrmation:CURRent? and SYSTem:CHANnel:INFOrmation:POWer? (please note that max. power is not necessary simply multiplication of max. voltage and current).

Interesting info could be queried with SYSTem:CHANnel:INFOrmation:PROGram? that returns a list of all programmable features of the channel. For example for R5B6B it will returns:

SYST:CHAN:INFO:PROG?
"Volt, Current, Power, OE, DProg, LRipple, Rprog"

where DProg denotes Downprogrammer, LRipple a "low ripple" mode of operation when SMPS pre-regulator is pushed in 100% duty-cycle mode and Rprog allows remote (external) voltage programming.

SYSTem:CPU

SYSTem:CPU:INFOrmation:TYPE? Returns the type of CPU and SYSTem:CPU:MODel? returns the control board model identification:

SYST:CPU:MOD?
"Arduino, R2B6"
SYST:CPU:INFO:TYPE?
"Due"

SYSTem:CPU:INFOrmation:ETHernet:TYPE? returns the type of Ethernet controller:

SYST:CPU:INFO:ETH:TYPE?
"W5500"

SYSTem:CPU:OPTion? returns information about installed options on the Arduino shield. Currently on the R2B6 we have the following situation:

SYST:CPU:OPT?
"BPost, EEPROM, RTC, Display"

[void_error]

I have some difficulty understanding 1). Could you please elaborate it a little bit more?

Let me draw it:

So, here's the display, with the 3 slide columns for different adjustment increments:
________
| 1 | 2 | 3 |
|    |    |    |
|    |    |    |
|    |    |    |
|    |    |    |
=======

As you explained in the video, if you slide up/down on column 1, 2 or 3 it increments/decrements the value of V or I in different steps, 1 having the largest steps while 3 having the smallest.

What I wanted to say is either to have each column colored differently (or same color but different shade). That way it's more clear for the user where to slide the finger.

[prasimix]

Thanks for this. Maybe my presentation in misguided you to think that there is a three discrete "slider" zone. This is not correct, it's "continuous": depends of how left or right finger is positioned a different sensitivity (step value) will be set. Maybe we can display what is current step value in this view. Currently if you'd like to work with predefined step values you can use the second menu.

[prasimix]

The [SOURce[<n>]]:LRIPple command can be used to enable (ON, 1) or disable (OFF, 0) this mode of operation. Command also has query form that allows us to find out the current status of the selected channel. For example, if mode is off:

LRIP?
0

or if we want to specify the first channel:

SOUR1:LRIP?
0

Another command is [SOURce[<n>]]:LRIPple:AUTO that maximize this functionality by pushing channel to stay in low ripple mode as much as possible. That means that once AUTOmatic selection is enabled channel will switch back and forth from low to "high" ripple mode of operation depending of programmed output parameters and connected load. When AUTOmatic mode is activated you can use [SOURce[<n>]]:LRIPple? to obtain current status:

LRIP:AUTO ON
LRIP?
1

Entering low ripple mode of operation require monitoring of the max. output power. The maximum output power is limited by the first of the following conditions that is met:

• The pre-regulator regulation element (switching mosfet) capability is limited with max. allowed continuous current (SOA_PREG_CURR value) for the applied input voltage (SOA_VIN value). The set output current cannot exceeds this value in any moment.
• The post-regulator regulation element (pass mosfet) could dissipate finite power (SOA_POSTREG_PTOT value) while load is connected. Therefore output power cannot exceed product of voltage difference (SOA_VIN and output voltage) and output current.

For example, when output voltage is set to 12 V and SOA_VIN = 50 V, SOA_PREG_CURR = 0.8 A and SOA_POSTREG_PTOT = 20 W, the max. output current in low ripple mode cannot exceed 0.526 A because SOA_VIN-VOLT = 50-12 = 38 V and Imax=SOA_POSTREG_PTOT/38 = 20/38 = 0.526 A.
If output voltage is set to 36 V with the same SOA values as in example above the max. output current cannot exceed 0.8 A (limited by SOA_PREG_CURR) regardless of the fact that max. power dissipation of 20 W allows output current of up to 1.428 A or 20/(50-36).

Please let me know if we missed or miscalculated here something.

Any attempt to set low ripple mode (LRIP ON) will generate an error. The AUTOmatic mode should be used to avoid error conditions. Also if AUTOmatic mode disables low ripple, an attempt to enable it, will also generate an execution error (-200).

Of course, this functionality as all other can be tested using firmware simulator with the latest firmware build. Quick video about how to use simulator is here:





 

[prasimix]

Remote programming of output voltage is also now implemented in the firmware as new SCPI command: [SOURce[<n>]]:VOLTage:PROGram[:SOURce] that accept INTernal or EXTernal parameter if output voltage has to be programmed "localy" (by MCU) or "remotely" applying analog signal (2.5 V for full scale). The same command has query form that returns 0 (internal/local) or 1 (external/remote). For example:

VOLT:PROG EXT
VOLT:PROG?
1

An additional indication that channel entered remote programming mode is red LED above "push-in" connector on the front panel (Arduino shield PCB).
When output voltage programming source is set to EXTernal OVP is also enabled. Before we implemented selection of output voltage programming source, enabling OVP means that OVP will trip automatically if PSU enters CV mode. There was no possibility to set "trip" threshold. While remote programming is selected MCU cannot set the output voltage so we added a new [SOURce[<n>]]:VOLTage:PROTection[:LEVel] command that define when OVP will trip. By default it's set to max. value (e.g. 40 V in case of 0-40 V model), but you can decrease it to desired value. The following command sequence check OVP status, OVP delay, OVP level and change level to 12 V:

VOLT:PROT:STAT?
1

VOLT:PROT:DEL?
0.1

VOLT:PROT?
40

VOLT:PROT 12

When OVP tripped channel will be automatically change output voltage programming mode back to INTernal (as a precaution). That we can check if the following sequence:

VOLT:PROT:TRIP?
1

VOLT:PROG?
0

While channel is in remote programming mode, the actual voltage could be acquired as in local mode. For example if 1.25 V is applied on remote programming input the MEASure[:SCALar][:VOLTage][:DC]? will returns 20 V for 0-40 V model (half scale):

MEAS?
20.00