The intervention traffic stream has been replaced by a parameterisable trigger event.
Display |
Identifier |
Values |
Description |
Name |
Modification name |
|
Each modification must have a unique name. |
|
|
|
|
Signal Frame plan |
Dependent signal frame plan |
|
Signal frame plan on which the modification depends. |
|
|
|
|
|
|
List |
All frame signal programs |
Cycle time |
Cycle time of the signal frame plan |
|
The cycle time of the selected signal frame plan. Is displayed as information and cannot be changed. |
|
|
|
|
|
|
tC |
Cycle time in seconds. |
Intervention |
|
|
Time period for the execution of the modification |
|
|
|
|
|
|
0 .. tC - 1 |
Time in cycle in seconds. |
Activation |
|
|
Time period for testing the trigger event. |
|
|
|
|
|
|
0 .. tC - 1 |
Time in cycle in seconds. |
Priority |
|
|
If there are several activated interventions that share the same intervention time at the same time, then the set priority decides which intervention is executed. |
|
|
|
|
|
|
1 .. 100 |
Priority value (lower value = higher priority) |
Basic intervention |
|
|
In the basic intervention field, the "predecessor" for the modification is defined. The basic master plan (basic plan) or one of the other defined modifications are possible here. With "Basic plan", a modification is defined that intervenes in the basic master plan, otherwise the defined modification is a subsequent intervention of the selected predecessor modification. |
|
|
|
|
|
|
Basic plan |
|
|
|
List |
All modifications. |
Trigger event |
|
The modification is no longer triggered by an intervention traffic stream, but activated via a logical condition, the so-called "trigger event". This can be defined individually for each modification. With an expression generator, in which open vs | plus functions, traffic streams and detectors are available, a logical expression must be created, which returns the value "true" or "false". |
|
|
|
|
|
|
|
Expression |
Created logical expression. |
Base frame start |
|
|
The values in the Base frame start columns indicate the frame signal defined in the underlying frame plan for the respective traffic stream at the start of the modification. |
|
|
|
|
|
|
Request |
Request area. |
|
|
Extension |
Extension area. |
|
|
None |
Neither. |
Call x |
Start of call |
|
Beginning of the call area, two starts. |
|
|
|
|
|
|
Intervention |
Time within the defined intervention in seconds. |
Extension x |
Extension starts |
|
Start of the extension area, two starts. |
|
|
|
|
|
|
Intervention |
Time within the defined intervention in seconds. |
End x |
Frame end |
|
End of the signal frame plan, two drops. |
|
|
|
|
|
|
Intervention |
Time within the defined intervention in second. |
Base frame end |
|
|
The values in the columns base frame end indicate the frame signal defined in the underlying frame plan for the respective traffic stream at the end of the modification. |
|
|
|
|
|
|
Request |
Request area. |
|
|
Extension |
Extension area. |
|
|
None |
Neither. |
Parameter |
from vs | plus version |
Comment |
|
TdMod |
8.1.0 |
A modification is part of a signal frame plan as of vs | plus 8.1. It is always valid when the signal frame plan to which it was assigned is active. If the signal frame plan is changed by a network control, the modifications belonging to the previous frame plan are also automatically deactivated. |
|
8.1.0 to 9.0 |
Since the r_DetWait( ... ) function does not work correctly in vs | plus versions 8.1.0 and 9.0, it should not be used. The error will be fixed in vs | plus version 9.1. |