Handle missing time/source values for stepped simulations

[PeterFeicht]

The attached .raw file contains four steps of a DC Sweep (.dc) simulation from two separate .step commands. The number of data points is not divisible by 4, because in some of the steps the last source value is missing.

I have no idea why LTspice would save the data this way, but we should try to handle this case nonetheless. I also don't know whether this can occur for Transient (.tran) simulations, but the handling is the same in any case.

[neil538]

I have the same problem when using LTspice2Matlab to read .raw file from .tran with .step. I looked at the ascii file. Although the time span (defined by me) is the same for all the steps in my simulation, the number of time points is different for the 3 steps. I think this is why LTspice2Matlab breaks down (not divisible by steps as you mentioned). Not sure how LTspice sets the number of points in time.

I worked around on this with the ascii file. Since the time span is the same for all steps, I find the start time (min) and end time (max) and parse the data for each step without doing division by the number of steps. I only did ascii file. Hope LTspice2Matlab can work this out.

[reserschnell]

I have the same problem when using LTspice2Matlab to read .raw file from .tran with .step. I looked at the ascii file. Although the time span (defined by me) is the same for all the steps in my simulation, the number of time points is different for the 3 steps. I think this is why LTspice2Matlab breaks down (not divisible by steps as you mentioned). Not sure how LTspice sets the number of points in time.

I worked around on this with the ascii file. Since the time span is the same for all steps, I find the start time (min) and end time (max) and parse the data for each step without doing division by the number of steps. I only did ascii file. Hope LTspice2Matlab can work this out.

Hi neil538,

I have the same issue and I've created a workaround. The problem is for me that LTSpice selects different time steps for the different simulations. First I tried to manipulate this in LTSpice with the print arguments in the following command but it doesn't work. The raw file was not changed by this: .tran {print_step} {print_stop} [print_start [dTmax]] [modifiers] In my workaround I detect every simulation run and resample the simulation data at fixed time steps and in this way I generate simulation runs with equal length. In my opinion this is not the best solution but it works without changing the returned data type. If you like I can provide this solution in a fork and you can pull it. It's no solution for the DC Sweep topic, but maybe I can have a look as well.

A better way would be to change the returned data type for time simulation data to Time Table. Advantage:

• Working with this data type is unified
• Different experiments can have different length
• Great support from Mathworks Disadvantage:
• Can only be used with Matlab >= R16b

I can create a feature request and we can have this version in a fork with a clear statement that at least R16b is required.

Looking forward to your reply.

Regards

Andreas

[NasimMM]

There's a similar patch of code around line 697 for the ascii setting that throws up the same reshape error. Replacing those 3 lines with reserschnell's workaround seems to fix the issue.

[lucasvl]

Hi all, I fixed it for my simulations by creating a struct in stead of a array. Struct handles the different data length per step in stepped simulations without problems. It is not very pretty, but I think it may be useful for others as well. Shall I create a pull-request? Thanks @PeterFeicht for updating LTspice2Matlab to work with XVII, I am using your file (with my small edit) extensively!