element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Test & Tools
  • Technologies
  • More
Test & Tools
Blog Programmable Electronic Load - SCPI interface and Error Handling
  • Blog
  • Forum
  • Documents
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Test & Tools to participate - click to join for free!
  • Share
  • More
  • Cancel
Group Actions
  • Group RSS
  • More
  • Cancel
Engagement
  • Author Author: Jan Cumps
  • Date Created: 10 Oct 2020 6:56 AM Date Created
  • Views 2422 views
  • Likes 3 likes
  • Comments 3 comments
  • electronic_load
  • scpi
Related
Recommended

Programmable Electronic Load - SCPI interface and Error Handling

Jan Cumps
Jan Cumps
10 Oct 2020

This blog documents focuses on the SCPI functionality of the electronic load that Robert Peter Oakes, jc2048 and Jan Cumps designed.

image

The interface works with software that can do serial communications on a COM port.

This project comes with a LABView driver and 2 proto GUIs.

 

SCPI Interface

 

SCPI CommandstatusSCPI standardCommentExample
*IDN?worksStandard SCPI, implemented by librarycallsignTHEBREADBOARD,ELECTRONICLOAD,0,01.00
*CLScheckStandard SCPI, implemented by library
SYST:ERR?worksStandard SCPI, implemented by library
SYST:ERR:COUN?worksStandard SCPI, implemented by library
SYST:VERS?worksStandard SCPI, implemented by librarySCPI Standard version1999.0
*RSTworksStandard SCPI, custom implementation neededreset to a  known status.
Switch input off and set to constant current mode. Does not alter stored or temporary calibration settings.
*ESEcheck
*ESE?check
*ESR?check
*OPCcheck
*OPC?check
*SREcheck
*SRE?check
*STB?check
*TST?todoStandard SCPI, custom implementation neededTest instrument. Currently does nothing
*WAIcheck

<read voltage>

MEASure:VOLTage:DC?

worksQuery the voltage on the voltage sense inputs.

<read current>

todo

<set mode constant current, constant resistance, what have you, ...>

[:SOURce]:FUNCtion

 

values:

CURRent

RESistance

VOLTage

POWer

wipset the constant regulation mode

On reset, always constant current

At this time supports constant current

FUNC CURRent

FUNC RESistance

FUNC VOLTage

FUNC POWer

[:SOURce]:FUNCtion?wipget the constant regulation modeAt this time supports constant currentFUNC?

[:SOURce]:INPut[:STATe] <b>

worksSet the input state to ON or OFF

INP ON

INP OFF

[:SOURce]:INPut[:STATe]?works

Query the input state

INP?
<limits>todo
DEVElop:DAC# <16 bit value>works for DAC1Development low levelSend the passed value to the DAC. Currently only for the first DAC

DEVE:DAC1 2000

DEVE:DAC1 #H4000

DEVElop:ADC#?

DEVElop:ADC#:RAW?

DEVElop:ADC#:VOLTage?

works for ADC1Development low levelRetrieve the last buffered ADC value. Currently only for ADC 1 - 3

DEVE:ADC1?

DEVE:ADC2:RAW?

DEVE:ADC3:VOLT?

[:SOURce]:CURRent[:LEVel][:IMMediate]worksConstant Current ModeCurrently accepts RAW DAC value instead of a voltage

CURR 5

[:SOURce]:CURRent[:LEVel][:IMMediate]?works

Retriev@e the set current level

CURR?
[:SOURce]:VOLTage[:LEVel][:IMMediate]todoConstant Voltage ModeWIP. Mode not implemented yetVOLT 2
CALibratewipCalibration and Configurationdocumented here: Programmable Electronic Load - Calibration Steps

 

For ref: this is what typical instrument (DMM) commands look like

We may want to check the commands of a few existing loads, to see if there's a pattern or standard

 

    /* DMM */
    {.pattern = "MEASure:VOLTage:DC?", .callback = DMM_MeasureVoltageDcQ,},
    {.pattern = "CONFigure:VOLTage:DC", .callback = DMM_ConfigureVoltageDc,},
    {.pattern = "MEASure:VOLTage:DC:RATio?", .callback = SCPI_StubQ,},
    {.pattern = "MEASure:VOLTage:AC?", .callback = DMM_MeasureVoltageAcQ,},
    {.pattern = "MEASure:CURRent:DC?", .callback = SCPI_StubQ,},
    {.pattern = "MEASure:CURRent:AC?", .callback = SCPI_StubQ,},
    {.pattern = "MEASure:RESistance?", .callback = SCPI_StubQ,},
    {.pattern = "MEASure:FRESistance?", .callback = SCPI_StubQ,},
    {.pattern = "MEASure:FREQuency?", .callback = SCPI_StubQ,},
    {.pattern = "MEASure:PERiod?", .callback = SCPI_StubQ,},

 

Error Handling

 

SCPI

good example: https://github.com/eez-open/psu-firmware/tree/master/eez_psu_sketch, in particular https://github.com/eez-open/psu-firmware/blob/master/eez_psu_sketch/scpi_user_config.h

Complete list: SCPI Errors

e.g.: this can be used to report an invalid function call (set constant voltage value when in constant current mode, ...):

 

-221

std_settingsConflict

Settings conflict - Indicates that a legal program data element was parsed but could not be executed due to the current device state.

 

catch in the SCPI interface:

missing parameter

parameter out of bounds

index out of bounds

 

- a non-implemented ADC channel:

DEVE:ADC5?
SYST:ERR?
-131,"Invalid suffix"

 

- a missing DAC value:

DEVE:DAC2
SYST:ERR?
-109,"Missing parameter"

 

- more than 16 bits to the DAC:

DEVE:DAC1 66666
SYST:ERR?
-224,"Illegal parameter value"

  • Sign in to reply

Top Comments

  • Andrew J
    Andrew J over 4 years ago +1
    Hi Jan, can I just confirm something: DEVelop: is a command very specific to your implementation? It seems not unreasonable to define your own SCPI commands outside the common set where they don't exist…
  • Jan Cumps
    Jan Cumps over 4 years ago in reply to Andrew J +1
    Yes, I named all commands that were for development / debug purpose DEVElop. For the DACs, I used it to send raw values. For the ADC, I used the handles to get raw data and conversion without calibration…
  • Andrew J
    Andrew J over 4 years ago in reply to Jan Cumps +1
    I think TEST might be a good one too - that seems undefined beyond the top level subsystem name and down to the instrument itself.
  • Andrew J
    Andrew J over 4 years ago in reply to Jan Cumps

    I think TEST might be a good one too - that seems undefined beyond the top level subsystem name and down to the instrument itself.

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Jan Cumps
    Jan Cumps over 4 years ago in reply to Andrew J

    Yes, I named all commands that were for development / debug purpose DEVElop.

    For the DACs, I used it to send raw values. For the ADC, I used the handles to get raw data and conversion without calibration corrections.

    For the normal commands, I consulted the development guide of commercial loads and digital meters.

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Andrew J
    Andrew J over 4 years ago

    Hi Jan,

    can I just confirm something:  DEVelop:  is a command very specific to your implementation?  It seems not unreasonable to define your own SCPI commands outside the common set where they don't exist.  I was looking for something to, say, set voltage to a raw value for a DAC (e.g. 32768) rather than a specific voltage (e.g. 2.5[v]).

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube