Feature Request: API to retrieve scope signal names via scripting

General
, ,
1

Hello PLECS team,

I’ve been working on automated post-processing scripts that run parallel parameter sweeps and extract loss measurements from scopes using GetCursorData. The workflow works well, but I encountered a significant limitation: there is currently no scripting API to retrieve the signal names displayed in a scope.

The problem:

When using GetCursorData, the returned struct organizes data by plot index and signal index (cursorData{plot}{signal}), but there is no way to programmatically know which signal corresponds to which index. The plecs('get', scopePath) command returns general scope parameters (Name, Axes, TimeRange, etc.) but does not expose signal names.

Current workaround:

The only way I found to obtain signal names is to export the full scope data to a temporary CSV file using ExportCSV, read just the header line, parse the comma-separated names, and then delete the file:

octave

function names = getScopeSignalNames(scopePath)
  tmpFile = 'tmp_scope_header.csv';
  plecs('scope', scopePath, 'ExportCSV', tmpFile);
  fid = fopen(tmpFile, 'r');
  headerLine = fgetl(fid);
  fclose(fid);
  delete(tmpFile);
  % ... parse headerLine to extract names
end

This works but is inefficient — especially for scopes with large datasets or many traces, the entire data is written to disk just to retrieve a single line of metadata. It also creates unnecessary file I/O and temporary files.

Proposed solution:

It would be very helpful to have a dedicated command to query signal information from a scope, for example:

octave

% Option A: return cell array of signal names per plot
names = plecs('scope', scopePath, 'GetSignalNames')
% Returns: { {'Tj HV', 'Tj LV'}, {'SW-HV Current', 'SYNC-LV Current'}, ... }

% Option B: extend 'get' to include signal info
info = plecs('get', scopePath, 'SignalNames')

This would return a nested cell array where the outer index corresponds to the plot number and the inner index corresponds to the signal within that plot — matching the same structure used by GetCursorData.

Why this matters:

When building automated reporting scripts — for example, sweeping multiple operating points and generating loss summary tables or bar charts — it is essential to label results with their actual signal names rather than generic indices like Signal_1, Signal_2. This is especially important in power electronics workflows where scopes may contain many loss signals (Pcond, Psw, etc.) across multiple semiconductor devices, and the mapping between signal index and physical quantity must be reliable and automatic.

A native API would eliminate the file I/O workaround, improve script performance, and make automated post-processing workflows cleaner and more robust.

Thank you for considering this enhancement.