This is machine translation

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

Note: This page has been translated by MathWorks. Please click here
To view all translated materals including this page, select Japan from the country navigator on the bottom of this page.

Function-Call Feedback Latch

Break feedback loop involving data signals between function-call blocks


Ports & Subsystems


Use the Function-Call Feedback Latch block to break a feedback loop of data signals between one or more function-call blocks. Specifically, break a loop formed in one of the following ways.

  • When function-call blocks connect to branches of the same function-call signal

    Place the Function-Call Feedback Latch block on the feedback signal between the branched blocks. As a result, the latch block delays the signal at the input of the destination function-call block, and the destination function-call block executes prior to the source function-call block of the latch block.

  • When the loop involves parent and child function-call blocks, where the child initiator is inside the parent

    Place the Function-Call Feedback Latch block on the feedback signal between the child and the parent. This arrangement prevents the signal value, read by the parent (FCSS1), from changing during execution of the child. In other words, the parent reads the value from the previous execution of the child (FCSS2).

Using the latch block is equivalent to selecting the Latch input for function-call feedback signals check box on the Inport block in the destination function-call subsystem. However, an advantage of the latch block over the dialog parameter is that one can design the destination function-call subsystem (or model) in a modular fashion and then use it either in or out of the context of loops.

The Function-Call Feedback Latch block is better suited than the Unit Delay or Memory blocks in breaking function-call feedback loops for the following reasons:

  • The latch block delays the feedback signal for exactly one execution of the source function-call block. This behavior is different from the Unit Delay or Memory blocks for cases where the function-call subsystem blocks may execute multiple times in a given simulation step.

  • Unlike the Unit Delay or Memory blocks, the latch block may be used to break loops involving asynchronous function-call subsystems.

  • The latch block can result in better performance, in terms of memory optimization, for generated code.

Data Type Support

The Function-Call Feedback Latch block accepts real or complex signals of the following data types:

  • Floating point

  • Built-in integer

  • Fixed point

  • Boolean

  • Enumerated

In addition, the latch block accepts bus signals provided that they do not contain any variable-sized signals.

This block does not accept:

  • Function-call signals

  • Action signals

  • Variable-sized signals

For more information, see Data Types Supported by Simulink in the Simulink® documentation.


In the following model, a single function-call subsystem output serves as its own input.

A more complex case occurs when a merged signal serves as the input to a function-call subsystem. Latching is necessary if one of the signals entering the Merge block forms a feedback loop with the function-call subsystem. In this example, one of the output signals from FCSS2 combines with the output of an Enabled Subsystem block and then feeds back into an inport of FCSS2.


Data Types

Double | Single | Boolean | Base Integer | Fixed-Point | Enumerated | Bus

Sample Time

Inherited from driving block

Direct Feedthrough


Multidimensional Signals


Variable-Size Signals


Zero-Crossing Detection


Code Generation


Introduced in R2011a

Was this topic helpful?