Спецификация протокола Profibus
Подождите немного. Документ загружается.
Page 711
PROFIBUS-Specification-Normative-Parts-8:1997
Copyright by PNO 1997 - all rights reserved
User- User-
Interface ! DDLM !FDL BUS FDL! DDLM ! Interface
-----------------------------------------------------------
! ! ! !
Function.req ! ! ! !
------------>! SDN.req ! (Data) ! !
!-------->! SDN_REQ_PDU ! !
! !------------->!SDN.ind !
!<--------!--) !-------->!Function.ind
<------------! SDN.con ! ! !----------->
Function.con ! ! ! !
! ! ! !
Figure 10. Processing of Master-Slave communication of the DDLM_function
DDLM_Global_Control
7.5.2 Master-Master Communication
Communication requests are initiated by the User Interface of a DP-Master (class
2) and will be sent to the DDLM with the function primitive Request (.req). The
DDLM acknowledgement will be received with the function primitive (.con).
Depending on the type of DDLM function, two types of sequences of processing can
be identified between User and DDLM. The Master-Master communication functions
will be executed in one or more layer 2 message cycles. A DP-Master (class 1)
processes all communication-functions with the exception of DDLM_Act_Para_Brct
with an Indication-Response-Sequence.
The Coding of the DDLM-Functions is accomplished through a defined layer 2
service access point. Additionally, the Master-Master communication needs more
coding information. This coding will be placed by the DDLM in the first octet of
the Data-Unit of layer 2.
An overview of possible Master-Master functions can be found in section "DP-
Master - DP-Master Functions".
Instead of these Master-Master DDLM communication functions, FMS-services
according to PROFIBUS Application Layer Service Definitions can be used. This
applies for devices which use PROFIBUS-DP and PROFIBUS-FMS simultaneously (see
annex 2-B.1).
Page 712
PROFIBUS-Specification-Normative-Parts-8:1997
Copyright by PNO 1997 - all rights reserved
User ! DDLM !FDL BUS FDL! DDLM ! User
-------------------------------------------------------------
! ! ! !
! ! ! !
Function.req ! ! ! !
------------>! SRD.req ! (Data) ! !
!-------->! SRD_REQ_PDU ! !
! !------------->!SRD.ind !
! !<------------/!-------->!Function.ind
! [<-----! SRD_RES_PDU ! !----------->
! SRD.con ! (no Data) ! !
! ! ! !
! SRD.req ! (no Data) ! !
! [----->! SRD_REQ_PDU ! !
! !-------------]! !
! !<------------/! !
! [<-----! SRD_RES_PDU ! !
! SRD.con ! (no Data) ! !
! ! . ! !
! ! . ! !
! ! . ! !
! ! ! !Function_res
! ! !Upd.req !<---------
! ! (--!<--------!
! ! (->!-->] !
! ! !Upd.con !
! SRD.req ! (no Data) ! !
! [----->! SRD_REQ_PDU ! !
! !------------->!SRD.ind !
! !<------------/!----->] !
!<--------! SRD_RES_PDU ! !
<------------! SRD.con ! (Data) ! !
Function.con ! ! ! !
Figure 11. Processing of all Master-Master communications except
DDLM_Act_Para_Brct
User ! DDLM !FDL BUS FDL! DDLM ! User
------------------------------------------------------------
! ! ! !
Function.req ! ! ! !
------------>! SDN.req ! (Data) ! !
!-------->! SDN_REQ_PDU ! !
! !------------->!SDN.ind !
!<--------!--) !-------->!Function.ind
<------------! SDN.con ! ! !----------->
Function.con ! ! ! !
! ! ! !
Figure 12. Processing of the Master-Master communication
DDLM_Act_Para_Brct
Page 713
PROFIBUS-Specification-Normative-Parts-8:1997
Copyright by PNO 1997 - all rights reserved
8 Medium Access and Transmission Protocol
8.1 General
The medium access and transmission protocol has to be implemented according to
the PROFIBUS Specification. PROFIBUS-DP distinguishes between active and passive
stations. The active stations form a virtual Token-Ring.
Passive stations do not participate in token passing and are thus not members of
the virtual token ring. They shall be polled by a Master in a Master-Slave
communication cycle.
In PROFIBUS-DP a DP-Slave is associated with a distinct DP-Master. The DP-Master
(class 1) is polling the associated DP-Slaves cyclically according to the
master's data base.
The DP-Master (class 2) communicates with DP-Slaves acyclically.
The FMS-Master is polling the associated FMS-Slaves according to its Poll List
cyclically or acyclically.
The following configurations are possible:
- PROFIBUS-DP System (Monomaster)
active Station
Token
+ - - - - - - -+
! DP-Master !
! (class 1) !
! +----+ !
+ ->! 1 ! - ->+
+----+
!
!
-+-------+-------+------++-------+-------+-------+-
! ! ! ! ! ! !
! ! ! ! ! ! !
::::: ::::: ::::: ::::: ::::: ::::: :::::
! 2 ! ! 3 ! ! 4 ! !.. ! !.. ! !.. ! !.. !
::::: ::::: ::::: ::::: ::::: ::::: :::::
DP-Slaves
Figure 13. Monomaster PROFIBUS-DP System
Figure 13 shows a PROFIBUS-DP Monomaster-System. The system consists of a DP-
Master (class 1) and up to 125 DP-Slaves.
According to the Data Link Layer Service Protocol Specifications of PROFIBUS the
DP-Master (class 1) passes the Token regularly (if there is no request or the
T
TR
expired) to itself.
Page 714
PROFIBUS-Specification-Normative-Parts-8:1997
Copyright by PNO 1997 - all rights reserved
- PROFIBUS-DP System (Multimaster)
active Stations
Token
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
! DP-Master DP-Master DP-Master DP-Master !
! (class 2) (class 1) (class 1) (class 1) !
! +----+ +----+ +----+ +----+ !
+ - - >! 0 ! - - > ! 1 ! - - >! 2 ! - - >! 3 ! - - - >+
+----+ +----+ +----+ +----+
! ! ! !
! ! ! !
-+-------+-+-----+------++-------+--+----+-----+-+-------
! ! ! ! ! ! !
! ! ! ! ! ! !
::::: ::::: ::::: ::::: ::::: ::::: :::::
!11 ! !12 ! !13 ! !14 ! !15 ! !16 ! !17 !
::::: ::::: ::::: ::::: ::::: ::::: :::::
DP-Slaves
Possible associations of DP-Slaves to the Master:
DP-Slave: 11,12,13 DP-Master: 1
DP-Slave: 14,15 DP-Master: 2
DP-Slave: 16,17 DP-Master: 3
Figure 14. Multimaster PROFIBUS-DP System
Figure 14 shows a PROFIBUS-DP Multimaster system configuration. The association
of DP-Slaves to the DP-Master (class 1) is defined during system configuration
and will be stored in the master's parameter set. Up to 126 devices are possible
on one network.
Page 715
PROFIBUS-Specification-Normative-Parts-8:1997
Copyright by PNO 1997 - all rights reserved
- mixed PROFIBUS System
active Stations
Token
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
! DP-Master DP-Master DP-Master FMS- !
! (class 2) (class 1) (class 1) Master !
! +----+ +----+ +----+ +----+ !
+ - - >! 0 ! - - > ! 1 ! - - >! 2 ! - - >! 3 ! - - - >+
+----+ +----+ +----+ +----+
! ! ! !
! ! ! !
-+-------+-+-----+------++-------+--+----+-----+-+-------
! ! ! ! ! ! !
! ! ! ! ! ! !
::::: ::::: ::::: ::::: ::::: ::::: :::::
!11 ! !12 ! !13 ! !14 ! !15 ! !16 ! !17 !
::::: ::::: ::::: ::::: ::::: ::::: :::::
passive Station
Possible association of Slaves to the Master:
DP-Slave: 11,12,13 DP-Master: 1
DP-Slave: 14,15 DP-Master: 2
FMS-Slave: 16,17 FMS-Master: 3
Figure 15. Mixed PROFIBUS-System
The structures in Figure 14 and 15 show the general outline of a Multi-Master-
System. The Token is passed from active station to active station. The Master
that currently holds the token is able to access the media as a requester.
In a mixed PROFIBUS-System, PROFIBUS-DP devices and PROFIBUS-FMS stations can
use the same media. They are compatible at the physical and media access layer,
but they can not exchange information at application level.
Depending on the requirements, several FMS- and/or DP-Masters are allowed. Up to
126 devices are possible on one network.
For performance reasons a PROFIBUS-DP system should not consist of more than 3
DP-Masters.
8.2 Token Rotation Time
A very important fact for a DP-Master (class 1) connected to field devices is a
fixed cycle time. A DP-Master (class 1) has to have a Target Rotation Time (T
TR
)
large enough, so that it can poll each associated DP-Slave once per token
cycle.
In a multimaster system the cycle time of each DP-Master (class 1) has to be
extended by the token hold time of all other masters.
To maintain the cycle time of the DP-system in a specific DP-application, a DP-
Master (class 1) should have a sufficient Target Rotation Time (T
TR
) for a
complete poll cycle. To reach this goal, it is necessary to prioritize the DP-
Master (class 1) towards the other Masters. Thus, the T
TR
is set in a way that
the DP-Masters (class 1) add the time of a complete poll cycle to the T
TR
of the
other masters in the ring.
Page 716
PROFIBUS-Specification-Normative-Parts-8:1997
Copyright by PNO 1997 - all rights reserved
Calculation:
for FMS-Masters and DP-Masters (class 2):
T
TR(FMS)
> ∑T
SLP
(1)
for DP-Masters (class 1):
T
TR(DP)
= T
SLP(TS)
+ T
TR(FMS)
+ T
ADD
(2)
T
ADD
= (T
ID1
+ T
SL
+ 2⋅255⋅11⋅t
Bit
)⋅(Max_Retry_Limit + 1) (3)
Legend:
T
TR(FMS)
= FMS- and DP-Masters (class 2) Target Rotation Time
∑T
SLP
= Sum of the poll cycles of all DP-Masters (class 1)
T
SLP(TS)
= Poll cycle of the DP-Master (class 1) "TS"
T
TR(DP)
= the DP-Master's (class 1) Target Rotation Time
T
ADD
= Safety margin for message retransmissions
The bus parameters T
ID1
, T
SL
, t
Bit
, Max_Retry_Limit are described the Data
Link Layer Service Protocol Specifications.
8.3 Priorities
The PROFIBUS-DP protocol uses high and low priority messages. All request
messages are sent with high priority (Master-Slave-communication). If there is
new diagnostic information in a DP-Slave the response messages in the user data
exchange mode will be replied with high priority. In all other cases, the
replies are sent as low priority messages.
8.4 Control Intervals
In industrial control systems there is a need for checking the correct
functioning of each individual part. In a DP system a media failure or a defect
in a DP-Master shall not cause errors in the peripheral system. In the above
mentioned cases, a DP-Slave shall switch to a safe state. Additionally, the user
of a DP-Master (class 1) has to be informed about transmission breakdowns after
a certain amount of time.
- Control Interval at the DP-Slave:
This Timer (watchdog control), retriggered by received Master-requests, will set
the outputs of a DP-Slave to the safe state after expiration of the timer.
The definition of the watchdog control time can be found in section "Send
Parameter Data".
- Control Interval at the DP-Master (class 1):
The data transfer between DP-Master (class 1) and its associated DP-Slaves will
be controlled by the User-Interface. By this means a master checks the data
transfer to its DP-Slaves.
Additionally the Data_Control_Time defines the time in which a DP-Master (class
1) indicates his operation mode to the dedicated DP-Slaves.
The master parameter set contains the Data_Control_Time.
Rule:
T
WD
> T
TR
(4)
Data Control Time ≥ 6⋅T
WD
(5)
Page 717
PROFIBUS-Specification-Normative-Parts-8:1997
Copyright by PNO 1997 - all rights reserved
8.5 System Reaction Time
The system reaction time depends mainly on the number of stations, the number of
bytes per DP-Slave and the number and types of masters in the system.
Furthermore, the maximum reaction time (max T
SDR
) of the individual Stations
will influence the system reaction time.
A typical DP-Station will have a max. T
SDR
according to Table 4.
The calculation of the system reaction time is straightforward in a monomaster
system. The formula below will predict the system behaviour.
To maintain a fast reaction time, the bus traffic shall not have gaps between
messages.
The theoretical system reaction time is calculated as follows:
theoretical system reaction time =
[Token + GAP-Request + Number Stations⋅Offset + (6)
+ Number I/O-Bytes⋅11 + T
SM
]⋅t
Bit
If the minimal values according to Table 3 can be applied, at a transmission
speed of 1500 kBit/s (all stations have Inputs and Outputs) the cycle time
equals to:
= [70 + 403 + Number Stations⋅246 + Number I/O-Bytes⋅11 + (7)
+ T
SM
]⋅t
Bit
The formula above assumes a mono-master-system. The DP-Master sends out the
Token to itself. min T
SDR
is set to 11 t
BIT
, T
ID1
/ T
ID2
is set to 37 t
BIT
.
time for Token : T
ID1
+T
Token
= (37+33)t
BIT
= 70t
BIT
time for GAP : T
ID1
+T
SD1
+T
SLOT
= (37+66+300)t
BIT
= 403t
BIT
time for Offset: T
ID1
+2⋅T
SD2_R
+min T
SDR
= (37+198+11)t
BIT
= 246t
BIT
time for T
SM
: = 1t
BIT
Legend:
T
Token
Time to transmit a token-frame
T
SD1
Time to transmit a frame with Start Delimiter SD1
T
SD2_R
Time to transmit a frame with Start Delimiter SD2
(without Lsdu)
The bus parameters T
ID1
, T
SL
, t
Bit
, T
SM
are described in the Data Link Layer
Service Protocol Specifications.
For communication networks with more than one master this calculation is
complex. In this case, the individual token-hold-time of each DP-Master shall be
part of the calculation.
Part 4 gives a basic rule for the token rotation time.
Page 718
PROFIBUS-Specification-Normative-Parts-8:1997
Copyright by PNO 1997 - all rights reserved
8.6 Frame Formats
The frame format of PROFIBUS-DP is according to the Data Link Layer Service
Protocol Specifications.
8.7 Address Extension
The PROFIBUS-DP protocol uses service access points (SAP) of FDL as a basic
function code.
The data exchange function has no address-extension (NIL SAP) for efficiency
reasons.
The section "Direct-Data-Link-Mapper" gives the assignment of service access
points to the functions.
Frames with address extension "Segment" (Bridge SEG Addresses) are not allowed
for PROFIBUS-DP. Frames received with segment address-extensions are ignored in
a DP station.
8.8 Bus Parameter
The following tables give an overview of the most important bus parameters and
their values in a monomaster system.
Table 3. Bus Parameter/Reaction times for a DP-Master
+--------------------+--------------+--------------+-------------+
!Baud rate in kbit/s ! up to 187,5 ! 500 ! 1500 !
+--------------------+--------------+--------------+-------------+
!T
RDY
(t
Bit
) ! ≤11 ! ≤11 ! ≤11 !
!T
SDI
(t
Bit
) ! ≤80 ! ≤180 ! ≤280 !
+--------------------+--------------+--------------+-------------+
!Default ! ! ! !
!T
SL
(t
Bit
) ! 100 ! 200 ! 300 !
!min T
SDR
(t
Bit
) ! 11 ! 11 ! 11 !
!max T
SDR
(t
Bit
) ! 60 ! 100 ! 150 !
!T
SET
(t
Bit
) ! 1 ! 1 ! 1 !
!T
QUI
(t
Bit
) ! 0 ! 0 ! 0 !
!G ! 100 ! 100 ! 100 !
!HSA ! 126 ! 126 ! 126 !
!max_retry_limit ! 1 ! 1 ! 1 !
+--------------------+--------------+--------------+-------------+
For a DP-Master it is necessary to reach the values for T
RDY
and T
SDI
as shown
in Table 3. The allowed scale of the parameters T
RDY
and T
SDI
are not fixed by
this table. In a multimaster environment or in a mixed operation with FMS-
Masters some bus parameters may have to be set to higher values. Especially the
slot time may be extended because of token passing. Each master shall have the
chance to receive the token and if necessary react (send a request or token)
properly.
Page 719
PROFIBUS-Specification-Normative-Parts-8:1997
Copyright by PNO 1997 - all rights reserved
Table 4. Bus Parameter/Reaction times for a DP-Slave
+--------------------+------------+-----------+----------+
!Baud rate in kbit/s ! up to 187,5! 500 ! 1500 !
+--------------------+------------+-----------+----------+
!max T
SDR
(t
Bit
) ! ≤60 ! ≤100 ! ≤150 !
+--------------------+------------+-----------+----------+
!Default ! ! ! !
!min T
SDR
(t
Bit
) ! 11 ! 11 ! 11 !
+--------------------+------------+-----------+----------+
For a DP-Slave it is not allowed to exceed the values of max T
SDR
as shown
in
Table 4. The allowed scale of the parameter max T
SDR
is not fixed by this table.
In a multimaster environment or in a mixed operation with FMS it is possile that
max T
SDR
has to be set to higher values.
Another performance feature for a DP-Slave implementation is the time
Min_Slave_Interval (see section "Data Interface"). Each slave implementation has
to ensure that the Min_Slave_Interval reaches the smallest value that is
possible. This means, that in a DP system with more than ten stations the
Min_Slave_Interval shall not be the dominant factor for the cycle time.
Additionally, a DP-Slave shall implement a time T
WD
(see section "Send Parameter
Data").
8.9 Statistic Counters
To install and maintain a PROFIBUS system, a DP-Master may optionally implement
the following statistic counter (FDL Variables). These counters shall be treated
pairwise:
- Counter for sent frames (Frame_sent_count), without SDN-,
FDL-Status- and Token frames.
- Counter for sent frames with no response or erroneous response
(Error_count), except SDN-, FDL-Status- and Token frames.
These counters are maintained for each individual station.
Page 720
PROFIBUS-Specification-Normative-Parts-8:1997
Copyright by PNO 1997 - all rights reserved
9 Interface between DDLM and User-Interface
This section gives a detailed specification of DDLM functions and primitives
which are provided on the interface between DDLM and User-Interface.
9.1 Device Specific Function Reference
Table 5 gives an overview of the functions which shall be implemented in a DP-
Slave and in a DP-Master. Some functions are additionally possible. Requester
and responder roles in function execution are given separatly.
Table 5. Attachment of the functions to DP-Masters and DP-Slaves
+------------------------------------------------------------+
!function DP-Slave DP-Master DP-Master !
! (class 1) (class 2) !
! Req Res Req Res Req Res !
+------------------------------------------------------------+
! !
!Data_Exchange - M M - O - !
!RD_Inp - M - - O - !
!RD_Outp - M - - O - !
!Slave_Diag - M M - O - !
!Set_Prm - M M - O - !
!Chk_Cfg - M M - O - !
!Get_Cfg - M - - O - !
!Global_Control - M M - O - !
!Set_Slave_Add - O - - O - !
! !
!Get_Master_Diag - - - M O - !
!Start_Seq - - - O O - !
!Download - - - O O - !
!Upload - - - O O - !
!End_Seq - - - O O - !
!Act_Para_Brct - - - O O - !
!Act_Param - - - O O - !
! !
+------------------------------------------------------------+
! !
!Req = Requester !
!Res = Responder/Receiver !
!M = Mandatory !
!O = Optional !
+------------------------------------------------------------+
9.2 Description Format of DDLM-Function Calls
This section describes the general outline of the function-calls between User
Interface and DDLM.
The necessary function parameters are given in a formal description as a table.
The way to implement the functions is not defined in this specification.
All parameter values shall have a defined value at execution time. The format
and the number of request or response parameters depends on the different
functions.
The first column specifies the name of the parameter. The following columns are
reserved for function primitives. It is marked whether or not a parameter is
needed for a specific primitive.