It is easy to strip off insulation from Fast-Connect (FC) cables with a special tool.
Cable marked as suitable for Fast-Connect (FC) |
The cross-section of a "standard" PROFIBUS cable is not always round. |
|
The cross-section of a "Fast Connect" PROFIBUS cable is round and can therefore be easily stripped with the special tool. |
1. Hold tool in right hand. |
2. Measure off the length of cable to be stripped according to specifications against the side of the tool and hold this length firmly with the left thumb. |
3. Insert the end of the cable into the tool, using your finger as an end-stop. |
4. Close the tool tightly. |
5. Rotate the tool three times in the direction of the arrow. |
6. Keep the tool closed and pull away in the direction of the arrow. |
7. The stripped insulation stays in the tool. When the tool is opened it can easily be removed. |
8. Remove any remaining insulating foil. |
9. If required: After removal of insulation, the cable can be connected in the plug. |
Before commissioning a PROFIBUS system, stations must be assigned unique addresses.
The PROFIBUS address of a DP slave can be adjusted in two ways:
1.Through settings on the device with the help of switches or another control interface.
2.By sending a special telegram via the PROFIBUS. Address 126 is reserved as the default address for a DP slave.
This second function is not necessarily supported by every DP slave. The entry
Set_Slave_Add_supp = 1
in the GSD file indicates whether this function is supported.
The address of a DP slave can only be changed in the state Wait Parameter (WPRM). Only when the DP slave is in this state can the master (typically a class 2 master) send a telegram to modify the DP slave's address. The master should first verify that the new address is actually free.
After the address has been changed, it is necessary to execute a cold-start (power supply off and on again) of the DP slave.
Address: telegram to change address with 4 bytes
New address |
Ident number High byte |
Ident number Low byte |
Extensions |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Address byte 1: New address |
0–125 (0x00–0xFE) |
New address |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Address byte 2 & 3: ident number |
0-255 (0x00-0xFF) |
Ident number high byte |
|||||||
0-255 (0x00-0xFF) |
Ident number low byte |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Address byte 4: |
|
|
|
|
|
|
|
X |
Further changes of the address are not allowed |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
|
Reserved |
The two address bytes in the telegram header of telegrams (Request, Confirmation and Response telegrams) contain the station's destination address (DA) and source address (SA).
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
DA: Destination address |
|
0 - 127 (0x7F) |
Destination address |
||||||
0 1 |
|
|
|
|
|
|
|
no DSAP (SAP = NIL) DSAP present |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
SA : Source address |
|
0 – 126 (0x7E) |
Source address |
||||||
0 1 |
|
|
|
|
|
|
|
no SSAP (SAP = NIL) SSAP present |
Address 127 is reserved as a global address for broadcast or multicast messages (telegrams to all bus users or user groups selected via service access point; only allowed with Send Data with No Acknowledge, SDN).
The address byte of the Request telegram should be reflected in the Response telegram in reverse, i.e. the SA byte of the Response telegram contains the destination station address and the DA byte the source station address of the Request.
For formats with a PDU, the address extension serves to identify a destination and/or source address extension in the form of a Service Access Point (SAP) that immediately follows the FC byte in the PDU. The address extensions of a Request telegram must be reflected in the Response telegram in reverse.
If the address extension bit has not been set, it is the special SAP = NIL. This Service Access Point has the advantage that its telegram is 2 bytes shorter and is therefore used for cyclic data exchange.
Every PROFIBUS station must have a unique address for communication. These PROFIBUS addresses are coded in one byte and comprise the range 0 - 127. However, individual address values are reserved and no longer free to be assigned.
Address |
Use |
0 |
is reserved as a rule for diagnostic tools, such as programming devices |
1 ... n |
Master station addresses should start with the lowest address. A single master will therefore have address 1.
Additional master stations will have addresses 2, 3... etc. |
n ... 125 |
This means that, in a PROFIBUS network with one master, no more than 124 addresses will be left free for slave stations. |
126 |
is reserved as a delivery address (default) for stations whose address can be adjusted via the bus. This is explained in more detail in the chapter on address changes. |
127 |
is reserved for addressing all or groups (broadcast) and cannot therefore be set for one station. |
Infrastructural components like repeaters, couplers and fibre optic (FO) converters transmit telegrams transparently from one segment to another and therefore do not require their own address.
The bus cycle time TDP in a multi-master system is dependent on various factors:
•how many class 2 masters are active in the system alongside the class 1 master?
•how much acyclic data is transferred by the class 1 master or the class 2 master?
To keep the bus cycle time constant - equidistant - the following procedure is used:
Structure of the equidistant bus cycle
The class 1 DP master commences cyclic data exchange. It can signal this by sending a global control (GC) telegram. First it sends - if necessary - a GC to signal its operating state. Cyclic data for all DP slaves will then follow. It is possible to calculate the time required for cyclic data as for a single master. Subsequently, the class 1 master processes one acyclic service (MS1) and passes the token (TC) on to any class 2 master. This master in turn processes another acyclic service (MS2) and passes the token back to the class 1 master.
In a non-equidistant cycle, the class 1 master will immediately continue here with cyclic communication. The duration of a bus cycle therefore depends to a great extent on the presence of a second master and the need for acyclic services.
With an equidistant bus cycle the class 1 master waits until the cycle time has elapsed before it starts another bus cycle. It does this by executing an "active pause" (ASP). It keeps sending an FDL status request telegram to itself. This ensures that the bus remains active and controlled for all other bus users. Only when there is too little time for such a telegram - e.g. remaining time is less than TSL - does the cyclic master execute a "passive pause" (PSP) until the bus cycle time has elapsed. At this precise microsecond, it is now possible - if desired - to retransmit a clock telegram or start up cyclic data exchange.
For an equidistant cycle to be maintained, this time must be selected to be long enough and the number of permitted acyclic services with a class 2 master must be restricted.
The active bus termination is mounted as a separate component in the switch cabinet. This bus termination is easier to identify than a switch on a plug and, through appropriate measures, it is possible to make sure that it is always supplied with power. |
|
Suitable models have a redundant input and plug for the connection of diagnostic tools.
Bus lines are connected via terminal connectors, since the bus termination as part of the infrastructure must not be regularly plugged in and out. However, plug-in terminals make it easier to measure the cable laid. |
Alarms are assigned to a slot and can exhibit different types.
The alarms supported are defined in the GSD file. In the Set_Parameter telegram, the DP master specifies which alarms may be sent by the DP slave.
Diagnostic_Alarm_supp = 1
Diagnostic_Alarm_required = 0
The DP slave supports diagnostic alarms, but does not necessarily need this support to function correctly. A diagnostic alarm signals an event in a slot, e.g. excessive temperature, short circuit, etc.
Process_Alarm_supp = 1
Process_Alarm_required = 0
A process alarm signals an event in association with the connected process, e.g. overshooting an upper limiting value.
Pull_Plug_Alarm_supp = 1
Pull_Plug_Alarm_required = 0
When a module is withdrawn from or plugged into a slot, this DP slave can generate a pull or plug alarm.
Status_Alarm_supp = 1
Status_Alarm_required = 0
A status alarm signals a change of state in the DP slave, e.g. Ready, Run, Stop etc.
Update_Alarm_supp = 1
Update_Alarm_required = 0
As soon as a parameter is modified by local operation or an engineering device, an alarm can be generated by this DP slave.
Manufacturer_Specific_Alarm_supp = 1
Manufacturer_Specific_Alarm_required = 1
The manufacturer can define further alarms.
The alarm model allows transmission of alarms from a DP-V1 slave to its DP-V1 master and demands an explicit acknowledgement of this alarm by the master to the slave.
The following conditions must be satisfied as the basic requirement for an alarm:
•The slave must be in the data-exchange state (DXCHG).
•The MS1 connection must be enabled (i.e. in the parameter telegram DPV1_Enable = TRUE has been set).
•The corresponding bit for this alarm has also been set in the parameter telegram.
•The maximum active alarms limit has not yet been reached. Two models are supported for the maximum number of alarms:
1.Only one alarm per specified type can be active (Alarm_Type_Mode).
2.Numerous alarms can be active with a fixed total number (Alarm_Sequence_Mode).
This alarm mode is indicated with the following GSD file key words:
Alarm_Sequence_Mode_Count = 0
0 = not supported, 2 - 32 number of pending alarms
The current total is set by the master in the Set_Parameter telegram. This function is optional, i.e. the value 0 is allowed.
Alarm_Type_Mode_supp = 1
Support for Alarm_Type_Mode is mandatory, i.e. this key word must always stand among the supported alarms in the GSD with value 1.
When an alarm occurs, the alarm message is inserted in the diagnostic field of the diagnostic telegram and, with the priority bit in the next data cycle, the DP-V1 master is requested to read the diagnosis. Any reading of the alarm is registered and the alarm is written to a queue. Further alarms will not overwrite this alarm.
Sequence of frames for the handling of alarms
The class 1 DP master (controller) with cyclic process data exchange (MS0) is the only master that may acknowledge alarms on the DP slave. For this purpose it uses SAP = 51, as for the other acyclic services. The DP slave can optionally provide an additional SAP = 50 for acknowledging alarms. This avoids any delay of acknowledgements due to possible pending acyclic services. Support for this option is indicated in the GSD file with the key word
Extra_Alarm_SAP_supp = 1
These two SAPs are enabled by the DP-V1 slave as soon as it is in the data exchange state. Since these two SAPs are directly related to cyclic MS0 communication, it is not necessary to administer the communications relationship specially with an Initiate and Abort. The DP-V1 master must explicitly acknowledge the alarms with a DPV1_Alarm_Ack telegram at SAP 50 or 51. After successful acknowledgement, the DP-V1 slave can remove the alarm from the queue. The maximum number of alarms in this queue is defined in the parameter telegram.
Diagnostic messages are supported by every DP slave. These messages are easily transmitted as required, but they are neither acknowledged nor is their reception or processing verified.
With an MS1 connection, additional alarm and status messages are now defined.
•With a status message the data structures for events are defined more comprehensively.
•With alarms, various types are differentiated, the sequence of telegrams for acknowledgement is set down, and the data structures are defined.
Alarms are transferred as blocks in a diagnostic telegram. These blocks have the following structure:
Header |
Alarm_Typ |
Slot_Number |
Alarm_Specifier |
Diag_User_Data |
The Header for an alarm block specifies the length of the block:
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
---|---|---|---|---|---|---|---|---|
0 |
0 |
|
|
|
|
|
|
Header for diagnostic block |
|
|
0 - 63 |
Number of bytes in this diagnostic block (inc. this byte) |
In the byte Alarm_Typ the type of alarm is indicated:
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
---|---|---|---|---|---|---|---|---|
0 |
|
|
|
|
|
|
|
Identification as alarm block |
|
0 (0x00) 1 (0x01) 2 (0x02) 3 (0x03) 4 (0x04) 5 (0x05) 6 (0x06) 32-126 sonst |
Reserved Diagnostic alarm Process alarm Pull Alarm Plug Alarm Status Alarm Update Alarm Manufacturer-specific Reserved |
Byte Slot_Number:
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
0 – 254 |
Number of slot concerned (255 is reserved) |
Byte Alarm_Specifier:
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
|
|
|
|
|
0 |
1 |
Error occurs and fault present |
|
|
|
|
|
|
1 |
0 |
Error goes and fault is gone |
|
|
|
|
|
|
1 |
1 |
Error goes but fault remains |
|
|
|
|
|
1 |
|
|
Acknowledgement required |
|
|
|
|
|
0 |
|
|
Acknowledgement not required |
0-31 |
|
|
|
Sequence number of alarm |
Further Diag_User_Data bytes are manufacturer-specific and must be explained in the GSD file.
For MS1 and MS2 connections an extended device model of DP-V1 is used. In addition, the functions for identification and maintenance are declared as mandatory for all devices.
The demands placed on a fieldbus interface can be grouped according to various criteria: economical, powerful, commercial and open.
Economical
The various communications interfaces not only have different performance features, but also differ on the price that such an interface might cost. If we assume the rule of thumb that the network interface of a system element should not represent more than 30% of the cost of the element itself, we arrive at the possible price dimensions: a connection to an industrial control system costing CHF 10 000 may easily cost a sum of around CHF 3000. However, if an individual sensor costing less than CHF 100 is connected, its fieldbus connection must be possible for less than CHF 30.
The same considerations must also apply regarding the planned unit volumes. If it is only intended to create individual connections for special measuring equipment or sensors, it will be hard to amortize the in-house development work. If, however, a product is developed which subsequently comes onto the market in large volumes, in-house development work can in this case be used to reduce the cost of manufacturing the communications interface. These days it is possible to obtain all types of interfaces from appropriate technology suppliers for all industrial communications systems, ranging from simple ASICs with diagrams and mounting instructions to complete interface assemblies on a board. Only in rare cases is it worthwhile for large mass producers to work out their own industrial communications technology.
Powerful
Demands on a fieldbus interface also differ according to the area of application. Depending on use, requirements change regarding reaction times and data volumes to be transferred. On the basis of these demands, different performance characteristics can be put together regarding PROFIBUS, for example.
Designation |
Use |
Requirements |
Bit rate |
PA/GA |
Process automation building automation |
Large distances slow processes |
93.75 kBit/s |
MPI |
Programming |
Compatible with SIMATIC |
187.5 kBit/s |
FMS |
Master-to-master communication |
(not used much any more) |
500 kBit/s |
DP |
Decentralized periphery |
Efficient protocols |
1.5 Mbit/s |
MC |
Motion control |
Short cycle times |
12 Mbit/s |
For every profile, the price structure is therefore also different. It is quite clear that the higher the demands, the higher the costs of the interface connection. It must therefore also be possible to reduce the cost of an interface by lowering the demands.
With PROFIBUS we have yet another distinguishing feature: the individual devices can be either active masters or passive slaves. The expense of implementing an active master is greater by a factor of 10 than for a passive slave.
Another criterion is the amount of data to be transferred. As a rule, process data is not particularly bulky. These days, for one process point, people tend to use a float value of 4 bytes followed by one status byte. This means that 5 bytes have to be transmitted for every value. With PROFIBUS this allows more than 40 process points to be transferred at once in one device, which leads to great efficiency for average data volumes.
Commercial
Why does being commercial play an important role? One individual manufacturer can no longer develop and produce for itself all the products it needs to integrate a complex system. Therefore they turn to open interfaces that are covered by commercial products. The manufacturer limits itself to developing and producing the actual product for which its core competencies apply, complementing its products with those of other manufacturers. A fieldbus is therefore all the more suitable, the more manufacturers and products there are for this system.
Being future-proof is just as important. Anyone who invests in new technology wants to be sure that these developments can be amortized. In automation technology product life cycles are significantly greater and longer than is normal for information technology. After one year, information technology hardware becomes obsolete while operating systems change every three years and application programs after no more than six years. In automation technology, people want to use a building for 30 years with the same infrastructure, a production line remains in operation for at least 10 years, and in the chemical industry we have IT still in use today in production after 20 years.
Today, more than 50% of all fieldbus systems in automation technology are implemented with PROFIBUS according to IEC 61158. Forecasts clearly indicate that this will also remain the case in future. Currently, only Ethernet-based technology represents an alternative, but one which is still divided into several versions. With PROFINET a seamless transition will be possible from PROFIBUS.
Open
Openness has various aspects: technical and legal openness. Technical openness means that we can turn to the technical documentation and have access to a precise description that can be used for an implementation. Today, technical openness is often documented with international standards. IEC 61158 can serve here as an example, in which PROFIBUS too is openly disclosed.
Legal openness is much more complex. If a fieldbus is an international standard, it can still come under the protection of patent law, i.e. we need a licence to be able to implement this standard in a product. The standards authorities only demand that these restrictions are declared in the standardization and that all manufacturers receive a licence on fair terms. Often there is a general release that limits itself to the standardized parts, i.e. under certain conditions one is allowed to implement the standardized part and so one receives a kind of implicit licence. For token passing and field device technologies that relate to PROFIBUS, patents have been lodged by Siemens and Endress+Hauser. Members of the PROFIBUS organization automatically receive with their membership the right to the unlimited use and sale of these technologies. It is the declared intention of the patent holder to prevent any circulation of PROFIBUS technology under open source licensing terms. In the view of the patent holder, an open source solution does not satisfactorily deal with the question of liability in case of quality defects in an implementation.
With a systematic approach to the planning, commissioning and maintenance of a PROFIBUS network, errors can be avoided and expense reduced. We recommend the following tried and tested steps:
Step |
Description |
---|---|
1. Prepare |
1.We select which field devices we wish to use in our automation task. 2.We collect the General Station Description (GSD) files for our chosen field devices. This lets us know what properties the devices used have. 3.The GSD files are loaded into the library of the planning tool. |
2. Plan |
1.The system is planned by assigning field devices to the controller. 2.Controllers and field devices are configured. The individual stations are taught by the configuration who is supposed to communicate and exchange data with whom. 3.Controllers and field devices are parametrized. The individual parameters define how specific functions are to be executed within the devices. |
3. Install |
1.The network is constructed with the distances and number of repeaters. 2.Cable is laid on a correct route. 3.Cables are connected with suitable connectors. 4.The installation is checked. |
4. Commission |
The PROFIBUS network must be commissioned systematically. |
5. Monitor |
1.All devices supply diagnostic information. Rigorous interpretation and assessment of this information assists in locating faults. 2.Field devices can report their status with diagnostic information. 3.The quality of data transmission on the PROFIBUS can be monitored. |
All devices are connected in a bus structure (line). In one segment up to 32 stations (masters, slaves or repeaters) can be switched together. Rules regarding stub lines must be respected.
Each PROFIBUS segment must be terminated at the beginning and end and in no case include and bus termination between these ends. Some PROFIBUS devices have integral bus terminations that can be switched on and off. In such cases it is important for these bus terminations to be switched off. A common error is to have the bus termination in the connector and in the device switched on at the same time! This duplicate termination leads to a termination fault and hence to reflections.
In any one segment, it is important that terminations should be switched on and off in the right connectors. For this reason, the rules and a few examples are explained in detail here:
1.Optimum position of the masters and of bus terminations
2.Connection of more than 32 stations on one bus
3.Transmitting over a longer distance
4.Covering complex topologies
5.Electrical isolation of individual segments on the bus
Additional possibilities result from the use of FOC converters.
The acyclic services always have a function number (Function_Num) in their first byte. This function number defines the acyclic service. During the response, the 7th bit signals whether an error has occurred in the request.
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
DP-V1 services: 1st byte Function_Num |
X |
|
|
|
|
|
|
|
0 positive response / 1 error message |
|
72 (0x48) 81 (0x51) 86 (0x56) 87 (0x57) 88 (0x58) 92 (0x5C) 94 (0x5E) 95 (0x5F) |
Idle DPV1_Data_Transport DPV1_Resource_Manager DPV1_Initiate DPV1_Abort DPV1_Alarm_Ack DPV1_Read DPV1_Write |
The coding of services is listed in the following table.
DPV1 service |
Function Num |
Direction |
Further parameters |
---|---|---|---|
Initiate |
0x57 |
REQ |
reserved (3 Octets), Send_Timeout, Features_Supported, Profile_Features_Supported, Profile_Ident_Number, Add_Addr_Param |
RES |
Max_Len_Data_Unit, Features_Supported, Profile_Features_Supported, Profile_Ident_Number, Add_Addr_Param |
||
Abort |
0x58 |
REQ |
Subnet, Instance/Reason_Code |
Read |
0x5E |
REQ |
Slot_Number, Index, Length |
RES |
Slot_Number, Index, Length, Data |
||
Write |
0x5F |
REQ |
Slot_Number, Index, Length, Data |
RES |
Slot_Number, Index, Length |
||
Alarm Ack |
0x5C |
REQ |
Slot_Number, Alarm_Type, Specifier |
RES |
Slot_Number, Alarm_Type, Specifier |
||
Idle |
0x48 |
REQ |
- |
RES |
- |
||
Data Transport |
0x51 |
REQ |
Slot_Number, Index, Length, Data |
RES |
Function_Num (0x51), Slot_Number, Index, Length, Data |
||
Resource Manager |
0x56 |
REQ |
Function_Num (0x56), Server_SAP, Send_Timeout |
In the case of a negative answer, the response will always contain 4 bytes: after the function number with 7th bit set, the following bytes are always added:
Function_Num |
Error_Decode |
Error_Code1 |
Error_Code2 |
with the meanings:
Byte Error_Decode: Type of status message
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
0 - 127 128 (0x80) 129 - 253 254 (0xFE) 255 (0xFF) |
Reserved PROFIBUS DP Reserved PROFIBUS-FMS HART |
Byte Error_Code_1: Consists of the Error_Class (bits 4 to 7) and the Error_Code (bits 0 to 3). The meaning of the error code depends on the error class:
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Error_Class |
Error_Code |
---|---|---|---|---|---|---|---|---|---|
0-9 |
|
Reserved |
|
||||||
10 |
0 1 2 3 – 7 8 9 10 – 15 |
Application error |
Read error Write error Module failure Reserved Version conflict Feature not supported User specific |
||||||
11 |
0 1 2 3 4 5 6 7 8 9 10 - 15 |
Access error |
Invalid index Write length error Invalid slot Type conflict Invalid area State conflict Access denied Invalid range Invalid parameter Invalid type User specific |
||||||
12 |
0 1 2 3 8 4 – 7 9 - 15 |
Resource error |
Read constrain conflict Write constraint conflict Resource busy Resource unavailable Version conflict Reserved User specific |
||||||
13-15 |
|
User specific |
|
Byte Error_Code_2: Further manufacturer-specific error codes.
On this MS1 connection, two services can be executed for data: DPV1_Read and DPV1_Write.
DPV1_Read:
0x5E |
Slot_Number |
Index |
ReqLength |
Several poll cycles without data, last poll cycle with response data. If the response is positive:
0x5E |
Slot_Number |
Index |
ResLength |
Data |
If the response is negative:
0xDE |
Error_Decode |
Error_Code1 |
Error_Code2 |