EEVblog Electronics Community Forum

Electronics => Projects, Designs, and Technical Stuff => Topic started by: prasimix on November 01, 2015, 04:09:15 pm

Title: Open-source firmware and software for the programmable power supply
Post by: prasimix on November 01, 2015, 04:09:15 pm
List of important changes

Update 2015-12-30: The firmware Milestone One (https://www.eevblog.com/forum/projects/open-source-firmware-and-software-for-the-programmable-power-supply/msg832065/#msg832065) is available on the GitHub.
__________________________________________________

Introduction

I'm opening a new thread about open source firmware for the programmable bench power supply that is presented here (https://www.eevblog.com/forum/projects/diy-programmable-dual-channel-bench-psu-0-50v3a/). The idea is to make it flexible enough that it can be used with many other power supplies that can be controlled by dedicated ADC/DAC or even with MCU's built-in capability (ADC/PWM or ADC/DAC combination). In this thread will be also discussed various software solutions that will be developed as a part of this project or it's already available for programming and monitoring power supplies and similar equipment. We are open for all your suggestions and comments to make it attractive and cover various usage scenarios. I hope that discussion here will stay primarily focused on the software aspects of the power supply programming and monitoring.

Why such software solution could be attractive for anyone? Here is some ideas: this firmware will support from the beginning SCPI (more about it later) that you can found only on middle and high class commercial devices. On the other side in DIY and open hw/sw arena there is many solutions that covers only basic functionality (sort of "hello world" for power supply) mostly limited to the built-in 2 lines LCD display that many people could found insufficient shortly after frequent usage. I hate idea to require i.e. separate battery charger next to the programmable power supply on the bench (looks to me like huge calculator populating my desk next to PC monitor). This software comes somewhere in between; enabling user interface that comes mostly with the premium price and in the same time is executable on the platform that is popular in the DIY world. I hope that in posts that shortly follows you'll see that such thing is possible and could be or real value.

Above mentioned programmable bench power supply has an MCU board (https://www.eevblog.com/forum/projects/diy-programmable-dual-channel-bench-psu-0-50v3a/msg782249/#msg782249) designed as an Arduino Shield (https://www.arduino.cc/en/Main/ArduinoShields) and it will be used as an reference platform for development. Let's start with the short list of hardware related features:
Firmware feature overview:
The firmware will be developed in few consecutive steps/milestones. Each milestone will represent a functional solution that accomplish certain list of features. The source code of a milestone will be published when internal testing on reference platform is finished. From the beginning other people could also test milestone thanks to Windows and Linux simulator that will be also published together with the source code. In some of the future milestones we are planning to add support for "plain" Arduino board functionality (ADC/PWM on Mega, and ADC/DAC on Due). Thanks to that someone could "automate" existing power supply with minimal set of additional components (no Arduino shield mentioned above is required). Of course that include also solutions such as uSupply (http://www.eevblog.com/projects/usupply/) architecture but with little bit better MCU.
Usage has to be straight forward: download, unzip, compile and upload using Arduino IDE (https://www.arduino.cc/en/Main/Software) (1.6.5 or higher) and it's ready to run.

Development of the firmware is started around SCPI specification. That helps us to familiarize with various functionality that big guys (Agilent/Keysight, NI, etc.) incorporates into their power supplies firmware. As I already mentioned most of (if not all) upper class power supplies comes with SCPI support usually using IEEE 488 as a primary interface (the "only" drawback is that is not open-source and you cannot do anything outside strictly defined boundaries).
According to SCPI power supply represent distinctive class of device (instrument) that has many applications in laboratories for basic research, automated testing, etc. Consulting only the latest SCPI specification wasn't enough. We found very quickly that various manufacturers interpret it in many different ways even when questionable feature is nicely defined by the SCPI specification. Such deviance is more understandable when certain function is not already covered by the specification (the SCPI Consortium, today IVI Foundation (http://www.ivifoundation.org/scpi/), publish only final version, not drafts). In our design we tried to stay as much as possible within the specification and use intuitive naming for all extra features not covered with the latest SCPI version (1999.0).

The first milestone (M1) will contain only functionality to work with power supply using SCPI commands over serial (via UCB) or Ethernet communication port. Some of the most important commands will be presented in the following post, and complete command set will be announced in one of posts that follows. I can also announce right away what is scheduled for the M2 (milestone two): adding support for the local console using color TFT display with touch-screen. That means that most or eventually all features that is available in M1 will become functional directly on the power supply (no remote PC with controller software is required).
Title: Basic SCPI programming
Post by: prasimix on November 01, 2015, 05:56:29 pm
Before starting to talk about SCPI commands that is already implemented and will be included into the firmware M1 maybe it's good to say something in general about SCPI.
SCPI is used for remote control of various electronic devices what are called Instruments. The remote "console" software is called Controller and it is used to send SCPI commands or queries. In general commands are used for setting certain parameters (i.e. set voltage or current), enable some function (i.e. output enable) or start execution (i.e. start arbitrary waveform generation). To get information from the instrument (power supply) a query form of the command is usually used that represents command with question mark (?). For example to set output voltage to 20V you can use: VOLTage 20 and to get what is currently set (but is not necessary present on the output since channel is in CC mode or output is disabled) you can use: VOLTage?
20.00I wrote VOLTage as a mix of upper and  lower case to indicate another specific feature of the SCPI: all commands are case insensitive and commands have short (three or four character) and long form. It's a common practice to make distinction between short and long variant by using upper case for the short variant. Therefore all of the following is allowed:
VoLtaGe
voltage
VOLT
volt

... but you cannot use other then short or long word such as:

VOL
volta
VOLTAG

Before starting to talk about SCPI commands that is already implemented and will be included into the firmware M1 maybe it's good to say something in general about SCPI. SCPI is used for remote control of various electronic devices what are called instruments. The remote "console" software is called controlled and it is used to send SCPI commands or queries. In general commands are used for setting certain parameters (i.e. set voltage or current), enable some function (i.e. output enable) or start execution (i.e. start arbitrary waveform generation). To get information from the instrument (power supply) a query form of the command is usually used that represents command with question mark (?). For example to set output voltage to 20V you can use: VOLTage 20 and to get what is currently set (but is not necessary present on the output since channel is in CC mode or output is disabled) you can use: VOLTage?
20.00I wrote VOLTage as a mix of upper and  lower case to indicate another specific feature of the SCPI: all commands are case insensitive and commands have short (three or four character) and long form. It's a common practice to make distinction between short and long variant by using upper case for the short variant. Therefore all of the following is allowed:

VoLtaGe
voltage
VOLT
volt

... but you cannot use other then short or long word such as:

VOL
volta
VOLTAG

The primary communication channel for SCPI was IEEE 488 bus (GPIB) and due to that there is a mandatory set of IEEE 488.2 commands that has to be supported by any SCPI compliant instrument. Such command regularly started with asterisk (*) and also could have query form (by using question mark). Some example are:

*CLR
*IDN?
*RST
*TST?

IEEE 488 bus could be partially emulated via serial port or almost completely over Ethernet with two sockets opened to emulate SRQ (ServiceReQuest)) that will be discussed in some of the future posts. The SCPI represent a group of commands divided in various so-called subsystem. Not all SCPI commands are applicable to any particular SCPI-enabled instrument. The Volume 4 of the SCPI specification 1999.0 specifically address mandatory command  set for each class of instrument (power supply is one of them). Each SCPI subsystem is hierarchical and that should helps user to remember valid commands for particular action. Each command (word) in the system represent node and each node starts with :, while for root node ":" is optional. Some nodes (commands) could be also optional and it is written in square brackets. Here is an example od the TEMPerature subsystem that will be supported in M1:

TEMPerature
                  :PROTection
                                   [:HIGH]
                                              :CLEar, {MAIN|S1|S2|BAT1|BAT2}
                                              [:LEVel] <temperature>, {MAIN|S1|S2|BAT1|BAT2}
                                              :STATe <bool>, {MAIN|S1|S2|BAT1|BAT2}
                                              :DELay
                                                        [:TIME] <delay>, {MAIN|S1|S2|BAT1|BAT2}
                                              :TRIPped? {MAIN|S1|S2|BAT1|BAT2}

Notice also that mandatory arguments are closed in curly brackets ({}). Here nodes HIGH and LEVel are optional therefore you can set protection against higher temperature the 50oC by sending any of the following commands:

TEMPerature:PROTection:HIGH:LEVel 50
TEMP:PROT 50
temp:prot 50
temperature:protection 50

If command execution failed an error will be generated and the easier way to check that is by using command SYSTem:ERRor? (or simply syst:err?). The instrument will return an up to three digit integer and optionally textual description. For example if I wants to set out of range voltage I'll get the following error:

volt 60
syst:err?
-222,"Data out of range"

Complete error mechanism and list of error messages is an important topic that will be addressed separately. The support for SCPI is built around open-source parser (https://j123b567.github.io/scpi-parser/). My colleague took active part to make it more suitable for AVR platform (Mega) and fork it here (https://github.com/mvladic/scpi-parser) because without such intervention we will shortly run out of SRAM (8Kb). But that's the beauty of the open-source :).

You can concatenate more then one command in the single command line by using ";". For example in you'd like to set voltage and current to the new desired values in the single line use:

volt 30;curr 1.25

We already can access power supply using serial or Ethernet communication. Here is a session over serial (gtkTerm):

(https://i.imgur.com/baIvimI.png)

When during development some debug information are necessary than serial port can also be used for displaying it. This is an example of power on initialization with debug enabled:

(https://i.imgur.com/3xoZgrZ.png)

When Ethernet port is enabled you can for example test communication with the power supply using ping:

(https://i.imgur.com/0z5LTLP.png)

... or start session using telnet:

(https://i.imgur.com/hH2DVdR.png)
Title: Programming channel output
Post by: prasimix on November 02, 2015, 10:37:37 am
I'll present shortly how to "make alive" power supply channels using SCPI commands. In many SCPI examples we can find that first is issued a query command *IDN? that returns instrument identification string, so let's start with it:

*idn?
EEZ,PSU 25003D (Mega),00001,0.44

Returning string contains four comma separated values as follow:Select channel (instrument)
The INSTrument subsystem provides a mechanism to identify and select logical instruments by either name or number. In this way a particular logical instrument could be selected and it would respond to commands, such as MEASure, in the same manner as a dedicated instrument having the same functionality as the logical instrument.
Reference design has two isolated channel that represents two logical instruments. They can be addressed using numeric values 1 or 2 or discrete values CH1 or CH2 (remember everything is case-insensitive). In many situation if channel (instrument) is not declared then the currently selected channel will be manipulated. The CH1 is selected when the power supply is turned on.
To select desired channel we can use INSTRument[:SELect] with discrete value or INSTrument:NSELect with numeric value. Note that SELect is not mandatory (written in square brackets. If I'd like to set channel 2 as default I can use the following commands:

INST CH2
INST:SEL ch2
inst:nsel 2

INSTrument has also query form and I can use it to determine what is the currently selected channel:

INSTRUMENT?
CH2
inst?
CH2
inst:sel?
CH2
inst:nsel?
2

Set voltage and current
According to SCPI a power supply is a basic sourcing instrument. It typically supplies a constant voltage or current at significant power levels to energize an electrical circuit. Because a power supply is primarily a source, the SOURce root node is optional. That means the important parameters such as max. output voltage and current that belongs to SOURce subsystem can be specify without root node SOURce. Setting voltage and current is pretty straight forward: you have to use VOLTage or CURRent. For example if I want to set on the currently selected channel max. voltage of 20V and max. current of 500ma I can use any of the following commands:

volt 20
curr 0.5
curr 500ma
volt 20;curr 0.5

Actually that two commands has a much longer form and that is: [SOURce[<n>]:]CURRent[:LEVel][:IMMediate][:AMPLitude] <current> and [SOURce[<n>]:]VOLTage[:LEVel][:IMMediate][:AMPLitude] <voltage>
As you can see most of that is not mandatory and not practical if you are using i.e. telnet session to manually set desired values. But, there is one exception here that can save some typing. The root node SOURce has optional argument <n> that is channel/instrument number. Using it you can directly set voltage or current without previous channel selection. For example if currently selected is CH2 I can set CH1 without using INST or INST:NSEL command:

inst?
CH2
sour1:volt 3.30
sour1:curr 100ma

Both VOLTage and CURRent commands has query form that allows us to check what is a programmed value. That value is not necessary present on the output terminals and for that an another command is used! To check what is set on previously programmed CH1 the following commands has to be used:

sour1:volt?
3.30
sour1:curr?
0.10

It's also possible to concatenate few query commands like this:

inst?
CH2
volt?;curr?
20.00;0.02

The resolution of the power supply is fixed to 10mV and 10mA (regardless of the fact that it can be more precise), therefore all values will be rounded to two decimal places. Prefixes such as mV and mA are allowed but all returned values will be presented in main units (V and A).

For channel programming most of the manufacturer use non-standard (yet) command APPLy. Therefore we also decided to add it into our SCPI command set. This command is a combination of INSTrument:SELect (or INSTrument:NSELect), VOLTage and CURRent commands. Syntax is APPLy {CH1|CH2} <voltage>, <current>. For example to set channel 1 to 20V and 300ma we'll use the following command:

appl ch1, 20, 0.3

This command also has the query form:

appl? ch1
CH1:40.00 V/5.00 A, 20.00, 0.30

In addition to programmed voltage and current, some additional channel information is available. In this example we can see channel 1 capability (up to 40V and up to 5A).
Few other distinctive value can be used in case of APPLy and many other commands that is used for programming of output voltage, current and power: MINimum, MAXimum, or DEFault. Mentioned parameters are model specific, i.e. MAXimum for 0-30V is 30V or 3.12A for 0-3.12A model. Here is few examples:

appl ch1, 24, max
curr?
3.12
volt max
volt?
50.00
curr def
curr?
0.00

Output enable
When voltage and current are set only what is still missing is to activate channel's output because when the power supply is turned on both channel are set to 0V, 0A and output is disabled. The OUTPut is another important subsystem that is used to work with an instrument output. To change or query the channel's output state use OUTPut[:STATe] {ON|OFF|0|1} [CH1|CH2|ALL] command. This command has additional discrete value ALL to affect all logical instrument of the power supply. For example if we wants to activate both outputs any of the following command is valid:

outp on, all
outp 1, all
outp 1, ch1;outp 1, ch2
outp on, ch1; outp on, ch2

To query output state of current channel, channel 2 or all channels use the following examples:

inst?
CH1
outp?
1
outp? ch2
1
outp? all
1;1

Summary
As a short summary to program and activate channels we can use the following sequences:

inst ch1;volt 20;curr 500ma;outp on
inst ch2;volt 12.4;curr 2.5;outp on

...or:

appl ch1, 20, 0.5;outp 1, ch1
appl ch2, 12.4, 2.5;outp 1, ch2
Title: Measuring output parameters on uncalibrated channel
Post by: prasimix on November 02, 2015, 02:24:10 pm
After programming and activate channel's output we can now proceed with measuring of actual values present on the output terminals. Each power supply channel has separate 4-channel ADC that is connected to voltage monitor op-amp output (U_MON) and current monitor op-amp output (I_MON). The remaining two channels are connected to DAC outputs that set output voltage (U_SET) and current (I_SET). They are currently not used. Sampling rate is 600sps (samples per second) that give us interrupt resolution in best case of 1.667ms. Such relatively high sampling rate is required because we'd like to have acceptable resolution for over-voltage (OVP) and over-current (OCP) protection since current power supply design does not include dedicated circuits for mentioned functionality. I come to that again in a separate post about commands for protection.
Currently we are pretty fast on both Arduino's (Mega and Due). Of course Due is slightly faster in processing all codes between two interrupts. On Mega we have cycle of ~2.6ms for both channel (in average 1.3ms that is 770 interrupts per second):

(https://i.imgur.com/l18wzYr.png)

With Arduino Due we have cycle of 2.08ms for both channel (in average 1.04ms that is 962 interrupts per second):

(https://i.imgur.com/Bsw5e2Q.png)

SCPI command has two subsystems for acquiring data: FETCh and MEASure. The SCPI specification said:
Quote
FETCh? performs the postprocessing function and returns the data. This allows the user to perform several different FETCh? functions on a single set of acquired data. For example, an oscilloscope can acquire measurement data that can yield many different signal characteristics such as frequency or AC and DC voltages. Thus, a transient signal may be captured once using a MEASure?, READ? or INITiate. A FETCh? may then be used to obtain each of the different signal characteristics without reacquiring a new measurement. MEASure? provides the best compatibility between instruments because no knowledge of the instrument is required to perform the operation.
We added support for MEASure only that is common practice for our class of instrument. The MEASure:VOLTage? is used for acquire output voltage and  MEASure:CURRent? for output current. In fact that are simpler form of the following: MEASure[:SCALar]:VOLTage[:DC]? [CH1|CH2] and MEASure[:SCALar]:CURRent[:DC]? [CH1|CH2]. Here is an example if we want to measure current on the channel 1:

MEAS:CURR?
0.12

For measuring voltage we have:

MEAS:VOLT?
5.00

... but in the case of voltage measurement it can be even shorter since VOLTage is so-called fundamental measurement layer and MEASure? without additional info will returns output voltage on the currently selected channel:

meas?
5.00

We can do the same thing on specified channel like:

meas? ch2
12.00

We also added MEASure[:SCALar]:POWer[:DC]? [CH1|CH2] that returns U*I value that can be used in the following way:

meas:pow?
34.22

Finally we can get all three values using single line sequence (that is equal to meas:volt?;:meas:curr?;:meas:pow?):

meas:volt?;curr?;pow?
4.76;0.56;2.68

We'll also working on MEASure[:SCALar][:TEMPerature][:THERmistor][:DC] that is also scheduled for M1 (Milestone  1). Now, let see how measured value correspond to programmed value. I'll set 12.00V and read it back:

volt 12
volt?
12.00
meas?
12.02

The reason why we have the difference of +20mV is that the channel is not calibrated! Quite another reason for difference between programmed and actual value is changing of channel mode of operation that could be CV (constant voltage), CC (constant current) or UR (unregulated). For example if we set output to 20V and limit current to 200mA with 16R4 load channel will enters the CC mode and voltage will drop to 3.28V. To achieve channel mode of operation a special event registers has to be consulted that is not plain simple and I'll present our register's scheme in another post. Some manufacturers decided to offer a more intuitive way of obtain such important information (i.e. Rigol) and we decide to follow that practice by adding user-specific query command OUTPut:MODE?. This returns one of three possible values: "CC", "CV" or "UR". Here is an example with above mentioned programmed 20V, 200mA and 16R4 load:

appl ch1, 20, 200ma; outp 1
volt?; curr?
20.00; 0.20
meas?
3.30
meas:curr?
.21
outp:mode?
"CC"
Title: Re: Open-source firmware and software for the programmable power supply
Post by: bingo600 on November 02, 2015, 07:37:13 pm
 :-+ :-+

This is actually rather cool.

I'll be checkking out the "mini" scpi parser for sure.

Thank you for publishing it.

/Bingo
Title: Voltage and current calibration
Post by: prasimix on November 02, 2015, 10:48:59 pm
In the previous post we can see that programmed and measured value is not necessarily the same or at least within target resolution what is in our case 10mV/10mA. There is many possible sources of such inaccuracy: used voltage reference, gain precision of voltage and current control loops and various errors in ADC and DAC circuits. Initial inaccuracy from one channel to another could be significant (i.e. more then 50mV) and it can be with positive or negative offset. Due to than it's a common practice to provide calibrating mechanism when external meters is used to provide more precise measurement than used ADC/DAC resolution can offer. All higher class commercial power supply provides calibration mechanism at least using the local console. Some of them comes with remote calibration using once again SCPI commands.
We also decided to add calibration over SCPI commands that helps us to understand a whole procedure. In that way we also got a required foundation for simple generation of local "calibration wizard" that will guide user through all steps necessary for the successful calibration.
The SCPI CALibrate subsystem is assigned for such functionality. We found a lots of inconsistence in using it even with the same manufacturer that possibly indicates that various teams has different ideas how to use it or that they make corrections over the time and implemented in new generations of instruments. Maybe the toughest decision was how to use CALibrate:STATe. Someone use it to switch channel into calibration mode, other use it to activate calibration, that means that calibration data will be taken into account for programming and querying measured data.
The process of calibration is conceived as multi-step procedure when at least two testing points is measured each on the other side of the full scale. Actually it's better to choose a small offset because of possible negative deviation. We are also using the third point in the middle between that two for verification purposes. For example for 0-50V model that is 200mV, 24.1V and 48V or for 0-3.125A model 50mA, 1.475A and 3A.

Calibration mode
Calibration procedure is possible only when the selected channel is in the calibration mode. It is not possible to enters calibration mode while channel output is in the OFF state. If we wants to start calibration on the CH2 it is necessary to execute the following commands:

inst ch2
inst?
CH2
outp on
outp?
1

Changing channel mode to and from calibration mode require calibration password which is in our case different from password used for i.e. locking local console or to switch between local and remote mode of operation. Default calibration password is set to "eezpsu" and we can change channel between "regular" and calibration mode using the CALibrate[:MODE] {ON|OFF}, "<password>". Any of the following commands in that case are valid:

cal:mode on, "eezpsu"
cal on, "eezpsu"
cal 1, "eezpsu"

When the selected channel enters calibration mode we can test that using the same command as an query and without password:

cal?
1

Voltage calibration
Now we have to decide what circuit we want to calibrate: voltage or current. Let's continue with voltage. Two additional command is required for that. One that set test point and another that allows user to enter measured value by mean of external precise voltmeter. To set test point we are using CALibrate:VOLTage:LEVel {MINimum|MIDdle|MAXimum}. The sequence is important and it's not allowed to jump from MIN to MAX, or start calibration with i.e. MID or MAX. In the same time it is allowed to go backward. For example if you are already on MIDdle point and you want to repeat measuring of MINimum point you can do that without restrictions.
Another command required to accomplish each step is CALibrate:VOLTage[:DATA] <value>. Before proceed with executing calibration commands check that no load is connected to the channel's output terminals. When first voltage calibration test point is entered the output current will be set to the 50mA. The following sequence is one example of voltage calibration with testing points sets to 200mV, 19.1V and 38V (for 0-40V model):

cal:volt:lev min
cal:volt 238mv   
cal:volt:lev mid
cal:volt 19.122
cal:volt:lev max
cal:volt 37.9

Please note that 238mV, 19.122V and 37.9V value was aquired using external voltmeter. We added DIAGnostic command that can me used to check calibration data when channel is in the calibration mode but also when it is in "regular" mode. The  DIAGnostic[:INFOrmation]:CALibration? will returns the following data for the above mentioned example:

diag:cal?
u_min=0.24 V
u_mid=19.12 V
u_max=37.90 V
u_level=max
u_level_value=38.00 V
u_adc=38.04 V
i_level=none

Current calibration
Now we can proceed with current circuit calibration or simply finalize calibration session with saving only calibration data for the voltage. Let's say that we want to continue with current. The command for setting test points is similar as for voltage: CALibrate:CURRent:LEVel {MINimum|MIDdle|MAXimum}. For successful calibration of current we'll require some load that can survive maximum rated current (i.e. 5A for 0-5A model). Calibration will fail if no load is connected during calibration of current. When first current calibration test point is entered the output voltage will be set to the middle (i.e. 20V for 0-40V model). Here is an example of current calibration:

cal:curr:lev min
cal:curr 44.5ma
cal:curr:lev mid
cal:curr 2.42
cal:curr:lev max
cal:curr 4.798

Please note that 44.5mA, 2.42A and 4.798A value was acquired using the external ammeter for the following test points: 50mA, 2.425A and 4.8A (0-5A model). Now we are only two steps from completed calibration session. We have to enter remark and save calibrated parameters in to external EEPROM. For that we are using CALibrate:REMark "<text>" and CALibrate:SAVE, "password".

Finalizing calibration
If calibration data are valid they will be stored and after that we need to change channel mode back to regular. Here is one example how to finalize calibration session:

cal:rem "calibration demo"
cal:save
cal off, "eezpsu"
cal?
0

Now we use once again DIAG:CAL? when channel exit calibration mode (CAL? returns 0 for OFF):

diag:cal?
remark=20151102 calibration demo
u_cal_params_exists=1
u_min_level=0.20 V
u_min_data=0.24 V
u_min_adc=0.24 V
u_mid_level=19.10 V
u_mid_data=19.12 V
u_mid_adc=19.14 V
u_max_level=38.00 V
u_max_data=37.90 V
u_max_adc=38.04 V
i_cal_params_exists=1
i_min_level=0.05 A
i_min_data=0.04 A
i_min_adc=0.05 A
i_mid_level=2.43 A
i_mid_data=2.42 A
i_mid_adc=2.42 A
i_max_level=4.80 A
i_max_data=4.80 A
i_max_adc=4.80 A

Testing calibrated channel
If everything went fine channel will automatically starts to use calibration date for programming and measurement. We can test that with the command CALibrate:STATe?

cal:stat?
1

Since the calibration data are saved into EEPROM they will be also used after the next power on. If calibration data are valid you can also use cal:stat to disable their usage. That can be used for testing what i.e. MEASure command will return with or without taking calibration data into account:

cal:stat off
cal:stat?
0
volt 12.34
volt?
12.34
meas?
12.39

If we activate usage of the calibration data we will get something like this:

cal:stat on
cal:stat?
1
meas?
12.34


Calibration summary
The whole calibration procedure could be summarized to the following list:
1   INST {CH1|CH2}; OUTP ON         Select the channel to be calibrated and enable the channel output.
2   CAL ON, “<password>”   The power supply enters calibration mode on the channel selected in step 1. Both voltage and current on the selected channel are set to the MINimum value. The VOLT? and CURR? commands can be optionally used here to test channel output values.
3   For voltage calibration, connect a digital voltmeter (DVM) across the channel's output terminals.
4   CAL:VOLT:LEV MIN   Set the channel to the low-end (MIN) calibration point.
5   CAL:VOLT 238mv   Enter the reading you obtained from the external DVM.
6   CAL:VOLT:LEV MID   Set the channel to the middle (MID) calibration point.
7   CAL:VOLT 19.122   Enter the reading you obtained from the DVM.
8   CAL:VOLT:LEV MAX   Set the channel to the high (MAX) calibration point.
9   CAL:VOLT 37.9   Enter the reading you obtained from the DVM.
10   For current calibration, connect an appropriate current monitoring resistor (shunt) across the output terminals and connect the DVM across the shunt resistor.
11   Repeat step 4 through step 9 by substituting CURR for VOLT for current calibration. For example, CAL:CURR:LEV MIN.
12   Repeat step 1 through step 11 for the other channel calibration.
13   CAL:REM “<string>”   Record calibration information such as next calibration due date for future reference. The calibration string may contain up to 40 characters.
14   CAL:SAVE   Save to non-volatile memory new calibration data.
15   CAL OFF, “<password>”        The channel exit calibration mode. Both voltage and current on the selected channel are again set to the MINimum value.

Title: Communication with 3rd party SCPI controller
Post by: prasimix on November 05, 2015, 11:19:23 am
I'd like to present here how is possible to use one of existing instrument control software for communication using SCPI commands. It's the Agilent/Keysight Command Expert, a free software for Windows that can be downloaded here (http://www.keysight.com/en/pd-2036130/command-expert). It requires installation of another free component IO Libraries Suite (http://www.keysight.com/en/pd-1985909/io-libraries-suite). When installed it is accessible from the system tray where first we need to make a connection using the Keysight Connection Expert:

(https://i.imgur.com/IB53CDM.png)

When choose manual configuration it is possible to define the PSU IP address, connection type and port:

(https://i.imgur.com/hVzUPbi.png)

After successful connection the PSU will be recognized and shown on the left side and it's ready to accept command by selecting "Send Commands To This Instrument"

(https://i.imgur.com/aQesqZ6.png)

That will open a new window showing Keysight Interactive IO:

(https://i.imgur.com/VVXJHo3.png)

Finally for the Keysight Connection Expert we can run Keysight Command Expert using Start Command Expert option (huh, so many names):

(https://i.imgur.com/5KcmdSU.png)

I didn't succeed to make a connection with the PSU using WinXP in VirtualBox environment so here is a screen from my colleague's desktop:

(https://i.imgur.com/in2OM38.png)

The Keysight Command expert allows sending a sequence of SCPI commands and some other stuff. It comes with list of Keysight predefined devices/instruments but it also support "generic SCPI" that is used for our testing. Here is a screenshot:

(https://i.imgur.com/LKK0hNp.png)
Title: Re: Open-source firmware and software for the programmable power supply
Post by: quantumvolt on November 06, 2015, 02:42:58 am
I am very impressed with your work - both the PSU and now the FW/SW.

This means that - even if we do not build your PSU - we can take any PSU that is controlled by DAC's and relays (etc.), adapt your control logic from the Arduino, make some changes to the FW sketch, and control the PSU from Command Expert?

I was thinking of just choosing one of the 'fixed' PSU command sets for a HP programmable PSU, and make an Arduino GPIB emulator for it to control a DAC (or two to control the Voltage Programming of an HP E3630A). But your SCPI based solution seems much more general.

Thank you.
Title: Re: Open-source firmware and software for the programmable power supply
Post by: prasimix on November 06, 2015, 08:56:32 am
Quote from: quantumvolt on November 06, 2015, 02:42:58 am
I am very impressed with your work - both the PSU and now the FW/SW.

This means that - even if we do not build your PSU - we can take any PSU that is controlled by DAC's and relays (etc.), adapt your control logic from the Arduino, make some changes to the FW sketch, and control the PSU from Command Expert?

Yes, and actually more then that. Here is the current "roadmap":
Release timeframes for versions beyond M1 is currently not known. If you succeed to continue with current rhythm everything could happen in 2016.
Starting from M1 release we are open for adding more people to the software team, and already we are open for anyone who would like to participate in improving hardware design (especially power part: pre-regulator/post-regulator). Possible "end-scenario" is to organize a "crowd funded group buy" not just for PCB's but for assembled modules and even complete solution (main transformer, power heatsink, metal enclosure, nice front panel with TFT display, etc.) and push total cost below 200EUR for serious (feature- and capacity-wise) dual channel programmable and open source bench power supply.


Title: Re: Open-source firmware and software for the programmable power supply
Post by: timofonic on November 06, 2015, 07:14:08 pm
Are you considering to add Sigrok support? :D
Title: Re: Open-source firmware and software for the programmable power supply
Post by: Macbeth on November 06, 2015, 08:09:49 pm
Quote from: Circuiteromalaguito on November 06, 2015, 07:14:08 pm
Are you considering to add Sigrok support? :D
That is effectively what he has done.
Title: Re: Open-source firmware and software for the programmable power supply
Post by: bingo600 on November 06, 2015, 08:28:30 pm
Am i missing something here , wrt. the software download ?

All i can find is this: https://github.com/mvladic/scpi-parser/tree/master/libscpi

But the doc says: "download & unzip"

Could someone point me to the right software link/repos ?

/Bingo
Title: Re: Open-source firmware and software for the programmable power supply
Post by: prasimix on November 06, 2015, 10:53:44 pm
Quote from: bingo600 on November 06, 2015, 08:28:30 pm
Am i missing something here , wrt. the software download ?

All i can find is this: https://github.com/mvladic/scpi-parser/tree/master/libscpi

But the doc says: "download & unzip"

Could someone point me to the right software link/repos ?

/Bingo

Bingo, this is only our fork of the SCPI parser that we are using in our firmware to have more efficient usage of SRAM on AVR platform and address few other minor issues. The firmware that is announced in my recent post will include that SCPI parser and support for real hardware, and it will comes with simulator for testing all implemented SCPI commands.
Title: Re: Open-source firmware and software for the programmable power supply
Post by: prasimix on November 06, 2015, 11:12:11 pm
Quote from: Macbeth on November 06, 2015, 08:09:49 pm
Quote from: Circuiteromalaguito on November 06, 2015, 07:14:08 pm
Are you considering to add Sigrok support? :D
That is effectively what he has done.

As I understand Sigrok is primarily addressing front end for communication with various class of instruments that have closed or open firmware. SCPI is mentioned as one mean of communication. We are working on both "backend" (firmware for Arduino Mega and Due) and local "frontend" that is color TFT touch-screen display and in the later phase PC frontend that will mirrors all functionality of the local frontend. In that case I suppose we can also make connection to Sigrok if that could in anyway improve usability of the power supply.
Title: Re: Open-source firmware and software for the programmable power supply
Post by: dom0 on November 06, 2015, 11:19:18 pm
I think there was some basic support for SCPI planned in sigrok, or even implemented, I dunno. Either way, it'd be pointless to write a dedicated sigrok driver.
Title: Re: Open-source firmware and software for the programmable power supply
Post by: Macbeth on November 06, 2015, 11:31:34 pm
When I last looked at Sigrok the only front end was for logic analysers. Perhaps they have simple multimeters (with the proprietary protocols) sorted too with a nice GUI by now.

Some people don't understand that if a hardware vendor releases a SCPI protocol and documentation then that is all that is needed for any front end to be developed by anybody on the planet, Sigrok included.

It's absurd to expect a hardware developer (open source or otherwise) to have specific support, including a universal front end interface for all instruments no matter what they are, to do Sigroks job for them.

Some people don't quite understand how open source does not mean you will develop everything nebulously possible for free.
Title: Re: Open-source firmware and software for the programmable power supply
Post by: prasimix on November 06, 2015, 11:36:08 pm
Quote from: Macbeth on November 06, 2015, 11:31:34 pm
It's absurd to expect a hardware developer (open source or otherwise) to have specific support, including a universal front end interface for all instruments no matter what they are, to do Sigroks job for them.

Yes, in that way you'll ends up with something like NI LabVIEW or Agilent/Keysight VEE Pro. And they spent decades to make all that job for their own and 3rd party devices.
Title: SCPI commands for various protections
Post by: prasimix on November 07, 2015, 09:53:19 am
We added four types of protection: over-voltage (OVP), over-current (OCP) aimed for protecting connected load, and over-power (OPP), over-temperature (OTP) that primarily has to protect the PSU itself. The latest one will be presented in some of the future posts.
The current PSU design do not include dedicated OVP and OCP circuits. Therefore voltage and current protection is implemented by monitoring programmed output values (VOLTage and CURRent) and mode of operation (CV or CC) combined with delay time required for "tripping". For example if we'd like to activate over-current protection what has to trip after 50ms we'll monitor the moment when channel changes from CV to CC mode of operation. If channel stays in that mode for more then mentioned 50ms the output will be turned off (OUTPut OFF) and we'll have indication that OCP was tripped.

Over-voltage protection (OVP)
the following SCPI commands for over-voltage protections is now supported:

[SOURce[<n>]]:VOLTage:PROTection:STATe
[SOURce[<n>]]:VOLTage:PROTection:DELay
[SOURce[<n>]]:VOLTage:PROTection:TRIPped?

The first one is used for enabling OVP, the second one for defining required time delay before OVP will "tripped" and the last one can be used to check if OVP is tripped. Again, since we don't have dedicated OVP circuit we cannot define level higher then that is programmed with VOLTage command. I don't know if make any sense to eventualy provide OVP voltage level setting that is below programmed voltage. If such case exists please let me know and we can add appropriate command that is [SOURce[<n>]]:VOLTage:PROTection:LEVel <voltage>.
Activating such protection before connecting load does not make sense because it will trip immediately after programmed DELay expire. For example we will set output voltage to 25V and current to 1A that is low enough that with connected load channel will immediately enters CC mode of operation. If load resistance is increased or loaf is disconnected that voltage reach programmed 25V for more then 50ms, the OVP will trip:

volt 25
volt:prot:stat on
volt:prot:del 50ms
outp on

The channel output will looks like this:

(https://i.imgur.com/QO1bDGM.png)

We can check output and OVP function state using the following sequence:

outp?
0
volt:prot:trip?
1

If OVP or any other protection was activated (tripped), it is not possible to turn on channel output before clearing "trip" state. We can see that in the following example when OUTPut ON attempts will generate an error that is queried with the SYSTem:ERRor[:NEXT]? command:

outp on
outp?
0
syst:err?
201,"Cannot execute before clearing protection"

Trip reset of OCP, OVP and OPP require execution of the following command:

OUTPut:PROTection:CLEar

The following sequence shows that channel output successfully is activated again when it is executed:

outp:prot:cle
outp on
outp?
1

Over-current protection (OCP)
Command set for over-current protection is similar to that for OVP and the working principle is the similar:

[SOURce[<n>]]:CURRent:PROTection:STATe
[SOURce[<n>]]:CURRent:PROTection:DELay
[SOURce[<n>]]:CURRent:PROTection:TRIPped?

In this case the output current programmed by the CURRent command and change of operation mode to the CV mode is used as a trigger. If such condition exists on the channel for more then a programmed delay the OCP will "trip". During OCP initialization it is not necessary to have load connected, and if it's connected it has to be low enough that channel remain in the CV mode of operation. Here is an example how to initiate OCP on 1A with 5ms delay:

curr 1
curr:prot:stat on
curr:prot:del 5ms
outp on

OCP trip will cause the following changes on the channel output:

(https://i.imgur.com/iFkr1ci.png)

The following command sequence can be used to check OCP activation, clear/reset protection and make output active once again:

curr:prot:trip?
1
outp?
0
outp:prot:cle
outp on
outp?
1

Over-power protection (OPP)
Power protection command set include one additional command that allows us to set threshold value in Watts:

[SOURce[<n>]]:POWer:PROTection[:LEVel]
[SOURce[<n>]]:POWer:PROTection:STATe
[SOURce[<n>]]:POWer:PROTection:DELay
[SOURce[<n>]]:POWer:PROTection:TRIPped?

OPP mechanism do not monitor channel mode of operation (CV or CC) but rely on the measured value as in the case of the MEASure[:SCALar]:POWer[:DC]? command. The following example shows how to activate OPP on 80W output power that lasts more then 10 seconds:

pow:prot 80
pow:prot:del 10
pow:prot:stat on
outp on

With OPP tripped the channel output switches off and tripping and output condition can be check using the following commands:

pow:prot:trip?
1
outp?
0

Clearing OPP trip condition and set channel output back to on state will require:

outp:prot:cle
outp on


Finally we also added one specialized command within DIAGnostic subsystem to query all information about implemented protections:

DIAGnostic[:INFOrmation]:PROTection?

An example of the query:

diag:prot?
"CH1 u_tripped=0","CH1 u_state=0","CH1 u_delay=0 ms","CH1 i_tripped=0","CH1 i_state=0","CH1 i_delay=0 ms","CH1 p_tripped=0","CH1 p_state=0","CH1 p_delay=0 s","CH1 p_level=0.00 W","CH2 u_tripped=0","CH2 u_state=0","CH2 u_delay=0 ms","CH2 i_tripped=0","CH2 i_state=0","CH2 i_delay=0 ms","CH2 p_tripped=0","CH2 p_state=0","CH2 p_delay=0 s","CH2 p_level=0.00 W"

And few words about delay resolution of implemented protection functions. It's currently defined by the sampling speed of the ADC which generates interrupts and in that way sets duration time of the main programming loop. In the case of Arduino Mega2560r3 that cycle is ~2.6ms when Due is slightly faster with ~2ms for the same sampling rate (600SPS). This information is crucial for OVP and OCP functionality while OPP and OTP delay that are normally sets in seconds does not suffer too much.
So, in the worst case OVP and OCP could be late for 2.6ms or 2ms depends of the chosen MCU. I think that for this kind of emulated protection (without dedicated OVP and OCP circuits) is acceptable. That offset will be included in DELay value i.e. if you specify 10ms, 7.ms or 8ms will be set.
Title: Re: Open-source firmware and software for the programmable power supply
Post by: timofonic on November 09, 2015, 06:49:31 am
Half Offtopic:

I had a little conversation with sigrok guys (the project leader insists about writing it uncapitalized!) and said me the project already supports SCPI, so there's need of just adding a profile for your hardware!

I'm interested in your PSU, I prefer it than buying one of these cheap manufacturers and finally find weird bugs or issues with Linux (I "unfortunately " am too used to it and prefer "libre" stuff all the time).

I have a few questions:

- Are you going to release all parts as FOSS and OSHW? Preferably if releasing the project files in KiCad format.
- Are you going to publish it in GitHub and see the progress on it? This could make others could fork it, then later submit pull requests for modification proposals to the design or firmware. If the project gains enough traction, it could become a nice community project and the favorite DIY PSU.
- Is possible to do a comparison and test against different manufacturers of
 commercial PSUs from low to high end? So less skilled people like me can see how the project is compared to proprietary designs by major manufacturers.

Sent from my ZTE Blade A450 using Tapatalk

Title: Re: Open-source firmware and software for the programmable power supply
Post by: prasimix on November 09, 2015, 05:34:22 pm
Quote from: timofonic on November 09, 2015, 06:49:31 am
I'm interested in your PSU, I prefer it than buying one of these cheap manufacturers and finally find weird bugs or issues with Linux (I "unfortunately " am too used to it and prefer "libre" stuff all the time).

That was also my initial starting point: have something that if serviceable and upgradeable over time whatever it is: hardware or software part.

Quote from: timofonic on November 09, 2015, 06:49:31 am
I have a few questions:

- Are you going to release all parts as FOSS and OSHW? Preferably if releasing the project files in KiCad format.
- Are you going to publish it in GitHub and see the progress on it? This could make others could fork it, then later submit pull requests for modification proposals to the design or firmware. If the project gains enough traction, it could become a nice community project and the favorite DIY PSU.

Yes, I promised that at the very beginning and that is not an empty promise: some are already published on this forum and the first design is just published on Github (Follow this link: https://github.com/eez-open). We are also currently working on building up dedicated web pages for this type of projects.
I'm using Eagle and most of the PCBs are within Eagle Freeware dimensions of 80x100mm that one can make changes without limitation. Anyone is invited to convert them in one moment to KiCad. Currently I don't have time to learn it, rebuild all parts and draw once again schematics and PCB layout.

Quote from: timofonic on November 09, 2015, 06:49:31 am
- Is possible to do a comparison and test against different manufacturers of
 commercial PSUs from low to high end? So less skilled people like me can see how the project is compared to proprietary designs by major manufacturers.

I'm afraid that could be a mission impossible without having such equipment on site. One thing is reading marketing materials and quite another when that become DUT (device under test). Maybe over time some people which decides to build this PSU will be in position to compare it with what they already have on their desktops and inform us about results, impressions and disappointments :).

Title: SCPI status registers
Post by: prasimix on November 18, 2015, 12:57:46 pm
Today I'd like to say something about SCPI status registers structure that is implemented in the PSU firmware. This is a complex subject and I'll use here descriptions from our SCPI reference guide, a 100-page document that described all SCPI commands currently supported.

SCPI requires the status mechanism described in Section 11 of IEEE 488.2, including full implementation of the status register structure. Summary of implemented registers structure for the PSU is shown on figure below. (commands used to access registers are written in parentheses).

(https://i.imgur.com/6xGyNeq.png)

All SCPI instruments have to implement status registers in the same way. The status system records various instrument conditions in the following register groups:
The Status Byte register records high-level summary information reported in the other register groups.
Message interchanging between Controller and Instrument is accomplished by using input buffer and Output queue and Error queue. The length of the Input buffer is 48 (user-defined) characters. Both Output and Error queue can handle up to 16 messages.

Standard Event Status Register
An status register group is consist of Condition, Event and Enable registers:
An error status (bit 2, 3, 4 or 5) records one or more errors in the PSU error queue. The SYSTem:ERRor? command can be used to read the error queue.

Implementation of the Standard Event Status register follows IEEE 488.2 Section 11.5.1.1:

(https://i.imgur.com/a2MEFGZ.png)

Status Byte Register
The Status Byte summary register reports conditions from the other status registers. Query data that is waiting in the PSU’s output buffer is immediately reported through the "Message Available" (MAV) bit (bit 4) of the Status Byte register. Bits in the summary register are NOT latched. Clearing an event register will clear the corresponding bits in the Status Byte summary register. Reading all messages in the output buffer, including any pending queries, will clear the message available bit (MAV).
The Status Byte summary register is cleared when the *CLS (clear status) command has been executed.
The Status Byte enable register (request service) is cleared when the *SRE 0 command has been executed.
Querying the Standard Event register (*ESR? command) will clear only bit 5 (ESR) in the Status Byte summary register. For example, 24 (8 + 16) is returned when you have queried the status of the Status Byte register, QUES and MAV conditions have occurred.

(https://i.imgur.com/RYxhQzV.png)
Title: Re: Open-source firmware and software for the programmable power supply
Post by: timofonic on November 18, 2015, 01:07:42 pm
So are there a standardized specific SCPI subset used for DMMs? Are those used equally on all DMMs or there are difference implementations?

This seems pretty interesting, but I fail to see the broader picture. I need to understand SCPI first, I suppose.

Sent from my ZTE Blade A450 using Tapatalk

Title: OPERation Status Register
Post by: prasimix on November 18, 2015, 01:09:18 pm
OPERation Status Register
The OPERation status register contains conditions which are part of the instrument’s normal operation.
Each channel of the PSU is considered as separate "instrument". The two logical outputs (channels) of the PSU include an INSTrument summary status register and an individual instrument ISUMmary register for each logical output.

(https://i.imgur.com/oFvNUdy.png)

The bit definition of OPERation Status register shown on figure from the previous post:

(https://i.imgur.com/tuhkwVH.png)

Bit 8 and 9 settings will be supported from the M3 version (see roadmap here (https://www.eevblog.com/forum/projects/open-source-firmware-and-software-for-the-programmable-power-supply/msg794341/#msg794341)).

The Event Status Enable register is cleared when the STAT:EVEN:ENAB 0 command is executed. The *CLS command can be also used to clear the register.

Operation INSTrument Status register
The bit definition of OPERation INSTrument Status register shown on above picture (right section):

(https://i.imgur.com/nWd8lsE.png)

Operation Instrument SUMmary status register
The ISUMmary registers report to the INSTrument register, which in turn reports to bit 13 of the Operation Status register. This is illustrated on the picture above. Using such a status register configuration allows a status event to be cross- referenced by output channel and type of event. The INSTrument register indicates which channel(s) have generated an event. The ISUMmary register represent a pseudo-operation Status register for a particular logical output.

The bit definition of OPERation INSTrument ISUMmary Status register shown on above picture (left section):

(https://i.imgur.com/7fNTHLD.png)




Title: QUEStionable Status Register
Post by: prasimix on November 18, 2015, 01:32:23 pm
QUEStionable Status Register
The Questionable Status register provides information about unexpected operations of the PSU. Each channel of the PSU is considered as separate "instrument". The two logical outputs (channels) of the PSU include an INSTrument summary status register and an individual instrument ISUMmary register for each logical output.
The ISUMmary registers report to the INSTrument register, which in turn reports to bit 13 of the Questionable Status register. This is illustrated on the picture that follows. Using such a status register configuration allows a status event to be cross-referenced by output channel and type of event. The INSTrument register indicates which channel(s) have generated an event. The ISUMmary register represent a pseudo-Questionable Status register for a particular logical output.

(https://i.imgur.com/7v2CVpA.png)

For example, if one of the two channels is in constant voltage (CV) mode and due to an overload looses regulation, bit 13 is set (latched). To read the register, the command STATus:QUEStionable? is required. To make use of bit 13 (ISUM), enable register must be correctly set. The command STAT:QUES:INST:ENAB 6 (2 + 4) has to be send to enable the Questionable instrument register, followed by the command STAT:QUES:INST:ISUM<n>:ENAB 19 for each channel to enable the QUEStionable INSTrument SUMmary register, where n is 1 or 2.

Bit definition for QUEStionable Status register (see the picture from the first post related to this topic):

(https://i.imgur.com/DQiRzvk.png)

The Questionable Status Enable register is cleared when the STAT:QUES:ENAB 0 command is executed. The *CLS command can be also used to clear the register.

Questionable INSTrument Status register
Bit definition for QUEStionable INSTrument register:

(https://i.imgur.com/2IYiuWG.png)

Questionable Instrument SUMmary status register
There are two questionable instrument summary registers, one for each PSU output. These registers provide information about voltage and current regulation.
Bit definition for QUEStionable INSTrument SUMmary register:

(https://i.imgur.com/7ddkNHr.png)

Please note here that CURRent bit is use for questionable Voltage operating mode and vice versa.
If 0 and 1 bits is true that indicate neither the voltage nor the current is regulated (so-called unregulated or UR mode), and both bits false indicate the PSU channel are off.

To read the register for each PSU channel, the command STAT:QUES:INST:ISUM[<n>]? has to be send, where [<n>] is 1 or 2. If [<n>] is not specified the currently selected channel is used.
Use STAT:QUES:INST:ISUM<n>:COND? to determine operating mode (CV or CC) for the PSU channel (where n is 1 or 2 depending on the output).
The Questionable Status event register is cleared with:

It's important to know that all this complex structure will be completely hidden for the user when the support for the local console (TFT display/touch screen) will be added. One don't need to learn anything about SCPI if don't want to use controller application such as LabView, VEE Pro, etc.
Title: Re: Open-source firmware and software for the programmable power supply
Post by: prasimix on November 18, 2015, 01:43:27 pm
Quote from: timofonic on November 18, 2015, 01:07:42 pm
So are there a standardized specific SCPI subset used for DMMs? Are those used equally on all DMMs or there are difference implementations?

This seems pretty interesting, but I fail to see the broader picture. I need to understand SCPI first, I suppose.

Sent from my ZTE Blade A450 using Tapatalk

Yes, there is a specific SCPI subset for DMMs. But, they are not equally used even in the case of the same manufacturer. That is not a real problem as far as decent programming reference manual exists what is normally a case. We are also prepared our SCPI reference guide that I hope will be helpful. You'll be our judges.
Title: Error queue
Post by: prasimix on November 18, 2015, 03:40:15 pm
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):

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.


Title: Working with configuration profiles
Post by: prasimix on November 19, 2015, 08:08:59 pm
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:
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
Title: Re: Open-source firmware and software for the programmable power supply
Post by: kia on November 20, 2015, 11:07:09 am
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.
Title: Development status
Post by: prasimix on November 25, 2015, 02:43:55 pm
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 (http://"http://envox.hr/eez/images/sampledata/EEZ_PSU_SCPI_reference_M1-preliminary_DRAFT.pdf") (I cannot attach it here because of its size of 3MB).
Title: Re: Open-source firmware and software for the programmable power supply
Post by: timofonic on December 02, 2015, 08:35:39 pm
Very nice! You are doing a lot of nice progress, congratulations! ;)
Title: Re: Open-source firmware and software for the programmable power supply
Post by: KuchateK on December 02, 2015, 08:58:58 pm
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.
Title: Re: Open-source firmware and software for the programmable power supply
Post by: prasimix on December 02, 2015, 10:10:30 pm
Quote from: KuchateK on December 02, 2015, 08:58:58 pm
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 (https://www.arduino.cc/en/Main/ArduinoBoardLeonardo), 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.
Title: Experimenting with the GUI
Post by: prasimix on December 04, 2015, 07:12:50 am
The complete SCPI manual pages are now available on line (http://www.envox.hr/eez/bench-power-supply/psu-scpi-reference-manual/psu-scpi-introduction.html), 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) (https://www.libsdl.org/index.php) 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:

(https://i.imgur.com/wnyY6y3.png)

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


(https://i.imgur.com/VjmekLd.png)

Title: The Milestone One is reached!
Post by: prasimix on December 30, 2015, 08:16:08 am
Finally the first milestone (M1) is completed and its source code is published on the GitHub (https://github.com/eez-open/psu-firmware).
It is accompanied with the reference guide for supported supported SCPI command set (http://www.envox.hr/eez/bench-power-supply/psu-scpi-reference-manual/psu-scpi-commands-summary.html) that can be used in this stage for remote control of the bench power supply (https://www.eevblog.com/forum/projects/diy-programmable-dual-channel-bench-psu-0-50v3a/) 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 (https://ubuntu-mate.org/raspberry-pi/) for Raspberry Pi 2). Windows installation is available on the mentioned GitHub start page or at the bottom of this (http://www.envox.hr/eez/bench-power-supply/psu-firmware.html) page.

How to use software simulator is described in the Section 9 (http://www.envox.hr/eez/bench-power-supply/psu-scpi-reference-manual/psu-scpi-simulator.html) of the SCPI reference guide, and some examples of usage are listed in Section 10 (http://www.envox.hr/eez/bench-power-supply/psu-scpi-reference-manual/psu-scpi-programming-examples.html).

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.
Title: Re: Open-source firmware and software for the programmable power supply
Post by: Macbeth on December 30, 2015, 08:49:56 pm
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  :-+
Title: Espressif ESP8266 support in Arduino IDE
Post by: prasimix on January 13, 2016, 12:54:36 pm
Don't know how many of you are aware of what's going on with ESP8266 (http://espressif.com/en/products/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 (https://github.com/esp8266/arduino).

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 ;).
Title: Playing with M1 firmware configuration parameters
Post by: prasimix on January 19, 2016, 10:54:11 am
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:
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 (http://www.envox.hr/eez/bench-power-supply/psu-scpi-reference-manual/psu-scpi-subsystem-command-reference/psu-scpi-measure.html#meas_temp) 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? (http://www.envox.hr/eez/bench-power-supply/psu-scpi-reference-manual/psu-scpi-common-command-reference.html#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:

(https://i.imgur.com/DTozkul.png)

conf_channel.h
Channel specific information such as pin mapping (http://www.envox.hr/eez/bench-power-supply/psu-digital-control/psu-arduino-shield-pin-mapping.html) 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 (http://www.envox.hr/eez/bench-power-supply/psu-post-regulator.html) 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 (http://www.envox.hr/eez/bench-power-supply/psu-scpi-reference-manual/psu-scpi-subsystem-command-reference/psu-scpi-source.html#sour_volt_step) and [SOURce[<n>]]:CURRent:STEP (http://www.envox.hr/eez/bench-power-supply/psu-scpi-reference-manual/psu-scpi-subsystem-command-reference/psu-scpi-source.html#sour_curr_step)), calibration LEVels (see CALibration:VOLTage:LEVel (http://www.envox.hr/eez/bench-power-supply/psu-scpi-reference-manual/psu-scpi-subsystem-command-reference/psu-scpi-calibrate.html#cal_volt_lev) and CALibration:CURRent:LEVel (http://www.envox.hr/eez/bench-power-supply/psu-scpi-reference-manual/psu-scpi-subsystem-command-reference/psu-scpi-calibrate.html#cal_curr_lev)), OVP (http://www.envox.hr/eez/bench-power-supply/psu-scpi-reference-manual/psu-scpi-subsystem-command-reference/psu-scpi-source.html#sour_volt_prot_del) and OCP (http://www.envox.hr/eez/bench-power-supply/psu-scpi-reference-manual/psu-scpi-subsystem-command-reference/psu-scpi-source.html#sour_curr_prot_del) 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
Title: Hard time with Utouch library...
Post by: prasimix on January 28, 2016, 03:25:38 pm
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.  |O. 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.

Title: Working with touch screen
Post by: prasimix on March 18, 2016, 03:38:18 pm
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 (http://dlbeer.co.nz/articles/tsf.html) (thank you very much).
I prepared two short demos, first one with simple filtering and second one with new approach:

https://www.youtube.com/watch?v=_mrBomMLKiI (https://www.youtube.com/watch?v=_mrBomMLKiI)

https://www.youtube.com/watch?v=BP_5paHGkL8 (https://www.youtube.com/watch?v=BP_5paHGkL8)
Title: First video...
Post by: prasimix on March 26, 2016, 12:34:20 pm
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.

https://www.youtube.com/watch?v=jofIdGx2gTg (https://www.youtube.com/watch?v=jofIdGx2gTg)
Title: Re: Open-source firmware and software for the programmable power supply
Post by: kolesar007 on March 30, 2016, 04:41:54 am
Prasimix thats looks very nice, cant wait to try it by my self.
Title: Re: Open-source firmware and software for the programmable power supply
Post by: void_error on May 22, 2016, 10:27:36 pm
Sorry for the late reply...

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

These are my thoughts so far, if I have more ideas I'll let you know.
Title: Re: Open-source firmware and software for the programmable power supply
Post by: prasimix on June 04, 2016, 09:22:10 am
Quote from: void_error on May 22, 2016, 10:27:36 pm
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 (http://www.envox.hr/eez/bench-power-supply/psu-scpi-reference-manual/psu-scpi-subsystem-command-reference/psu-scpi-memory.html) 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?
Title: Support for multiple revisions
Post by: prasimix on June 04, 2016, 10:12:16 am
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"
Title: Re: Open-source firmware and software for the programmable power supply
Post by: void_error on June 04, 2016, 11:37:11 am
Quote from: prasimix on June 04, 2016, 09:22:10 am
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.
Title: Re: Open-source firmware and software for the programmable power supply
Post by: prasimix on June 04, 2016, 01:00:35 pm
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.
Title: "Low ripple" mode of operation
Post by: prasimix on June 04, 2016, 03:23:40 pm
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:
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 (https://github.com/eez-open/psu-firmware/tree/local_control). Quick video about how to use simulator is here:

https://www.youtube.com/watch?v=hhGT8GlrUEk (https://www.youtube.com/watch?v=hhGT8GlrUEk)



 
Title: Output voltage remote programming
Post by: prasimix on June 07, 2016, 01:54:32 pm
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