Continuing actions assign the value True or False to their operands depending on the status the step has and that of the assignation condition, if present. The continuing action therefore always describes the operand.
Use cases exist where it is necessary that the value is only written to the operand when a step is activated or deactivated. In these cases, storing actions are used. When the step linked to the action is activated or deactivated, the operand for a storing action is written and remains until it is overwritten by another storing action.
This learning phase shows you how to label and apply the storing action when a step is activated or deactivated.
You can use the storing action function if the output of a motor is set in one step and the motor is to remain switched on throughout several steps. In this case, the motor remains switched on until another (saving) action explicitly switches it off.
Fig. 3.89 Storing actions on activation and deactivation of a step
In , step 1 is waiting for advancement to step 2 by S1. Motors M1 and M2 are both switched off.
Fig. 3.90 Mode of action pursued by the storing actions when the step is activated (arrow up)\ and when the step is deactivated (arrow down)
Steps 2-4 are shown in the figure above, and show the storing actions when activated (arrow up on the symbol) and deactivated (arrow down on the symbol) in conjunction with the respective active step. You can see the GRAFCET Studio IO panel on the right. It shows the status of the individual operands during each situation depicted.
Activating step 2:
The storing action M1:= 1 is performed once in step 2 with the rising edge for the step variables. Since the action is defined as a storing action when the step is activated (arrow up), the rising edge for the step for activating the action is evaluated.
For storing actions, assignation to the operand must take place with the assignation operator ":=". This is because any value (valid for the operand) can be written for these actions. For example, a decimal number can be written for digital operands. We will demonstrate this later on in the section.
In this case, the bit operand is assigned a '1', i.e. the value True. The motor M1 is now active and, as you can see below in step 3, continues to remain active (see status in the GRAFCET Studio IO panel).
Activating step 3:
The storing action with the down arrow only takes effect on exiting step 3, i.e. with the negative edge for the step variables. Motor M2 is still not active at this time for this reason.
Activating step 4:
On exiting step 3, motor M2 was set to the value True. On activating step 4, motor M1 with the rising edge for the step, is set by the assignation M1 := 0 to False.
If the transition to step 4 is fulfilled, the transition to the initial step 1 takes place. Therefore, the falling edge for the step variables from step 4 causes the motor M2 with M2 := 0 to be set to False. The initial state from is restored.
Transported parts are to be counted on a belt using a sensor. The sensor S1CounterSignal supplies a pos. edge for each part. This edge should increase the value of the CounterValue in increments of 1.
Fig. 3.91 Diagram of the technology for belt conveyor
The assignation of a value to an operand, taking into account its contents, represents a special form. In the example, the number 1 is added to the contents in CounterValue and the result saved back to CounterValue (step 2).
Fig. 3.92 Use of a storing action\ on activation for implementing a forward counter
When the storing action taken place on activation (e.g. rising edge for the step variable X2), the value of the forward counter with CounterValue := CounterValue + 1 is only increased once on activating the step. Afterwards, the step must be first exited and then activated again.
Fig. 3.93 Storing action on activation in Watch mode
You can see the counting process in . Here, the value of the operand CounterValue is increased on activating step 2 and its contents are now 1.
A transient evolution exists when the transition condition following a step is already fulfilled during transition to the step. This means that the step is not 'permanently' active, but unstable. One also refers to it as the step becoming virtually activated and virtually deactivated.
The GRAFCET shown below may be given.
Fig. 3.94 Example of a transient evolution
The figure on the right shows that the initial step 1 is
active. Furthermore, one can also see that the condition for the
transition following step 2 is already fulfilled, i.e. S2 has
the value True.
As soon as S1 has the value True, the transition from step
1 to step 2 takes place.
However, because the transition condition following step 2 is
already fulfilled as well, the immediate transition from step 2 to step 3 takes place.
The question now is what happens to the actions attached to step 2?
The operand H1 is influenced by a continuing action. The operand
H1 should receive the value True, if at all, only for very
a very short time, since step 2 is only activated for a short time.
The operand H2 is described by a storing action on activation.
This type of action depends on the activation event for the
step. This event takes place because step 2 is certainly
activated and deactivated immediately.
The answer to this is as follows: Step 2 is virtually activated and virtually deactivated; it is not stably active. Thus, the two events, activation and deactivation, take place, but the status that the step is active does not.
For the example above, this means that the storing action on activation is executed and the value '1' is written to the operand H2. The continuing action does not 'sense' that step 2 is active, however. This means that the operand H1 does not, even briefly, change to True.
If H2 were to be influenced by a storing action on deactivation instead of a storing action on activation, then this action would also be performed. As explained above, this is because this deactivation event also occurs at step 2, which is decisive for performing the storing action on deactivation.
If a transient evolution exists, the step involved is activated and deactivated virtually. The step does not become stably active here, but is unstable. Continuing actions do not 'sense' the change in the step as a result.
This is different for storing actions on activation or deactivation, since these events actually occur. These actions are activated and performed as a result.
A tank is to be filled with a medium. After filling, the medium in the tank is to be heated to 35°C and agitated with an agitator. The agitator is then switched off and the tank emptied.
Fig. 3.95 Diagram of the technology for controlling the tank
Definition of the operands:
|S1Start||"Start" button, value = True if pressed|
|S2TankFull||Tank full sensor, value = False if tank is full|
|S3TankEmpty||Tank empty sensor, value = False if tank is drained|
|TempValue||Liquid temperature sensor, integral value of 10 - 35°C|
|M1PumpFilling||Pump for filling the tank|
|Y1Filling||Valve for filling the tank, True = open valve|
|M3Agitator||Pump for draining the tank|
|Y2Drain||Valve for draining the tank|
|Heating||Heating to heat the liquid|
You can see the solution in the next picture. The solution to this task is somewhat more extensive.
Fig. 3.96 Filling, heating, agitating and draining of medium
shows the initial situation for an empty tank (S2TankFull is True and S3TankEmpty is False).
Fig. 3.97 Filling the tank
The Start button is now pressed and the tank is filled. In step 2, the valve is opened and the time for the transition condition started. After two seconds, the transition to step 3 takes place and the pump is switched on as a result. The S2TankFull sensor returns False when it is rinsed with liquid; for this reason, the sensor is integrated negated into the transition condition. When the tank is full, the transition to step 4 takes place and the pump is switched off.
In step 2, the valve with the storing action Y1Filling:= 1 is set permanently, while in step 3, the pump M1PumpFilling is influenced by a continuing action. This means the operand Y1Filling must be explicitly set to the value 0 in another storing action. This is carried out when step 4 is activated.
The temperature is measured analogously and digitised. A digitised value is not a bit operand. In the example, the temperature is an integral value. The term for the transition condition after step 4 needs to be placed in square brackets in line with the standard [TempValue>=35]. This comprises a comparison: It returns the value True if the contents of the operand TempValue is greater than or equal to 35. The transition then takes place.
Fig. 3.98 Heating and agitating
In Fig. 3.98 step 4 is active thus switching the heater on. Likewise, the positive edge for the step closes the open valve for filling with Y1Filling:=0 again. Step 4 remains active until a temperature of 35°C is reached. The temperature is currently 20°C. The agitator M2Agitator is switched on by the continuing action.
Fig. 3.99 Draining
In the figure above, step 5 is active and the tank is drained. Here, the pump and the drainage valve are set and waiting for the empty message S3TankEmpty with False, so that the backward sequence to the initial step takes place and the entire procedure can be restarted.
The delay of two seconds vs. opening the valve Y2Drain was realised using the time-dependent assignation condition at the action M3PumpDrain. This selected a slightly different implementation than with filling, where the pump also cuts in two seconds after the valve is opened. The second solution saves a step.