PCS 7 V7.1 Basic Library - 03 - 2009
PCS 7 V7.1 Basic Library - 03 - 2009
Block Description 1
Family: CONTROL 2
Family: @System 3
SIMATIC
Internal block 4
Process Control System PCS 7
PCS 7 Basic Library V71 Faceplates and block icons 5
Appendix 6
Function Manual
03/2009
A5E02102513-01
Legal information
Warning notice system
This manual contains notices you have to observe in order to ensure your personal safety, as well as to prevent
damage to property. The notices referring to your personal safety are highlighted in the manual by a safety alert
symbol, notices referring only to property damage have no safety alert symbol. These notices shown below are
graded according to the degree of danger.
DANGER
indicates that death or severe personal injury will result if proper precautions are not taken.
WARNING
indicates that death or severe personal injury may result if proper precautions are not taken.
CAUTION
with a safety alert symbol, indicates that minor personal injury can result if proper precautions are not taken.
CAUTION
without a safety alert symbol, indicates that property damage can result if proper precautions are not taken.
NOTICE
indicates that an unintended result or situation can occur if the corresponding information is not taken into
account.
If more than one degree of danger is present, the warning notice representing the highest degree of danger will
be used. A notice warning of injury to persons with a safety alert symbol may also include a warning relating to
property damage.
Qualified Personnel
The device/system may only be set up and used in conjunction with this documentation. Commissioning and
operation of a device/system may only be performed by qualified personnel. Within the context of the safety notes
in this documentation qualified persons are defined as persons who are authorized to commission, ground and
label devices, systems and circuits in accordance with established safety practices and standards.
Proper use of Siemens products
Note the following:
WARNING
Siemens products may only be used for the applications described in the catalog and in the relevant technical
documentation. If products and components from other manufacturers are used, these must be recommended
or approved by Siemens. Proper transport, storage, installation, assembly, commissioning, operation and
maintenance are required to ensure that the products operate safely and without any problems. The permissible
ambient conditions must be adhered to. The information in the relevant documentation must be observed.
Trademarks
All names identified by ® are registered trademarks of the Siemens AG. The remaining trademarks in this
publication may be trademarks whose use by third parties for their own purposes could violate the rights of the
owner.
Disclaimer of Liability
We have reviewed the contents of this publication to ensure consistency with the hardware and software
described. Since variance cannot be precluded entirely, we cannot guarantee full consistency. However, the
information in this publication is reviewed regularly and any necessary corrections are included in subsequent
editions.
3.31 OR_M_8C: OR value status of 2 redundant signal modules, max. 8 channels, channel
granular ..................................................................................................................................... 227
3.31.1 Description of OR_M_8C........................................................................................................... 227
3.31.2 I/Os of OR_M_8C / OR_M_16C / OR_M_32C / OR_HA16C..................................................... 230
3.31.3 Message texts and associated values of OR_M_8C ................................................................ 232
3.32 PADP_L0x: Monitoring DP/PA slaves....................................................................................... 234
3.32.1 Description of PADP_L00.......................................................................................................... 234
3.32.2 I/Os of PADP_L0x ..................................................................................................................... 238
3.32.3 Message Texts and Associated Values of PADP_L00 ............................................................. 239
3.32.4 Description of PADP_L01.......................................................................................................... 240
3.32.5 Message Texts and Associated Values of PADP_L01 ............................................................. 244
3.32.6 Description of PADP_L02.......................................................................................................... 245
3.32.7 Message Texts and Associated Values of PADP_L02 ............................................................. 249
3.33 PADP_L10: Monitoring PA slaves downstream of DPV0 with up to 16 slots ........................... 251
3.33.1 Description of PADP_L10.......................................................................................................... 251
3.33.2 I/Os of PADP_L10 ..................................................................................................................... 257
3.34 PO_UPDAT: Output Process Image ......................................................................................... 258
3.34.1 PO_UPDAT: Output Process Image ......................................................................................... 258
3.35 PS: Power supply monitoring .................................................................................................... 259
3.35.1 Description of PS ...................................................................................................................... 259
3.35.2 I/Os of PS .................................................................................................................................. 262
3.35.3 Message Texts and Associated Values of PS .......................................................................... 263
3.36 RACK: Rack monitoring ............................................................................................................ 264
3.36.1 Description of RACK ................................................................................................................. 264
3.36.2 I/Os of RACK............................................................................................................................. 268
3.36.3 Message Texts and Associated Values of RACK ..................................................................... 269
3.37 RED_F: Status processing of redundant F modules................................................................. 270
3.37.1 Description of RED_F................................................................................................................ 270
3.37.2 I/Os of RED_F ........................................................................................................................... 272
3.38 SUBNET: DP master system monitoring .................................................................................. 273
3.38.1 Description of SUBNET............................................................................................................. 273
3.38.2 I/Os of SUBNET ........................................................................................................................ 277
3.38.3 Message Texts and Associated Values of SUBNET ................................................................ 278
4 Internal block ......................................................................................................................................... 279
4.1 ChkREAL: Internal Block........................................................................................................... 279
4.2 QC_CHNG: Internal block ......................................................................................................... 279
Function
Here, you will find a brief description of the block function.
You will find additional information about complex blocks in the "How it works" section.
How it works
Here, you will find more detailed information, for example about the function of specific
inputs, operating modes or time sequences. You must be familiar with these relationships in
order to use the block effectively.
Calling OBs
Here you will find information on the organization blocks (OBs), in which the described block
must be installed. If the CFC is used, the block is automatically installed in the cyclic OB
(cyclic interrupt) and in the OBs listed in the block's task list (for eample in restart OB100).
CFC generates the required OBs during compilation. If you use the blocks without CFC, you
will have to program these OBs and call their instance within the blocks.
Error handling
The ENO Boolean block output indicates the error in the CFC chart.
The value is equivalent to the BIE (binary result in STEP 7 STL, after completion of the
block) or OK bit (in SCL notation) and indicates:
ENO = BIE = OK = 1 (TRUE) -> The result of the block is free of errors.
ENO = BIE = OK = 0 (FALSE) -> Invalid result or constraints (for example, input values and
modes).
The FBs also return the inverted BIE at the QERR output of the instance DB.
QERR = NOT ENO
The error message is generated in two separate operations:
● The operating system detects a processing error (e.g. value overflow, system functions
called return an error ID with BIE = 0).
This is a system function and is not specifically mentioned in the block description.
● The block algorithm checks for functional invalidity of values and operating modes. These
error events are logged in the block description.
You can evaluate the error display, for example, to generate messages or use substitute
values for invalid results. You will find more information about messages in the "Message
blocks" section.
Startup characteristics
The different startup behaviors are as follows:
● Initial start
The block is called for the first time from the OB in which it has been inserted. This is
usually the OB that performs the standard, process-specific operations (for example, the
cyclic interrupt OB).
The block adopts a status that conforms to its input parameters. These may be default
values (additional information in "I/Os" section) or values you have already configured, for
example, in CFC. The initial startup characteristics are not described separately unless
the block does not conform to this rule.
● Startup
The block is executed once during CPU startup. The block is called in the startup OB
(where it is additionally installed either automatically in the ES or manually in STEP 7). In
this case, the startup characteristics are described.
Please note that the block outputs have default values and that these can take effect
during the CPU startup with other blocks, if these are processed first.
The correct startup behavior of the blocks is the responsibility of the configuration
engineer.
Time response
A block assigned this function must be installed in a cyclic interrupt OB. It calculates its time
constants/parameters on the basis of its sampling time (the time which elapses between two
consecutive cyclic operations).
In a CFC configuration on ES, the sampling time is also determined by the segmentation of
the runtime group, which ensures that the block is not executed during every OB run.
This sampling time is entered at the I/Os, in the SAMPLE_T parameter.
When configuring with CFC, this occurs automatically once the block has been inserted in
the OB and the runtime group. For this reason, this input is set to invisible in CFC.
During the STEP 7 configuration, you set the time response manually.
Time response is mentioned only if the block has been assigned this feature.
Message response
A block with message response reports various events to the higher level OS. Existing
parameters required for the generation of messages are documented.
Blocks without message response can be expanded with additional message blocks. A
reference to the message response is found in the description of the individual message
blocks.
I/Os
The I/Os of the block represent its data interface. These I/Os can be used either to transfer
data to the block or to fetch results from the block.
Abbrevi Type
ation
I Input. Supplies values to the block (representation in CFC: left-hand block side)
O Output. Output value. (representation in CFC: right-hand block side)
IO Run = input/output. Retroactive input that can be written to by the OS and written back by
the block (representation in CFC: left-hand block side)
● OCM
Parameters marked "+" can be adjusted and monitored via the corresponding faceplate.
● Permissible values
Additional limitation within the data type's range of values
Function
The block coordinates the reading of the data record of blocks FM_CNT, FMCS_PID,
FMT_PID or READ355P. The block is installed and the parameters interconnected by the
driver generator.
It is possible to include data record reading blocks of other modules in the coordination.
How it works
The FM_CO block can start a maximum of 8 block chains.
The blocks connected to the output structure EN_COx check whether the current
coordination number (EN_COx.CO_ACT) corresponds to their own coordination number. If
this is the case, they read their data records from the module and reduce the coordination
number EN_COx.CO_ACT by 1, so that the next block can read out its data records.
If the current coordination number of a sequence (EN_COx.CO_ACT) has a value less than
1, the FM_CO block determines the highest number assigned in sequence x based on its
inputs ENCOx_yy. The inputs ENCOx_yy (yy = coordination number) are supplied with their
coordination number via an interconnection by the data record reading blocks. The highest
coordination number is the number for which ENCOx_yy = yy still applies. The FM_CO
module restarts the sequence in which it sets EN_COx.CO_ACT to this value.
This algorithm ensures that no more than one read data record operation ever takes place at
any given time within the block sequence.
Calling OBs
The fastest cyclic interrupt OB of all OBs in which you have installed FM_CNT, FMCS_PID,
FMT_PID or READ355P blocks, including OB100.
Use in CFC
When using the CFC function "Generate Module Drivers", the block is automatically installed
and the connections, such as those described under "Installation regulation" are made.
If you install, delete or move blocks of an existing block chain in other OBs or runtime
groups, the driver generator must be called.
Should the sequence not start up as expected (after CPU restart) or not continue to run
(after downloading changes), you must set ACC_ID to 1.
Installation rules
An FM_CO is responsible for a DP master system (chain). On this DP master system, a
maximum of 8 DP slaves (only ET 200M) can be operated with at least one FM 350, FM 355
or FM 355-2 module. A standard rail can hold up to four FM 355 modules. An FM 355 can be
configured for one to four controller channels, in other words, a maximum of 16 controller
channels can be operated with one DP slave.
In the following, only the FMCS_PID block , which also represents FM_CNT, FMT_PID or
READ355P is taken into consideration. The FM_CO must always be installed before the first
FMCS_PID block in the fastest cyclic interrupt OB. The output structure EN_COx for the rack
x is connected to the input structures EN_COx of all FMCS_PID blocks, which communicate
to controller modules of rack x. The output ENCO of each FMCS_PID block is connected to
an input ENCOx_yy (yy corresponds to the coordination number CO_NO assigned to each
FMCS_PID block) of the FM_CO block.
As described above, 8 DP slaves can be operated with one FM_CO block on a DP master
system.
The selection of the cyclic interrupt OB depends on the CPU load. Note that the CPU has no
reserves for other "Read data record" jobs if operating with eight DP slaves because only
eight jobs can be buffered per DP master system. Simply inserting a module would lead to
an overflow. It is advisable to operate only up to six DP slaves on a DP master system. The
remaining DP slaves must be distributed on other DP master systems with further FM_CO
blocks.
When selecting the cyclic OB, remember that the new data will be available at the earliest
after two cycles. Make sure that the maximum runtime of this OB does not have any
negative impact on overall system runtime as a result of the number of blocks installed. If the
FMCS_PID blocks to be processed exceed the runtime limit, group the DP slaves with the
FM 355 modules in fast and slow control loops.
Startup characteristics
EN_CO_x.CO_ACT = 1 is set at all outputs during startup (restart).
Time response
Not available
Message response
Not available
Area of application
The CONEC block monitors the status of AS connections, and reports the associated error
events.
Calling OBs
The block must be installed in the run sequence in the following OBs:
Use in CFC
With the "Generate module drivers" CFC function, the CONEC block is automatically
installed in the OBs listed above.
Note
The messages "Failure or loss of redundancy connection ID" are generated by each CPU of
the two connected AS except when the CPU of an AS fails (or both H-CPUs).
The connection ID determines whether a message is output.
If the connection ID >= 16#C00, no message is generated.
Error handling
Error handling for the block is limited to the evaluation of the error information of ALARM_8P.
You will find more information in the
"Error Information of Output Parameter MSG_STAT" (Page 322) section.
Startup characteristics
The CONEC block initializes the messages of ALARM_8P.
If there is a CPU with SFC 87, connection diagnostics is initialized. After this, there is a wait
time of approx. 1 minute in the cyclic interrupt OB before the connection diagnostics
messages are generated.
Overload behavior
Not available
Time response
For further information, refer to "Message response".
Message response
The block generates the following messages in the OBs listed below:
Additional information
For further information, refer to the sections:
Message texts and associated values of CONEC (Page 23)
Maintenance status of MS (Page 326)
Additional information
For further information, refer to the following sections:
Message texts and associated values of CONEC (Page 23)
Maintenance status of MS (Page 326)
Area of application
The CPU_RT block is installed by the CFC in OB 100, OB 1, in all OB 3x as well as OB 8x, if
this is used by the user program.
The CPU_RT determines the runtime of the individual OBs and their participation in the cycle
time. If there is CPU overload (OB 80 cycle time exceeded), it instigates suitable actions
selected by the user in limits to ensure operability of the AS.
This situation is designated as emergency operation and is made clearly visible by a control
system message. Buffered start events (OB 3x still executing) are also detected and
displayed. The loss of start events is reported as error.
Use in CFC
During compilation of the CFC, a chart is automatically created with the name @CPU_RT.
The CPU_RT block is already included in it.
Note
Never attempt to insert the CPU_RT block in a different block because it is a system block.
Note
Older CPUs do not support SFC78. Use SZL112 to check whether SFC78 is available.
Note
The status of CPU_RT is reset when you download.
Finally, the reduction ratio will be set to 0 for all other cyclic OBs.
If no SFC78 is present, then the time at which reversal of the stop avoidance measures can
be triggered cannot be calculated.
The reversal of reduction ratios is started when the slowest OB has again processed a
number of cycles (UndoCycle).
The value of the UndoCycle in this case should not be too low, to avoid a frequent back and
forth between stop avoidance measures and normal operation.
For the reduction ratio in the CFC, two parameters are available in the CPU_RT block for
each cyclic OB:
OB3x_N_START The start value for reduction ratio is specified by the input OB3x_N of CPU_RT
and also in OB3x_N_CNT
OB3x_N_CNT The counter is decremented in the CFC at each OB call. For OB3x_N_CNT <= 0
there is complete OB processing and OB3x_N_START will be re-entered in
OB3x_N_CNT.
The CPU block is also called when reduction becomes necessary, so that in emergency
operation an evaluation of the averaged cycle time is possible.
Error handling
If the read-out of data from the cyclic OB fails for the CPU_RT block, then ERR_NUM = 1 is
set and processing of the CPU_RT block is abandoned, because these data are the basic
prerequisite for useful processing.
Startup characteristics
Calculations with SFC78 are restarted only after a number of cycles (RunUpCyc) after
restart. The RunUpCyles are counted down in the slowest cyclic OB.
Time response
Not applicable.
Message response
The block reports via OB_BEGIN (Page 183)
Additional information
You will find more information on this subject in the following sections:
Message texts and associated values of OB_BEGIN (Page 189)
Maintenance status of MS (Page 326)
Additional information
You will find more information on this subject in the following sections:
Message texts and associated values of OB_BEGIN (Page 189)
See also
Maintenance Status of MS (Page 326)
Area of application
The DIAG_AB block evaluates the status word of an AB7000 slave and acknowledges newly
reported errors via the control word of the slave.
Calling OBs
The cyclic OB and OB 100.
Use in CFC
The following actions are executed automatically with the "Generate module drivers" CFC
function:
● The block is installed in the run sequence before the MOD_PAL0 or MOD_PAX0 block,
both of which are also installed by the driver generator. The install is executed in the
same cyclic OB as the associated signal processing blocks FF_A_xx.
● Parameters are assigned to the LADDR_C input with the address of the control word of
the AB7000.
● Parameters are assigned to the input LADDR_S with the address control word of the
AB7000.
● The OUT structure CPU_DIAG of the OB_BEGIN block is interconnected with the
IN_OUT structures of the same name of DIAG_AB.
● The input mode of the DIAG_AB block is interconnected with the output OMODE_00 of
the PADP_L10 or PADP_L01 block.
● The input PA_DIAG of the DIAG_AB block is interconnected with the output PA_DIAG of
the PADP_L10 or PADP_L01 block.
● The output OMODE of the DIAG_AB block is interconnected with the input MODE_00 of
the MOD_PAL0 or MOD_PAX0 block.
● The output ODIAG of the DIAG_AB block is interconnected with the input PA_DIAG of the
MOD_PAL0 or MOD_PAX0 block.
Error handling
The plausibility of input parameters is not checked.
Startup characteristics
Initialization of outputs OMODE with 16#80000001 ("valid value") and ODIAG with
16#00000000 ("no error")
Time response
Not available
Message response
Not available
Area of application
Block DPAY_V0 monitors the status of a DP/PA or Y-Link as a V0 slave (IM 157) and reports
the corresponding error events.
The DP/PA link operates as a PA master for the lower-level PA field devices and as a slave
on the DP bus.
The Y-Link operates as a DP master for the lower-level DP field devices and as a slave on
the higher-level DP bus.
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 70 I/O redundancy error
OB 72 CPU redundancy error
OB 82 Diagnostic interrupt
OB 85 Program execution error
OB 86 Rack failure
OB 100 Restart (warm start)
Use in CFC
The following actions are executed automatically with the "Generate module drivers" CFC
function:
● The block is integrated in the run sequence downstream from the SUBNET block and
upstream from the PADP_L0x block.
● RACK_NO (rack/station number) is configured.
● SUBN_TYP (internal/external Profibus interface) is set.
● SUBN1_ID (ID of the master systems) is set.
● SUBN2_ID (ID of the redundant master system) is set.
● DADDR (diagnostic address of the DP/PA or Y-Link) is set.
● DPPA_xx (slave xx address), 1st module (slot) address of slave xx in the link, number of
slots of slave xx are set.
● The CPU_DIAG of the OB_BEGIN block and SUB_DIAG of the SUBNET block OUT
structures are interconnected with the IN_OUT structures of the same name of DPAY_V0.
● In the case of PA or DP field devices, they are interconnected with PADP_L0x.
The block generates a corresponding message (see "Message Response") on the basis of
the startup information of calling OBs, if the current instance is affected.
When operating with redundant PROFIBUS DP interfaces, the block determines the
currently active preferred channel (SUBN1ACT, SUBN2ACT) by evaluating the error events
as well as via the diagnostic address DADDR of the link.
SFC 13 (DPNRM_DG, read diagnostic data consistently) reads the diagnostic data (OB 82).
The reading process can take several cycles (OB 1). It is therefore possible in a few rare
cases that the triggering diagnostic event cannot be recognized.
Diagnostic user data contains information about the status of the link, and of connected field
devices. The structure DPPA_ST indicates the link status.
The status of a field device is entered in the structure DPA_M_xx.
A field device can have a maximum of 32 slots (modules). Three block types are available,
according to the number of slots on the field device:
● PADP_L00 (field device with max. 7 slots)
● PADP_L01 (field device with max. 16 slots)
● PADP_L02 (field device with max. 32 slots)
The structure DPA_M_xx is interconnected to the structure DPA_M and the output EN_Mx
with EN of one of the PADP_Lxx blocks (carried out by the CFC function "Generate module
drivers").
The DPA_M_xx structure consists of two DWORD value (S_01 for modules 1 to 16 and S_02
for modules 17 to 32) and one BOOL value (S_ERR = DP/PA field device faulty). Two bits of
the DWORD are assigned to each slot of the DP/PA field device, whereby bit 0 and bit 1
belong to slot 1 (module 1) of the DP/PA field device, etc. These bits are defined as follows:
Redundancy
The block supports redundant DP master systems in an H system (only distributed I/Os).
The SUBN1_ID (connection to CPU 0) and SUBN2_ID (connection to CPU 1) inputs of the
SUBNET block are configured with the numbers of the redundant DP master systems. If the
DP master systems are not redundant, the remaining input is set to 16#FF (default).
Error handling
The error handling for the block is limited to evaluation of the error information of
ALARM_8P.
You will find more information about this in the
Error information of the MSG_STAT output parameter (Page 322)" section.
Startup characteristics
The block initializes the messages of ALARM_8P. Availability of the link is verified. In H
systems, determines the preferred channel of the link.
Overload behavior
The block counts OB 86 (no DP master system failure, see SUBNET block) and OB 82 calls.
Both counters are reset in OB 1. If more than five OB 86 events or more than five OB 82
events in succession before the cycle control point is reached (OB 1), these events are
discarded and the message ""DP-Link DP-Master:x Rack:y: Multiple failure" or the message
"DP-Link Master:x Rack:y: Muktiple alarm (OB 82)" is output. 1 minute later the status of the
link will be re-checked.
Time response
Not available
Message response
After its call by OB 70, OB 72, OB 85 or OB 86, the block analyzes the status of its assigned
CPU, DP master and link. If the link loses redundancy or fails, the block outputs
corresponding messages via ALARM_8P.
The block generally reports only the events generated in the link that it monitors.
Redundancy loss and link failures which are caused by the failure of a DP masters or of a
CPU, are initially neither signaled nor indicated at the outputs SUBN1ERR and SUBN2ERR.
The DELAY input is used to delay the output of error messages for higher-priority outgoing
errors. This delay time is configurable. When the block recognizes an outgoing error at an
interconnected DP master, it initially assumes that there is a faulty assigned DP slave in the
link it monitors and sets the corresponding output SUBNxERR. The error status is not reset
until the DP slave returns (in this case: OB 86, OB 70). The blocks delay error messages
relevant to any slave failure states for a time in seconds as specified in DELAY, in order not
to trigger the output of surge of messages from DP slaves which are not yet synchronized
after the master has returned. An error message is not output to the OS unless the DP slave
has reported its return before this delay time has expired.
Do not set the value of DELAY too high, since messages reporting faulty DP slaves or their
removal during a master failure will be output too late to the OS after the DP master returns.
The block generates the following messages in the OBs listed below:
Additional information
For further information, refer to the sections:
Message texts and associated values of DPAY_V0 (Page 42)
Maintenance status of MS (Page 326)
I/O
The default block view in the CFC is identified in the "I/O" column:
I/O name in bold = I/O is visible, standard I/O name = I/O is not visible.
You will find explanations of, and information about the abbreviations used in the
"General information about the block description" (Page 9) section.
Additional information
For further information, refer to the following sections:
Message texts and associated values of DPAY_V0 (Page 42)
Maintenance status of MS (Page 326)
Area of application
The DPAY_V1 block enables the field device-specific blocks downstream of the DP/PA or Y
links.
The DP/PA link acts as a PA master for the lower-level PA field devices, and as a slave on
the DP bus.
The Y link acts as a DP master for the lower-level DP field devices, and as a slave on the
higher-level DP bus.
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 55 Status interrupt
OB 56 Update interrupt
OB 57 Vendor-specific interrupts
OB 70 I/O redundancy error
OB 72 CPU redundancy error
OB 82 Diagnostic interrupt
OB 83 Insert/remove module interrupt
OB 85 Program runtime error
OB 86 Rack failure
OB 100 Warm restart
Use in CFC
The following actions are executed automatically with the "Generate module drivers" CFC
function:
● The block is integrated in the run sequence after the OB_DIAG1 block.
● SUBN_1ID (ID of primary DP master system) is configured.
● SUBN_2ID (ID of secondary DP master system) is configured.
● RACK_NO (rack/station number) is configured.
● The OUT structure CPU_DIAG of the OB_BEGIN block is interconnected with the
IN_OUT structures of the same name of DPAY_V1.
● The OUT structure CPU_OB_5X of the OB_BEGIN block is interconnected with the
IN_OUT structures of the same name of DPAY_V1.
● EN_Mxx are interconnected with EN of OB_DIAG1 and PADP_L10 for each field device.
OB 5x characteristics
Enables the output for the affected field device.
Redundancy
The redundancy is evaluated in OB_DIAG1.
Error handling
The plausibility of input parameters is not checked.
Startup characteristics
The block initializes its outputs.
Overload behavior
OB_DIAG1 disables the block in response to an overload.
Time response
Not available
Message functionality
Not available
Area of application
The DPDIAGV0 block monitors the status of the modules of an ET 200S acting as a DPV0
slave (IM 151-1 High Feature) after a Y link.
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB82 Diagnostic interrupt
OB 83 Insert/remove module interrupt
OB 85 Program runtime error
OB 86 Rack failure
OB 100 Warm restart
Use in CFC
The following actions are executed automatically with the "Generate module drivers" CFC
function:
● The block is integrated in the run sequence after the OB_DIAG1 block.
● The following inputs are configured:
– SUBN_1ID (ID primary DP master system)
– SUBN_2ID (ID secondary DP master system)
– RACK_NO (rack/station number)
● The following I/Os are interconnected:
– The OUT structures CPU_DIAG of the OB_BEGIN block and RAC_DIAG of the RACK
block with the DPDIAGV0-block IN_OUT structures of the same name
– EN_Mxx with EN of the OB_DIAG1 block and the DPDIAGV0 block of each ET 200S
– The DPA_M_xx outputs with the DPA_M input and EN_Mxx output with EN of a
MOD_4 block.
Redundancy
Only non-redundant devices may be used downstream of a Y link.
Error handling
The plausibility of input parameters is not checked.
Startup characteristics
The system verifies that the ET 200S is available.
Overload behavior
The overload behavior takes place in the upstream OB_DIAG1 block.
Time response
Not available
Message functionality
Not available
Area of application
The DREP block evaluates the diagnostic data from a SIMATIC diagnostic repeater for
PROFIBUS DP. This repeater must be connected to a DP master.
Calling OBs
OB 1 Cyclic processing
OB 82 Diagnostic interrupt
OB 86 Rack failure
OB 100 Restart (warm restart, message initialization)
Use in CFC
The following actions are executed automatically with the "Generate module drivers" CFC
function:
● Block OB_DIAG1 is installed in the run sequence upstream of the DREP block.
● The following addresses are configured:
– The diagnostic address DADDR of the diagnostics repeater
– The geographic address (SUBN_ID and PADP_ADR)
● The following I/Os are interconnected:
– The OUT structures CPU_DIAG of the OB_BEGIN block and RAC_DIAG of the
OB_DIAG1 block with the IN_OUT structures of the same name of the DREP block.
– The EN input with the output of an AND block.
– The inputs of the AND block with the EN_SUBx outputs (x = number of the DP master
system) of the OB_BEGIN block, with EN_Rxxx (xxx = rack/station number) of the
SUBNET block and with EN_F of the OB_DIAG1 block.
– EN_DIAG with the EN_DIAG output of the OB_DIAG1 block.
Bit Description
A.0 1: The location and cause of the error cannot be identified (possibly electromagnetic
interference)
A.1 CPU redundancy loss
A.2 1: - -
A.3 1: Further measurement circuits at the segment, the other diagnostic repeater is connected
with its segment DP2
A.4 1: Further measurement circuits at the segment, the other diagnostic repeater is connected
with its segment DP3
A.5 1: - -
A.6 1: Indefinite error cause
A.7 1: Critical message frame error rate
Bit Description
B.0 1:- -.
B.1 1: - -
B.2 1: - -
B.3 1: - -
B.4 1: - -.
B.5 1: - -
B.6 1: - -.
B.7 1: - -
C.0 1: Segment automatically switched off due to continuous zero level on the line.
C.1 1: Segment automatically switched off due to constantly fluctuating line levels.
C.2 1: - -
C.3 1: - -
C.4 1: More than 32 nodes connected to the measurement segment.
C.5 1: The distance between the node and the diagnostic repeater exceeds the permitted
line length.
C.6 1: The maximum permitted number of diagnostic repeaters connected in series has been
exceeded.
C.7 1: - -
The outgoing message will be generated when all segment bits are equal to zero.
Call HW Config to analyze details of events output by the diagnostic repeater.
An appropriate incoming/outgoing message is going to be generated for the segments (DP2
or DP3) as a result of the following events recognized by a diagnostics repeater:
Bit Description
A.0 1: -
A.1 1:-
A.2 1: -
A.3 1: -
A.4 1: -
A.5 1: -
A.6 1: -
A.7 1:
B.0 1: Wire break on signal line A.
B.1 1: Short-circuit to shield on signal line B.
B.2 1: -
B.3 1: Short-circuit to shield on signal line A.
B.4 1: Wire break on signal line B.
B.5 1: -
B.6 1: Wire break on signal line A and/or B, or the terminating resistor is missing.
B.7 1: Short-circuit between signal line A and/or B, or an additional terminating resistor
has been installed.
Bit Description
C.0 1: -
C.1 1: -
C.2 1: -
C.3 1: -
C.4 1: -
C.5 1: -.
C.6 1: -
C.7 1: -
Events detected by the diagnostics repeater are acquired synchronously in OB 82.
Diagnostic event data is fetched via SFB 54 in the OB_BEGIN block and written to the
structure DINFO. The function always sets just one bit to indicate the cause of an event-
entering state. Bit C7 may also be set, if the diagnostics repeater has detected further errors.
In this case, all previously reported events will be queued. DREP generates a corresponding
group error message via ALARM_8P. Flutter messages may develop especially due to error
events A.0.1 and A.6.1. They are suppressed as follows :
After an outgoing message, a new outgoing message will be delayed by the time in [s] set at
the DELAY parameter. If a further error is queued, the outgoing message will not be
generated until this error has been reported outgoing.
Error handling
The block evaluates the error information of ALARM_8P and writes it to the corresponding
output parameters. You will find additional information in the "Error information for output
parameter MSG_STAT (Page 322)" section.
The block reports a diagnostic error if an error occurs while reading the diagnostic data, or if
any other fault corrupts diagnostic data.
Startup characteristics
ALARM_8P messages are initialized by the DREP block. This uses SFC13 (DPNRM_DG) to
read the latest diagnostic information from the diagnostic repeater.
Overload behavior
The interconnected OB_DIAG1 locks the call of DREP for diagnostics if an overload has
occurred.
Dynamic response:
Not available
Message response:
The multiple instance ALARM_8P are only called if a message is to be output by this
instance. It is only at this point that previously acknowledged messages are updated by the
corresponding ALARM block. If the connection to WinCC is down, each ALARM_8P instance
can hold up to two message statuses of its event ID. (Usually two messages maximum).
Fluuter messages can be suppressed via the DELAY input.
The block generates the messages listed below:
Additional information
For further information, refer to the sections:
Message texts and associated values of DREP (Page 57)
Maintenance status of MS (Page 326)
Additional information
For further information, refer to the sections:
Message texts and associated values of DREP (Page 57)
Maintenance status of MS (Page 326)
Area of application
The DREP_L block evaluates diagnostic data from a SIMATIC diagnostic repeater for
PROFIBUS DP. The diagnostic repeater (after DPV0) must be connected downstream of a
Y-Link (after DPV1).
Calling OBs
OB 1 Cyclic processing
OB 82 Diagnostic interrupt
OB 86 Rack failure
OB 100 Restart (warm start) (startup, message initialization)
Use in CFC
The following actions are executed automatically with the "Generate module drivers" CFC
function:
● The OB_DIAG1 block is integrated into the run sequence upstream of DREP_L.
● The following addresses are configured:
– The diagnostic address of the DP/PA link (DADDR) is connected downstream of the
diagnostic repeater
– The geographical address (SUBN1_ID, SUBN2_ID, RACK_NO and PADP_ADR)
● The following I/Os are interconnected:
– The OUT structures CPU_DIAG of the OB_BEGIN block and RAC_DIAG of the
OB_DIAG1 block with the DREP_L INOUT structures of the same name.
– The EN input is interconnected with the output of an AND block.
The inputs of the AND block with the EN_SUBx outputs (x = number of the DP master
system) of the OB_BEGIN block, with EN_Rxxx (xxx = rack/station number) of the
SUBNET block, and with EN_F of the OB_DIAG1 block.
– EN_DIAG with the EN_DIAG output of the OB_DIAG1 block.
Bit Description
A.0 1: The location and cause of the error cannot be identified (possibly electromagnetic
interference)
A.1 CPU redundancy loss
A.2 1: - -
A.3 1: Further measurement circuits at the segment, the other diagnostic repeater is connected
to its segment DP2
A.4 1: Further measurement circuits at the segment, the other diagnostic repeater is connected
to its segment DP3
A.5 1: - -
A.6 1: Cause of error is not clearly identified
A.7 1: Critical message frame error rate
Bit Description
B.0 1:
B.1 1:
B.2 1: - -
B.3 1:
B.4 1:
B.5 1: - -
B.6 1:
B.7 1:
C.0 1: Segment automatically switched off due to continuous zero level on the line.
C.1 1: Segment automatically switched off due to constantly fluctuating line levels.
C.2 1: - -
C.3 1: - -
C.4 1: More than 32 nodes connected to the measurement segment
C.5 1: The distance between the node and the diagnostic repeater exceeds the permitted
line length
C.6 1: The maximum permitted number of diagnostic repeaters connected in series has been
exceeded
C.7 1: - -
The outgoing message will be generated when all segment bits are equal to zero.
Call HW Config to analyze details of events output by the diagnostic repeater.
An appropriate incoming/outgoing message will be generated for each segment (DP2 or
DP3) in response to the following events detected by a diagnostic repeater:
Bit Description
A.0 1: -
A.1 1:-
A.2 1: -
A.3 1: -
A.4 1: -
A.5 1: -
A.6 1: -
A.7 1:
B.0 1: Wire break at signal line A
B.1 1: Short-circuit to shielding at signal line B
B.2 1: -
B.3 1: Short-circuit to shielding at signal line A
B.4 1: Wire break at signal line B
B.5 1: -
B.6 1: Wire break at signal line A and/or B, or the terminating resistor is missing
B.7 1: Short-circuit signal line A <-> B, or an additional terminating resistor has been
installed
Bit Description
C.0 1: -
C.1 1: -
C.2 1: -
C.3 1: -
C.4 1: -
C.5 1: -.
C.6 1: -
C.7 1: -
Events detected by the diagnostics repeater are acquired synchronously in OB 82.
Diagnostic event data is fetched via SFB 54 in the OB_BEGIN block and written to the
structure DINFO. The function always sets only one bit to indicate the cause of an incoming
event. Bit C7 may also be set if the diagnostics repeater has detected further errors. In this
case, all previously reported events will be queued. DREP_L generates a corresponding
group error message via ALARM_8P. Flutter messages may occur, particularly in response
to error events A.0.1 and A.6.1. They are suppressed as follows :
After an outgoing message, a new outgoing message will be delayed by the time in [s] set at
the DELAY parameter. If a further fault is queued, the outgoing message will not be
generated until this fault is outgoing.
Error handling
The block evaluates the error information from ALARM_8P, and writes it to the
corresponding output parameters.
You will find additional information in the "Error information for output parameter
MSG_STATx (Page 322)" section.
The block reports a diagnostic error if an error occurs while reading the diagnostic data, or if
any other fault corrupts diagnostic data.
Startup characteristics
ALARM_8P messages are initialized by the DREP_L block. The current diagnostics
information is read from the diagnostics repeater using SFB 52 (RDREC).
Overload behavior
In the event of an overload, the upstream OB_DIAG1 block prevents DREP_L being called
for diagnostics.
Dynamic response:
Not available
Message response:
The multiple instance ALARM_8P are only called if a message is to be output by this
instance. It is only at this point that previously acknowledged messages are updated by the
corresponding ALARM block. If the connection to WinCC is down, each ALARM_8P instance
can hold up to two message statuses of its event ID. Flutter messages can be suppressed
via the DELAY input.
The block generates the messages listed below:
Additional information
For further information, refer to the following sections:
Message Texts and associated values of DREP_L (Page 65)
Maintenance status of MS (Page 326)
Additional information
For further information, refer to the following sections:
Message texts and associated values of DREP_L (Page 65)
Maintenance status of MS (Page 326)
Area of application
Block FM_CNT is used to configure and control FM 350-1 and FM 350-2 modules. It writes
the counter levels, limits and comparison values of the FM 350-2 module.
Calling OBs
OB 100 and the cyclic OB (100 ms recommended) used for transmitting data.
Also note the assignments (Page 325) to the FM_CO block.
Addressing
The logical base address of the module is entered in the LADDR I/O by the CFC driver
generator.
Redundancy
Higher-level block MOD_D1 evaluates the redundancy of DP master systems operating in an
H system. Redundancy for two FM 350-1 or FM 350-2 modules is not supported, and must
be controlled by the user outside the block.
MODE Setting
Signal states of the MODE_xx input, or QMODE_xx output of the FM_CNT block are
described under the MODE settings.
MODE_xx input parameters are available for up to 8 signal channels. Their default setting is
"0" (no signal). For each signal channel xx, the operating mode of the FM 350 module must
be set at the MODE_xx input (the CFC driver generator does this for you).
The module recognizes the following modes:
Continuous counting 16#xx01 The FM 350 counts continuously, starting with the
current counter level when the internal gate opens.
One-time counting 16#xx02 The FM 350 counts from the start value to the end
value when the internal gate opens.
Periodic counting 16#xx03 The FM 350 counts between the start value and the
end value when the internal gate opens.
Frequency measurement 16#xx04 The FM 350 determines the frequency pulse sequence
at the input.
Speed measurement 16#xx05 The FM 350 determines the speed of the device
connected to the input.
Period duration 16#xx06 The FM 350 determines the duration of the pulse
measurement sequence at the input.
Dosing 16#xx07 Four channels of the FM 350-2 are used for dosing.
The count and measured values can be recorded for the FM 350-2 module, either via the
process image(fast update) or via "Read data record" (slower update).
If the count and measured value of a channel are made available in the process image, they
must be aligned in the process image. The following variants are possible.
Error handling
The plausibility of input parameters is not checked.
Startup characteristics
Whenever the system or FM 350-1/FM 350-2 starts up, the block coordinates the restart with
the module. The CMP_VALx parameters are then loaded into the FM 350.
ALARM_8P is initialized.
Overload behavior
Not available
Time response
Not available
Message functionality
The block reports operating and data errors for the FM 350-1 module, and data errors for FM
350-2 using ALARM_8P. The message function can be disabled by setting EN_MSG =
FALSE. The MOD_D1 block reports diagnostic interrupts from the FM 350-1 or FM 350-2.
Additional information
You will find more information in:
Message texts and associated values of FM_CNT (Page 72)
Additional information
Additional information is available in the section:
Message texts and associated values of FM_CNT (Page 72)
Area of application
The IMDRV_TS block transfers time-stamped process signal changes to the MSG_TS
blocks, and messages from the interface module (IM) to the OS.
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 40 Hardware interrupt
OB 100 Restart (warm start)
Use in CFC
The following actions are executed automatically with the "Generate module drivers" CFC
function:
● The IMDRV_TS block is copied from the library and instantiated in a system chart. The
block is installed in its runtime group after the RACK block runtime group in the above-
mentioned OBs.
● OR_32_TS is always interconnected between MSG_TS and IMDRV_TS.
● The logical address LADDR is configured with the logical address of the IM (diagnostics
address). If you operate the DP master system in DPV1 mode, the input address of the
IM is entered.
● The RAC_DIAG structure of the RACK block is interconnected with the structure of the
same name of the IMDRV_TS block.
● The S_CH_xxx and TINF_xxx inputs of the TRIG_INF structure are set.
Every signal that is time-stamped by the IM has a unique assignment identified by the slot
of the module combined with the corresponding channel number. There are 128 inputs of
the WORD data type for 128 signals. The slot number of the relevant digital input module
is entered in the more significant byte and the channel number (signal of the digital input
module) is entered into the less significant byte. The slot and channel number of the
process signals are entered in the block inputs S_CH_xxx.
Example:
In HW Config, you have activated time-stamping for the digital signal of channel 10 of a
digital input module that is inserted in slot 5 of an ET 200M. The number 16#050A is
entered at the first available input S_CH_xxx of the IM_DRV_TS.
The information about the edge evaluation for the event entering state is stored in the
TINF_xxx parameters of the TRIG_INF structure.
0 means: 0 -> 1 is event entering state
1 means: 1 -> 0 is event entering state.
How it works
● Hardware interrupt (OB 40): The IM generates a hardware interrupt if there are new
messages. The time-stamp status, including the number of the IM data record to be
fetched and the number of messages in the data record, are fetched from the start
information of the process interrupt OB and stored for cyclic processing. The interrupt
stack can hold up to 17 process interrupts. If this maximum is exceeded, all new
information will be lost. The loss of information is indicated by the "Loss of message at IM
(buffer overflow)" message.
● Cyclic processing: If any messages are queued in the stack, SFB 52 (RDREC, read data
record) reads the relevant data record (message buffer). If there are several data records
to be fetched, it will fetch the record that contains the oldest messages (oldest hardware
interrupt). The block instance temporarily stores a maximum of 20 messages of a data
record.
The IM can enter new messages in a data record once it has been read. If all data
records are in use, the IM enters "Loss of message at IM (buffer overflow)" (incoming) as
the last message in the message buffer. "Loss of message at IM (buffer overflow)"
(outgoing) is then entered as the first message in the first free data record. Messages
received within the interval between a buffer overflow and the enabling of a record will be
lost.
The function compares the slot/channel number of the stored messages with the input
parameters of the slot/channel number block (S_CH_xxx). If they match, the message is
written to the corresponding output (TS_xxx).
Errors occurring during data exchange between the block and IM are reported by the
ALARM_8P block (for example, an I/O access error).
Addressing
For general information, see also Addressing (Page 323)
The logical address of the IM obtained in HW Config (corresponds to the diagnostic address,
or the input address of the IM for a DP master system in DPV1 mode) is entered at the
driver's block input (LADDR) by the "Generate module driver" CFC function. Any change to
the LADDR block input will initiate a single check of the logical address according to the
startup characteristics of the block.
Process signals that require a time stamp and are detected via an IM must be configured
accordingly in HW Config.
Error handling
I/O access error:
QPERAF The block could not access the IM. A data record could not be read.
Block processing error:
QBPARF Faulty block configuration: The slot/channel number of an IM message does not match
any slot/channel number of the block input parameters.
Rack error:
IM Startup Characteristics
During startup/restart of the IM, the system will generate process interrupts once again for
those records which were occupied prior to restart but had not been fetched.
The message "Startup data (incoming)" is entered as the first message of the first free data
record. After restart, the system checks all monitored digital signals for changes, outputs a
message if appropriate. It finally generates the message "Startup data (outgoing)".
Redundancy
Time stamping in H systems equipped with two IM units is redundant under the following
conditions:
● Both IM units communicate via the communication (K) bus.
● No error has occurred during the update of the active and passive IM.
The SUBNET and RACK blocks report loss of redundancy (failure of an IM), separately from
the IMDRV_TS block.
Time stamping is interrupted for the duration of the changeover between the active and
passive IM. This period of interruption is indicated by the message "Redundant changeover"
(incoming/outgoing state).
The active IM usually reports the current I/O status to the redundant IM. If this
communication is disrupted, the message "Loss of information with redundancy" (entering
state) is output. When the I/O statuses of the active and redundant IM are synchronized, the
message "Loss of information with redundancy" (outgoing) is output.
Time response
Not available
Message response
The block signals system messages from the IM via the ALARM_8P block. The time-
stamped hardware interrupts are forwarded to the MSG_TS IM message block via
OR_32_TS.
Additional information
You will find more information in:
Message texts of IMDRV_TS (Page 79)
Additional information
For further information, refer to the sections:
Message texts of IMDRV_TS (Page 79)
EV_ID
(ALARM_8P) 1 IM @1%d@@2%d@: Parameter assignment error S
Slot=@3%d@ Channel=@4%d@
2 IM @1%d@@2%d@: I/O access error: Ret_Val@5%d@ S
3 IM @1%d@@2%d@: Parameter assignment error LADDR S
4 IM @1%d@@2%d@: Output TS_xxx of S_CHxx: S
Slot=@3%d@ Channel=@4%d@ is not interconnected
5 Reserve5 No message
6 Reserve6 No message
7 Reserve7 No message
8 Reserve8 No message
EV_ID_00
(ALARM_8P) 1 IM @3%d@@4%d@: Startup data S
2 IM @3%d@@4%d@: Time-of-day frame failure S
3 No message
4 IM @3%d@@4%d@: Time difference between the frame and the S
internal clock may cause inaccuracy
5 IM @3%d@@4%d@: Stop the time stamp function S
6 IM @3%d@@4%d@: Message loss on IM (buffer overflow) S
7 IM @3%d@@4%d@: Redundant changeover S
8 IM @3%d@@4%d@: Loss of information with redundancy S
Area of application
The MOD_1 block monitors up to 16 channels on S7-300/400 SM modules without
diagnostic capability (no mixed modules). H systems support only the modules installed in
switched racks.
The block can also be used to monitor the FM 350 counter module.
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 83 Insert/remove module interrupt
OB 85 Program runtime error
OB 86 Rack failure
OB 100 Warm restart
Use in CFC
The following actions are executed automatically with the "Generate module drivers" CFC
function:
● The MOD_1 block is installed in its runtime group downstream of the RACK block runtime
group in the above-mentioned OBs.
● The MODE_xx inputs (mode of module channels xx) are configured.
● The logical base address of the LADDR module is configured.
● The OUT structures CPU_DIAG of the OB_BEGIN block and RAC_DIAG of the RACK
block are interconnected with the IN_OUT structures of the same name of MOD_1.
● The EN input is interconnected with the output of an AND block.
Its inputs are interconnected with the outputs EN_SUBx (x = number of the DP master
system) of the OB_BEGIN block, EN_Rxxx (xxx = rack/station number) of the SUBNET
block and EN_Mxx (xx = module number) of the RACK block.
● The output parameter of DXCHG_xx is interconnected with the following channel block at
the DataXchg parameter.
● The output parameter of O_MS is interconnected with the following channel block at the
MS parameter.
Function
The MOD_1 block analyzes all events that affect a module and its channels acyclically. It
generates a channel-specific MODE (Page 313) and value status for the signal processing
blocks. ALARM_8P reports the events.
The block is enabled by the higher-level RACK block at runtime. The event to be evaluated
can be found in the CPU_DIAG start information of the OB_DIAG block. There is a
MODE_xx input for each signal channel of the module. The module channel configuration
data created in HW Config is reported here. The function writes MODE_xx to the low word of
the OMODE_xx (Page 312) output parameter. This occurs only during startup or if you set
ACC_MODE = TRUE. The current channel value status is written to the most significant
byte. If the result is positive, the system sets OMODE_xx = 16#80xxxxxx.
The following events lead to the value status "invalid value due to higher-level error"
(OMODE_xx = 16#40xxxxxx):
● Events that are evaluated by the RACK block:
– Rack failure (OB 86) (output parameter QRACKF = TRUE)
● Events evaluated by the MOD block:
– Program execution error (OB 85) (output parameter QPERAF = TRUE)
– Module removed (OB 83) (output parameter QMODF = TRUE)
"Module removed" and "I/O access error" events are reported to the OS by ALARM_8P. The
diagnostic interrupt function distinguishes between module and channel errors, and each
channel is assigned a message ID.
The system verifies during startup that the module is available (plugged in). The module
status information read here is made available in the form of service output parameters
(MOD_INF).
You will find further information about faults in the System Software for S7-300/400 System
and Standard Functions reference manual.
Redundancy
The higher-level RACK block monitors the redundancy of DP master systems operating in an
H system.
MODE setting
For further information, refer to the section "MODE (Page 313) settings".
Note
If you make changes to the MODE_xx input configurations at runtime, they are not accepted
at the outputs until you set the ACC_MODE input to 1.
OMODE Structure
You will find further information in the "OMODE (Page 312)" section.
Addressing
You will find further information in the "Addressing (Page 323)" section.
Error handling
The plausibility of the input parameters is not checked.
You will find further information about error handling in the "Error information for output
parameter MSG_STAT (Page 322)" section.
Service Information
To analyze faults, the module status information entered during startup is read via the
structured MOD_INF output parameter. You will find further information in the System
Software for S7-300/400 System and Standard Functions; System Status List, Module
Status Information reference manual.
Startup characteristics
After a restart/initial startup, the system verifies that the module is available under its logical
base address. A restart (OB 100) is reported via the LSB in byte 2 of the OMODE_xx
(Page 312) ouptuts.
Time response
Not available
Message functionality
MOD_1 uses ALARM_8P to report module errors. The DELAY1 and DELAY2 inputs are
used to delay the reporting of I/O access error messages. DELAY1 allows you to enter a
time in seconds for which the block will wait for a higher-priority error (rack failure or
removal/insertion) following a program execution error (OB 85) before it outputs the
message. The message is output only under the condition that no higher-priority error is
reported within this delay time. DELAY2 determines the number of seconds the block waits
after the higher-priority error has been reported outgoing until it outputs the queued I/O
access error as well. The default of both values is 2 seconds.
The message function can be disabled by setting EN_MSG = FALSE.
Additional information
For further information, refer to the sections:
Message texts and associated values of MOD_1 (Page 86)
Maintenance status of MS (Page 326)
You will find more information on this in PCS 7 Advanced Process Library > Basics of APL >
General functions of the blocks > Operating, monitoring and reporting > Maintenance release
Additional information
For further information, refer to the sections:
Message texts and associated values of MOD_1/MOD_2 (Page 86)
Maintenance status of MS (Page 326)
See also
OMODE Settings for SM Modules (Page 312)
Assignment of message text and message class (Page 324) to the block parameters of
MOD_1/MOD_2/MOD_3/MOD_64
Area of application
The MOD_2 block monitors 32 channels on S7-300/400 SM modules without diagnostic
capability (no mixed modules). H systems support only the modules installed in switched
racks.
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 83 Insert/remove module interrupt
OB 85 Program runtime error
OB 86 Rack failure
OB 100 Warm restart
Use in CFC
The following actions are executed automatically with the "Generate module drivers" CFC
function:
● The MOD_2 block is installed in its runtime group downstream of the RACK block runtime
group in the above-mentioned OBs.
● The MODE_xx inputs (mode of module channels xx) are configured.
● The logical base address of the LADDR module is configured.
● The OUT structures CPU_DIAG of the OB_BEGIN block and RAC_DIAG of the RACK
block are interconnected with the IN_OUT structures of the same name of MOD_2.
● The EN input is interconnected with the output of an AND block.
Its inputs are interconnected with the outputs EN_SUBx (x = number of the DP master
system) of the OB_BEGIN block, EN_Rxxx (xxx = rack/station number) of the SUBNET
block and EN_Mxx (xx = module number) of the RACK block.
● The output parameter of DXCHG_xx is interconnected with the following channel block at
the DataXchg parameter.
● The output parameter of O_MS is interconnected with the following channel block at the
MS parameter.
Function
Block MOD_2 analyzes all events affecting a module and its channels in non-cyclic mode. It
generates a channel-specific MODE (Page 313) and value status for the signal processing
blocks. ALARM_8P reports the events.
The block is enabled to run by the higher-level RACK block. The event to be evaluated can
be found in the CPU_DIAG start information of the OB_DIAG block. There is a MODE_xx
input for each signal channel of the module. The module channel configuration data created
in HW Config is reported here. The function writes MODE_xx to the low word of the
OMODE_xx (Page 312) output parameter. This occurs only during startup or if you set
ACC_MODE = TRUE. The current channel value status is written to the most significant
byte. If the result is positive, the system sets OMODE_xx = 16#80xxxxxx.
The following events lead to the value status "invalid value due to higher-level error"
(OMODE_xx = 16#40xxxxxx):
● Events that are evaluated by the RACK block:
– Rack failure (OB 86) (output parameter QRACKF = TRUE)
● Events evaluated by the MOD block:
– Program execution error (OB 85) (output parameter QPERAF = TRUE)
– Module removed (OB 83) (output parameter QMODF = TRUE)
"Module removed" and "I/O access error" events are reported to the OS by ALARM_8P. The
diagnostic interrupt function distinguishes between module and channel errors, and each
channel is assigned a message ID.
The system verifies during startup that the module is available (plugged in). The module
status information read here provides this data in the form of service output parameters
(MOD_INF).
You will find further information about errors in the System Software for S7-300/40; System
and Standard Functions reference manual.
Redundancy
The higher-level RACK block monitors the redundancy of DP master systems operating in an
H system.
MODE setting
You will find more information about this in the "OMODE settings (Page 313)" section.
Note
If you change the parameter settings for the MODE_xx inputs at runtime, these changes will
not be accepted at the outputs until the ACC_MODE is set to 1.
OMODE Structure
You will find further information in the "OMODE (Page 312)" section.
Addressing
You will find further information about this in the "Addressing (Page 323)" section.
Error handling
The plausibility of the input parameters is not checked.
You will find further information about error handling in the "Error information for output
parameter MSG_STAT (Page 322)" section.
Service Information
To analyze faults, the module status information entered during startup is read via the
MOD_INF structured output parameter. You will find more information about this in the
System Software for S7-300/400 System and Standard Functions; System Status List,
Module Status Information reference manual.
Startup characteristics
After a restart/initial startup, the system verifies that the module is available under its logical
base address. A restart (OB 100) is reported via the LSB in byte 2 of the OMODE_xx
(Page 312) outputs.
Time response
Not available
Message functionality
MOD_2 uses ALARM_8P to report module errors. The DELAY1 and DELAY2 inputs are
used to delay the reporting of I/O access error messages. DELAY1 allows you to enter a
time in seconds for which the block will wait for a higher-priority error (rack failure or
removal/insertion) following a program execution error (OB 85) before it outputs the
message. The message is output only under the condition that no higher-priority error is
reported within this delay time. DELAY2 determines the number of seconds the block waits
after the higher-priority error has been reported outgoing until it outputs the queued I/O
access error as well. Both values are set to 2 seconds by default.
The message function can be disabled by setting EN_MSG = FALSE.
Additional information
For further information, refer to the sections:
Message texts and associated values of MOD_2 (Page 93)
Maintenance status of MS (Page 326)
You will find more information on this in PCS 7 Advanced Process Library > Basics of APL >
General functions of the blocks > Operating, monitoring and reporting > Maintenance release
Additional information
For further information, refer to the sections:
Message texts and associated values of MOD_1/MOD_2 (Page 93)
Maintenance status of MS (Page 326)
Assignment of message text and message class (Page 324) to the block parameters of
MOD_1/MOD_2/MOD_3/MOD_64
Area of application
The MOD_3 block monitors up to 16 channels on S7-300/400 SM mixed modules without
diagnostic capability (I/O modules). H systems support only the modules installed in
switched racks.
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 83 Insert/remove module interrupt
OB 85 Program runtime error
OB 86 Rack failure
OB 100 Warm restart
Function
The MOD_3 block cyclically analyzes all events that affect a module. It generates a channel-
specific MODE (Page 313) and value status for the signal processing blocks. ALARM_8P
reports the events. The message function can be disabled.
The block is enabled to run by the higher-level RACK block. The diagnostic event is entered
in the CPU_DIAG start information of the OB_BEGIN block.
There is a MODE_xx input for each signal channel of the module. The module channel
configuration data created in HW Config is reported here. MODE_00 to MODE_15 inputs are
available for encoding up to 16 input channels, and MODE_16 … MODE_31 for encosing up
to 16 output channels.
The function writes MODE_xx to the low word of the OMODE_xx (Page 312) output
parameter. This occurs only during startup or if you set ACC_MODE = TRUE. The current
channel value status is written to the most significant byte. If the result is positive, the system
sets OMODE_xx = 16#80xxxxxx.
The following events lead to the value status "invalid value due to higher-level error"
(OMODE_xx = 16#40xxxxxx):
● Events that are evaluated by the RACK block:
– Rack failure (OB 86) (output parameter QRACKF = TRUE)
– Program execution error (OB 85) (output parameter QRACKF = TRUE)
● Events that are evaluated by the MOD block:
– I/O access error (OB 85) (output parameter QPERAF = TRUE)
– Module removed (OB 83) (output parameter QMODF = TRUE)
"Module removed" and "I/O access error" events are reported to the OS by ALARM_8P. The
diagnostic interrupt function distinguishes between module and channel errors, and each
channel is assigned a message ID.
The system verifies during startup that the module is available (plugged in). The module
status information read here makes this data available in the form of service output
parameters (MOD_INF).
You will find further information about faults in the System Software for S7-300/400 System
and Standard Functions reference manual.
Redundancy
Block MOD_3 supports segment redundancy of H systems operating with distributed I/Os. If
you want to use this function, you must configure the SUBN1_ID (connection to CPU 0) and
SUBN2_ID (connection to CPU 1) inputs of the SUBNET block with the numbers of the
redundant segments. If there is no segment redundancy, the remaining input must be set to
the (default) value 16#FF.
MODE setting
You will find more information about this in the "OMODE settings (Page 313)" section.
Note
If you change the parameter settings for the MODE_xx inputs at runtime, these changes will
not be accepted at the outputs until the ACC_MODE is set to 1.
OMODE Structure
You will find further information in the "OMODE (Page 312)" section.
Addressing
You will find further information about this in the "Addressing (Page 323)" section.
Error handling
The plausibility of the input parameters is not checked.
You will find further information about error handling in the "Error information for output
parameter MSG_STAT (Page 322)" section.
Service Information
To analyze faults, the module status information entered during startup is read via the
MOD_INF structured output parameter. You will find more information about this in the
reference manual System Software for S7-300/400 System and Standard Functions; System
Status List, Module Status Information.
Startup characteristics
After a restart/initial startup, the system verifies that the module is available under its logical
base address. A restart (OB 100) is reported via the LSB in byte 2 of the OMODE_xx
(Page 312) ouptuts.
Time response
Not available
Message functionality
Block MOD_3 uses ALARM_8P to report module errors. The DELAY1 and DELAY2 inputs
are used to delay the reporting of I/O access error messages. DELAY1 allows you to enter a
time in seconds for which the block will wait for a higher-priority error (rack failure or
removal/insertion) following a program execution error (OB 85) before it outputs the
message. DELAY2 determines the number of seconds the block waits after the higher-
priority error has been reported outgoing until it outputs the queued I/O access error as well.
The default value in both cases is 2 seconds. The message function can be disabled by
setting EN_MSG = FALSE.
Additional information
For further information, refer to the sections:
Message texts and associated values of MOD_3 (Page 100)
Maintenance status of MS (Page 326)
You will find more information on this in PCS 7 Advanced Process Library > Basics of APL >
General functions of the blocks > Operating, monitoring and reporting > Maintenance release
Additional information
For further information, refer to the following sections:
Message texts and associated values of MOD_3 (Page 100)
Maintenance status of MS (Page 326)
Assignment of message text and message class (Page 324) to the block parameters of
MOD_1/MOD_2/MOD_3/MOD_64
Area of application
Block MOD_4 monitors modules (up to 16 channels) of an ET 200S acting as a DPV0 slave
(IM 151 High Feature) downstream of a Y link.
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 82 Diagnostic interrupt
OB 83 Insert/remove module interrupt
OB 85 Program runtime error
OB 86 Rack failure
OB 100 Warm restart
● The DPA_M input is interconnected with the DPA_Mxx (xx= module slot number in the
ET 200S) output of the DPDIAGV0 block.
● The output parameter of DXCHG_xx is interconnected with the following channel block at
the DataXchg parameter.
● The output parameter of O_MS is interconnected with the following channel block at the
MS parameter.
Function
Block MOD_4 analyzes all events related to an ET 200S module acyclically. It generates a
channel-specific MODE (Page 313) and value status for the signal processing blocks.
ALARM_8P reports events separately for each module.
The block enabled to run by the higher-level DPDIAGV0 block. The event to be evaluated is
available at input DPA_M. Possible byte assignments:
0000000 = Module OK
0000001 = Module error
0000010 = Wrong module
0000011 = Module missing
00001xx = ET 200S failure; x = irrelevant
There is a MODE_xx input for each signal channel of the module. The module channel
configuration data created in HW Config is reported here. The function writes MODE_xx to
the low word of the OMODE_xx (Page 312) output parameter. This only occurs if the module
status changes during startup, or if you set ACC_MODE = TRUE. The current channel value
status is written to the most significant byte. If the result is positive, the system sets
OMODE_xx = 16#80xxxxxx.
The following events will lead to the value status "invalid value due to higher-level error"
(OMODE_xx = 16#40xxxxxx):
● Events that are evaluated by the OB_DIAG1 block:
– Rack failure (OB 86,OB 83) (output parameter QRACKF = TRUE)
● Events that are evaluated by the MOD block:
– Module diagnostics (OB 82) (output parameter QMODF = TRUE)
ALARM_8P is used to report "Module error ", "Wrong module " or "Module missing " events
to the OS.
Redundancy
You can not use redundant DP slaves downstream of a Y link.
MODE setting
You will find more information about this in the "OMODE settings (Page 313)" section.
Note
If you change the parameter settings for the MODE_xx inputs at runtime, these changes will
not be accepted at the outputs until the ACC_MODE is set to 1.
OMODE Structure
You will find further information in the "OMODE (Page 312)" section.
Addressing
You will find further information about this in the "Addressing (Page 323)" section.
Error handling
The plausibility of input parameters is not checked.
You will find further information about error handling in
"Error information for output parameter MSG_STAT (Page 322)".
Startup characteristics
A restart (OB 100) is reported via the LSB in byte 2 of the OMODE_xx (Page 312) outputs.
Time response
Not available
Message functionality
MOD_4 uses ALARM_8P to report module errors. The message function can be disabled by
setting EN_MSG = FALSE.
The block generates the maintenance status MS.
Additional information
For further information, refer to the sections:
Message texts and associated values of MOD_4 (Page 106)
Maintenance status of MS (Page 326)
You will find more information on this in PCS 7 Advanced Process Library > Basics of APL >
General functions of the blocks > Operating, monitoring and reporting > Maintenance release
Additional information
For further information, refer to the following sections:
Message texts and associated values of MOD_4 (Page 106)
Maintenance status of MS (Page 326)
Area of application
The MOD_64 block monitors 64 channels on S7-300 SM modules without diagnostic
capability (no mixed modules). H systems support only the modules installed in switched
racks.
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 83 Insert/remove module interrupt
OB 85 Program execution error
OB 86 Rack failure
OB 100 Warm restart
● The output parameter of DXCHG_xx is interconnected with the following channel block at
the DataXchg parameter.
● The output parameter of O_MS is interconnected with the following channel block at the
MS parameter.
Function
The MOD_64 block analyzes all events that affect a module and its channels acyclically. It
generates a channel-specific MODE (Page 313) and value status for the signal processing
blocks. ALARM_8P reports the events.
The block is enabled to run by the higher-level RACK block. The event to be evaluated can
be found in the CPU_DIAG start information of the OB_DIAG block. There is a MODE_xx
input for each signal channel of the module. The module channel configuration data created
in HW Config is reported here. The function writes MODE_xx to the low word of the
OMODE_xx (Page 312) output parameter. This occurs only during startup or if you set
ACC_MODE = TRUE. The current channel value status is written to the most significant
byte. If the result is positive, the system sets OMODE_xx = 16#80xxxxxx.
The following events will lead to the value status "invalid value due to higher-level error"
(OMODE_xx = 16#40xxxxxx):
● Events that are evaluated by the RACK block:
– Rack failure (OB 86) (output parameter QRACKF = TRUE)
● Events that are evaluated by the MOD block:
– Program execution error (OB 85) (output parameter QPERAF = TRUE)
– Module removed (OB 83) (output parameter QMODF = TRUE)
"Module removed" and "I/O access error" events are reported to the OS by ALARM_8P. The
diagnostics interrupt function distinguishes between module and channel errors, whereby
each channel is assigned a message ID.
The system verifies during startup that the module is available (plugged in). The module
status information that is read here is then available in the form of service output parameters
(MOD_INF).
You will find further information about errors in the System Software for S7-300/40; System
and Standard Functions reference manual.
Redundancy
The higher-level RACK block monitors the redundancy of DP master systems operating in an
H system.
MODE setting
You will find more information about this in the "OMODE settings (Page 313)" section.
Note
If you change the parameter settings for the MODE_xx inputs at runtime, these changes will
not be accepted at the outputs until the ACC_MODE is set to 1.
OMODE Structure
You will find additional information in the "OMODE (Page 312)" section.
Addressing
You will find additional information in the "Addressing (Page 323)" section.
Error handling
The plausibility of input parameters is not checked.
You will find additional information about error handling in the "Error information for output
parameter MSG_STAT (Page 322)" section.
Service Information
To analyze faults, the module status information entered during startup is read via the
MOD_INF structured output parameter. You will find more information about this in the
reference manual System Software for S7-300/400 System and Standard Functions; System
Status List, Module Status Information.
Startup characteristics
After a restart/initial startup, the system verifies that the module is available under its logical
base address. A restart (OB 100) is reported via the LSB in byte 2 of the OMODE_xx
(Page 312) outputs.
Time response
Not available
Message functionality
MOD_64 uses ALARM_8P to report module errors. The DELAY1 and DELAY2 inputs are
used to delay the reporting of I/O access error messages. DELAY1 allows you to enter a
time in seconds for which the block will wait for a higher-priority error (rack failure or
removal/insertion) following a program execution error (OB 85) before it outputs the
message. The message is output only under the condition that no higher-priority error is
reported within this delay time. DELAY2 determines the number of seconds the block waits
after the higher-priority error has been reported outgoing until it outputs the queued I/O
access error as well. Both values are set to 2 seconds by default.
The message function can be disabled by setting EN_MSG = FALSE.
Additional information
For further information, refer to the following sections:
Message texts and associated values of MOD_64 (Page 113)
Maintenance status of MS (Page 326)
You will find more information on this in PCS 7 Advanced Process Library > Basics of APL >
General functions of the blocks > Operating, monitoring and reporting > Maintenance release
Additional information
For further information, refer to the following sections:
Message texts and associated values of MOD_64 (Page 113)
Maintenance status of MS (Page 326)
Assignment of message text and message class (Page 337) to the block parameters of
MOD_1/MOD_2/MOD_3/MOD_64
See also
Message Classes (Page 324)
Area of application
Block MOD_CP monitors a CP 341 or CP 441 serial communication module. H systems only
support modules in switched racks.
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 82 Diagnostic interrupt
OB 83 Insert/remove module interrupt
OB 85 Program runtime error
OB 86 Rack failure
OB 100 Warm restart
Redundancy
The higher-level RACK block monitors the redundancy of DP master systems operating in an
H system.
Error handling
The plausibility of the input parameters is not checked.
Startup characteristics
After a restart/initial startup, the system verifies that the module is available under its logical
base address. A restart (OB 100) is reported via the LSB in byte 2 of the OMODE_xx
(Page 312) outputs.
Overload behavior
The MOD_CP block counts the OB 82 calls. The counter is reset in OB 1. If more than five
OB 82 events occur in succession before the cycle control point is reached (OB 1), these
events are rejected and the message "OB 82 DP master failure: x Rack: y Slot: z" is output.
Time response
Not available
Message functionality
MOD_CP uses ALARM_8P to report module errors. The DELAY1 and DELAY2 inputs are
used to delay the reporting of I/O access error messages. DELAY1 allows you to enter a
time in seconds for which the block will wait for a higher-priority error (rack failure or
removal/insertion) following a program execution error (OB 85) before it outputs the
message. The message is output only under the condition that no higher-priority error is
reported within this delay time. DELAY2 determines the number of seconds the block waits
after the higher-priority error has been reported outgoing until it outputs the queued I/O
access error as well. Both values are set to 2 seconds by default.
The message function can be disabled by setting EN_MSG = FALSE.
Additional information
For further information, refer to the following sections:
Message texts and associated values of MOD_CP (Page 118)
Maintenance status of MS (Page 326)
Additional information
For further information, refer to the following sections:
Message texts and associated values of MOD_CP (Page 118)
Maintenance status of MS (Page 326)
Area of application
The MOD_D1 block monitors up to 16-channel S7-300/400 SM modules with diagnostic
capability (no mixed modules), and the power supplies of an ET 200iSP in a redundant
configuration. H systems support only the modules installed in switched racks.
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 82 Diagnostic interrupt
OB 83 Insert/remove module interrupt
OB 85 Program execution error
OB 86 Rack failure
OB 100 Warm restart
The diagnostic interrupt function distinguishes between module and channel errors, and
each channel is assigned a message ID. Only one incoming/outgoing event can be reported
for each channel. As long as an incoming message is queued at a channel, further
messages on new events at this channel will be lost.
If the event is defined uniquely in the diagnostic information, the corresponding text will be
entered in the message. If there are ambiguous entries, the text of the first set bit in the error
byte of the diagnostic information will be displayed. When using modules assigned
diagnostic functions and more than one error byte for diagnostic information, only the
channel xx error text will be output if the error information is not displayed in the first error
byte.
The system verifies during startup that the module is available (plugged in). The module
status information read here makes this data available in the form of service output
parameters (MOD_INF).
Detailed information about the errors is entered in the DIAG_INF output parameter of data
type STRUCT. You will find more information about this in the reference manual System
Software for S7-300/400 System and Standard Functions; Diagnostic Data, Byte 0 to Byte 8,
Structure of Channel-Specific Diagnostic Data.
Note
If you run a HART module in HART MODE (Page 313) =16#070C, any HART protocol
errors/configuration changes will be masked by the MOD_D1 driver block, and will not be
signaled as channel errors.
Redundancy
The higher-level RACK block monitors the redundancy of DP master systems operating in an
H system.
MODE setting
You will find more information about this in the "OMODE settings (Page 313)" section.
Note
If you change the parameter settings for the MODE_xx inputs at runtime, these changes will
not be accepted at the outputs until the ACC_MODE is set to 1.
OMODE Structure
You will find further information in the "OMODE (Page 312)" section.
Addressing
You will find more information about this in "Addressing (Page 323)".
HART modules with read/write access to the process image are configured in the same way
as input modules. The set I/O range must always be identical.
Example: SM332 AO 2x0/4..20mA HART 332-5TB00-0AB0:
Error handling
The plausibility of input parameters is not checked.
You will find further information about error handling in the "Error information for output
parameter MSG_STAT (Page 322)" section.
Service Information
To analyze faults, the module status information entered during startup is read via the
MOD_INF structured output parameter. You will find more information about this in the
reference manual System Software for S7-300/400 System and Standard Functions; System
Status List, Module Status Information.
Following a diagnostic interrupt, you will also find detailed module diagnostic information in
the MODDIAG0 to MODDIAG8 output parameters. You will find more information in the
reference manual System Software for S7-300/400 System and Standard Functions;
Diagnostic Data, Byte 0 to Byte 8.
The CHDIAG00 to CHDIAG15 output parameters contain detailed channel-status
information. You will find more information in the reference manual System Software for
S7-300/400 System and Standard Functions; Structure of Channel-Specific Diagnostic Data.
The system resets this diagnostic information after a diagnostic interrupt has been reported
outgoing (no further channel or module errors are queued).
Startup characteristics
After a restart/initial startup, the system verifies that the module is available under its logical
base address. A restart (OB100) is reported via the LSB in byte 2 of the OMODE_xx
(Page 312) outputs.
Overload behavior
The MOD_D1 block counts the OB82 calls. The counter is reset in OB1. If more than two
OB82 events occur in succession before the cycle control point is reached (OB1), these
events are rejected, and the message "OB82 DP master failure: x Rack: y Slot: z" is output.
Time response
Not available
Message functionality
MOD_D1 uses ALARM_8P_1 to report module errors. The function also calls ALARM_8P_2
and ALARM_8P_3 which are intended for channel errors. The DELAY1 and DELAY2 inputs
are used to delay the reporting of I/O access error messages. DELAY1 allows you to enter a
time in seconds for which the block will wait for a higher-priority error (rack failure or
removal/insertion) following a program execution error (OB85) before it outputs the
message. The message is output only under the condition that no higher-priority error is
reported within this delay time. DELAY2 determines the number of seconds the block waits
after the higher-priority error has been reported outgoing until it outputs the queued I/O
access error as well. Both values are set to 2 seconds by default.
The message function can be disabled by setting EN_MSG = FALSE.
Additional information
For further information, refer to the following sections:
Message texts and associated values of MOD_D1 (Page 127)
Maintenance status of MS (Page 326)
You will find more information on this in PCS 7 Advanced Process Library > Basics of APL >
General functions of the blocks > Operating, monitoring and reporting > Maintenance release
Additional information
For further information, refer to the following sections:
Message texts and associated values of MOD_D1 (Page 127)
Message texts and associated values of MOD_D2 (Page 137)
Maintenance status of MS (Page 326)
Area of application
Block MOD_D2 monitors up to 32 channels on S7-300/400 SM modules with diagnostic
capability (no mixed modules). H systems support only the modules installed in switched
racks.
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 82 Diagnostic interrupt
OB 83 Insert/remove module interrupt
OB 85 Program runtime error
OB 86 Rack failure
OB 100 Warm restart
The diagnostic interrupt function distinguishes between module and channel errors, and
each channel is assigned a message ID. Only one incoming or outgoing event can be
reported for each channel. As long as an incoming message is queued at a channel, further
messages on new events at this channel will be lost.
If the event is defined uniquely in the diagnostic information, the corresponding text will be
entered in the message. If ambiguous entries exist, the text of the first set bit in the error byte
of the diagnostic information will be displayed. When using modules assigned diagnostic
functions and more than one error byte for diagnostic information, only the channel xx error
text will be output if the error information is not displayed in the first error byte.
The system verifies during startup that the module is available (plugged in). The module
status information read here makes this data available in the form of service output
parameters (MOD_INF).
Detailed information about the errors is entered in the DIAG_INF output parameter of data
type STRUCT. You will find further information about this in the reference manual System
Software for S7-300/400 System and Standard Functions; Diagnostic Data, Byte 0 to Byte 8,
Structure of Channel-Specific Diagnostic Data.
Redundancy
The block supports segment redundancy of CPU 417H for distributed I/Os. The SUBN1_ID
(connection to CPU 0) and SUBN2_ID (connection to CPU 1) inputs are configured with the
numbers of the redundant segments. If there is no segment redundancy, the remaining input
must be set to the (default) value 16#FF.
MODE setting
You will find more information about this in the "OMODE settings (Page 313)" section.
Note
If you change the parameter settings for the MODE_xx inputs at runtime, these changes will
not be accepted at the outputs until the ACC_MODE is set to 1.
OMODE Structure
You will find further information in the "OMODE (Page 312)" section.
Addressing
You will find further information in "Addressing (Page 323)".
Error handling
The plausibility of the input parameters is not checked.
You will find further information about error handling in "Error information for output
parameter MSG_STAT (Page 322)".
Service Information
To analyze faults, the module status information entered during startup is read via the
MOD_INF structured output parameter. You will find more information about this in the
reference manual System Software for S7-300/400 System and Standard Functions; System
Status List, Module Status Information.
Following a diagnostic interrupt, you will also find detailed module diagnostic information in
the MODDIAG0 to MODDIAG10 output parameters. You will find more information in the
reference manual System Software for S7-300/400 System and Standard Functions;
Diagnostic Data, Byte 0 to Byte 10.
The CHDIAG00 to CHDIAG31 output parameters contain detailed channel status
information. You will find more information in the reference manual System Software for S7-
300/400 System and Standard Functions; Structure of Channel-Specific Diagnostic Data.
The system resets this diagnostic information after a diagnostic interrupt has been reported
outgoing (no further channel or module errors are queued).
Startup characteristics
After a restart/initial startup, the system verifies that the module is available under its logical
base address. A restart (OB100) is reported via the LSB in byte 2 of the OMODE_xx
(Page 312) outputs.
Time response
Not available
Message functionality
MOD_D2 uses ALARM_8P_1 to report module errors. In addition, the error blocks
ALARM_8P_2, ALARM_8P_3, ALARM_8P_4 and ALARM_8P_5 are called. The DELAY1
and DELAY2 inputs are used to delay the reporting of I/O access error messages. DELAY1
allows you to enter a time in seconds for which the block will wait for a higher-priority error
(rack failure or removal/insertion) following a program execution error (OB85) before it
outputs the message. The message is output only under the condition that no higher-priority
error is reported within this delay time. DELAY2 determines the number of seconds the block
waits after the higher-priority error has been reported outgoing until it outputs the queued I/O
access error as well. Both values are set to 2 seconds by default.
The message function can be disabled by setting EN_MSG = FALSE.
Additional information
For further information, refer to the following sections:
Message texts and associated values of MOD_D2 (Page 137)
Maintenance status of MS (Page 326)
You will find more information on this in PCS 7 Advanced Process Library > Basics of APL >
General functions of the blocks > Operating, monitoring and reporting > Maintenance release
Additional information
For further information, refer to the following sections:
Message texts and associated values of MOD_D1 (Page 127)
Message texts and associated values of MOD_D2 (Page 137)
Maintenance status of MS (Page 326)
See also
MODE Settings for SM Modules (Page 313)
OMODE Settings for SM Modules (Page 312)
Area of application
Block MOD_D3 monitors a maximum of up to 16 channels on S7-300 SM modules with
diagnostics functions. H systems support only the modules installed in switched racks.
MOD_D3 includes all the functionality of MOD_D1, plus additional functions for diagnostic
evaluation of multiple channel types in a diagnostic data record. The block also fully supports
4-byte channel-specific diagnostics.
Note: MOD_D1 only evaluated 8 selected bits of the 4-byte channel-specific diagnosis.
The modules supported are the ET 200PRO modules:
6ES7148 4FC00 0AB0 -> 8DI/4DO
6ES7148 4FA00 0AB0 -> 8/16 DI
and the ET 200M HART modules:
6ES7331-7TF01-0AB0 -> AI8 HART
6ES7332-8TF01-0AB0 -> AO8 HART
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 82 Diagnostic interrupt
OB 83 Insert/remove module interrupt
OB 85 Program execution error
OB 86 Rack failure
OB 100 Warm restart
● Overload
● Hardware interrupt
● Actuator warning
● Safety shutdown
● Ambiguous error
● Error 1 in actuator/sensor
● Error 2 in actuator/sensor
● Channel temporarily not available
ALARM_8P is used to report "Module removed", "I/O access error" and "Diagnostics
interrupt" events to the OS.
The diagnostics interrupt function distinguishes between module and channel errors,
whereby each channel is assigned a message ID. Only one incoming/outgoing event can be
reported for each channel. As long as an incoming message is queued at a channel, further
messages on new events at this channel will be lost.
If the event is defined uniquely in the diagnostic information, the corresponding text will be
entered in the message. If ambiguous entries exist, the text of the first set bit in the error byte
of the diagnostic information will be displayed. When using modules assigned diagnostic
functions and more than one error byte for diagnostic information, only the channel xx error
text will be output if the error information is not displayed in the first error byte.
The system verifies during startup that the module is available (plugged in). The module
status information read here provides this data as service output parameters (MOD_INF).
Detailed information about the errors is entered in the DIAG_INF output parameter of data
type STRUCT. You will find more information about this in the reference manual System
Software for S7-300/400 System and Standard Functions; Diagnostic Data, Byte 0 to Byte 8,
Structure of Channel-Specific Diagnostic Data.
Note
Even if you run a HART module in HART MODE =16#070C, any HART protocol
errors/configuration changes that may occur will be masked by the MOD_D3 block, and not
signaled as channel errors.
Several channel types can occur in one diagnostic data record. If the "further channel types
exist" bit is set, MOD_D3 runs through the entire diagnostic evaluation and handles reporting
for each further channel type.
HART modules with the firmware update and the new additional channel type 16#66 for
measured value calibration are also supported.
The new HART channel type 66 can also occur in the diagnostic data record as a further
channel type.
The new diagnostic data ("channel being calibrated" and "channel temporarily not available")
are considered as channel errors and output. The detailed texts are output via the system
text library and a corresponding associated value.
Channel type 0x66:
1 byte channel diagnostics
Bit0 channel being calibrated
Bit1 channel temporarily not available
Firmware update
The firmware update for the listed HART modules is started by a diagnostic event "OB83
entering state" (remove module) followed directly by diagnostic event "OB83 exiting state"
(insert module). With "OB83 exiting state", byte 2 bit 2 is set in data record 0 (1 = STOP
mode).
Once the firmware is completed, there is a repeated diagnostic event "OB83 entering state"
(remove module) followed directly by diagnostic event "OB83 exiting state" (insert module).
With "OB83 exiting state", byte 2 bit 2 is reset in data record 0 (0 = RUN mode).
In MOD_D3, after an "OB83 exiting state" (module removed) the data record 0 (DS0) is
always read extra in OB1 using SFC51 and SZL 00B1 to establish whether bit (1 = STOP
mode) is set. If this is the case, this is always recognized as a firmware update and the
module continues to be indicated as removed and not available. Only when there is an OB83
(module inserted) with the information in DS0 (0 = RUN mode), is the module indicated as
being inserted and available again.
It is assumed that "Module change in run" is always set for the ET 200M head modules so
that a firmware update of the HART module always calls an OB83. This means that a
firmware update cannot trigger an OB86 diagnostic interrupt.
The "Generate module driver" function enters 16#0001 in the Feature01 parameter for both
HART modules. This means that DS0 is read extra when there is an OB 83 exiting state only
when Feature01 = 16#0001
The Feature parameters (FEATURE_01 .. FEATURE_10) are intended for future expansions
of the MOD_D3 block and for parameter settings for special module situations.
Currently only FEATURE_01 is used as an ID for HART module with a firmware update in
RUN.
Redundancy
The higher-level RACK block monitors the redundancy of DP master systems operating in an
H system.
MODE Setting
You will find more information about this in the "OMODE settings (Page 313)" section.
Note
If you change the parameter settings for the MODE_xx inputs at runtime, these changes will
not be accepted at the outputs until the ACC_MODE is set to 1.
OMODE Structure
You will find more information about this in the "OMODE settings (Page 312)" section.
Addressing
You will find more information about this in "Addressing (Page 323)".
HART modules with read/write access to the process image are configured in the same way
as input modules. The set I/O range must always be identical.
Example: SM 332 AO 2x0/4..20mA HART 332-5TB00-0AB0:
Address input range (HW Config) Address output range (HW Config) LADDR (decimal/hex)
544 544 544 / 16#0220
Error handling
The plausibility of the input parameters is not checked.
You will find more information about error handling in "Error information of output parameter
MSG_STAT" (Page 322).
Service Information
To analyze faults, the module status information entered during startup is read via the
MOD_INF structured output parameter. You will find more information about this in the
reference manual System Software for S7-300/400 System and Standard Functions; System
Status List, Module Status Information.
Following a diagnostic interrupt, you will also find detailed module diagnostic information in
the MODDIAG0 to MODDIAG8 output parameters. You will find more information in the
reference manual System Software for S7-300/400 System and Standard Functions;
Diagnostic Data, Byte 0 to Byte 8.
The CHDIAG00 to CHDIAG15 output parameters contain detailed channel-status
information. You will find more information in the reference manual System Software for S7-
300/400 System and Standard Functions; Structure of Channel-Specific Diagnostic Data.
The system resets this diagnostic information after a diagnostic interrupt has been reported
outgoing (no further channel or module errors are queued).
Startup characteristics
After a restart/initial startup, the system verifies that the module is available under its logical
base address. A restart (OB100) is reported via the LSB in byte 2 of the OMODE_xx ouptuts.
Overload Behavior
The MOD_D3 block counts the OB82 calls. The counter is reset in OB1. If more than two
OB82 events occur in succession before the cycle control point is reached (OB1), these
events are rejected and the message "OB82 DP master failure: x Rack: y Slot: z" is output.
Time response
Not available
Message response
MOD_D3 uses ALARM_8P_1 to report module errors. The function also calls ALARM_8P_2
and ALARM_8P_3 which are intended for channel errors. The inputs DELAY1 and DELAY2
are used to delay the output of I/O access error messages. DELAY1 allows you to enter a
time in seconds for which the block will wait for a higher-priority error (rack failure or
removal/insertion) following a program execution error (OB85) before it outputs the
message. The message is output only under the condition that no higher-priority error is
reported within this delay time. DELAY2 determines the number of seconds the block waits
after the higher-priority error has been reported outgoing until it outputs the queued I/O
access error as well. Both values are set to 2 seconds by default.
The message function can be disabled by setting EN_MSG = FALSE.
Additional information
You will find more information in:
Message texts and associated values of MOD_D3 (Page 148)
Maintenance status of MS (Page 326)
You will find more information on this in PCS 7 Advanced Process Library > Basics of APL >
General functions of the blocks > Operating, monitoring and reporting > Maintenance release
Additional information
You will find more information in:
Message texts and associated values of MOD_D3 (Page 148)
Maintenance status of MS (Page 326)
Area of application
The MOD_HA block reports diagnostic events for a HART field device that is connected to a
channel of an SM 300 HART module (6ES7331-7TB00-0AB0 or 6ES7332-5TB00-0AB0) (ET
200M) or ET 200iSP HART module (6ES7134-7TD00-0AB0, 6ES7134-7TD50-0AB0 or
6ES7135-7TD00-0AB0). H systems support only the modules installed in switched racks.
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 82 Diagnostic interrupt
OB 83 Insert/remove module interrupt
OB 85 Program execution error
OB 86 Rack failure
OB 100 Warm restart
Bit Meaning
0 Parameter assignment error (HART module)
1 HART communications error (HART module)
2 Readback error (HART module)
3 Short circuit (HART module)
4 Wire break (HART module)
5 No load voltage (HART module)
6 Overflow (HART module)
7 Underflow (HART module)
Bit Meaning
0 Primary variable outside limits (field device)
1 Secondary variable outside limits (field device)
2 Analog output saturated (field device)
3 Analog output current specified (field device)
4 More statuses available (field device)
5 Reserved for maintenance alarm (field device)
6 Reassignment the field device parameters
7 Malfunction of the field device
For an ET 200M with two-channel HART modules, channel type 16#61 or 16#63 is
generated during diagnostics. Bit 5 in byte 8 for channel 0 and byte 9 for channel 1 in the
additional alarm information means "HART channel error". If bit 5 = TRUE, the additional
diagnostic data is read with SFB 52 (RDREC) as follows:
● with data record 128 for channel 0
● with data record 129 for channel 1
Diagnostic data records 128 (for channel 0) and 129 (for channel 1) have the same structure.
and return detailed HART diagnostic information on the previous transfer. The table below
shows the individual error messages/warnings.
(Note: The table in the PCS 7 Library manual is clearer and easier to read because the
tables have lines, in contrast to the online help.)
Byte/Bit No. 7 6 5 4 3 2 1 0
0: general 1= Mod. No. of (triggering) client, Polling address (of HART transducer),
comm. when module comm. no. =0 always 0 for monodrop
1: fault groups Channel HART HART HART device status more status Command 0 = Not
= group error fault channel slave command <> 0 (e.g., rejected used
(L+, fault communi- error configuration
DrBr) cation changed)
then bytes - 2 8 8 9 - - -
2: HART cf = HART parity overrun framing wrong Wrong char too many wrong
"communication access error in error in error in checksum in timing chars in telegram
faults" not response response response response response timing
possible
Field device for
module
3 to 6: time Broadcast system time: Milliseconds (10s and 100s), seconds, minutes, and hours in two-digit BCD
stamp code. If the timestamp function is not used: Content = 0
7: HART/module last HART or module command
8: HART ce 1 "Communication error bits" of "slave", (first status byte)
0 "Command response" list - no errors, but warnings
9: HART ds Device status bits (second status byte)
Two HART status bytes are reserved in the HART protocol to display errors and warnings.
These are entered in diagnostic data records 128 and 129 unchanged. The meaning of the
HART status bytes is defined in the HART Standard.
● Second HART status byte: Device status of the HART field device in the event of a
communication error
(otherwise, byte = 0)
Bit No. 7 6 5 4 3 2 1 0
HART Malfunction Reassignment Cold Further Analog output Analog Non-primary Primary
device of the field of parameters: restart status current output variable variable
status: device "configuration available specified saturated outside outside limits
"field changed (CC)" "more ("fixed)" limits
device status"
status"
Process control messages are generated when "communication errors" and HART field
device errors (byte 9 <> 0) occur. Operating messages with acknowledgement are
generated if bit 7 = 0 (byte 8) and the remaining bits <> 0. The last read data record 128 or
129 (depending on the channel number) is written to the output structure DIAG_H.
Bytes 8 and 9 are evaluated and event messages generated in OB1.
You will find further information in "Message texts and associated values of MOD_HA
(Page 158)".
The MODE input is interconnected with the corresponding OMODE_xx output of the
MOD_D1 block. The module channel configurations set in HW Config are reported at these
locations. MODE (Page 313) is written to the low word of theOMODE (Page 312) output
parameter. This occurs only during startup or if you set ACC_MODE = TRUE. The current
channel value status is written to the most significant byte. If valid, OMODE = 16#80xxxxxx.
The MOD_D1 block contains the events that lead to the value status "invalid value due to
higher-priority error" (OMODE = 16#40xxxxxx), or to channel error (OMODE =
16#00xxxxxx).
Redundancy
The higher-level RACK block evaluates the redundancy of DP master systems operating in
an H system. Redundant HART field devices are not supported.
Error handling
The plausibility of input parameters is not checked.
Startup characteristics
A restart (OB 100) is reported via the LSB in byte 2 of the OMODE (Page 312) output.
ALARM_8P will be initialized.
Overload behavior
The MOD_HA block counts the OB 82 calls. The counter is reset in OB1. A diagnostic
message will not be generated if more than five OB 82 events occur before the cycle control
point is reached (OB 1). A "multiple diagnostic interrupt" message will not be generated,
since the MOD_D1 block performs this action.
Time response
Not available
Message functionality
MOD_HA reports diagnostic information from a HART field device by means of ALARM_8P
or NOTIFY_8P.
The message function can be disabled by setting EN_MSG = FALSE.
Additional information
Additional information is available in the sections:
Message texts and associated values of MOD_HA (Page 158)
Maintenance status of MS (Page 326)
You will find more information on this in PCS 7 Advanced Process Library > Basics of APL >
General functions of the blocks > Operating, monitoring and reporting > Maintenance release
Additional information
For further information, refer to the following sections:
Message texts and associated values of MOD_HA (Page 158)
Maintenance status of MS (Page 326)
Area of application
The MOD_MS block the up to 16-channel motor starter modules with diagnostic capability
(ET 200S). H systems support only the modules installed in switched racks.
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 82 Diagnostic interrupt
OB 83 Insert/remove module interrupt
OB 85 Program runtime error
OB 86 Rack failure
OB 100 Warm restart
ALARM_8P is used to report "module removed", "I/O access error", and the above "OB 82
error" events to WinCC.
The system verifies during startup that the module is available (plugged in). The module
status information that is read here is then available in the form of service output parameters
(MOD_INF).
Detailed information about the faults is entered in the DIAG_INF output parameter of data
type STRUCT.
You will find further information in the "Service Information" section, and in theSystem
Software for S7-300/400 System and Standard Functions; Diagnostic Data, Byte 0 to Byte 8,
Structure of Channel-Specific Diagnostic Data reference manual.
Redundancy
The block supports segment redundancy of CPU 417H for distributed I/Os. To use this
function, you must configure the SUBN1_ID (connection to CPU 0) and SUBN2_ID
(connection to CPU 1) inputs with the numbers of the redundant segments. If there is no
segment redundancy, the remaining input must be set to the (default) value 16#FF.
MODE setting
You will find more information about this in the "OMODE settings (Page 313)" section.
Note
If you change the parameter settings for the MODE_xx inputs at runtime, these changes will
not be accepted at the outputs until the ACC_MODE is set to 1.
OMODE Structure
You will find further information in the "OMODE (Page 312)" section.
Addressing
You will find further information in the "Addressing (Page 323)" section.
Error handling
The plausibility of input parameters is not checked.
You will find more information about this in "Error information of output parameter
MSG_STAT (Page 322)".
Service Information
To analyze faults, the module status information entered during startup is read via the
MOD_INF structured output parameter. You will find more information about this in the
reference manual System Software for S7-300/400 System and Standard Functions; System
Status List, Module Status Information.
Following a diagnostic interrupt, you will also find detailed module diagnostic information in
the MODDIAG0 to MODDIAG8 output parameters. You will find more information in the
reference manual System Software for S7-300/400 System and Standard Functions;
Diagnostic Data, Byte 0 to Byte 10.
The CHDIAG00 to CHDIAG15 output parameters contain detailed channel-status
information. You will find more information in the reference manual System Software for
S7-300/400 System and Standard Functions; Structure of Channel-Specific Diagnostic Data.
Of the motor starter module channels, only channel 0 is assigned the diagnostic function.
The error code is stored in CHDIAG00 to CHDIAG03. You will find further information about
this in the ET 200S, Motor Starter Safety Technology SIGUARD; Diagnostics and Monitoring
via the User Program reference manual.
The system resets this diagnostic information after a diagnostic interrupt has been reported
outgoing (no further channel or module errors are queued).
Startup characteristics
After a restart/initial startup, the system verifies that the module is available under its logical
base address. A restart (OB100) is reported via the LSB in byte 2 of the OMODE_xx
(Page 312) outputs.
Time response
Not available
Message functionality
MOD_MS reports module and motor-starter errors by means of ALARM_8P_1 and
ALARM_8P_2. The DELAY1 and DELAY2 inputs are used to delay the I/O access error
message. DELAY1 allows you to enter a time in seconds for which the block will wait for a
higher-priority error (rack failure or removal/insertion) following a program execution error
(OB 85) before it outputs the message. DELAY2 determines the number of seconds the
block waits after the higher-priority error has been reported outgoing until it outputs the
queued I/O access error as well. Both values are set to 2 seconds by default.
Additional information
For further information, refer to the following sections:
Message texts and associated values of MOD_MS (Page 167)
Maintenance status of MS (Page 326)
You will find more information on this in PCS 7 Advanced Process Library > Basics of APL >
General functions of the blocks > Operating, monitoring and reporting > Maintenance release
Additional information
For further information, refer to the following sections:
Message texts and associated values of MOD_MS (Page 167)
Maintenance status of MS (Page 326)
Area of application
Block MOD_PAL0 reports the maintenance status of a PA field device that is used as a
DPV0 slave downstream of a DP/PA link DPV1. The PA field devices must conform to the
PROFIBUS V3.0 profile.
Calling OBs
The cyclic OB and OB 100.
Note
The CFC function "Generate module drivers" can only be used if the PA field device
belongs to slave family 12.
Redundancy
The higher-level block evaluates the redundancy of DP master systems operating in an H
system.
Error handling
The plausibility of input parameters is not checked.
Startup characteristics
Initialization of ALARM_8P and NOTIFY_8P.
Time response
Not available
Message functionality
The block reports by means of ALARM_8P and NOTIFY_8P.
The block generates the following messages in the OBs listed below:
Additional information
For further information, refer to the following sections:
Message texts and associated values for MOD_PAL0 (Page 174)
Maintenance status of MS (Page 326)
You will find more information on this in PCS 7 Advanced Process Library > Basics of APL >
General functions of the blocks > Operating, monitoring and reporting > Maintenance release
I/Os
The default block view in the CFC is identified in the "I/O" column:
I/O name in bold = I/O is visible, standard I/O name = I/O is not visible.
You will find explanations of, and information about the abbreviations used in
"General information about the block description (Page 9)".
Additional information
For further information, refer to the following sections:
Message texts and associated values for MOD_PAL0 (Page 174)
Maintenance status of MS (Page 326)
PA field device status and diagnostic information (Page 333)
Area of application
Block MOD_PAX0 reports the maintenance status of a PA field device that is used as a
DPV0 slave in a DP master system. The PA field devices must conform to the PROFIBUS
V3.0 profile.
Calling OBs
The cyclic OB and OB 100.
Note
The CFC function "Generate module drivers" can only be used if the PA field device belongs
to slave family 12.
Note
If you change the parameter settings for the MODE_xx inputs at runtime, these changes will
not be accepted at the outputs until the ACC_MODE is set to 1.
OMODE Structure
You will find further information in the "OMODE (Page 312)" section.
Redundancy
The higher-level block evaluates the redundancy of DP master systems operating in an H
system.
Error handling
The plausibility of input parameters is not checked.
Startup characteristics
Initialization of ALARM_8P and NOTIFY_8P
Time response
Not available
Message functionality
The block uses ALARM_8P and NOTIFY_8P
The block generates the following messages in the OBs listed below:
Additional information
For further information, refer to the following sections:
Message texts and associated values for MOD_PAX0 (Page 181)
Maintenance status of MS (Page 326)
You will find more information on this in PCS 7 Advanced Process Library > Basics of APL >
General functions of the blocks > Operating, monitoring and reporting > Maintenance release
I/Os
The default block view in the CFC is identified in the "I/O" column:
I/O name in bold = I/O is visible, standard I/O name = I/O is not visible.
You will find explanations of, and information about the abbreviations used in
"General information about the block description (Page 9)" section.
Additional information
For further information, refer to the following sections:
Message texts and associated values for MOD_PAX0 (Page 181)
Maintenance status of MS (Page 326)
PA field device status and diagnostic information (Page 333)
Area of application
Block OB_BEGIN is used for CPU diagnostics of the automation system (AS). By installing
the block in CFC, the system creates all acyclic run sequences (OBs) for the driver blocks of
the PCS 7 Library.
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic processing
OB 40 - OB 47 Process interrupt (not in PCS 7 V6.1)
OB 55 Status interrupt (only if a DP/PA slave is required)
OB 56 Update interrupt (only if a DP/PA slave is required)
OB 57 Vendor-specific alarm (only if a DP/PA slave is required)
OB 60 Multicomputing interrupt (not in PCS 7 V6.1)
OB 61 - OB 64 Clocked interrupt (not in PCS 7 V6.1)
OB 70 I/O redundancy error
OB 72 CPU redundancy error
OB 80 Timeout error
OB 81 Power supply error
OB 82 Diagnostic interrupt
OB 83 Remove/insert interrupt
OB 84 CPU hardware error (only for CPU with this function)
OB 85 Program runtime error
OB 86 Rack failure
OB 88 Stop avoidance
OB 100 Restart
OB 121 Programming error
OB 122 I/O access error
Use in CFC
With the "Generate module drivers" CFC function, the OB_BEGIN block is automatically
installed in the OBs listed above.
Error handling
Block OB_BEGIN evaluates error information from ALARM_8P and writes it to the relevant
output parameters.
You will find additional information in the "Error information for output parameter MSG_STAT
(Page 322)" section.
If the block installation sequence OB_BEGIN, xx blocks, ..., OB_END is not observed in an
OB, the message "OB_END installation error, no OB 8x processing" will be output and
QERR = TRUE set. In this case, the acyclic OBs do not evaluate the data. The downstream
blocks will not be enabled.
Error information at output parameter STATUS of SFB 54 (RALRM) is handled as follows:
● The values 16#8096, 16#80A7, 16#80C0, 16#80C2, 16#80C3 oder 16#80C4 at
STATUS[2] and STATUS[3] indicate temporary errors. STATUS[3] of the corresponding
OB will be set in the structure CPU_DIAG = 16#C4. Downstream blocks can read access
the diagnostic data asynchronously.
● After any other error event, SFC 6 (RD_SINFO) reads the startup information once again
and the message "OB_BEGIN diagnostic error RALRM STATUS = xxxxxxxx" is output.
OB 1 generates the message exiting state once a delay of approximately 10 seconds has
expired.
Startup characteristics
Block OB_BEGIN initializes the messages of ALARM_8P. In H systems
(CPU_DIAG.H_MODE = TRUE), the current status of the two H CPUs is determined by
reading SSL71 (see "Function and operating principle").
Overload Behavior
Messages exiting state associated with OB 121, OB 122 and OB 88 are generated subject to
a delay of approx. 10 seconds. This on the one hand prevents blocking of the WinCC
connection due to a high message transfer volume of these OBs. On the other hand, OB
events may be due to the delay.
Time response
Not available
Message response
ALARM_8P multiple instances are only called if OB_BEGIN is to output a message. It is only
at this point that previously acknowledged messages are updated by the corresponding
ALARM block. If the connection to WinCC is down, each ALARM_8P can hold up to two
message statuses of its event ID.
The CPU generates a programming error (OB 121) only as an incoming event. OB 1 resets
the relevant message to status exiting state. In order to avoid an excessive number of
programming error messages, these will not be reported as outgoing until a delay time of 10
seconds has expired. The same applies to I/O access errors (OB 122) and OB 88 events.
The block generates the following messages in the OBs listed below:
Additional information
You will find more information in:
Message texts and associated values of OB_BEGIN (Page 189)
Maintenance status of MS (Page 326)
See also
Faceplates: Asset Management (Page 286)
Additional information
You will find more information in:
Message texts and associated values of OB_BEGIN (Page 189)
Maintenance status of MS (Page 326)
Control system messages for ALARM_8P with EV_ID4 are assigned as follows:
Additional information
You can find additional information in the following sections:
● Asset management block icons (Page 284)
● OB_BEGIN faceplate (Page 292)
Area of application
Block OB_DIAG1 monitors the failure and recovery of DP or PA slaves (referred to as
“slaves” below). The slaves can be connected to a DPV0 or DPV1 master system, or to a
DPV1 DP/PA link (Y link). OB_DIAG1 blocks further evaluation if a slave is defective
(frequent producer) to prevent the CPU stopping. It indicates the preferred channel of the
active slave in an H system. The indicated preferred channel 1 (SUBN1ACT) is always
TRUE if the slave is downstream of a DP/PA link (Y link) and is active.
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 70 I/O redundancy error
OB 72 CPU redundancy error
OB 82 Diagnostic interrupt
OB 83 Insert/remove module interrupt
OB 85 Program runtime error
OB 86 Rack failure
OB 100 Warm restart
OB 55 Status interrupt (only as required)
OB 56 Update interrupt (only as required)
OB 57 Manufacturer-specific alarms (only as required)
The driver generator only installs the block in OB 55, OB 56 and OB 57 if diagnostic
messages are to be expected from these locations; consequently OB 5x are not entered in
this block's task list.
Overload behavior
Block OB_DIAG1 counts the frequency of the calls to the acyclic OB 55, OB 56, OB 57,
OB 82, and OB 86 blocks (except in the case of a DP master system failure, see SUBNET
block). If the block is downstream of a DP/PA or Y link, the calls will be counted in OB 83,
rather than in OB 86. The following section deals only with OB 86.
Each OB is assigned a counter that is checked for the condition > 5. If this condition is
fulfilled, the block sets EN_F = FALSE (disable function block). The counters are reset in OB
1. The output EN_F = TRUE (enable function block) is set in all other OBs.
OB_DIAG1 reports failure of the blocks mentioned above in OB 1, OB 82 or OB 86, including
the geographic address of the slave.
OB 55, OB 56, OB 57 and OB 82 are locked in the event of an overload, however, so the
event is not evaluated in the downstream blocks. The outputs cannot correspond to the
current slave status. If an OB is locked and no more slave events have been reported after a
delay of around 1 minute, if it is OB 86 that is disabled, the slave status is checked, and the
outputs are updated. It may take several cycles to update the slave status.
If it is OB 82 that is disabled, rather than OB 86, the EN_DIAG variable is set to TRUE after
around 1 minute. The interconnected DP slave block can then fetch the current diagnostic
data for the slave, and update its own data. The same applies to OB 55, OB 56, and OB 57.
The “outgoing” message about the fault is generated when the OB lock is canceled, and
either a new event has occurred for this OB or the wait time has elapsed.
Redundancy
The block supports redundant DP master systems in an H system (distributed I/Os only).
The SUBN1_ID (connection to CPU 0) and SUBN2_ID (connection to CPU 1) inputs of the
OB_DIAG1 block are configured with the numbers of the redundant DP master systems. If
the DP master systems are not redundant, the remaining input is set to 16#FF (default).
Startup characteristics
The availability of the slave is checked. In H systems the preferred channel of the slave is
determined (active slaves only).
Error handling
The block evaluates the error information from ALARM_8P, and writes it to the relevant
output parameter.
You will find additional information in the "Error information for output parameter MSG_STAT
(Page 322)" section.
Message functionality
The multiple instance ALARM_8P are only called if a message is to be output by this
instance. It is only at this point that previously acknowledged messages are updated by the
corresponding ALARM block. If the connection to WinCC is down, each ALARM_8P instance
can hold up to two message statuses of its event ID (and generally no more than two
messages). The block generates the messages listed below:
Additional information
For further information, refer to the following sections:
Message texts and associated values of OB_DIAG1 (Page 200)
Maintenance status of MS (Page 326)
Additional information
For further information, refer to the following sections:
Message texts and associated values of OB_DIAG1 (Page 200)
Maintenance status of MS (Page 326)
Area of application
The OB_END block is used to reset the stack pointer of OB_BEGIN.
Calling OBs
The OB_END block is the final entry in the OB that contains an OB_BEGIN block.
OB 1 Cyclic processing
OB 55 Status interrupt (only as required)
OB 56 Update interrupt (only as required)
OB 57 Manufacturer-specific alarms (only as required)
OB 70 I/O redundancy error
OB 72 CPU redundancy error
OB 80 Timeout error
OB 81 Power supply error
OB 82 Diagnostic interrupt
OB 83 Remove/insert interrupt
OB 84 CPU hardware error (only for CPU with this function)
OB 85 Program runtime error
OB 86 Rack failure
OB 88 Stop avoidance
OB 100 Restart
OB 121 Programming error
OB 122 I/O access error
Function
The OB_END block decrements the stack pointer (NUM_CNT) of OB_BEGIN. In the event of
an interruption, it enters the last interrupted OB number read from the CPU stack into the
CPU_DIAG structure.
Error handling
Not available
Startup characteristics
Not available
Time response
Not available
Message functionality
Not available
Area of application
The OR_32_TS block forms the resulting time stamp from two redundant time-stamped
signal modules.
Calling OBs
The block must be installed in OB 1.
Use in CFC
The following actions are executed automatically with the "Generate module drivers" CFC
function:
● The OR_32_TS block is installed in OB 1.
● The TS1_xx inputs are interconnected with the TS_xx output of IMDRV_TS that is
responsible for the signal module with the lower address.
● The TS2_xx inputs are interconnected with the TS_xx output of IMDRV_TS that is
responsible for the signal module with the higher address.
● The TS_xx outputs are interconnected with the inputs of the MSG_TS channel blocks or
Pcs7InIT.
Redundancy
Redundancy of the modules in an H system is monitored in the higher-level RED_STATUS
block.
Error handling
The plausibility of input parameters is not checked.
Startup characteristics
Not available
Message response
Not available
Additional information
You will find more information in Description of IMDRV_TS (Page 73)
Additional information
You will find more information in:
● Maintenance Status of MS (Page 326)
Area of application
The OR_HA16C block is used to create a value status from two redundant signal modules,
and reports loss of redundancy for HART modules.
Calling OBs
The block must be installed in OB 100 and in the OB before the MOD_HA driver block that is
responsible for the relevant module.
Use in CFC
The following actions are executed automatically with the "Generate module drivers" CFC
function:
● The OR_HA16C block is installed before its interconnected MOD_HA driver block in its
OB.
● MODE1_xx inputs are interconnected with the OMODE_xx outputs of the MOD_x block in
the primary module.
● MODE2_xx inputs are interconnected with the OMODE_xx outputs of the MOD_x block in
the redundant module.
● The MOD_INF1 input structure is interconnected with the MOD_INF output structure of
the MOD_x block in the primary module.
● The MOD_INF2 input structure is interconnected with the MOD_INF output structure of
the MOD_x block in the redundant module.
● The ACTIV_H and ACTIV_L inputs are interconnected with the outputs of the same name
of the RED_STATUS block in the redundant module.
● The OMODE_xx outputs are interconnected with the downstream MOD_HA.
● The OUT structure CPU_DIAG of the OB_BEGIN block is interconnected with the
IN_OUT structures of the same name of the OR_HA_16C block.
● The inputs RACKF1 and RACKF2 are interconnected with the outputs QRACKF1 and
QRACKF2 of MOD_x.
● The inputs CH_INF_H and CH_INF_L are interconnected with the same name outputs of
RED_STATUS.
● The output parameter of DXCHG_xx is interconnected with the following channel block at
the DataXchg parameter.
● The output parameter of O_MS is interconnected with the following channel block at the
MS parameter.
Redundancy
Redundancy of the modules is monitored in a higher-level RED_STATUS block (FB 453).
Error handling
The plausibility of input parameters is not checked.
Startup characteristics
The OMODE_xx outputs are updated when the "Startup" bit is set. ALARM_8P will be
initialized.
Time response
Not available
Message response
OR_HA16C uses ALARM_8P for reporting. The message function can be disabled by setting
EN_MSG = FALSE.
Additional information
You will find more information in:
Message texts and associated values of OR_HA16C (Page 212)
Maintenance status of MS (Page 326)
You will find more information on this in PCS 7 Advanced Process Library > Basics of APL >
General functions of the blocks > Operating, monitoring and reporting > Maintenance release
Additional information
For further information, refer to the following sections:
Maintenance status of MS (Page 326)
Message texts and associated values of OR_M_8C (Page 232)
Message texts and associated values of OR_M_16C (Page 218)
Message texts and associated values of OR_HA16C (Page 212)
Message texts and associated values of OR_M_32C (Page 223)
General information about the block description (Page 9)
Additional information
For further information, refer to the following sections:
Message texts and associated values of OR_M_16C (Page 218)
Maintenance status of MS (Page 326)
You will find more information on this in PCS 7 Advanced Process Library > Basics of APL >
General functions of the blocks > Operating, monitoring and reporting > Maintenance release
Additional information
For further information, refer to the following sections:
Maintenance status of MS (Page 326)
Message texts and associated values of OR_M_8C
Message texts and associated values of OR_M_16C
Message texts and associated values of OR_HA16C
Message texts and associated values of OR_M_32C
General information about the block description
Additional information
You will find more information in:
Message texts and associated values of OR_M_32C (Page 223)
Maintenance status of MS (Page 326)
You will find more information on this in PCS 7 Advanced Process Library > Basics of APL >
General functions of the blocks > Operating, monitoring and reporting > Maintenance release
Additional information
For further information, refer to the following sections:
Maintenance status of MS (Page 326)
Message texts and associated values of OR_M_8C
Message texts and associated values of OR_M_16C
Message texts and associated values of OR_HA16C
Message texts and associated values of OR_M_32C
General information about the block description
Area of application
The OR_M_8C block generates a channel-granular value status from two redundant signal
modules.
Calling OBs
The block must be installed in OB 100 and in the fastest OB upstream of the CH_x block that
is interconnected with OR_M_8C.
Use in CFC
The following actions are executed automatically with the "Generate module drivers" CFC
function:
● The OR_M_8C block is installed upstream in the OBs of the CH_x channel blocks that are
interconnected with it.
● MODE1_x inputs are interconnected with the OMODE_xx outputs of the MOD_x block in
the primary module.
● MODE2_x inputs are interconnected with the OMODE_xx outputs of the MOD_x block in
the redundant module.
● The MOD_INF1 input structure is interconnected with the MOD_INF output structure of
the MOD_x block in the primary module.
● The MOD_INF2 input structure is interconnected with the MOD_INF output structure of
the MOD_x block in the redundant module.
● The ACTIV_H and ACTIV_L inputs are interconnected with the outputs of the same name
of the RED_STATUS block in the redundant module.
● The OMODE_xx outputs are interconnected with the relevant CH_x channel blocks.
● The OUT structure CPU_DIAG of the OB_BEGIN block is interconnected with the
IN_OUT structures of the same name of the OR_M_8C block.
● The inputs RACKF1 and RACKF2 are interconnected with the outputs QRACKF1 and
QRACKF2 of MOD_D1.
● The CH_INF_H and CH_INF_L inputs are interconnected with the outputs of the same
name of the RED_STATUS block.
● The output parameter of DXCHG_xx is interconnected with the following channel block at
the DataXchg parameter.
● The output parameter of O_MS is interconnected with the following channel block at the
MS parameter.
Redundancy
Redundancy of the modules in an H system is monitored in the higher-level RED_STATUS
block.
Error handling
The plausibility of input parameters is not checked.
Startup characteristics
The OMODE_xx (Page 312) outputs are updated when the "Startup" bit is set.
ALARM_8P will be initialized.
Message functionality
OR_M_8C uses ALARM_8P for reporting. The message function can be disabled by setting
EN_MSG = FALSE.
Additional information
For further information, refer to the following sections:
Message texts and associated values of OR_M_8C (Page 232)
Maintenance status of MS (Page 326)
You will find more information on this in PCS 7 Advanced Process Library > Basics of APL >
General functions of the blocks > Operating, monitoring and reporting > Maintenance release
Additional information
For further information, refer to the following sections:
Maintenance status of MS (Page 326)
Message texts and associated values of OR_M_8C
Message texts and associated values of OR_M_16C
Message texts and associated values of OR_HA16C
Message texts and associated values of OR_M_32C
General information about the block description
Field of application
Block PADP_L00 monitors DP/PA field devices operating as DPV0 or DPV1 slaves
downstream of a DP/PA or Y-Link that is operated as a DPV0 slave. The PA field devices
must conform to the PROFIBUS V3.0 profile. Individual blocks must be available for the
diagnostic and signal processing functions of DP field devices. H systems support only the
PA field devices at an active DP/PA-Link.
Calling OBs
The block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 82 Diagnostic interrupt
OB 85 Program runtime error
OB 86 Rack failure
OB100 Restart (warm start)
Note
The CFC function "Generate module drivers" can only be used if the PA field device belongs
to slave family 12.
An input (MODE_xx) exists for each slot (module) of the DP/PA field device that is used to
read in HW Config data for the slots (modules).
At DP field devices the user must enter his code manually at the MODE input.
The function writes MODE_xx to the low word of the OMODE_xx (Page 312) output
parameter. This occurs only during startup or if you set ACC_MODE = TRUE. The actual slot
value status is written to the most significant byte. If the result is positive, the system sets
OMODE_xx = 16#80xxxxxx. The following events are evaluated by block DPAY_V0 and lead
to the value status “Invalid value” due to a higher-level error (OMODE_xx = 16#40xxxxxx):
Redundancy
Higher-level block DPAY_V0 evaluates the redundancy of DP master systems operating in
an H system.
Note
Modifications of parameters at the MODE_xx inputs during runtime are not accepted at the
outputs until input ACC_MODE = 1.
OMODE Structure
You can find additional information in "OMODE (Page 312)".
Error handling
The plausibility of input parameters is not checked.
Startup characteristics
After a restart or an initial start the system verifies that the PA field device is available under
its logical base address. A restart (OB100) is reported via the LSB in byte 2 of the
OMODE_xx (Page 312) outputs.
Time response
n.a.
Message functionality
The block uses ALARM_8P to report field device errors and generates the following
messages in the OBs listed below:
Additional information
For further information, refer to the following sections:
Message texts and associated values for PADP_L00 (Page 239)
I/O
The I/Os of the PADP_L00, PADP_L01 and PADP_L02 blocks are identical save for the
number of MODE_xx and OMODE_xx. The number of monitored slots determines the
number of corresponding I/O parameters.
The default block view in the CFC is identified in the "I/O" column:
I/O name in bold = I/O is visible, standard I/O name = I/O is not visible.
You will find explanations of, and information about the abbreviations used in the
"General information about the block description (Page 9)" section.
Additional information
For further information, refer to the following sections:
Message texts and associated values for PADP_L00 (Page 239)
Message texts and associated values for PADP_L01 (Page 244)
Message texts and associated values for PADP_L02 (Page 249)
Area of application
The PADP_L01 monitors DP/PA field devices that are used as DPV0 or DPV1 slaves,
downstream of a DP/PA or Y link that is used as a DPV0 slave. The PA field devices must
conform to the PROFIBUS V3.0 profile. There must be individual blocks available for the
diagnostics and signal processing for DP field devices. H systems support only the PA field
devices at an active DP/PA-Link.
Calling OBs
The block must be installed in the run sequence in the following OBs (this is done
automatically in the CC):
OB 1 Cyclic program
OB 82 Diagnostic interrupt
OB 85 Program runtime error
OB 86 Rack failure
OB 100 Warm restart
Note
The CFC function "Generate module drivers" can only be used if the PA field device belongs
to slave family 12.
The block reports a diagnostic interrupt to the OS for a specific field device using
ALARM_8P. We distinguish between the field device and its slots; each slot is assigned a
message ID.
The “Device failure” message can be disabled with EM_MSG_D = FALSE.
Redundancy
The higher-level block DPAY_V0 evaluates the redundancy of the DP master systems used
in an H system.
Note
If you change the parameter settings for the MODE_xx inputs at runtime, these changes will
not be accepted at the outputs until the ACC_MODE is set to 1.
OMODE structure
You will find further information in the "OMODE (Page 312)" section.
Error handling
The plausibility of input parameters is not checked.
Startup characteristics
After a restart/initial startup, the system checks that the PA field device is available at its
logical base address. A restart (OB100) is reported via the LSB in byte 2 of the OMODE_xx
(Page 312) outputs.
Time response
Not available
Message functionality
The block signals field device errors using ALARM_8P, and generates the following
messages in the OBs listed below:
Additional information
For further information, refer to the following sections:
Message texts and associated values for PADP_L01 (Page 244)
Area of application
The PADP_L02 monitors DP/PA field devices that are used as DPV0 or DPV1 slaves,
downstream of a DP/PA or Y link that is used as a DPV0 slave. The PA field devices must
conform to the PROFIBUS V3.0 profile. There must be individual blocks available for the
diagnostics and signal processing for DP field devices. H systems support only the PA field
devices at an active DP/PA-Link.
Calling OBs
The PADP_L02 block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 82 Diagnostic interrupt
OB 85 Program runtime error
OB 86 Rack failure
OB 100 Warm restart
The block reports a diagnostic interrupt to WinCC for a specific field device using
ALARM_8P. We distinguish between the field device and its slots; each slot is assigned a
message ID.
The “Device failure” message can be disabled with EM_MSG_D = FALSE.
Redundancy
The higher-level block DPAY_V0 evaluates the redundancy of the DP master systems used
in an H system.
Note
If you change the parameter settings for the MODE_xx inputs at runtime, these changes will
not be accepted at the outputs until the ACC_MODE is set to 1.
OMODE Structure
You will find further information in the "OMODE (Page 312)" section.
Error handling
The plausibility of input parameters is not checked.
Startup characteristics
After a restart/initial startup, the system checks that the PA field device is available at its
logical base address. A restart (OB100) is reported via the LSB in byte 2 of the OMODE_xx
(Page 312) outputs.
Time response
Not available
Message functionality
The block signals field device errors using ALARM_8P, and generates the following
messages in the OBs listed below:
Additional information
For further information, refer to the following sections:
Message texts and associated values for PADP_L02 (Page 249)
Area of application
Block PADP_L10 monitors DPV0 PA field devices with a maximum of 16 slots, which are
operated as DPV0 slaves on a DP master system, either directly or via a DP/PA coupler.
The DP/PA coupler is connected downstream of a DPV1 DP/PA link. The PA field devices
must conform to the PROFIBUS V3.0 profile. H systems support only the PA field devices at
an active DP/PA-Link.
Calling OBs
The block must be installed in the run sequence downstream from the OB_DIAG1 block in
the following OBs (this is done automatically in the CFC):
OB 1 Cyclic program
OB 55 Status interrupt (only if a PA slave is required)
OB 56 Update interrupt (only if a PA slave is required)
OB 57 Vendor-specific interrupt (only if a PA slave is required)
OB 82 Diagnostic interrupt
OB 83 Remove/insert module interrupt (failure/return of a field device)
OB 85 Program runtime error
OB 86 Rack failure
OB 100 Warm restart
Note
The CFC function "Generate module drivers" can only be used if the PA field device belongs
to slave family 12.
How it works
Block PADP_L10 is enabled to run by the higher-level OB_DIAG1 block. The event to be
evaluated is entered in the start information (CPU_DIAG) of OB_BEGIN. Block PADP_L10
checks the geographic address and the number of slots (SLOT_NO) of the PA field device to
determine whether it is responsible for this event.
For a diagnostic event (OB 82, OB 55, OB 56, OB 57), SFB 54 is used to synchronously
read the data from OB_BEGIN.
If diagnostic data could not be read synchronously from OB_BEGIN or when requested by
OB_DIAG1 (EN_DIAG = TRUE), SFB 52 (RDREC) is used to read the current diagnostic
data asynchronously.
Byte 9 of the additional alarm information contains the slot number of the field device that
triggered the diagnostic interrupt. The corresponding slot is enabled.
The following diagnostic data is interpreted as a higher-level error in the block:
Additional alarm information
Redundancy
The higher-level block evaluates the redundancy of DP master systems operating in an H
system.
OMODE Structure
You will find further information in the "OMODE (Page 312)" section.
Addressing
You will find further information in the "Addressing (Page 323)" section.
Error handling
The plausibility of input parameters is not checked.
Startup characteristics
A restart (OB100) is reported via the LSB in byte 2 of the OMODE_xx (Page 312) outputs.
Time response
Not available
Message functionality
Not available
Field of application
The PO_UPDAT block safeguards the output module functions "Hold last value" and "Apply
substitute value" when a CPU is restarted (OB 100).
Run Sequence
With the "Generate module drivers" CFC function, the PO_UPDAT block is automatically
installed in OB 100 at the end.
Description of Functions
On a CPU restart (OB 100), the CH_DO and CH_AO blocks write the start values to the
process image. The PO_UPDAT block sends all process images (partitions) to the modules
at the end of OB 100 in order for these values to be active immediately when the CPU goes
into RUN. Output PO_MAP indicates the process image partitions which have been updated
or are used in the system (BIT0: Process image 0, BIT15: Process image partition 15).
3.35.1 Description of PS
Area of application
The PS block monitors the status of a rack power supply, and reports the associated error
events.
Calling OBs
The PS block must be installed in the run sequence of the following OBs:
OB 1 Cyclic program
OB 81 Power supply error
OB 83 Insert/remove module interrupt
OB 100 Warm restart
Note
Note the following:
• If a battery fails, the battery must always be replaced with the power supply turned on.
Then press the "FMR" button. In all other situations, the block does not reset a reported
error.
• For redundant power supply modules in a rack with a standard CPU, a corresponding
message is sent for both power supply modules in the event of a battery error or power
supply error. You can tell which module is affected by the "BATTF" LED that lights up.
Redundancy
In a redundant system, the block is also installed extra for the power supply of the redundant
rack.
Error handling
The error handling for the block is limited to evaluation of the error information from
ALARM_8P.
You will find further information about error handling in the "Error information for output
parameter MSG_STAT (Page 322)" section.
Startup characteristics
The PS block initializes the messages of the ALARM_8P.
Overload behavior
Not available
Time response
You will find additional information in the "Message response" section.
Message functionality
After OB 81 or OB 83 is called, the block analyzes the status of the power supply of the rack
assigned to it. It generates the "Backup battery failure", "Backup voltage failure" and "24 V
supply failure" or "Module removed" or "Wrong or faulty module" messages with ALARM_8P.
The message function can be disabled by setting EN_MSG = FALSE.
Additional information
For further information, refer to the following sections:
Message texts and associated values of PS (Page 263)
Maintenance status of MS (Page 326)
3.35.2 I/Os of PS
The factory setting of the block display in the CFC is identified in the "I/O" column:
I/O name bold = I/O visible, I/O name normal = I/O not visible.
Detailed information about the abbreviations used is available in the section "General
information pertaining to the block description (Page 9)".
Additional information
For further information, refer to the following sections:
Message texts and associated values of PS (Page 263)
Maintenance status of MS (Page 326)
Area of application
The RACK block monitors the status of a rack, and reports the associated error events.
Calling OBs
The block is installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 70 I/O redundancy error
OB 72 CPU redundancy error
OB 81 Power supply error
OB 82 Diagnostic interrupt
OB 83 Insert/remove module interrupt
OB 85 Program runtime error
OB 86 Rack failure
OB 100 Warm restart
Redundancy
In H systems with distributed I/Os, the RACK block supports redundancy of the DP Master
systems. If you want to use this function, you must configure the SUBN1_ID (connection to
CPU 0) and SUBN2_ID (connection to CPU 1) inputs of the RACK block with the numbers of
the redundant DP master systems. If there is no redundancy, the remaining input must be
set to the (default) value 16#FF.
Note
With redundant CPU racks, the two RACK blocks inserted in the system chart are only
responsible for enabling lower-level block chains. Their maintenance status MS is therefore
irrelevant. The "Good" and "Not redundant" state is always shown in the associated
faceplate and block icon because the bits 0 to 16 of the MS are always "0" in this case.
Error handling
Error handling of the block is limited to evaluation of the error information of ALARM_8P.
You will find more information about this in "Error information for output parameter
MSG_STAT (Page 322)".
Startup characteristics
The RACK block initializes ALARM_8P messages. It checks availability of the station and, in
H systems, determines the preferred channel of the station.
The SUB_DIAG.V1_MODE structure (0 = compatibility mode, 1 = DPV1 mode) is transferred
to the RAC_DIAG.V1_MODE structure.
Overload behavior
The RACK block counts the OB 86 calls (except in the case of a DP master system failure;
see SUBNET block). The counter is reset in OB 1. If more than two OB 86 events occur in
succession before the cycle control point (OB 1) is reached, these will be rejected and the
message "Station...: Multiple failure" is output. When an OB 86 call is rejected, the rack
(station) is registered as having failed.
Time response
See "Message Response"
Message functionality
After it is called by OB 70, OB 72, OB 85 or OB 86, the block analyzes the status of its
assigned CPU, DP master and DP slave. If the rack (station) loses redundancy or fails, the
block outputs the corresponding messages by broadcasting an ALARM_8P. The message
function can be disabled by setting EN_MSG = FALSE.
The block generally reports only the events that were originally generated in the rack that it
monitors. Redundancy loss and station failures which are caused by the failure of a DP
master or CPU are initially neither signaled nor indicated at the SUBN1ERR and
SUBN2ERR outputs.
The DELAY input is used to delay the outputting of error messages for an outgoing, higher-
priority error. For example, if the RACK block recognizes an outgoing error at an
interconnected DP master, it initially assumes that there is a faulty assigned DP slave in the
rack it monitors, and sets the corresponding output SUBNxERR. The error status is not reset
until the DP slave returns (in this case: OB 86, OB 70). The RACK blocks suppress the
potential slave failure states for DELAY seconds so as not to trigger a surge of messages
from DP slaves which are not yet synchronized when the master returns. An error message
is not output to the OS unless the DP slave has reported its return before this delay time has
expired.
Note: Do not set the value of DELAY too high, otherwise DP slaves that were removed
during the master failure or are defective will be signaled to the OS too late after the DP
master returns.
The RACK block generates the following messages in the OBs listed below:
Additional information
For further information, refer to the following sections:
Message texts and associated values of RACK (Page 269)
Maintenance status of MS (Page 326)
Additional information
For further information, refer to the following sections:
Message texts and associated values of RACK (Page 269)
Maintenance status of MS (Page 326)
Area of application
The RED_F block is used to set up redundant F modules in safety mode.
Calling OBs
The block must be installed in the same OB before the OR block. It is also installed in OB
100.
Use in CFC
The following actions are executed automatically with the "Generate module drivers" CFC
function:
● The RED_F block is installed before the OR block in its OB.
● MODE1_xx inputs are interconnected with the OMODE_xx outputs of the MOD_x block in
the primary module.
● MODE2_xx inputs are interconnected with the OMODE_xx outputs of the MOD_x block in
the redundant module.
● The RACKF1 input is interconnected with the QRACKF output of the MOD_x block of the
primary module.
● The RACKF2 input is interconnected with the QRACKF output of the MOD_x block of the
redundant module.
● The MS1 input is interconnected with the O_MS output of the MOD_x block of the primary
module.
● The MS2 input is interconnected with the O_MS output of the MOD_x block of the
redundant module.
● The ACTIV_H and ACTIV_L outputs are interconnected with the inputs with the same
name in the OR block.
● The CH_INF_H and CH_INF_L outputs are interconnected with the inputs with the same
name in the OR block.
● The RETURN_VAL output is interconnected with the RED_STAT input of the OR block.
● The MODUL_STATUS_WORD output is interconnected with the MOD_STAT input of the
OR block.
Addressing
Not available
Error handling
Not available
Startup characteristics
Not available
Time response
Not available
Message response
Not available
Additional information
You will find more information in:
Maintenance status of MS (Page 326)
Area of application
The SUBNET block is used to shorten acyclic OB processing times. Only the blocks that are
actually affected can be called for an acyclic event.
Calling OBs
The SUBNET block must be installed in the run sequence in the following OBs:
OB 1 Cyclic program
OB 55 Status interrupt (only if a DP/PA slave is required)
OB 56 Update interrupt (only if a DP/PA slave is required)
OB 57 Vendor-specific alarm (only if a DP/PA slave is required)
OB 70 I/O redundancy error
OB 72 CPU redundancy error
OB 81 Power supply error
OB 82 Diagnostic interrupt
OB 83 Insert/remove module interrupt
OB 85 Program runtime error
OB 86 Rack failure
OB 100 Warm restart
Redundancy
The SUBNET block supports redundancy of DP master systems of the 414-H/417-H CPU if
distributed I/Os are used. To use this function, you must configure the SUBN1_ID
(connection to CPU 0) and SUBN2_ID (connection to CPU 1) inputs with the numbers of the
redundant DP master systems. If there is no redundancy, the remaining input must be
assigned the value 16#FF (default).
Error handling
The error handling for the block is limited to evaluation of the error information from
ALARM_8P.
You will find further information about error handling in "Error information for output
parameter MSG_STAT (Page 322)".
Overload behavior
The SUBNET block counts the OB 86 calls (failures only). The counter is reset in OB1. If
more than two OB 86 failure events occur in succession before the cycle control point (OB1)
is reached, these are rejected and a message "Failure OB 86 DP master system:x" is output.
If an OB 86 call is rejected, the DP master system is registered as having failed.
Time response
Not available
Message functionality
After being called by an OB 86, OB 70 and OB 72, the block analyzes the status of its
assigned DP master system, and generates the relevant messages for redundancy loss or
DP master system failure by broadcasting an ALARM_8P.
The message function can be disabled by setting EN_MSG = FALSE.
The SUBNET block generally reports only events triggered in the DP master system it
monitors.
Exception: If a CPU fails in the H system, the following messages are generated:
● in a non-redundant DP master system: “DP master failure” message
● in a redundant DP master system: “DP master redundancy loss” message
Additional information
For further information, refer to the following sections:
Message Texts and associated values of SUBNET (Page 278)
Maintenance status of MS (Page 326)
Note
The maximum number of racks is determined by the address volume of PROFIBUS. All
available CPUs can thus be used. The entire address volume is used by the CPU 417-4.
Additional information
For further information, refer to the following sections:
Message Texts and associated values of SUBNET (Page 278)
Maintenance status of MS (Page 326)
Configuration
You configure the OB_BEGIN block icon for each AS. You then interconnect each block icon
with the corresponding OB_BEGIN structure variable.
To achieve all the required interconnections to the block icon, it is best to use the PCS 7
WinCC Wizard for interconnecting faceplates to process tags. In the tag dialog "List of all
structure variables", you can select the relevant OB_BEGIN instance.
ASSET Toolbox
The ASSET Toolbox includes several functions:
● Complete export
● Message correction
● Filtered complete export
The ASSET Toolbox is called up with the button in the diagnostics overview screen:
6WDQGDUG
7ULJJHUFRPSOHWHH[SRUW
0DNHPHVVDJHFRUUHFWLRQ
A complete export is started with the button. This export is saved as an export file on
the maintenance server. This file forms the basis for the filtered complete export.
6HOHFWLRQ
'HYLFHVWDWXV 26RSHUDWLRQ
*RRG 0DLQWHQDQFHGHPDQGUHTXHVWHG
3DVVLYDWHG 0DLQWHQDQFHUHTXHVWUHTXHVWHG
2XWRIVHUYLFH 0DLQWHQDQFHDODUPUHTXHVWHG
6LPXODWLRQ
/RFDORSHUDWRUFRQWURO 6WDWH
0DLQWHQDQFHGHPDQG &RPSOHWHG
0DLQWHQDQFHUHTXHVW $ERUWHG
0DLQWHQDQFHDODUP ,QSURJUHVV
'HYLFHVWDWXVXQNQRZQ 0DLQWHQDQFHQRWVWDUWHG
&RQILJXUDWLRQPRGLILFDWLRQ
6HOHFWDOO
7H[W
$VVHW,' QRW
DQG
RU
$VVHW,' QRW
6KRZGDWD
Here, you can set individual filters for device status, OS operation, status and free text.
Select the check boxes to enable or disable the individual filter criteria. You can enable all
the check boxes with the "Select All" button.
In the lower "Text" area, there are two text filters available. In the left-hand text boxes, you
can select the available identification data from a drop-down list box. You can enter any text
you require in the right-hand text boxes. You can also set "AND", "OR" or "NOT" options for
these text boxes.
Select the "Show data" button to display the required view in the form of a table in the
"Result" faceplate.
Configuration changed
Maintenance in progress
Overview
Global representations and views of asset faceplates (Page 305)
Maintenance View [Asset] (Page 297)
Message View [Asset] (Page 299)
Ident View [Asset] (Page 300)
Individual views of the PDM faceplate [Asset] (Page 287)
Individual views of the IPC faceplate [Asset] (Page 290)
Views of the OB_BEGIN faceplate [Asset] (Page 292)
@PG_ASSETPDM_CHANGELOG
Data are read out in XML format via a COM interface to PDM and displayed as a table in a
web browser control.
The PDM change log for the current instance is displayed.
@PG_ASSETPDM_Parameters
The data is read to PDM in XML format via a COM interface, and displayed in table format in
a web browser control.
The device parameters saved in PDM for the current instance are displayed.
@PG_ASSETPDM_Diagnostics
The data is read and displayed in XML format via a COM interface to PDM.
The diagnostic data saved in PDM for the current instance is displayed.
The current diagnostic data can be read from the device to PDM and displayed using the
"Update" button. The date field beside "Last check" shows the date and time of the last
check.
Additional information
For additional information, see:
Global representations and views of asset faceplates (Page 305)
Views
With the IPC faceplate, the data of the views "Monitoring1", "Monitoring2", "Monitoring3" of
variables is read from the data manager.
These variables are created using the "Export variables for WinCC" function in the OPC
server properties.
@PG_ASSETIPC_Monitoring1
6103B$'3&
0RQLWRULQJ
*2 *2 *2 2SHUDWLQJKRXUV K
39 39 39
*8 *8 *8
@PG_ASSETIPC_Monitoring2
6103B$'3&
0RQLWRULQJ
*8 *8 *8
@PG_ASSETIPC_Monitoring3
6103B$'3&
0RQLWRULQJ
+'GULYH +'GULYH
6WDWXV 2N 6WDWXV 2N
+'GULYH +'GULYH
61U
01U 67$6
6WDWXV 2N
Additional information
You will find more information in:
Global representations and views of asset faceplates (Page 305)
Views
The faceplate has 7 views:
● Maintenance view (Page 297)
● Message view (Page 299)
● Ident view (Page 300)
● Performance View (Overview)
● OB3x View (Detailed View)
● OB8x/OB1 View (Detailed View)
● Parameter view
Performance View
The overall situation of the CPU are graphically displayed in the overview.
The overall situation of the CPU is displayed in the form of a bar display. It contains the total
runtime with the following values:
All the values in the bar diagram are specified in %, relative to the set maximum cycle
monitoring time. Its numeric magnitude is displayed under the bar.
The following are also graphically displayed:
● The mean value, gross value and the net values of all OB 3x, relative to the respective
OB cycle time,
● The net values of OB 8x and the OB 1, both relative to the set maximum cycle monitoring
time.
Because the actual value display of the respective last cycle would cause a widely
fluctuating reduction ratio display in the screen refreshing cycle, all of the displays of the
overall situation are mean values.
The graphic display of the OB 3x times is expanded by an indicator that signals buffered and
lost start events.
OB3x view
In the detailed view for "OB3x", the following four absolute values are displayed for all OB 3x
for net and gross runtime:
Display Meaning
Actual value Runtime of the last cycle
Average value Value formed from the actual values over a number of "Sample" cycles
Max. value Value formed from the actual value since the last reset
Min. value Value formed from the actual value since the last reset
If a cyclic OB is not assigned by the user, then no values for this are displayed.
OB8x/OB1 view
In the detailed view for "OB8x OB1", the four absolute values for the net runtime are
displayed for all of OB 8x and for OB 1:
Display Meaning
Actual value Runtime of the last cycle
Average value Value formed from the actual values over a number of "Sample" cycles
Max. value Value formed from the actual value since the last reset
Min. value Value formed from the actual value since the last reset
Note: The values displayed in this view are net values; the values displayed in HW Config
are gross values.
Parameter view
In this view, you can select the OBs on the left to which a reduction ratio will apply if there is
overload.
On the right-hand side, you enter the parameter values that apply when avoiding the CPU
changing to STOP and keeping the AS operable.
If SFC 78 is not supported in the AS, some information will not be displayed in the view. This
involves the following:
● Alarm limit capacity
● Cancel reduction for
● Hysteresis alarm limit
● Calculation of CPU load (display)
● Calculation of CPU load (internal)
Additional information
You will find more information in:
Global representations and views of asset faceplates (Page 305)
Layout
The maintenance view of an asset faceplate has the following display and operator control
elements:
● Request number: The job number assigned for the maintenance job is displayed here.
● Request operator: The maintenance requests from the different components are defined
here. The maintenance operator determines the status that is set for maintenance. The
following statuses are available:
– Alarm
– Demand
– Request
– In progress
– Completed
– Cancel
If one of the listed radio buttons is clicked, a dialog box opens, in which a comment and a
job number can be entered. The request status icon then changes.
● Note: The comments entered for the maintenance job are displayed here.
● Request via: Currently, only "Printer" or "Single export" are possible. Printing a print
report for the selected faceplate.
Note
A second print job may not be initiated until the previous job is complete.
Additional information
You will find more information in:
Global representations and views of asset faceplates (Page 305)
Layout
Additional information
You will find more information in:
Global representations and views of asset faceplates (Page 305)
@PG_ASSETAS_Ident
,GHQW
&RPSRQHQWV )XQFWLRQ
/RFDWLRQ
*RRG
'HVFULSWLRQ
1RWLILFDWLRQ
'HVLJQDWLRQ
$GGUHVV
'HYLFHW\SH
&RPPHQW
0DQXIDFWXUHU
2UGHUQXPEHU
6HULDOQXPEHU
,QVWDOOGDWH
+:UHYLVLRQ
6:UHYLVLRQ
/DVWXSGDWH 8SGDWH
The layout of the Ident page is the same for all faceplates; only the dynamic sampling of the
ident data is different.
Exception: For devices containing a Web server, a button is available to call a viewer that
displays the HTML pages on the devices.
AS faceplate
On the AS faceplate, the identification data is read out from the properties of the block or
dynamically from the CPU.
PC faceplate
For PC faceplates, the identification data of the variables is read from the data manager.
IPC faceplate
For IPC faceplates, the identification data of the variables is read from the data manager.
These variables are created using the "Export variables for WinCC" function in the OPC
server properties.
OSM faceplate
For OSM faceplates, the Ident data of the variables are read from the data manager. These
variables are created using the "Export variables for WinCC" function in the OPC server
properties.
PDM faceplate
On the PDM faceplate, the ident data is read in XML format via a COM interface to PDM.
ASSETMON faceplate
On the ASSETMON faceplate, the ident data is read out in XML format via a COM interface
to PDM or from variables of the data manager.
Additional information
You will find more information in:
Global representations and views of asset faceplates (Page 305)
Introduction
The following representations and views appear in all asset faceplates.
Local operation
Out of service
Component passivated
Untested/unknown
If the operator performs a status change, the 3 icons listed Configuration changed
under "After operator action" can be displayed in the status
After operator action:
display.
The operator changes the maintenance status in the
faceplate "Maintenance" view. State change to
Maintenance alarm
State change to
Maintenance required
State change to
Maintenance request
Maintenance required
The icons listed under "Component" indicate the original
status of the component, as reported by the AS. Component good
Local operation/local
Overwrite
Out of service
Component passivated
Untested/unknown
Configuration changed
Note
If the maintenance status is "Untested/unknown", all the other dynamic displays in the asset-
management faceplates are not relevant for this instance.
Overview
0DLQWHQDQFH
The following keys are added to the overview of asset faceplates, which always looks the
same:
● The key for calling HW Config is added to @PG_ASSETAS_Overview:
The icon only appears if STEP 7 is also installed on the computer on which the faceplate
was opened.
● The keys for calling PDM and HW Config are added to @PG_ASSETPDM_Overview:
These keys only appear if PDM and STEP 7 are also installed on the computer, on which
the faceplate was opened.
● The key for depassivation is added to @PG_ASSETAS_Overview:
The icon only appears if STEP 7 is also installed on the computer on which the faceplate
was opened.
Additional information
You will find more information in:
Objects in the overview
Overview
The table below contains the technical data for the blocks. The table columns have the
following meanings:
● Block type name
The symbolic identifier in the symbol table of the library for the relevant FB or FC. Must
be unique within the project.
● Object name
Consists of the block type (FB, FC) and number.
● Typical execution time
CPU runtime for processing the corresponding block program under normal
circumstances (for example, for a driver, this is the execution time in the cyclic interrupt
OB (OB3x), without generation of a channel error message).
The table below shows the runtime of blocks in a 417-4 CPU. The block runtime on other
CPUs depends on the CPU performance.
● Block length in load/work memory
Memory requirements of the program code, once for each block type.
● Length of instance data in load/work memory
Memory requirement of an instance DB.
● Temporary memory
The local-data memory required in a priority class when the block is called. This limit is
CPU specific. When it is exceeded, you have to check the CPU configuration in the local-
data memory and, if necessary, distribute it amongst the OBs to meet the actual
requirements.
Block FB/FC Typical run Block length in Length of the Temporary Multiple
(Type name) no. time CPU load/work memory instance data in the memory instance
417-4 (µs) (bytes) load/work (bytes) block
memory
(bytes)
ChkREAL FC 260
CONEC FB 88 98 10266 / 8642 1186 / 340 84 16 x SFB 35
CPU_RT FB 128 67 31434 / 27370 2800 / 1784 86
DIAG_AB FB 414
DPAY_V0 FB 108 159 1792 / 1202 542 / 70 22
DPAY_V1 FB 115 155 11206 / 8506 3588 / 1388 136 SFB 35
DPDIAGV0 FB 117 115 3980 / 2184 1800 / 194 66
DREP FB 113 19 4202 / 3038 1296 / 366 124
DREP_L FB 125 20 6578 / 5358 1406 / 486 52 2 x SFB 35
FM_CNT FB 126 36 1496 / 1060 546 / 140 10
FM_CO FB 79 18 3132 / 1780 1732 / 566 46
FRC_CFC FB 136
IMDRV_TS FB 129
MOD_1 FB 91 91 13202/ 10498 5946 / 4060 116 16 x SFB 35
MOD_2 FB 92 91 4912 / 3862 1120 / 346 68 SFB 35
MOD_3 FB 95 91 4984 / 3868 1280 / 442 66 SFB 35
MOD_4 FB 119 16 4988 / 3872 1288 / 448 66 SFB 35
MOD_64 FB 137 SFB 35
MOD_CP FB 98 104 3496 / 2540 1108 / 346 52 SFB 35
MOD_D1 FB 93 96 6850 / 5622 1186 / 340 80 SFB 35
MOD_D2 FB 94 97 12552 / 10752 1818 / 700 86 3 x SFB 35
MOD_D3 FB 134 103 13432 / 11442 3958 / 2164 90 3 x SFB 35
MOD_HA FB 97 18 10836 / 8938 2440 / 1090 82 5 x SFB 35
MOD_MS FB 96 99 5442 / 4282 1356 / 464 54 SFB 35
MOD_PAL0 FB 99 169 7758 / 6322 1814 / 740 84 2 x SFB 35
MOD_PAX0 FB 112 112 4470 / 3746 1006 / 490 50 2 x SFB 35
SFB 52
MODB_341 FB 80 594 4388 / 3666 1012 / 490 54 2 x SFB 35
OB_BEGIN FB 100 158 3012 / 2268 1206 / 630 120
OB_DIAG1 FB118 23 10886 / 8924 1690 / 306 116 SFB 35
SFB 52
OB_END FC280 4 514 / 86 -/- 4
OR_HA16C FB 133 181 8492 / 6972 2362 / 1146 70 5 x SFB 35
OR_M_16 FB 81 181 3682 / 2736 1176 / 410 50 SFB 35
OR_M_16C FB 84 183 8010 / 6516 2356 / 1146 70 SFB 35
OR_M_32 FB 82 268 3778 / 2736 1464 / 602 50 SFB 35
Block FB/FC Typical run Block length in Length of the Temporary Multiple
(Type name) no. time CPU load/work memory instance data in the memory instance
417-4 (µs) (bytes) load/work (bytes) block
memory
(bytes)
OR_M_32C FB 85 374 12618 / 10436 3958 / 2164 70 9 x SFB 35
OR_M_8C FB 83 94 5926 / 4730 1656 / 698 70
PADP_L00 FB 109 15 3526 / 2690 904 / 262 40 SFB 35
PADP_L01 FB 110 19 4642 / 3600 1410 / 578 40 3 x SFB 35
PADP_L02 FB 111 23 6170 / 4890 201 / 954 40 5 x SFB 35
PADP_L10 FB 116 80 4998 / 3516 1460 / 228 56 SFB 52
PO_UPDAT FC279 328 / 256 -/- 10
PS FB 89 12 3062 / 2226 816 / 196 74
QC_CHNG FB 135
RACK FB 107 102 822 / 7484 1102 / 248 102 SFB 35
REC_BO FB 208 69 3246 / 2356 992 / 128 2 SFB 13
REC_R FB 210 69 1838 / 1332 956 / 476 2 SFB 13
RED_F FC 289 41 5234 / 5020 -/- 24
SEND_BO FB 207 163 2298 / 1668 718 / 110 2 SFB 12
SEND_R FB 209 195 4486 / 3886 908 / 478 2 SFB 12
SUBNET FB 106 308 6800 / 4920 1736 / 234 112 SFB 35
OMODE structure
The table below shows the structure and meaning of the outputs OMODE_xx of data type
DWORD:
6.6 Addressing
Rules
If you do not use the CFC function “Generate module drivers”, you must set the logical basic
address of the module created with HW Config at the LADDR input parameter. If input
SUBN_TYP = FALSE, the RACK of the module is connected to an integrated DP interface
(distributed I/O device interface) of the CPU module by means of a line. Otherwise, you must
set SUBN_TYP = TRUE.
The following points are generally to be observed for all SM and PA modules:
● The basic address of modules equipped only with inputs, i.e., modules which only write
data to the input area of the CPU process image, can be fetched directly from HW Config;
for example: the module SM331 AI 8x12Bit 6ES7331-7KF01-0AB0:
Message classes
Message classes are used to group messages according to their cause. The following
message classes are used in the SIMATIC process control system:
● Process messages triggered when process-specific monitoring values (for example,
alarms, warnings, high/low tolerances, general process messages) are reached or
exceeded.
● Process-control messages; output by the control system (system messages) or the I/O
units (errors in the field), or for preventive maintenance.
● Requests for operator input which, in the case of certain operation sequences, draw the
operator's attention to the necessity of an operator intervention (for example, request to
acknowledge a stepping operation manually in order to enable transition) or operation
logs.
6.8 Dependencies
Displayable Statuses
The maintenance status (MS) can display the following statuses, that are entered in Bit 0 to
7 or Bit 8 to 15 (for redundant partner):
0 0 0 0 0 0 0 1 Passivated 7
0 0 0 0 0 0 1 0 Out of service 6
0 0 0 0 0 1 0 1 Maintenance required 3
0 0 0 0 0 1 1 0 Maintenance request 2
0 0 0 0 0 1 1 1 Maintenance alarm 1
0 0 0 0 1 0 0 0 Untested/unknown 0
0 0 0 0 1 0 0 1 Configuration changed 8
Note
If the maintenance status is "untested/unknown", all other dynamic displays in the faceplates
for Asset Management are not relevant to this instance.
Redundancy
In case of redundancy, several combinations of the displays are possible. See:
Status display for redundant components [Asset] (Page 328)
Note
The status MS = 9, configuration changed, is for the redundant components and is therefore
not listed here.
PV = process value
PA-Field-Device Status
Diagnostic information
The structure of the PA_DIAG parameter is as follows:
6.10.4 Text library for MOD_1, MOD_2, MOD_3, MOD_64, MOD_D2, MOD_CP
The following table lists the message texts and their text numbers from the text library for the
MOD_1 (FB 91) / MOD_2 (FB 92) / MOD_3 (FB 95) / MOD_64 (FB 137) / MOD_D2 (FB 94) /
MOD_CP (FB 98) blocks :
Description of I
SUBNET, 273
I/Os of
Description of
IMDRV_TS, 78
ChkREAL, 279
I/Os of, 22, 31, 41, 46, 50, 56, 64, 71
Description of
CONEC, 22
QC_CHNG, 279
CPU_RT, 31
DIAG_AB
DIAG_AB, 35
Description, 33
DPAY V1, 46
I/Os, 35
DPAY_V0, 41
DPAY V1, 46
DPDIAGV0, 50
I/Os, 46
DREP, 56
DPAY_V0, 41
DREP_L, 64
Description, 36
FM_CNT, 71
I/O, 41
FM_CO, 17
DPAY_V1, 43
I/Os of
Description, 43
MOD_2, 84
DPDIAGV0, 47, 50
I/Os of
Description, 47
MOD_1, 84
I/Os, 50
I/Os of, 84
DREP, 51, 56
I/Os of
Description, 51
MOD_2, 91
I/Os, 56
I/Os of
DREP_L, 59, 64
MOD_1, 91
Description, 59
I/Os of, 91
I/Os, 64
I/Os of, 98
I/Os of
MOD_3, 98
E
I/Os of
Error Information of Output Parameter MOD_4, 105
MSG_STAT, 322 I/Os of, 105
I/Os of, 111
I/Os of
F MOD_64, 111
I/Os of, 117
Faceplate, 292
I/Os of
OB_BEGIN, 292
MOD_CP, 117
Faceplates, 286
I/Os of
Asset Management, 286
MOD_D2, 125
FM_CNT, 67, 71
I/Os of
Description, 67
MOD_D1, 125
I/Os, 71
I/Os of, 125
FM_CO
I/Os of
Description, 15
MOD_D2, 135
I/Os, 17
I/Os of
MOD_D1, 135
I/Os of, 135
G
I/Os of
General information about the block description, 9 MOD_D3, 146
Global representations and views of asset I/Os of, 157
faceplates, 305 I/Os of
MOD_HA, 157
I/Os of, 165
Q MOD_3, 337
Text library for
QC_CHNG, 279
MOD_2, 337
Description, 279
Text library for
MOD_1, 337
Text library for
R
MOD_D1, 339
RACK, 264, 268 Text library for, 339
Description, 264 Text library for, 343
I/Os, 268 Text library for
RED_F MOD_MS, 343
Description, 270 Text library for
I/Os, 272 OB_BEGIN, 344
Text library for, 344
S
Status display for redundant components [asset], 328
SUBNET, 273, 277
Description, 273
I/Os, 277
T
Technical specifications
Blocks in the basic library, 309
Text library for
MOD_D3, 341
MOD_PAX0, 336
Text library for, 336
Text library for
MOD_PAL0, 336
Text library for, 336
Text library for
PADP_L00, 336
Text library for
PADP_L01, 336
Text library for
PADP_L02, 336
Text library for
DREP, 336
Text library for
DREP_L, 336
Text library for, 336
Text library for
MOD_64, 337
Text library for, 337
Text library for
MOD_D2, 337
Text library for
MOD_CP, 337
Text library for