programmatically collect sim errors

I would like to collect up the errors and warnings related to a model simulation. Help docs have run me down the sldiagviewer.diary rabbit hole to record such to a diary file. (Looking for a better solution here as this is just plain klunky). The sldiagviewer doesn't collect the errors when using the sim function however. Weird and why doesn't the sim command return errors? So I use the set_param function to 'push' the run button. That collects in the diary file but one of simulink's annoying features is that the .m file doesn't wait for the sim command to complete (please don't suggest a pause timer) so when I go to close, the close_system fails. I do see a 'wait' associated w/yet another rabbit hole known as Simulink.Simulation.Job but I gotta think there's a better way.

Thanks,

-Chris

Answer 1

[Paul]

Using the sim command, simulation warnings are captured in the SimulationMetaData.ExecutionInfo of the output of the sim command. I ran a simulation that generated two divide by zero warnings:

>> out = sim('untitled');
>> out.SimulationMetadata.ExecutionInfo.WarningDiagnostics.Diagnostic

ans = 

  MSLDiagnostic with properties:

    identifier: 'Simulink:blocks:DivideByZero'
       message: 'Division by zero in 'untitled/Math Function''
         paths: {'untitled/Math Function'}
         cause: {}
         stack: [0×1 struct]


ans = 

  MSLDiagnostic with properties:

    identifier: 'Simulink:blocks:DivideByZero'
       message: 'Division by zero in 'untitled/Math Function1''
         paths: {'untitled/Math Function1'}
         cause: {}
         stack: [0×1 struct]

I'm pretty sure that error messages will be captured in the ErrorDiagnostics field

>> out.SimulationMetadata.ExecutionInfo

ans = 

  struct with fields:

               StopEvent: 'ReachedStopTime'
         StopEventSource: []
    StopEventDescription: 'Reached stop time of 10'
         ErrorDiagnostic: []
      WarningDiagnostics: [2×1 struct]

See Simulink.SimulationMetadata for more info.

[checker]

Thanks Paul for your response. I was getting curiously different results using sim on friday (only model outputs returned, no structure) but it was a long and frustrating day. So a revisit today and sim doesn't return anything if the model is considered "unsim-able". Using a model that passes a float32 inport to a uint32 outport yeilds the following:

>> out=sim(gcs);

Error due to multiple causes.

Caused by:

Data type mismatch. 'Input Port 1' of 'untitled/Outport' expects a signal of data type

'uint32'. However, it is driven by a signal of data type 'single'.

Data type mismatch. 'Output Port 1' of 'untitled/Inport' is a signal of data type 'single'.

However, it is driving a signal of data type 'uint32'.

>> out

Unrecognized function or variable 'out'.:

Using the set_param and sldiagviewer does capture the error but I'm stuck w/the timing issue described in my original post. Now I remember why I was frustrated!

[Paul]

I'm not following the workflow.

Regarding this: "So I use the set_param function to 'push' the run button. That collects in the diary file but one of simulink's annoying features is that the .m file doesn't wait for the sim command to complete (please don't suggest a pause timer) so when I go to close, the close_system fails."

Which .m file are we talking about here? The .m file in which you're runing the the set_param function(s)? But if that's the case, how does the sim command come into play?

I don't know anything about sldiagviewer. At the risk of sounding silly, you can always use diary to capture output to the Command window to a text file if all that's needed to see what that output is.

Looks like Simulink.Simulation.Job is only applicable if you use the batchsim command. But if you go down that path, the Simulink.Simulation.Job does have a diary method that will show the Command window output from when the job was run. At least that's what the doc says; I've not tried it.

[Paul]

Or maybe a try/catch block will suffice?

>> try,sim(gcs),catch ME, ME, end

ME = 

  MSLException with properties:

       handles: {1×0 cell}
    identifier: 'MATLAB:MException:MultipleErrors'
       message: 'Error due to multiple causes.'
         cause: {2×1 cell}
         stack: [0×1 struct]
    Correction: []

>> ME.cause

ans =

  2×1 cell array

    {1×1 MSLException}
    {1×1 MSLException}

>> ME.cause{1}

ans = 

  MSLException with properties:

       handles: {[4.0360e+03]}
    identifier: 'Simulink:DataType:InputPortDataTypeMismatch'
       message: 'Data type mismatch. 'Input Port 1' of 'checkersim/Out1' expects a signal of data type 'uint32'. However, it is driven by a signal of data type 'single'.'
         cause: {}
         stack: [0×1 struct]
    Correction: []

>> ME.cause{2}

ans = 

  MSLException with properties:

       handles: {[2.2090e+03]}
    identifier: 'Simulink:DataType:OutputPortDataTypeMismatch'
       message: 'Data type mismatch. 'Output Port 1' of 'checkersim/In1' is a signal of data type 'single'. However, it is driving a signal of data type 'uint32'.'
         cause: {}
         stack: [0×1 struct]
    Correction: []

[checker]

The .m file is one being modified along the way. I tried the sim command w/o success so then commented out that portion and replaced it w/the set_param approach.

Thanks for the try/catch w/the sim command. It's an improvement over my current solution with is a try/catch using the set_param command and (to my shame) a pause.