Programmable Electronic Load

Jan Cumps — Sun, 11 Oct 2020 08:05:20 GMT

Current Revision posted to Documents by Jan Cumps on 10/11/2020 8:05:20 AM

Peter, Jon and Jan are building a programmable electronic load. This document is the common design sheet.

It's obviously work in progress. And fun.

We're building a programmable DC load. The focus is on making a real world working instrument.

Hardware and firmware are open source.

20 V, 6 A
SCPI controlled

To keep this document readable, this main post gives an overview of the design.

All detailed explanations are broken out in separate posts.

Hardware

The load design is modular.

Two out of box modules:

MSP432 LaunchPad
LCD Shield (optional)

3 new designs

DAC-ADC module
Analog control module
Power module

DAC-ADC BoosterPack

This module is a generic, isolated DAC / ADC boosterpack. It's the interface between the analog controller and the microcontroller.

It can also be used outside this project, for your other analog - digital conversion needs.

The board design is broken out in a separate post: Programmable Electronic Load - DAC / ADC BoosterPack.

Analog Controller and Driver Board

This is the core of the analog constant current block. Here lives the circuit that will translate desired constant current into the driver signal for the power MOSFET.

It integrates the feedback coming from that power board. This is a closed analog control loop.

There are also components to provide the on-off functionality and buffers/amplifiers for the analog data-points that fly back to the ADC module.

The board, schematics and BOM are documented in Programmable Electronic Load - Analog Controller and Driver Board.

Power Module - the MOSFET Board with Fan

For details of the design of the power stage, check Programmable Electronic Load - Power Stage.

BoosterPack Header Use and Pin Allocation

This info is broken out in a separate post: Programmable Electronic Load - BoosterPack Header Use.

Firmware

Prerequisites:

CCS 8 with MSP432 compiler TI v 16.12.0.STS or >
TI-RTOS for MSP43X, any SimpleLink version
MSP432 LaunchPad (not the black pre-prod because it's out of support)

The firmware is for the MSP432 microcontroller. But the harware can be driven from any controller, processor, PSoC or computer that can deliver i2c and power between 3V3 and 5V.

That includes Arduino, Raspberry Pi, BeagleBone, Warp7, IOT20xx, the ST Neo family, ... As long as they match that voltage range and have I2C master, it 'll work.

The ADC/DAC board takes care that the logic side is galvanicaly isolated from the power side (that is, if you leave the P1 and P2 jumpers open).

The only requirement is that you have a positive supply between 3V3 and 5V, a ground, and I2C signals (the board has I2C pull-ups that connect to the positive supply that you provide. If you don't want that (maybe your dev board already has 'm), leave R1 and R2 off.

ADC, DAC and Enable are all I2C driven.

GITHUB location: https://github.com/jancumps/msp432/tree/master/MSP432_SCPI_ElectronicLoad

download latest source files as a zip : https://github.com/jancumps/msp432/archive/master.zip

doxygen generated API documentation: https://jancumps.github.io/msp432

GIT artifacts don't contain CCS project files, only sources - get a zip with CCS project from the attachments at the end of this document.

SCPI interface and Error Handling

The SCPI commands are documented in this breakout post: SCPI interface.

UART Configuration

Together with SCPI, UART is the programming interface of this instrument.

The approach, and how to compile for USB or TTL, is documented in this breakout: UART.

RTOS and Posix Configuration

The TI-RTOS documentation is in breakout post RTOS Config.

LCD Display

Check here for a detailed explanation: LCD Display

The firmware supports SHARP LCD display,

ADC

I've broken out the ADC description to a separate post, because I'm working on improvements:

Programmable Electronic Load - ADC Firmware

DAC

DAC output is set on command, using RTOS MailBox and messaging.

The payload for a DAC message contains the DAC channel that needs to be set, and the value.

typedef struct MsgDAC {
    uint8_t module;
    uint16_t value;
} MsgDAC;

The DAC task is started by RTOS. It inialises the DAC settings, then waits until it receives a message.

void *threadDAC(void *arg0) {


    MsgDAC d_msg;
    d_daci2cTransaction.writeBuf = d_dactxBuffer;
    d_daci2cTransaction.readBuf = d_dacrxBuffer;
    d_daci2cTransaction.slaveAddress = DAC_I2C_ADDR;
    d_daci2cTransaction.writeCount = 3;
    d_daci2cTransaction.readCount = 0;


    mqd_t mq;
    struct mq_attr attr;


    attr.mq_flags = 0;
    attr.mq_maxmsg = 1;
    attr.mq_msgsize = MSGDAC_SIZE;
    attr.mq_curmsgs = 0;
    mq = mq_open(QUEUE_NAME_DAC, O_CREAT | O_RDONLY, 0644, &attr);


    while (1) {
        ssize_t bytes_read;
        bytes_read = mq_receive(mq, (char *)&d_msg, MSGDAC_SIZE, NULL);


        /* wait for mailbox to be posted by writer() */
        if (bytes_read) {
// ...

The waiting doesn't take processor time. RTOS takes care that it will only get a slice of clock cycles when there is a message.

Two things in the RTOS configuration make this happen:

The mailbox with room for exactly one message, and a receive event.

Because there is usually no message in the mailbox, the execution of the DAC logic becomes inactive at this line:

        bytes_read = mq_receive(mq, (char *)&d_msg, MSGDAC_SIZE, NULL);

When we send a DAC message somewhere else in the code (e.g.: when the user requests a new setting of the electronic load), RTOS reactivates the process and hands over the payload message.

The DAC task sets the output of the requested channel and returns to the point where it waits for a new message.

   while (1) {
        ssize_t bytes_read;
        bytes_read = mq_receive(mq, (char *)&d_msg, MSGDAC_SIZE, NULL);


        /* wait for mailbox to be posted by writer() */
        if (bytes_read) {
            d_dactxBuffer[0] = getAddressFromModule(d_msg.module); // set value direct
            d_dactxBuffer[1] = d_msg.value >> 8; // MSB
            d_dactxBuffer[2] = d_msg.value; // LSB
            if (! I2C_transfer(i2c_implGetHandle(), &d_daci2cTransaction)) {
//                System_printf("I2C Bus fault\n");
//                System_flush();
            }
        }
    }

You select the DAC channel by setting bit 2 and 1 in the control byte (tx_buffer[0]). There's a helper function that gives a correct control record.

// address 7 - 6: 0, load mode 5 - 4: 01 direct from i2c, 3: reserved 0, 2 - 1: channel select, 0: pwr down 0
#define DAC857X_CFG_H0 0b00010000
#define DAC857X_CFG_H1 0b00010010
#define DAC857X_CFG_H2 0b00010100
#define DAC857X_CFG_H3 0b00010110

static const uint8_t array_DAC857X_CFG_H[4] = {DAC857X_CFG_H0, DAC857X_CFG_H1, DAC857X_CFG_H2, DAC857X_CFG_H3};

/**
 * get the hex address for the requested DAC module
 */
uint8_t getAddressFromModule(uint8_t module) {
    return array_DAC857X_CFG_H[module];
}

Bits 7 - 3 and 0 are all fixed.

Input Enable

The functionality to activate and deactivate the load is documented here: Programmable Electronic Load - Input Enable Functionality .

Control Strategies

The firmware uses strategies to handle the different types of load operation (e.g. constant current, constant, voltage, ...).

A strategy is a set of functions that you can plug in, and that together run that particular operation type (this is a c version of the Gang of Four's Strategy Design Pattern).

The goal is to avoid that the firmware is riddled with if or switch statements whenever different behaviour is needed depending on the instrument's mode.

Each operation strategy will have the same set of functions that run the instrument in that mode.

The price to pay is not expensive - speed and memory burden is low. It is a little more complex to understand than the c++ version. Once you step trough it with a debugger, things become clear.

The code also tries to hide that we're using strategies

Currently starting to implement constant current strategy. The more difficult operation types can be added later, one by one, with not too much impact on the existing code across the firmware.

. Only the eload API (see below) knows about it. All code goes via that eload API.

API for the stategies is minimal now:

    controlFunction;
    getMode;
    getChar;

eload API

The eload API offers an abstraction layer for the strategies, so that the rest of the firmware doesn't have to know about it. It simplifies switching operation mode and driving the instrument.

Example: The eload API offers a simple function eloadGetMode() to check what the instrument's current mode is.

eload_mode eloadGetMode() {

    return getControlStrategy()->getMode();

}

In the background, it uses the strategy mechanism to fetch the mode from the currently active strategy and call the implementation function.

return getControlStrategy()->getMode();

The eload API also has the common eload functions that don't need a strategy because they are always valid, regardless of mode.

Calibration and Configuration Data

The functionality to store calibration and configuration data in Flash is described in a separate article: Programmable Electronic Load - Calibration Data in Flash.

The calibration and configuration procedures are documented in Programmable Electronic Load - Calibration Steps

Changes To Standard MSP_EXP432P401R.c

The standard file generated by the TI-RTOS application wizard has defaults for peripherals.

The following has changed: none - I removed this section because with the external ADC/DAC board and the SimpleLink RTOS version, everything is kept standard.

Remote Software

Teminal

Serial communication to the USB UART port.

9600/8/1/None

SCPI is a non-echoing protocol. To make the characters you type show in the Terminal, set Local echo to Force on.

If you also set Local line editing to Force on, you have the opportunity to correct characters in the current line before they are sent to the serial port.

Test:

*IDN?;SYST:ERR:COUN?

Should return

THEBREADBOARD,ELECTRONICLOAD,0,01.00;0

Windows GUI

There are two . A .NET made by Peter, a Java version made by Jan.

The .net GUI supports reading the 4 ADCs, setting one of the DACs abd shoot any SCPI command.

There's a window for SCPI output and a status window that shows SCPI errors.

Source and binary available from https://github.com/thebreadboard/SCPI_DC_LOAD_WIN

www.youtube.com/watch

The Java GUI is made as a POC that cross-platform instrument GUIs are possible.

It allows for switching the load on and off, set constant current and replicate the LCD values.

Additionally, you can requesst error status and run arbitrary SCPI commands.

Programmable Electronic Load - Java GUI Part 1: Basic Functionality

LabVIEW

The instrument comes with a LabVIEW library: Programmable Electronic Load - Write a LabVIEW Library part 1: Initialise Block

www.youtube.com/watch

Related blog
Programmable Electronic Load - Input Enable Functionality
Programmable Electronic Load - Power Stage
Programmable Electronic Load - Temperature Protection
Programmable Electronic Load - DAC / ADC BoosterPack
Programmable Electronic Load - Analog Controller and Driver Board
Programmable Electronic Load - SCPI interface and Error Handling
Programmable Electronic Load - UART
Programmable Electronic Load - RTOS Config
Programmable Electronic Load - Calibration Data in Flash
Programmable Electronic Load - Calibration Steps
Programmable Electronic Load - LCD Display
Programmable Electronic Load - ADC Firmware
Programmable Electronic Load - Current Sense Circuit
Programmable Electronic Load - BoosterPack Header Use
Programmable Electronic Load - ToDo and Done

Robert Peter Oakes articles:
Electronic DC Load - Design and Build to test PSU Project
youtube: Electronic DC Load Design and Testing
youtube: Full Build Analogue DC Load
youtube: Electronic DC Load - Performance Improvements
Raspberry PI 2, Fun with I2C DACs and ADC's

jc2048 articles:
Programmable Electronic Load: Dynamic Behaviour: Part 1 Overview
Programmable Electronic Load: Dynamic Behaviour: Part 2 The Servo Loop
Programmable Electronic Load: Dynamic Behaviour: Part 3 Effect of Output Inductance
Programmable Electronic Load: Dynamic Behaviour: Part 4 Effect of Output Voltage Change
Programmable Electronic Load: Dynamic Behaviour: Part 5 Stability
Programmable Load Build

Jan Cumps articles:
Programmable Electronic Load - ADC and DAC BoosterPack test
Programmable Electronic Load - Analyse the Summing Node Zero Point
Programmable Electronic Load - Measurements Part 1: Control Circuit

Java GUI
Programmable Electronic Load - Java GUI Part 1: Basic Functionality
Programmable Electronic Load - Java GUI Part 2: Support for Current Mode, Input On/Off, Error Log
LabView
Programmable Electronic Load - Write a LabVIEW Library part 1: Initialise Block
Programmable Electronic Load - Write a LabVIEW Library part 2: Read Output Block
Programmable Electronic Load - Write a LabVIEW Library part 3: Close Block
Programmable Electronic Load - Write a LabVIEW Library part 4: Function Set Block
Programmable Electronic Load - Write a LabVIEW Library part 5: Input Control Block
Programmable Electronic Load - Write a LabVIEW Library part 6: Raw DAC Block
Programmable Electronic Load - Write a LabVIEW Library part 7: Raw ADC Block
Programmable Electronic Load - Automating a DC Switcher Efficiency Test with LabVIEW
Programmable Electronic Load - LabVIEW Test Automation: Characterise the Instrument
Programmable Electronic Load - LabVIEW Test Automation: Characterise the Instrument Pt 2: Oscilloscope Measurements
Example LabVIEW Scenario: test a design with a Rigol PSU and a Keithley DMM
TI-RTOS: Switching to the SimpleLink Distribution
Switch from TI-RTOS to SimpleLink POSIX: Threads and Semaphores
Switch from TI-RTOS to SimpleLink POSIX: EEPROM API
Switch from TI-RTOS to SimpleLink POSIX: From MailBox to Message Queue
Switch from TI-RTOS to SimpleLink POSIX: LCD Display Driver
Switch from TI-RTOS to SimpleLink POSIX: Sleep when Idle

Attachments:

community.element14.com/.../pcb_5F00_proto.zip
community.element14.com/.../eload_5F00_v1_5F00_20170227.zip
community.element14.com/.../eload_5F00_1_5F00_2a.zip
community.element14.com/.../bom.ods
community.element14.com/.../MSP432_5F00_SCPI_5F00_ElectronicLoad_5F00_20180102.zip
community.element14.com/.../eload_5F00_power_5F00_20180104.zip
community.element14.com/.../eload.zip
community.element14.com/.../eload_5F00_examples.zip
community.element14.com/.../MSP432_5F00_SCPI_5F00_ElectronicLoad_5F00_20180514.zip
community.element14.com/.../measureefficiency.zip
community.element14.com/.../measureefficiency_5F00_5V_5F00_10V_5F00_600mA_5F00_RAW.zip
community.element14.com/.../MSP432_5F00_SCPI_5F00_ElectronicLoad_5F00_v_5F00_00_5F00_0_5F00_0_5F00_1_5F00_20180914.zip
community.element14.com/.../MSP432_5F00_SCPI_5F00_ElectronicLoad_5F00_20190706.zip

Tags: load_cell, metrology, msp432, ti-rtos, launchpad, laboratory, instrument