eez-open / psu-firmware Goto Github PK

*SAV has to generate an error on an unsuccessful attempt to save a profile when EEPROM test is failed or EEPROM is not installed.

We need a table with the following features availablity when channels are separated, coupled or in tracking mode:

• Protections
• Low ripple
• External voltage programming
• Remote sensing
• Calibration

In bar graphs view display mV and mA for smaller values (below 1 volt or ampere)

If channel is calibrated, its calibration parameters cannot be activated or deactivated without new restart. Both CAL:STAT? and local console option reflect changed state but that is not a real situation. An example:

cal:stat?
0
cal:stat 1
cal:stat?
1
meas?
15.74
volt?
16.00
syst:pow 0
// wait min. 5 sec
syst:pow 1  
meas?
16.00

This is a reminder that in one moment we should reuse parts of UTFT and UTouch only for display that we are using. Regardless of that we have to add test and init procedure for both TFT display and Touch controllers.

Add self-test of MAIN temp sensor that will return error if value is below -10oC. That could be used as criteria for disconnected NTC since Due in that case returns ~13.8oC. Also during the operation if returned value is so low that has to generate immediately a warning error on the local console that will require operators intervention. If such intervention is not happened max. current per channel has to be limited to e.g. 2 A.

When params are saved into unused user profile suggested description is not correct.

Display datetime (if RTC is set) at the beginning of each trace debug message.

A new option on sys_settings page is introduced (Set AUX sensor OTP) that has to be linked with sys_settings_aux_otp page. That page will be also used for clearing OTP tripping.
This protection currently shut down power supply, but we have to change that. It's enough to switch both outputs off.

If possible, add new command (e.g. SIM:GUI:MIN and SIMU:GUI:DEF to restore) that will resize simulator front panel to TFT display area only. That should simplify taking screenshots that can be used for writing user manual.

We need a central repository of all textual messages except SCPI error messages.

If channels are coupled and balancing is activated (i.e. initially set voltage or current is changed/decreased) when new value is set using step or slider edit, a balanced value will be used as a starting point instead of initally set value.
For example, if voltage was set to 60 V when coupled in series, and balancing corrected it to 30.68 V, later value will we offered as starting point instead of 60 V.

There is no reason why we shouldn't display output value range with taking into account LIMit instead of MAXimum value. For example if CURR:LIM is 3 A on the channel 1 then we should display:

Set Ch1 current [0.00-3.00A]

instead of:

Set Ch1 current [0.00-5.00A]

Compiler report error if CONF_SKIP_PWRGOOD_TEST is set:

sketch/ioexp.cpp: In member function 'bool eez::psu::IOExpander::test()':
ioexp.cpp:124: error: 'struct eez::psu::Channel::Flags' has no member named 'power_ok'
   channel.flags.power_ok = 1;
                 ^
exit status 1
'struct eez::psu::Channel::Flags' has no member named 'power_ok'

Add STEP command for SIMU:LOAD as it is already exists for VOLTage and CURRent. Also it could be added to the SIMU:TEMP.

The *RST command should set channel's temp sensors params to the following values:

SYST:TEMP:PROT CH1|CH2 75
SYST:TEMP:PROT:DEL CH1|CH2 30
SYST:TEMP:PROT:STAT CH1|CH2 ON

Remember selected page on channel basis, e.g. channel settings page/tab or edit output value page/tab.

Implement channel coupling in series and parallel using built in power relays. That require new SCPI commands INSTrument:COUPle:TRACking and introducting some sort of command dispatcher that more then one channel can be controlled as single entity. Also we need a new set of main pages where only one set of output programming and measured values will be displayed with new ranges (up to 80 V and up to 10 A). When channels are coupled in series, output voltage on each channel will be set to half of the programmed value. The same is true for setting current when channels are couple in parallel.
Defining coupling mode via local display we can make a wizard with the following steps:

1. Coupling type (series or parallel)
2. Display instruction that connected load has to be disconnected (We can test that by measuring current on both channel. When test passed set VOLT and CURR on both channel to zero, and disable both outputs)
3. Display instruction which binding posts will be used when channels are coupled (CH1-, CH2+)
4. Finished (power relay and SP_LED are activated, down-programmer on CH2 is unconditionally disabled when coupled in parallel and enable both outputs)

As indication when channels are coupled in series and output voltage is set over 40 V the SP_LED could flash. Additional indication could be warning sign on the local display in that mode.

Special case is entering CC mode when channels are couple in series. It's possible that output voltage on one of the channels become negative. To avoid such condition output voltage leveling is required.

to simplify setup we'll need a first time installation wizard for setting the following:

• touch-screen calibration
• date/time
• Ethernet connection
• calibration password and system password
• channel calibrations
• Load various default user profiles (e.g. +5V, +3.3V, +/-12V, Tracking, Paraller coupling, Series coupling, etc.)

We can also make visible "First time installation wizard" into system settings that user can run it any time. In that case we should take care about already set values (e.g. if we are going to load default user profiles that are different from what is stored into EEPROM).

Create DLL for communication over serial and TCP/IP that will enable Excel with VBA to be used for SCPI programming. Check for an example in the following document:

\BTSync\Manuals\Remote control\Other vendors programming guides\Agilent E364xA (E3646-90001).pdf

LIST SCPI subsystems will require implementation of the triggering system. Therefore the following commands has to be implemented:

*TRG
*WAI
ABORt
INITiate[:IMMediate]
INITiate:CONTinuous
MEMory:LIST:LOAD
MEMory:LIST:STORe
[SOURce[<n>]]:CURRent:MODE
[SOURce[<n>]]:CURRent[:LEVel]:TRIGgered[:AMPLitude]
[SOURce[<n>]]:LIST:COUNt
[SOURce[<n>]]:LIST:CURRent[:LEVel]
[SOURce[<n>]]:LIST:DWELl
[SOURce[<n>]]:LIST:VOLTage[:LEVel]
[SOURce[<n>]]:VOLTage:MODE
[SOURce[<n>]]:VOLTage[:LEVel]:TRIGgered[:AMPLitude]
TRIGger[:SEQuence]:DELay
TRIGger[:SEQuence]:SOURce

EEZ PSU SCPI reference guide.zip

Store and retrieve lists from SD card. If SD card is not installed or not present/formatted we have to return an error. Allow only basic operation with SD card: saving and retrieving one LIST per user profile. More comprehensive support for SD card will be addressed in #88.

Make necessary adjustment that displaying output values with three digits are correct. That should be done in one of the following ways:

1. Resize big font
2. Use smaller font for V and A
3. Use smaller font for displaying decimal numbers

Add software reset in initialization of SPI devices when applicable (for example set RESET register on ADS1120 for that).

Few possible useful links:
http://forum.arduino.cc/index.php?topic=343944.0
http://www.freetronics.com.au/pages/how-to-upload-a-sketch-to-your-arduino-via-a-network#.V3-v_u3SrMQ
http://playground.arduino.cc/EthernetBootloader/EthernetBootloader

GitHub:
https://github.com/codebendercc/Ariadne-Bootloader
https://github.com/mharizanov/TFTPBootloader_0_2
https://github.com/esmil/arduino-netboot
https://github.com/fullaware/arduino-tftpboot

Add support for W5500 in eez_psu_lib (currently only the enc28j60 is supported).

Existing power up self-test procedure does not include TLC5925 testing since its not possible to get feedback from that IC. Nevertheless we can add new option under system settings for turning on and off all it's outputs sequentially that user could visually test if all LEDs are working (here we can draw front panel and indicate which LED or relay is currently turned on).

When this procedure is started both channel's output must be disabled and output values set to zero!

Ethernet connection seems to freeze after some time with Mega. That could be 15 minutes or half an hour. When that occurs, firmware is still responsive via serial. Lost Ethernet connection is not possible to establish even after hard reset. If reset is activated, firmware immediately reports the following error on serial console:

EEZ PSU serial com ready
**TRACE: EEPROM test failed at index: 1
**ERROR: 240,"External EEPROM test failed"

... and when Ethernet connection timeout is happened usually another failure on RTC is reported:

**TRACE: Ethernet initialization started...
**TRACE: Ethernet initialization failed!
**TRACE: RTC test failed Control 1: w=8, r=0
**ERROR: 250,"RTC test failed"

I never noticed similar problem with Due board. I have to find out where is a problem in Arduino shield or Ethernet library when working with Mega.
It's interesting that only complete power off of the power supply restore Ethernet connection.
DIAG:TEST? returns the following data:

"0, EEPROM, installed, failed",
"0, Ethernet, installed, failed",
"0, RTC, installed, failed",
"2, DateTime, installed, skipped","2, BP option, installed, skipped",
"1, CH1 IOEXP, installed, passed","1, CH1 DAC, installed, passed",
"1, CH1 ADC, installed, passed","1, CH2 IOEXP, installed, passed",
"1, CH2 DAC, installed, passed","1, CH2 ADC, installed, passed"

Fan speed measurement is frequently returns false value. Possible cause is short measurement time that is probably interrupted by other task.

Currently, screen calibration data for three points are validated at the end of the calibration. We have to do that during the calibration process and inform user if data is not as expected (out of range or even equal that can be caused by some problem in communication with touchscreen controller).

A warning message can be displayed for few seconds on the screen if such thing is happened like: "Received data is invalid due to imprecise pointing or communication problem"

If SYST:POW 1 command is executed with load connected it will generate:

**ERROR [2016-10-27 11:05:11]: -242,"CH1 fault detected"
**TRACE [2016-10-27 11:05:12]: Ch1 PWRGOOD bit changed to 0

Going back from stand-by mode initiated from local console works fine.

Use 312,"Cannot execute when the channels are coupled" error (instead of -200) when one of the following SCPI commands is send when channels are coupled:

• CAL
• LRIP (SERial only)
• VOLT:PROG
• VOLT:SENS (SERial only)
• SIMU:RPOL
• SIMU:VOLT:PROG:EXT

Few rare situations are detected when RTC read returns not allowed values (e.g. number of seconds greated then 59). Add into self-test procedure new test that will address such situations and report an error.

If during power up self-test failed for any reason, outputs of all channels must be disabled.

We have a possible dangerous situation when for auto recall is selected user profile higher then 0. If e.g. that profile sets output to 12 V and after power on user decrease that voltage to 5 V in the next power on (that can be caused by AC blackout) voltage will be set back to 12 V. If output is enabled and load that require 5 V is still connected without proper OCP will be damaged. Therefore on the each power when auto recall is enabled output voltages and currents have to be compared (between profile 0 and selected auto recall profile) and if any difference is detected outputs must be disabled, and warning message like:

Auto-recall values mismatch

When output current is set to zero OCP does not makes sense. It has to be disabled or ignored in that case.

We need to monitor output power and if its go below DP_NEG_LEV that is negative value in Watts (default -1 W), and that condition lasts more then DP_NEG_DELAY seconds (default 5 s), down-programmer circuit has to be switched off.
Also an error 500,"Down-programmer switched off" has to be generated and in Event view a new warning message has to be inserted: DProg is turned off
Turning channel output off and on will return down-programmer circuit into previous state.

System commands such as SYST:DATE or SYST:TIME returns error if PSU is in stand-by mode. There is no reason for that since no channel resources are required for their execution.

Disable further over-temperature tripping when the PSU enters stand-by mode for any reason (that include also previous over-temperature trip).

Hi. I'm having problem with the EEZ using 120V AC main supply, and two SMPS 48V supplies instead of the toroidal transformer. Problem seems to be related with the SMPS to be slower to start under 120Vac, that slow the correct start of both PWR_PCB Pre-Regs and the three digital supplies (+/-5V, 9V). Then the Arduino is doing his startup checks, but doesn't get the replies from the IOEXP and ADC, and put the supply back in Standby, see the USB port trace:

**TRACE [2016-11-18 20:04:48]: PWR_DIRECT -> HIGH
**TRACE [2016-11-18 20:04:48]: Ch1 GPIO 0x0a
**TRACE [2016-11-18 20:04:48]: Ch2 GPIO 0x0a
**TRACE [2016-11-18 20:04:49]: Ch1 GPIO 0x0a
**TRACE [2016-11-18 20:04:49]: Ch2 GPIO 0x0a
**TRACE [2016-11-18 20:04:53]: Ch1 PWRGOOD bit changed to 0
**ERROR [2016-11-18 20:04:53]: -242,"CH1 fault detected"

**TRACE [2016-11-18 20:04:53]: PWR_DIRECT -> LOW
**TRACE [2016-11-18 20:05:04]: PWR_DIRECT -> HIGH
**TRACE [2016-11-18 20:05:04]: Ch1 GPIO 0x0a
**TRACE [2016-11-18 20:05:04]: Ch2 GPIO 0x0a
**TRACE [2016-11-18 20:05:05]: Ch1 GPIO 0x0a
**TRACE [2016-11-18 20:05:05]: Ch2 GPIO 0x0a
**TRACE [2016-11-18 20:05:09]: Ch1 PWRGOOD bit changed to 0
**ERROR [2016-11-18 20:05:09]: -242,"CH1 fault detected"

**TRACE [2016-11-18 20:05:09]: PWR_DIRECT -> LOW

If both PWR_PCB are supplied by an external 48V supply before the EEZ is taking out of standby, then the supply reports no fault, and it is working correctly. Maybe there is the need to add some delay into the code, before doing the selfchecks to let the time for the PWR_PCB supplies to stabilize at startup.

We need some faster mean of positioning while editing text strings (e.g. profile name, or calibration remark). Also "Delete" key on the keyboard should has autorepeat feature.

Simulated states such as SIMU:PRWGOOD 0 and DEBUG:WDOG 0 should be cleared after the PSU enters stand-by due to generated error

Two system-wide protection feature has to be added:

1. Switch off all outputs when protection tripped (see OUTPut:PROTection:COUPle)
2. Shutdown when protection tripped (see SYSTem:POWer:PROTection:TRIP)
3. Force disabling of all outputs on power up (see SYSTem:PON:OUTPut:DISable)

Use sys_settings_protections page to access them on the local console

When calibration page is selected we have to go back to main if no activity is detected for GUI_BACK_TO_MAIN_DELAY seconds. Other possibility is to switch off outputs on both channel when calibration wizard is started.

We have to add channel tracking now when channel coupling infrastructure is added. For SCPI control we have to implement OUTPut:TRACk[:STATe]. For local control we can follow the layout for channel coupling and use different info text like "[Warning sign] Channels tracking active"

The name of the MAIN sensor is misleading. People thinks of it as one that is in charge for fan speed control what is not the case. It's optional and can be used for monitoring e.g. main transformer or temperature inside enclosure. We need to change that in SCPI and GUI

Replace in bar graphs max. value with limited value. Red line used to indicate limit is no longer needed.

According to author of UTFT hosting of any variant of his library is a crime, and since UTFT_Pro is removed from the GitHub we have to remove UTFT_Pro from our distribution and forward users to download library from his site. That will also require the following changes in lcd.cpp:

#define TFT_320QVT_9341 CTE32_R2

Remove all other libraries from the project and do the following:

• Open a new project for eez_psu_lib
• Create fork within eez-open project for Ethernet2, scpi-parser and UIPEthernet
• Write help file how to collect libraries for that firmware can be successfully compiled

When latest UTFT library is used, screen colors looks "weird" and vertical (scan?) lines are clearly visible on the background color that was not hte case with UTFT_Pro. Maybe some user will find that unattractive and would like to stick with UTFT_Pro. Therefore we should allow firmware compilation with both UTFT and UTFT_Pro. Other possibility is to invest some time and find out how UTFT_Pro works with display that colors looks more appealing.

Another path for ILI9314 based displays is to try to use Adafruit library that is completely open source (MIT license).

Currently *RCL returns error -200 if selected profile does not exist. It has to be replaced with more specific error. Use: 400,"Cannot load empty profile"