Automating a DC Power Supply: SCPI, Modbus-RTU and CANopen

Three protocols, three jobs

The same supply usually speaks all three; the question is which one fits your control stack.

• SCPI (Standard Commands for Programmable Instruments) is the human-readable, text-based language of bench and rack instrumentation. It runs over LAN (often via VISA/sockets) or serial and is the natural choice when your test framework is Python, LabVIEW or any PC-based sequencer. Verbose but self-documenting.
• Modbus-RTU is a compact register-based protocol over RS-485/RS-232. It shines when the supply is one node among PLCs and industrial controllers, where deterministic polling of holding and input registers matters more than readability.
• CANopen rides on the CAN bus and is the right tool inside automotive and battery-test rigs, where the supply must share a deterministic, multi-drop bus with cyclers, BMS units and other ECUs using PDOs and SDOs.

A useful rule of thumb: PC-driven lab automation → SCPI; factory/PLC integration → Modbus; embedded automotive/BMS bus → CANopen.

Example SCPI commands

SCPI is hierarchical and case-insensitive (short forms shown in capitals). A minimal session to set 400 V at a 10 A limit, enable the output, then read back actual values, looks like this:

*IDN? — identify the instrument
*RST — reset to a known state
SOUR:FUNC VOLT — constant-voltage mode
SOUR:VOLT 400 — set 400 V
SOUR:CURR:LIM 10 — clamp current at 10 A
OUTP ON — enable output
MEAS:VOLT? — read measured output voltage
MEAS:CURR? — read measured output current
MEAS:POW? — read measured power

For a bidirectional supply you also command the sink side, for example setting a negative current limit or a constant-resistance sink:

SOUR:CURR:LIM:NEG 10 — allow up to 10 A of sink (regenerative) current
SOUR:FUNC RES — constant-resistance mode
SOUR:RES 8.5 — emulate an 8.5 Ω load

Always poll SYST:ERR? after a configuration block; an empty error queue is the cheapest insurance in an automated run.

Building sequences for ATE

One-off commands are fine on the bench; ATE needs repeatable sequences with handshaking. A robust pattern:

1. Initialise deterministically. Send *RST, then *CLS to clear status, then configure protection limits (OVP/OCP) before enabling output.
2. Use *OPC? to synchronise. After commanding a ramp or a step, query *OPC? so the controller blocks until the operation completes rather than racing ahead.
3. Read back, do not assume. Confirm each setpoint with the matching MEAS? query and compare against tolerance before scoring a step pass/fail.
4. Drive list/sequence mode on the instrument. For fast multi-step profiles (battery charge-discharge curves, ramps), download the steps into the supply's internal sequencer so timing is governed by the instrument clock, not PC latency.
5. Always re-enter a safe state on exit or fault. Trap errors, set output off, and verify with OUTP?.

The bidirectional platform we reference, the Ultra Power Systems N35500 series, exposes SCPI, Modbus-RTU and CANopen across LAN, RS-232, RS-485 and CAN, so the same physical supply can sit in a Python rack today and a CANopen battery-test bus tomorrow without changing hardware.

Practical interface choices

Beyond protocol, match the transport to the environment. LAN gives the highest throughput and easiest PC integration but needs clean network segmentation in a noisy lab. RS-485 multidrop is robust over long cable runs and tolerates electrical noise, which is why Modbus favours it. CAN is the only one designed from the ground up for deterministic, fault-tolerant multi-node messaging, hence its dominance in vehicle and BMS test cells. When in doubt, prototype the sequence over LAN/SCPI for visibility, then port the validated steps to the production bus.

Frequently asked questions