Timestamps of xml-rpc log vs scope exported csv timestamp

PLECS
1

I am running into a repeatable issue regarding sampling behavior when using variable-step solvers and XML‑RPC automation in PLECS Standalone. I would appreciate your insights on whether this is expected behavior or if there is a configuration I am missing.

Simulation Setup

  • PLECS Standalone

  • Solver Type: Variable-step

  • Solver: RADAU (stiff)

  • PWM Frequency: 33 kHz (generated inside a DLL that interacts with the control model)

  • Simulation is automated via XML‑RPC and waveforms are exported to CSV after each run.

Case 1 — CSV exported via XML‑RPC (sim.capture(...))

When running the simulation through automation and exporting scope data to CSV using XML‑RPC or the sim.capture() API, I get:

  • non‑uniform timestamps

  • Δt changes at every sample (as expected from variable-step integration)

  • Eg : time: 0, 1.2e‑6, 2.7e‑6, 3.0e‑6, 9.8e‑6, 10.1e‑6, …

This means the solver’s actual variable step sizes are being captured.

This causes a problem because I cannot directly compute an FFT unless I resample the data myself.

Case 2 — CSV exported from PLECS Scope GUI

If I run the simulation normally and then:

  1. Open a PLECS Scope

  2. Load the trace

  3. File → Export → CSV

Then the exported CSV contains:

  • perfectly uniform time steps

  • exactly 30 μs per sample, matching the fundamental sampling period I expected

  • Eg : 0, 30e‑6, 60e‑6, 90e‑6….

This CSV is FFT‑friendly without resampling.

1. Why does XML‑RPC scope capture produce variable-step timestamps, while the PLECS Scope GUI exports a uniformly sampled CSV?

Is the Scope GUI applying internal resampling before exporting?

2. Is there an XML‑RPC API option that allows me to export the uniformly sampled waveform exactly the same way the Scope GUI does?

3. What is the recommended method to obtain FFT‑compatible, uniformly sampled data when running PLECS in variable-step mode through automation?

I want to avoid:

  • manually interpolating large CSV files in Python

  • switching to fixed-step (the model runs significantly slower at required sub‑microsecond steps due to the DLL generating 33 kHz PWM)

Additional Notes

I attempted to use the “Variable Integration / Sample-Hold” block to enforce a fixed 30 µs sampling rate, but this only samples the signal, not the scope time grid.

The main goal is to replicate exactly the same uniformly-sampled CSV that PLECS GUI exports — but programmatically.

2

Hi vishweshgm
As a general remark, it is always helpful to post a model that demonstrates your issue. Without this, I can only make more or less educated guesses about your two cases.

Case 1

First of all, the command sim.capture() is not part of the PLECS API but appears to come from some third party tool. I can only assume that internally it uses the plecs.simulate() command from the PLECS RPC interface. The documentation for this command says:

By default, the simulation result contains all simulation steps that the solver makes. This can be controlled with the solver options OutputTimes and OutputTimesOption , where OutputTimes is a double vector and OutputTimesOption is a string as described in Tab. 19.

To get evenly-spaced output from your sim.capture() command, you’ll need to find a way to pass in the OutputTimes parameter with the desired time stamps.

Case 2

It appears that the scope uses a discrete (fixed-step) sample time because

  • you explicitly specified a discrete sample time in the scope settings, or
  • you feed only signals with a fixed-step discrete sample time into the scope, and hence it inherits this sample time.

Either way, the scope will record only samples at these discrete time steps, and so the CSV data will be evenly spaced.