Cascades in fieldbus follow a strict, yet 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. 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.
|
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).