This is machine translation

Translated by Microsoft
Mouseover text to see original. Click the button below to return to the English version of the page.

Note: This page has been translated by MathWorks. Click here to see
To view all translated materials including this page, select Country from the country navigator on the bottom of this page.

Operating Point Behavior

Learn how you can use operating point with a block, S-functions and model changes.

Change the States of a Block Within Operating Point

  • Use loggedStates to get or set the states of blocks. If xout is the state log that Simulink® exports to the workspace, then the loggedStates field has the same structure as xout.signals.

  • You cannot change the states that are not logged. Simulink does not allow this modification as it could cause the state to be inconsistent with the simulation.

S-Functions

You can use APIs for C-MEX and Level-2 MATLAB® S-functions to enable S-functions to work with the ModelOperatingPoint object. For information on how to implement these APIs within S-functions, see S-Function Compliance with the ModelOperatingPoint.

S-functions that have PWork vectors, which store pointers to data structures but do not declare their operating point compliance level or declare it to be unknown or disallowed do not support operating point. For more information, see S-Function Compliance with the ModelOperatingPoint.

Model Changes and Operating Point Restore

After saving the operating point of a model, you can change the model and restore an operating point with those changes

  • You can rename a model between saving and restoring its operating point.

  • The operating point interface checksum is primarily based on the configuration settings in a model and sample times used in the model. You can make some nonstructural changes to the model between saving and restoring an operating point. In the Configuration Parameters dialog box, in the Diagnostics pane, use the Operating point interface checksum mismatch diagnostic to track such changes. You can then find out if the interface checksum of the restored operating point matches the current interface checksum. See Operating point interface checksum mismatch.

    You can make the following nonstructural changes to the model without affecting your ability to restore a previously saved operating point:

    Note

    These modifications may change the number of sample times in the model. This can cause the model's interface checksum to be different from the operating point save and restore checksum. Configure the Operating point interface checksum mismatch diagnostic to display a warning (default), error, or none to not compare the checksums.

  • You cannot make structural changes to the model between the time you save the operating point and the time you restore the simulation using the operating point. Examples include, adding or removing a block after saving the operating point, changing the sample time of a model, and changing the type of solver from variable-step to fixed-step.

  • Mismatches can occur when you try to simulate using a solver that is different from the one that generated the saved operating point. Simulink permits solver changes. For example, you can use the ode15s solver to solve the initial stiff portion of a simulation and save the final operating point. You can then continue the simulation with the restored operating point using ode45. In other words, this diagnostic helps you see the solver changes but does not signal a problem with the simulation.

Note

When you use a variable-step solver with the maximum step size set to auto, Simulink uses the maximum step size from the restored ModelOperatingPoint object for the new simulation. To ensure that the concatenated operating point trajectory of two simulations matches that of an uninterrupted simulation, specify a value for the maximum step size.

Limitations of Saving and Restoring Operating Point

Note

In some cases, saving partial state information avoids some of the limitations of using operating point. For a comparison of the two ways to save state data, see Comparison of Operating Point and Final State Logging.

Block Support

The following blocks do not support operating point:

  • In the Stack and Queue blocks, the default setting for the Push full stack option is Dynamic reallocation. This default setting does not support ModelOpeartingPoint object. Other settings (Ignore, Warning and Error) support ModelOperatingPoint object.

  • Simscape™ Multibody™ First Generation blocks

Simulink tries to save the output of a block as part of an operating point. For S-functions, this happens even if the functions declare that no operating point is required. If the block output is of custom type, Simulink cannot save the operating point and displays an error. For more information about operating point use with S-functions, see S-Functions.

Model reference offers partial support for operating point. For details, see Model Referencing.

Simulation

  • You can use only the normal or the accelerator simulation mode.

  • You cannot save operating point in normal mode and restore it in accelerator mode, or vice versa.

  • You cannot change the states of certain blocks that are not logged. For more information, see Change the States of a Block Within Operating Point.

Code Generation

The operating point feature does not support Simulink Coder™ or Embedded Coder® code generation.

Model Referencing

  • You cannot modify logged states of blocks that are inside a referenced model in accelerator mode.

  • The following blocks do not support operating point when included in a model referenced in accelerator mode:

    • Level 2 MATLAB S-Function

    • MATLAB System

    • n-D Lookup Table

    • S-Function (with custom operating point or PWork vectors)

    • To File

    • Simscape blocks

For additional information, see State Information for Referenced Models.

Model Function

You cannot input the operating point to the model function.

Related Topics