Cascade Basics

Cascades in FOUNDATION Fieldbus follow a strict if simple set of rules. A cascade is a two (2) way
communication. The driving or master block provides an output that is used as the cascade input by a
lower block commonly referred to as the slave. The slave provides an output that informs the master as to
when its output is being accepted and the limit conditions that exist below it; this output is the back
calculation output. The master reads this input through a back calculation input. (Refer to Advanced Topics
- BKCAL Communications for more information.) For each cascade mode in a block, there is at least one
cascade input and one back calculation output. For each block that is defined as control block, there is at
least one output and one back calculation input.
When the target mode is changed to a cascade mode in the slave, the back calculation output is set with a
substatus of Initialization Requested (IR). Upon seeing IR at the back calculation input, the master sets
Initialization Acknowledge (IA) in its output substatus. The combination of IR in its back calculation output
and IA in its cascade input is the trigger for the slave block to change the actual mode to the cascade. This
logic is generally applicable to all cascade inputs and outputs and cascade modes (Cas, RCas, ROut).
(See below for the exception.) The following figure and table illustrate the initiation and completion of a
cascade with a master target mode of Auto and a slave initial mode of Auto. In fact, the initial slave mode
could be any of the operating modes Man, Auto, RCas, ROut. The master target mode could be Man, Auto,
RCas, ROut, Cas and, as long as the actual mode was not being forced to LO, the logic completes, as
shown in the following figure.

Cascade Configuration
Example Cascade with Auto as Target Mode
Substatus

Mode

Condition

Slave BKCAL
Output

Master OUT

Slave

Master

Cascade Is
Not Possible

Not Invited

Anything

Not Cas

Target: Auto
Actual: IMan

Initialization
Requested by
Slave

Initialization
Requested

Anything but IA

Target: Cas
Actual: Auto

Target: Auto
Actual: IMan

Master Sees
Initialization
Request

Initialization
Requested

Initialization
Acknowledge

Target: Cas
Actual: Auto

Target: Auto
Actual: IMan

Slave Sees
Initialization
Acknowledge

Drops Initialization
Requested and
Changes to Normal

Initialization
Acknowledge

Target: Cas
Actual: Cas

Target: Auto
Actual: IMan

Master Sees
Normal

Normal

Drops Initialization
Acknowledge and
Changes To Normal

Target: Cas
Actual: Cas

Target: Auto
Actual: Auto,
assuming no other
forcing condition.

The exception to the cascade handshaking behavior described above occurs when a CAS_IN or
CAS_IN_D parameter has a NonCascade substatus. This is the case when there is no master control block
providing a GoodCascade status to CAS_IN, but there is a parameter or calculation block providing a
GoodNonCascade status to CAS_IN. In such cases the receiving block does not need to see an
InitializationAcknowledge (IA) on CAS_IN. If the target mode is Cas, the actual mode will change to Cas
immediately if the status on CAS_IN is GoodNonCascade (and nothing else is preventing the actual mode
from climbing