Go Back   Home > Forums > >

Equipment & Tools From test equipment to hand tools

Open-source firmware and software for the programmable power supply
Open-source firmware and software for the programmable power supply
Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools
Old 1st November 2015, 04:24 PM   #1
prasimix is offline prasimix  Croatia
diyAudio Member
 
prasimix's Avatar
 
Join Date: Feb 2009
Default Open-source firmware and software for the programmable power supply

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)
Firmware feature overview:
  • 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)
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 architecture but with little bit better MCU.
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).

Last edited by prasimix; 3rd November 2015 at 12:47 PM. Reason: Feature list update
  Reply With Quote
Old 1st November 2015, 06:01 PM   #2
prasimix is offline prasimix  Croatia
diyAudio Member
 
prasimix's Avatar
 
Join Date: Feb 2009
Default Basic SCPI programming

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:
Code:
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:
Code:
VOLTage?
20.00
I 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:
Code:
VoLtaGe
voltage
VOLT
volt
... but you cannot use other then short or long word such as:
Code:
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:
Code:
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:
Code:
VOLTage?
20.00
I 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:
Code:
VoLtaGe
voltage
VOLT
volt
... but you cannot use other then short or long word such as:
Code:
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:
Code:
*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 (I'm using code below only for better formatting):
Code:
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:
Code:
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:
Code:
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:
Code:
volt 30;curr 1.25
We already can access power supply using serial or Ethernet communication. Here is a session over serial (gtkTerm):

Click the image to open in full size.

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:

Click the image to open in full size.

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

Click the image to open in full size.

... or start session using telnet:

Click the image to open in full size.
  Reply With Quote
Old 2nd November 2015, 10:40 AM   #3
prasimix is offline prasimix  Croatia
diyAudio Member
 
prasimix's Avatar
 
Join Date: Feb 2009
Default Programming channel output

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:
Code:
*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
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 <i>numeric</i> values 1 or 2 or <i>discrete</i> 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:
Code:
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:
Code:
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:
Code:
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>
[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:
Code:
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:
Code:
sour1:volt?
3.30
sour1:curr?
0.10
It's also possible to concatenate few query commands like this:
Code:
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:
Code:
appl ch1, 20, 0.3
This command also has the query form:
Code:
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:
Code:
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:
Code:
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:
Code:
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:
Code:
inst ch1;volt 20;curr 500ma;outp on
inst ch2;volt 12.4;curr 2.5;outp on
...or:
Code:
appl ch1, 20, 0.5;outp 1, ch1
appl ch2, 12.4, 2.5;outp 1, ch2
  Reply With Quote
Old 2nd November 2015, 02:28 PM   #4
prasimix is offline prasimix  Croatia
diyAudio Member
 
prasimix's Avatar
 
Join Date: Feb 2009
Default Measuring output parameters on uncalibrated channel

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):

Click the image to open in full size.

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

Click the image to open in full size.

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:
Code:
MEASure[:SCALar]:VOLTage[:DC]? [CH1|CH2] 
MEASure[:SCALar]:CURRent[:DC]? [CH1|CH2]
Here is an example if we want to measure current on the channel 1:
Code:
MEAS:CURR?
0.12
For measuring voltage we have:
Code:
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:
Code:
meas?
5.00
We can do the same thing on specified channel like:
Code:
meas? ch2
12.00
We also added
Code:
MEASure[:SCALar]:POWer[:DC]? [CH1|CH2]
that returns U*I value that can be used in the following way:
Code:
meas:pow?
34.22
Finally we can get all three values using single line sequence:
Code:
meas:volt?;curr?;pow?
4.76;0.56;2.68
We'll also working on
Code:
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:
Code:
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:
Code:
appl ch1, 20, 200ma; outp 1
volt?; curr?
20.00; 0.20
meas? 
3.30
meas:curr? 
.21
outp:mode?
"CC"
  Reply With Quote
Old 2nd November 2015, 04:29 PM   #5
Turbon is offline Turbon  Sweden
diyAudio Member
 
Turbon's Avatar
 
Join Date: Aug 2011
Location: EU-Southern part of Sweden, Europe.
Very, very nice!
One could easily write an gui for X or Windows that gives the commands backstage but that is better to take later when the commands are tested thru the cli.

Regards
  Reply With Quote
Old 2nd November 2015, 11:22 PM   #6
prasimix is offline prasimix  Croatia
diyAudio Member
 
prasimix's Avatar
 
Join Date: Feb 2009
Default Voltage and current calibration

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, 23.9V 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:
Code:
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:
Code:
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:
Code:
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
Code:
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, 18.9V and 38V (for 0-40V model):
Code:
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:
Code:
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:
Code:
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.375A 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:
Code:
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):
Code:
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?
Code:
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:
Code:
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:
Code:
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.
  Reply With Quote
Old 2nd November 2015, 11:27 PM   #7
prasimix is offline prasimix  Croatia
diyAudio Member
 
prasimix's Avatar
 
Join Date: Feb 2009
Quote:
Originally Posted by Turbon View Post
Very, very nice!
One could easily write an gui for X or Windows that gives the commands backstage but that is better to take later when the commands are tested thru the cli.

Regards
Exactly, and people who are addicted to smartphones can do that for IOS or Android too (you only have to connect it by the Ethernet cable to the nearest switch/wireless router). I the next post I'll demonstrate how it works with some of existing console that is used as an instrument controller.
  Reply With Quote
Old 3rd November 2015, 05:42 PM   #8
Turbon is offline Turbon  Sweden
diyAudio Member
 
Turbon's Avatar
 
Join Date: Aug 2011
Location: EU-Southern part of Sweden, Europe.
Now - get the core part running and debugged first - then think about phones and tablets or the risk is that things gets very confused.

Regards
  Reply With Quote
Old 5th November 2015, 11:17 AM   #9
prasimix is offline prasimix  Croatia
diyAudio Member
 
prasimix's Avatar
 
Join Date: Feb 2009
Default Communication with 3rd party SCPI controller

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:

Click the image to open in full size.

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

Click the image to open in full size.

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"

Click the image to open in full size.

That will open a new window showing Keysight Interactive IO:

Click the image to open in full size.

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

Click the image to open in full size.

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:

Click the image to open in full size.

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:

Click the image to open in full size.
  Reply With Quote
Old 5th November 2015, 09:14 PM   #10
Algar_emi is offline Algar_emi  Canada
diyAudio Member
 
Algar_emi's Avatar
 
Join Date: Oct 2002
Location: Canada, Qc
Open-source firmware and software for the programmable power supply
Wow that remind me of my early days in a calibration lab where we where using IEEE488 and HP computer to write test and calibration routines. Incredible work you're doing
  Reply With Quote

Reply


Open-source firmware and software for the programmable power supplyHide this!Advertise here!
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
A free open source Labview Loudspeaker Test Software elvischan917 Software Tools 15 23rd January 2015 10:04 PM
Open-source audio design software schodge Software Tools 3 28th December 2014 04:02 PM
High voltage, programmable power supply? exclamationmark Power Supplies 0 22nd January 2013 12:34 PM
Programmable Bench Power Supply? samsagaz Parts 1 22nd January 2008 03:21 AM
Looking for Linux based (open source) speaker design software Maxxarcade Multi-Way 3 17th January 2007 01:41 PM


New To Site? Need Help?

All times are GMT. The time now is 02:45 AM.


Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2021 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 15.79%
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2021 DragonByte Technologies Ltd.
Copyright ©1999-2021 diyAudio
Wiki