-
Open-source firmware and software for the programmable power supply
Posted by prasimix on 01 Nov, 2015 16:09 -
List of important changes
Update 2015-12-30: The firmware Milestone One 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. 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 designed as an Arduino Shield and it will be used as an reference platform for development. Let's start with the short list of hardware related features:- Arduino Mega2560r3 (8-bit AVR) and Arduino Due (32-bit ARM)
- SPI bus based on 10-pin ISCP connector
- External ADC and DAC
- Digital I/O (Output enable, down-programmer disable, powergood status, CV and CC indicators)
- Local console: color TFT with touch-screen as an input device
- Remote console: serial (via USB) and Ethernet
- External RTC with supercap backup
- Multiple temperature sensors (i.e. main transformer, channel's heatsinks, battery NTCs when works as an battery charger)
- Remote sense control with LED indications (BP option)
- Serial and parallel connection control with LED indications (BP option)
- SD-card for internal data logging
- Tone generator (beeper)
- Easy to use local console with GUI
- SCPI 1999.0 command set and reporting
- Multiple working profiles stored and recalled from non-volatile memory (EEPROM)
- Calibration
- Interrupt based ADC control
- RTC sync with external time server using NTP (require Ethernet connection)
- Measuring voltage, current and power
- Various protection mechanism for both power supply and connected load: over-voltage (OVP), over-current (OCP), over-power (OPP) and over-temperature (OTP)
- External data logging (via SCPI)
- Internal data logging (require SD-card)
- Arbitrary waveform generator
- Multiple lists for arbitrary waveform generator stored and recalled from non-volatile memory (EEPROM)
- Multiple predefined modes of operation (i.e. battery charger)
- Multi-language support (compile time or run time)
Usage has to be straight forward: download, unzip, compile and upload using Arduino IDE (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, 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). -
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. My colleague took active part to make it more suitable for AVR platform (Mega) and fork it here 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):
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:
When Ethernet port is enabled you can for example test communication with the power supply using ping:
... or start session using telnet:
-
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:- EEZ - manufacturer
- PSU 25003D (Mega) - model name
- 00001 - serial number
- 0.44 - firmware number
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
-
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):
With Arduino Due we have cycle of 2.08ms for both channel (in average 1.04ms that is 962 interrupts per second):
SCPI command has two subsystems for acquiring data: FETCh and MEASure. The SCPI specification said:QuoteFETCh? 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"
-
This is actually rather cool.
I'll be checkking out the "mini" scpi parser for sure.
Thank you for publishing it.
/Bingo
-
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.
-
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. It requires installation of another free component 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:
When choose manual configuration it is possible to define the PSU IP address, connection type and port:
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"
That will open a new window showing Keysight Interactive IO:
Finally for the Keysight Connection Expert we can run Keysight Command Expert using Start Command Expert option (huh, so many names):
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:
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:
-
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. -
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":- M1 (Milestone one) - SCPI compliant firmware for the power supply as a class of device that include programming voltage, current, OVP (over-voltage protection), OCP (over-current protection), OPP (over-power protection) and OTP (over-temperature protection), output measurement, ADC/DAC voltage and current calibration, output control, remote sense control, power up control, system date/time (using RTC), diagnostic reporting, beeper, Ethernet and serial (via USB) communication. That also include support for complex SCPI status registers structure. Milestone is scheduled to be released in next month or two (hopefully in this year) with source code and the SCPI reference guide.
But without hardware it doesn't make lots of sense for anyone potentially interesting in this approach so we'll also release simulator for Windows and Linux. Using this simulator one can test all commands described in the reference guide and with few "dummy" command could attach/detach load, etc. All data that are stored on reference design EEPROM will be write to the local disk file. You can test simulator with i.e. telnet session or application such as above presented Keysight Command Expert. - M2 - Add support for local console based on color TFT display with touch screen as an input device that remove requirement for many buttons and switches on the front panel and in parallel enables better user interaction thanks to "pointing device" (your finger on the touch-screen) that commercial devices in general do not offer.
- M3 - Extend SCPI command set introduced in M1. That will include full support for BP (binding post) for serial and parallel wiring of two channels, arbitrary waveform generator, work with "mas-storage" (SD-card) for data logging and support for *SRQ (service request) over Ethernet, triggers. It's also possible that from M3 it will be possible to use firmware even without Arduino shield employing built-in ADC/DAC/PWM/Digital I/O on Arduino Mega or Due board
- V1.0 - Incorporate all features added in M3 for local console (TFT). Probably we will add our own multi-platform console will mirrors all activities on local TFT console.
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.
- M1 (Milestone one) - SCPI compliant firmware for the power supply as a class of device that include programming voltage, current, OVP (over-voltage protection), OCP (over-current protection), OPP (over-power protection) and OTP (over-temperature protection), output measurement, ADC/DAC voltage and current calibration, output control, remote sense control, power up control, system date/time (using RTC), diagnostic reporting, beeper, Ethernet and serial (via USB) communication. That also include support for complex SCPI status registers structure. Milestone is scheduled to be released in next month or two (hopefully in this year) with source code and the SCPI reference guide.
-
Are you considering to add Sigrok support?
-
Are you considering to add Sigrok support?
That is effectively what he has done. -
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
-
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. -
Are you considering to add Sigrok support?
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. -
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.
-
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. -
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. -
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:
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:
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. -
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
-
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.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.- 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.
-
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).
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,
- the Standard Event register,
- the QUEStionable Status register group, and
- the OPERation Status register group.
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:- The CONDition register is a read-only register, which holds the live (unlatched) operational status of the instrument. Reading the Condition register does not clear it.
- The EVENt register is a read-only that reports defined conditions within the PSU. Bits in an event register are latched. Once an event bit is set, subsequent state changes are ignored. Bits in the Event register are automatically cleared by a query of that register (such as *ESR? or STATus:QUEStionable:EVENt?) or by sending the *CLS (clear status) command. A reset (*RST) or device clear will not clear bits in event registers. Querying an event register returns a decimal value which corresponds to the binary-weighted sum of all bits set in the register.
- The ENABle register is used to define which bits of the Event Status register will latch ESB (bit 5) of the Status byte register.
Implementation of the Standard Event Status register follows IEEE 488.2 Section 11.5.1.1:
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.
-
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
-
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.
The bit definition of OPERation Status register shown on figure from the previous post:
Bit 8 and 9 settings will be supported from the M3 version (see roadmap here).
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):
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):
-
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.
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):
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:
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:
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:- the *CLS (clear status) command or
- the event register is queried using the STAT:QUES? (status questionable event register) command.
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.
-
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.