Data exchange procedures and main participant / sub-participant fieldbus system

Abstract

Method for data transmission in a fieldbus system, with a transmission path (1) via which at least one main participant (2) and a plurality of sub-participants (3) which are connected to one another, wherein the sub-subscribers (3) each have a sub-connection (33) and a function connection (34) connected to the sub-connection (33), where status information is recorded in each sub-subscriber, indicating whether the function connection is active or not active, wherein the main participant (2) outputs telegrams (100) on the transmission path (1), wherein the sub-connections (33) of the sub-subscribers (3) process the telegrams (100) in a continuous process, wherein a telegram (100) output by the main subscriber (2) comprises at least one datagram (200) comprising a control data field (201), a user data field (202) and a counter field (203), wherein the control data field (201) comprises an address field and a command field, wherein the address field designates the sub-subscribers (3) that are to exchange data with the payload field (202), wherein the command field specifies the data transmission operations to be carried out by the sub-subscribers (3) with the payload data field (202), wherein, if the command field of the datagram (200) specifies a write operation as the data transmission process to be carried out by the sub-subscribers (3), data to be written into the payload field (202) of the datagram (200) are made available to the sub-interface (33) of the sub-subscriber (3) by the function interface (34) when the function interface (34) is active, wherein the counter field (203) is modified by the sub-connection (33) of the sub-subscriber (3), which has processed the user data field (202), in a manner predefined for the respective data transmission process being carried out, wherein the status information of the sub-subscribers (3) addressed in the datagram (200) is recorded with the telegram, wherein the datagram (200) is assigned an expected value for the counter field (203), which results when the user data field (202) has been processed by the addressed sub-subscribers (3) in accordance with the data transmission processes specified in the command field, wherein the main subscriber (2) determines the expected value for the counter field (203) of the datagram (200) on the basis of the status information acquired with the telegram and compares it with the value of the counter field (203) in the datagram (200) processed by the addressed sub-subscribers (3) in order to determine a processing error in the datagram (200) processed by the addressed sub-subscribers (3) in the event of a deviation.

Description

[0001] The invention relates to a method for data exchange based on the main subscriber / sub-subscriber principle and a main subscriber / sub-subscriber fieldbus system.

[0002] In manufacturing and process automation, fieldbus systems are used in which decentralized devices of a machine periphery, such as input and / or output modules, drives and operator terminals, are connected to control units via a fieldbus.

[0003] Data exchange on the fieldbus is usually based on the main station / substation principle. The control units on the fieldbus are the active bus stations, also referred to as main stations. The main stations have bus access authorization and determine data transfer on the fieldbus. The passive stations, also referred to as substations, are usually the machine peripheral devices. The substations have no bus access authorization and can only acknowledge received data or transmit data upon request from a main station.

[0004] On the fieldbus, data is transmitted between bus devices preferably in the form of data packets, also referred to as telegrams. The processing of the data from the telegrams often takes place in the subdevices in a continuous flow using subinterfaces provided within the subdevices.

[0005] When generating a telegram in a main connection of the main participant, the telegrams are preconfigured in such a way that for each sub-participant on the fieldbus it is determined with which section in a user data area of ​​the telegram the sub-connection of the sub-participant should exchange data during the pass-through or which data transmission process should be carried out.

[0006] The main interface of the main station also assigns an additional counter field, known as a working counter, to the payload area in the telegram. This counter field is incremented by the sub-interface in the sub-station when the sub-interface in the sub-station exchanges data with the assigned section in the payload area of ​​the telegram during the pass. The counter field is modified by the sub-interface in the sub-station in a predefined manner, which is characterized for the respective data transmission process being performed.

[0007] During the preconfiguration of the telegram, the main station determines the value assigned to the telegram for the working counter, which is expected when the payload area in the telegram has been successfully processed by all addressed sub-stations according to the specified data transmission processes. After receiving the processed telegram, the main station can then check whether the telegram has been completely processed by comparing the expected value for the working counter with the actual value of the working counter in the processed telegram.

[0008] If the main participant detects a processing error by the addressed sub-participants during the comparison, the main participant discards the telegram in order to prevent the control task to be performed by the main participant in the fieldbus system from being corrupted due to faulty telegram processing.

[0009] However, if, as in a modular control cabinet system, the sub-interface and a function interface, which supplies the sub-interface with the data to be exchanged with the payload area of ​​the telegram, are implemented in separate units in the sub-subscriber in order to be able to activate or deactivate the function module containing the function interface during operation, the main subscriber will detect a processing error when comparing the counter field values ​​even if, in addition to the sub-subscribers in the fieldbus system that correctly processed the data in the payload area of ​​the telegram, one or more sub-subscribers were not involved in the processing due to inactive function modules.

[0010] However, discarding the telegram data by the main station in the event of such a permissible processing error, which is indicated by the working counter in the telegram, can be critical for the fieldbus system. Discarding the data can lead to the interruption of communication on a fieldbus, making it impossible for the controller to address the active function modules. When the function modules are used in production and process automation, this can lead to an undesirable production downtime.

[0011] KR 10 2023 078 839 A discloses a method for data transmission in an EtherCAT fieldbus system, in which the main device determines whether a subdevice is in an error-free state or in a state in which a command was not executed correctly, or whether the network is in an interrupted state, by comparing the working counters in received datagrams with a working counter reference value. DE 10 2018 133 657 A1 discloses an EtherCAT-based control cabinet system comprising a base module and function modules, wherein the base module comprises a plurality of connection units and connection elements for a plurality of function modules. The connection elements are designed to engage with module connection elements of function modules.

[0012] The object of the invention is to provide a method for data exchange based on the main subscriber / sub-subscriber principle and a main subscriber / sub-subscriber fieldbus system in which the main subscriber can recognize, in a telegram processed by the sub-subscribers in transit, which data in the telegram is valid and which data in the telegram is invalid.

[0013] This object is achieved by the features of the independent claims. The dependent claims describe embodiments.

[0014] A fieldbus system has a transmission path via which at least one main station and a plurality of sub-stations are connected to one another, wherein the sub-stations each have a sub-interface and a function interface connected to the sub-interface. Status information is recorded in each sub-station, indicating whether the function interface is active or inactive. The main station outputs telegrams along the transmission path, wherein the sub-interfaces of the sub-stations process the telegrams as they pass through. A telegram output by the main station has at least one datagram comprising a control data field, a user data field, and a counter field.The control data field has an address field and a command field, whereby the address field designates the sub-subscribers that are to exchange data with the payload field, whereby the command field specifies the data transmission operations to be carried out by the sub-subscribers with the payload field. If the command field of the datagram specifies a write operation as the data transmission operation to be carried out by the sub-subscribers, the data to be written into the payload field of the datagram is made available to the sub-connection of the sub-subscriber by the function connection if the function connection is active, whereby the counter field is changed by the sub-connection of the sub-subscriber that processed the payload field in a manner predefined for the respective data transmission operation carried out. The status information of the sub-subscribers addressed in the datagram is recorded with the telegram.The datagram is assigned an expected value for the counter field, which results when the payload field has been processed by the addressed sub-devices according to the data transmission processes specified in the command field. The main device determines the expected value for the counter field of the datagram based on the status information captured with the telegram and compares it with the value of the counter field in the datagram processed by the addressed sub-devices. In the event of a discrepancy, the main device detects a processing error in the datagram processed by the addressed sub-devices.

[0015] The main station can determine from the value of the counter field in the telegram's datagram whether the datagram has been successfully processed by the sub-stations. If one or more sub-stations have not processed the datagram or have only partially processed it, the main station can detect such a processing error by comparing the expected value for the counter field with the actual value of the counter field. To ensure that the main station can determine which data in the datagram is valid and which is invalid with as little overhead as possible in the Ethernet telegram, the sub-station uses status information to determine whether a function connection is active in a sub-station.The status information of the sub-subscribers, which indicates whether the function connection is active or not, can be acquired with the telegram from the main subscriber in order to calculate the expected value for the counter field of the datagram based on the acquired status information.

[0016] The telegram output by the main station can contain a status datagram and a data datagram, with the address field of the status datagram and the address field of the data datagram designating the same sub-stations. For each addressed sub-station, a data area for status information is provided in the payload field of the status datagram, and a data area for the data to be exchanged is provided in the payload field of the data datagram. The command field of the status datagram specifies a write operation.Based on the captured status information in the status datagram processed by the addressed sub-devices, the main device can then determine the expected value for the counter field of the data datagram and compare it with the value of the counter field in the data datagram processed by the addressed sub-devices. In the event of a discrepancy, this can be used to identify a processing error in the data datagram processed by the addressed sub-devices. This procedure ensures that the main device receives the status datagram consistently with the data datagram, since both datagrams are contained in the same telegram. At the same time, however, it is possible to freely select the arrangement of the datagrams in the telegram and also the arrangement of the data areas in the individual datagrams, adapted to the requirements of the fieldbus system.

[0017] The main station can also check whether the value in the counter field in the status datagram corresponds to the expected value that results when all addressed sub-stations have successfully completed the write operation for entering the status information into the payload field of the status datagram. This additional check allows the main station to more easily locate the cause of processing errors in the fieldbus system.

[0018] The datagram may be a status / data datagram which alternatively comprises, for each addressed sub-subscriber in the payload field, a section in the data area allocated to the addressed sub-subscriber for the status information which the main subscriber initialises with the status information indicating that the function connection is not active, wherein the data transmission operations to be carried out by the sub-subscribers in the command field of the status / data datagram include a write operation.Based on the captured status information in the status / data datagram processed by the addressed sub-devices, the main device can determine the expected value for the counter field of the datagram and compare it with the value of the counter field in the status / data datagram processed by the addressed sub-devices. In the event of a discrepancy, the main device can identify a processing error in the status / data datagram processed by the addressed sub-devices. This approach allows the status information to be captured without requiring a modified telegram structure.

[0019] The status information indicating whether a function connection is active or inactive can be a 1-bit data, which keeps the additional data volume to a minimum.

[0020] The telegrams can be designed as Ethernet telegrams, whereby the EtherCAT protocol is used as the Ethernet protocol type for interpreting the datagrams.

[0021] In the fieldbus system, the sub-interface and the functional interface can be implemented as separable units in the sub-subscriber. The fieldbus system can be configured with a base module and a functional module, wherein the base module comprises the sub-interface connected to a base connection element, wherein the functional module comprises the functional interface connected to a module connection element, and wherein the base connection element and the module connection element form a plug-in connection.

[0022] The fieldbus system can be designed modularly so that the sub-device's sub-interface and a function interface, which supplies the sub-interface with the data to be exchanged with the payload area of ​​the telegram, are implemented as separate units. The status information in the status datagram, on the basis of which the expected value for the counter field of the data datagram is calculated, prevents the main device from detecting a processing error when comparing the counter field values, even if, in addition to the sub-devices in the fieldbus system that correctly processed the data in the payload area of ​​the telegram, one or more sub-devices were not involved in the processing due to inactive function modules.

[0023] The base module can have a plurality of sub-interfaces that are connected to each other and to a fieldbus connection via a serial data bus, wherein each sub-interface is connected to a base connection element into which the module connection element of a function module can be plugged.

[0024] The invention is explained in more detail below with reference to the accompanying drawings. Like reference numerals denote like or equivalent components. Fig. 1 shows a schematic diagram of the structure of a fieldbus system. Fig. Figure 2 shows a schematic diagram of the structure of an Ethernet telegram. Fig. Figure 3 shows a schematic representation of the structure of a datagram in an Ethernet telegram. Fig. 4 shows a schematic diagram of a modular control cabinet system with a base module and functional modules. Fig. 5 shows the basic module Fig. 4. Fig.6 shows the functional module from Fig. 4. Fig. Figure 7 shows a schematic cross section through the base module in Fig. 4. Fig. Figure 8 shows schematically the structure of a status datagram and a data datagram in the Ethernet telegram. Fig. 9 shows the structure of a status / data datagram in the Ethernet telegram.

[0025] In industrial automation, communication networks in the form of serial bus systems are used, in which decentralized devices of a machine peripheral communicate with control units. The bus devices are interconnected via a fieldbus. Data exchange between the bus devices is packet-oriented in the form of telegrams based on the main device / sub-device principle, with the main devices determining the data transfer on the fieldbus.

[0026] Fieldbus systems with main participant / sub-participant architecture can be operated with different transmission protocols, whereby protocols based on Ethernet technology are preferably used for telegram transmission.

[0027] The Ethernet telegram is 1518 bytes long by default, with 18 bytes reserved for a header and a tail. The header of the Ethernet telegram contains a data field that specifies the Ethernet protocol type used to interpret the payload data in the Ethernet telegram.

[0028] In industrial automation, protocol types that guarantee real-time capability are also preferred. One such real-time standard for Ethernet technology is the EtherCAT protocol, in which the processing of the payload data in the Ethernet telegram is carried out by the sub-devices in a continuous process.

[0029] In the EtherCAT protocol, the payload block in the Ethernet telegram is divided into a header, also referred to as the EtherCAT header, and one or more datagrams. The EtherCAT header contains characteristic data fields that, among other things, specify the length of the datagrams.

[0030] The datagrams, in turn, consist of a header section, a tail section, and a payload section in between. The header section of the datagram, also known as the datagram header, contains an address field and a command field. The address field specifies the sub-devices that are to exchange data with the payload section as the datagram passes through. The command field then specifies the data transfer operations to be performed with the addressed sub-devices. The data transfer operation can be a read operation, a write operation, or a combined read / write operation.

[0031] The invention is explained below using the example of an Ethernet-based fieldbus system in which the EtherCAT protocol is used for data transmission. However, the invention is neither limited to the Ethernet-based fieldbus system nor to the EtherCAT protocol. The invention can generally be used in all fieldbus systems in which the sub-devices are to process telegram data in a continuous process. For example, the Ethernet-based Sercos 3 protocol can be used as an alternative.

[0032] Fig. Figure 1 shows a schematic diagram of a possible fieldbus system design. The fieldbus system has a transmission path 1, for example, an electrical cable or a fiber optic cable. The bus devices are connected to the transmission path 1. In Fig.1 shows an embodiment with a main subscriber 2 and four sub-subscribers 3, a first sub-subscriber 301, a second sub-subscriber 302, a third sub-subscriber 303 and a fourth sub-subscriber 304.

[0033] EtherCAT technology allows for the networking of a main device with up to 65,534 subdevices. Multiple main devices can be connected to the transmission path simultaneously. The main devices and subdevices can be integrated directly into the transmission path or connected to the transmission path via a separate interface module. To illustrate the expandability of the Fig. In the fieldbus system shown in Figure 1, circles are drawn as placeholders between the second sub-subscriber 302 and the third sub-subscriber 303.

[0034] The execution of data transmission on transmission path 1 is determined by the communication protocol, in this example by the EtherCAT protocol. The EtherCAT protocol is implemented in the main device 2 in a main interface 23. The communication protocol components required for the subdevices 3 are stored in a subinterface 33.

[0035] The EtherCAT network logically represents an open ring bus, in which the main device 2 outputs Ethernet telegrams on transmission path 1 at one end and receives them back processed by the sub-devices 3 at the other end.

[0036] How Fig. 1 shows, the telegram transmission takes place in such a way that the main connection 23 of the main participant 2 outputs the Ethernet telegram via a main transmitter 22 to the first sub-participant 301 on transmission path 1, as seen from the main transmitter 22 in the main participant 2.

[0037] The first sub-subscriber 301 receives the Ethernet telegram via a first sub-receiver 311, processes the Ethernet telegram as it passes through a first sub-interface 331 and forwards the processed Ethernet telegram, delayed by a few bits, via a first sub-transmitter 321 to the second sub-subscriber 302 on transmission path 1.

[0038] The second sub-subscriber 302 receives the Ethernet telegram via a second sub-receiver 312, processes the Ethernet telegram as it passes through a second sub-interface 332 and forwards the processed Ethernet telegram, delayed by a few bits, via a second sub-transmitter 322 to the third sub-subscriber 303 on transmission path 1.

[0039] The third sub-subscriber 303 receives the Ethernet telegram via a third sub-receiver 313, processes the Ethernet telegram as it passes through a third sub-interface 333 and forwards the processed Ethernet telegram, delayed by a few bits, via a third sub-transmitter 323 to the fourth sub-subscriber 304 on transmission path 1.

[0040] The fourth sub-subscriber 304 receives the Ethernet telegram via a fourth sub-receiver 314, processes the Ethernet telegram as it passes through a fourth sub-interface 334 and forwards the processed Ethernet telegram, delayed by a few bits, via a fourth sub-transmitter 324 to a main receiver 21 of the main subscriber 2.

[0041] In a network operated with the EtherCAT protocol, the transmission path can, unlike in Fig.1, the network can also be designed directionally, with the transmission path from the main node forming a single physical branch, and the Ethernet telegrams being passed through twice by all sub-devices, namely on the outward and return paths. Telegram processing by the sub-connections in the sub-devices preferably takes place on the outward path. The return path serves to amplify the signal and to locate and close interruptions in the transmission path. The branch structure can also be expanded into a flexible tree structure by branching off at any sub-device.

[0042] The telegram is generated in the main interface 23 of the main device 2. With the EtherCAT protocol, the main interface 23 in the main device 2 generates an Ethernet telegram 100, as shown in Fig.2. The Ethernet telegram consists of a header data field 110, also referred to as the Ethernet header, a payload data field 120, and a check character field 130 at the end.

[0043] The destination and source addresses are specified in the Ethernet header 110. Furthermore, the Ethernet header 110 specifies the protocol used to interpret the data in the payload field 120. In the illustrated embodiment, the EtherCAT protocol is displayed in the Ethernet header 110. The check character field 130 at the end of the Ethernet telegram specifies a so-called FCS (Frame Check Sequence) to detect errors during data transmission.

[0044] The payload field 120 in the Ethernet telegram 100 then contains the actual EtherCAT data packet, which can be up to 1500 bytes long in the standard Ethernet telegram frame. The EtherCAT data packet consists of a header, also known as the EtherCAT header, and one or more datagrams. If the entire Ethernet telegram is smaller than 64 bytes, so-called padding bytes are inserted after the datagrams at the end of the EtherCAT data packet. The EtherCAT header contains a length specification, a reserved bit, and information about the protocol type.

[0045] Fig. Figure 3 shows an example of the datagram structure. The datagram 200 consists of a control data field 201, a payload field 202, and an end field 203. The control data field 201 includes a command field (Cmd), an identification field (Idx), an address field (Address), a length field (Length), and an interrupt field (IRQ).

[0046] The command field Cmd specifies, among other things, how the datagram is to be processed by the sub-devices. With a first value, the command field Cmd can identify the datagram as a read datagram, in which the sub-devices are to read the payload field 202 in the datagram. With a second value, the command field Cmd can alternatively identify the datagram as a write datagram, into whose payload field 202 data is to be written by the sub-devices. A third value in the command field Cmd can identify the datagram as a read / write datagram, in which the sub-devices are to both read data from the payload field 202 and write data into the payload field 202. With a fourth value, the command field Cmd can identify the datagram as an empty datagram, in which the sub-devices are to leave the payload field unchanged.

[0047] The main participant uses the identification field Idx to mark the datagram 200 so that it can be reassigned after reception.

[0048] The Address field specifies which sub-device(s) are selected to execute the data exchange process specified in the Cmd field. Addressing can be performed in various ways, depending on the network requirements.

[0049] It is possible to physically address a single sub-device, a plurality of sub-devices, or all sub-devices within broadcast telegrams. Alternatively, logical addressing can also be performed. Logical addressing involves pre-assigning the physical addresses of the sub-devices to logical addresses. The assignment is stored in FMMU units (Fieldbus Memory Management Units), which are part of the sub-devices' sub-connections.

[0050] Upon receiving a datagram with logical addressing, the sub-interface in the sub-device checks whether the address matches the stored logical addresses and then determines the corresponding assigned physical address in the sub-device. Logical addressing makes it possible to map any memory area in the sub-device, even bit by bit, to any logical address, thus allowing multiple sub-devices to be addressed simultaneously, for example, with a single datagram. Logical addressing is particularly suitable for transmitting process data between the main device and the sub-devices. Physical addressing is preferably used for transmitting parameter data.

[0051] The length field Length in the control data field 201 of the datagram 200 indicates the length of the payload data field 202.

[0052] The interrupt field IRQ defines an interrupt to be indicated by the sub-subscriber to the main-subscriber.

[0053] The payload field 202 of the datagram 200 contains the data to be exchanged between the main participant and the sub-participants.

[0054] The end field 203 is a counter field, also referred to as a working counter, with a size of 16 bits, for example. Each addressed sub-device that has processed the datagram 200 according to the specification in the Cmd field increments the value in the working counter 203. The working counter 203 is set to a predefined value, usually 0, by the main interface 23 of the main device 2 during telegram generation. The value in the working counter 203 is then changed in a predefined manner by the addressed sub-device when the addressed sub-device has successfully performed a read operation, a write operation, or a read / write operation. The following Table 1 shows a possible procedure for the sub-devices when incrementing the counter field 203: Table 1 command Execution Working Counter Read operation No success No change Successful reading +1 Write operation No success No change Successful writing +1 Read / write operation No success No change Successful reading +1 Successful writing +2 Successful reading and writing +3

[0055] Each datagram can thus be assigned a working counter value that is expected after the telegram has passed through all sub-devices. The main device can then check whether a datagram has been successfully processed by comparing the expected working counter value with the actual working counter value received after passing through all sub-devices.

[0056] As in Fig.As further illustrated in Figure 1, the main interface 23 in the main station 2 is connected to a processor 24 in the main station 2. The processor 24 of the main station 2 executes the control tasks, whereby the processor 24 uses input process images for individual control tasks to determine output process images. Typically, at least one datagram in the Ethernet telegram is assigned to the input or output process image of the individual control task.

[0057] The processing of the datagram 200 in the sub-subscribers 3 takes place, as shown by Fig.1, as explained, during the passage through the respective sub-interface 33. The Ethernet telegram 100 is transmitted from one sub-subscriber 3 to the next sub-subscriber 3 with a delay of a few bits. The sub-interface in sub-subscriber 3 evaluates the control data field 201 of the datagram 200 to determine, based on the command field Cmd, which data transmission process should be executed with the payload data field 202 of the datagram 200. Based on the address field Address, the sub-interface 33 in sub-subscriber 3 then determines whether a data area in sub-subscriber 3 is addressed with which sub-subscriber 3 should exchange data when passing through the payload data field 202.

[0058] The sub-connection 33 of the sub-subscriber 3 is further connected to a function connection 34 in order to process the user data intended for the sub-subscriber 3. In the Fig.1, the first sub-subscriber 301 has a first function connection 341, the second sub-subscriber 302 has a second function connection 342, the third sub-subscriber 303 has a third function connection 343 and the fourth sub-subscriber 304 has a fourth function connection 344.

[0059] During a read operation, the sub-interface 33 of the sub-subscriber 3 reads the payload data assigned to the sub-subscriber 3 from the payload field 202 in the datagram 200 of the Ethernet telegram 100 and forwards the payload data to the assigned function interface 34, which then stores the payload data in the addressed memory area in the sub-subscriber 3.

[0060] During a write operation, the function interface 34 in the sub-subscriber 3 makes the user data from the addressed memory area available to the sub-interface 33 in the sub-subscriber 3 so that the sub-interface 33 can then write the user data into the assigned area in the user data field 202 of the datagram 200.

[0061] When fieldbus systems are used in industrial automation, the sub-interface and the function interface are often implemented as separate units in the sub-devices. A possible example is a modular control cabinet system with a base module containing the basic sub-interfaces and pluggable function modules containing the function interface.

[0062] The function modules can, in principle, provide any desired functionality. The function modules in a control cabinet system can be, for example, input modules, output modules, control modules, line filter modules, contactor modules, frequency converter modules, power supply modules, etc., or a combination of the aforementioned modules.

[0063] Fig. 4 schematically shows a possible structure of a modular control cabinet system 400 in a perspective view with a base module 410 and a plurality of function modules 420, here eight function modules.

[0064] The base module 410 is in Fig.5. Eight openings, one for each functional module, are provided in the top surface of a rectangular housing 411. A base connection element 413 with contacts 414 is arranged in the area of ​​each opening 412. The contacts 414 can be configured as contact pins or contact openings to serve either as plugs or sockets.

[0065] Fig. Figure 6 schematically shows a functional module 420 in a perspective view. The functional module 420 has a module housing 421 with an opening 422 in its underside. A module connection element 423 with contacts 424 is arranged in the region of the opening 422 of the functional module 420. The contacts 424 of the module connection element 423 can in turn be designed either as contact pins or as contact openings to engage with the corresponding contacts of a base connection element in the base module.

[0066] The base connection elements and the module connection elements typically include data connections, extra-low voltage connections, and low-voltage connections. Instead of a single row of openings with base connection elements, the base module can also have several adjacent rows of openings with base connection elements. Instead of a single opening with a module connection element, the function modules can also include several openings with module connection elements. Furthermore, the function modules can then cover several openings in the base module with base connection elements.

[0067] As the schematic cross-section through the base module 410 in Fig.7 shows, each base connection element 413 is assigned a base sub-interface 415, wherein the base sub-interface 415 is connected to one of the base connection elements 413 via a data line 416 in order to exchange data with the function module 420 plugged into the corresponding base connection element 413.

[0068] The basic sub-interfaces 415 are connected to each other via a serial data bus 417 and additionally to a fieldbus connection 418. Telegrams can be fed into the data bus 417 via the fieldbus connection 418.

[0069] The fieldbus connection can also be formed by a basic connection element. If the fieldbus connection is designed as a basic connection element, an associated basic sub-connection can be omitted, since no processing of the input data is required.

[0070] Furthermore, a further fieldbus connection (not shown) can be provided in the base module 410 in order to transmit the telegrams that are fed into the base module 410 via the one fieldbus connection 418 to a further downstream base module via the further fieldbus connection.

[0071] The additional fieldbus connection can in turn be designed as a base connection element, whereby an associated base sub-connection can then be omitted, since no processing of the input data is required. The additional fieldbus connection can also share a base connection element with fieldbus connection 418.

[0072] The modular control cabinet system 400 offers the advantage that in the event of a defect or replacement of a function module, the additional function modules plugged onto the base module can be addressed. This way, when using the control cabinet system 400 in a production facility, for example, a production downtime can be prevented when replacing a function module.

[0073] As explained, the main node can determine whether the datagram has been successfully processed by the sub-devices based on the value of the working counter in the Ethernet telegram that has passed through the sub-devices in the fieldbus system. If one or more sub-devices have not processed the datagram or have only partially processed it, the main node can detect such a processing error by comparing the expected value for the working counter with the actual value of the processed working counter.

[0074] If the main node detects such a processing error, it can discard the data in the datagram. This is necessary, for example, if an error occurs in a sub-device of the fieldbus system, which then leads to the input or output process images for the control task to be performed by the main node being corrupted.

[0075] However, if, as in the control cabinet system, the sub-interface and the function interface are implemented in separate units in the sub-subscriber in order to be able to insert or remove the function module containing the function interface into the fieldbus system in the form of a pull-and-plug unit during operation, the main subscriber will detect a processing error even if the sub-subscribers in the fieldbus system have actually processed the data in the datagram correctly, but one or more sub-subscribers were not involved in processing the datagram due to inactive or not plugged-in function modules.

[0076] In fieldbus systems such as the control cabinet system, the control tasks performed by the main device do not depend on all subdevices in the fieldbus system being active and processing data. In such fieldbus systems, it is possible to activate or deactivate function modules during operation, for example, by plugging the function module into the base module or removing the function module from the base module in the Fig. 4 shown control cabinet system.

[0077] When the Ethernet telegram is generated in the main connection of the main participant, the datagrams in the EtherCAT data packet are preconfigured in such a way that for each sub-participant on the fieldbus system it is determined with which data area of ​​the user data field in the datagram of the sub-participants data is to be exchanged during the pass through or which data transmission process is to be carried out.

[0078] As part of this preconfiguration, the main node also determines the value assigned to each datagram for the working counter, which is expected when the datagram has been successfully processed by all addressed sub-nodes. However, the preconfiguration by the main node does not take into account whether the sub-nodes' functional module is active or not, i.e., whether Fig. 4 shown control cabinet system the function module of the corresponding sub-participants is plugged into the base module or not.

[0079] If the addressed sub-device then fails to process the Ethernet telegram with its sub-device according to the data transmission procedure specified in the datagram's command field due to the inactive function connection, which does not deliver any data, the sub-device will not increment the working counter in the datagram. When comparing the expected value for the working counter with the actual value of the working counter received after passing through all sub-devices, the main device will therefore detect a discrepancy and would normally discard the data in the datagram.

[0080] However, discarding the datagram data during operation by the main station due to such a permissible processing error can be critical for the fieldbus system with a sub-station that is essentially operating correctly. Discarding the datagram data leads to the interruption of communication on a fieldbus, meaning the active function modules cannot be addressed by the controller. If the function modules are used in a production plant, for example, this could result in an undesirable production downtime.

[0081] If the fieldbus system is designed as a modular control cabinet system, as in Fig.4, discarding the datagram data would also prevent functional modules from being replaced during operation. In the worst case, the production plant operated with the modular control cabinet system would have to be shut down in order to restart communication on the fieldbus after replacing a functional module.

[0082] In order for the main station to be able to identify which data in the datagram is valid and which data is invalid with as little overhead as possible in the Ethernet telegram, it is intended that the sub-station uses status information to record whether a function connection is active in a sub-station, that is, whether, for example, in the Fig. 4, the function module is plugged into a sub-interface in the base module.

[0083] The status information of the sub-devices, which indicates whether the respective function connection is active or inactive, can be captured by the main device with the Ethernet telegram. Based on the captured status information, the main device can then recalculate the expected value for the datagram's working counter in the Ethernet telegram.

[0084] The status information indicating whether a function connection is active or inactive can be a 1-bit data item. To acquire the status information, a function connection query unit can be provided in the sub-connection, which checks the operating status of the function connection. This can be done, for example, in the Fig.4, the function interface interrogation unit in the base sub-interface 415 checks via the data line 416 whether data exchange is possible with a function module 420 plugged into the associated base connection element 413. Instead of an active check by the sub-interface, the function interface in the function module 420 can also be designed to output corresponding status information to the sub-interface in the active state. The status information is then entered in a corresponding status register in the sub-interface.

[0085] The status information can be captured using an additional datagram in the telegram sent by the main node. The telegram then contains a status datagram and a data datagram. Fig.Figure 8 shows an example of the structure of the status datagram 210 for reading status information and the structure of the data datagram 220 for transmitting data. The structure of the status datagram 210 and the data datagram 220 corresponds to that shown in Fig. 3 shown datagram structure with a control data field, a payload field and an end field.

[0086] The control data field 211 of the status datagram 210 and the control data field 221 of the data datagram 220 each include the command field Cmd, the identification field Idx, the address field Address, the length field Length, and the interrupt field IRQ. The main interface of the main node configures the control data field 211 of the status datagram 210 and the control data field 221 of the data datagram 220 so that the same sub-devices are addressed in the address field Address. The command field Cmd of the control data field 211 of the status datagram 210 is set to a write operation by the main interface of the main participant, whereas the command field Cmd of the control data field 221 of the data datagram 220 can be any data transmission operation, i.e. a read operation, a write operation or a read / write operation.

[0087] For each sub-subscriber, there is then a data area for a status bit in the payload field 212 of the status datagram 210, which Fig. 8 with S1, S2, S3 etc., and in the payload field 222 of the data datagram 220 a data area for the data to be exchanged, which is shown in Fig. 8 are displayed with D1, D2, D3, etc. The order of the data areas assigned to the individual sub-subscribers in the payload field of the status datagram can differ from the order of the data areas assigned to the individual sub-subscribers in the payload field of the data datagram.

[0088] The end field 213 in the status datagram 210 and the end field 223 in the data datagram 220 are each a working counter that is incremented by each sub-subscriber that has processed the assigned data area in the payload field 212 of the status datagram 210 or in the payload field 222 of the data datagram 220.

[0089] In the status datagram 210, each addressed sub-subscriber performs a write operation with the sub-interface in accordance with the data exchange process specified in the command field Cmd of the control data field 211 of the status datagram 210, so that the counter value in the working counter 213 of the status datagram 210 is increased by the value 1 according to Table 1 if the status bit has been successfully entered by the sub-interface into the assigned data area in the payload field 212 of the status datagram 210.

[0090] In the data datagram 220, each addressed sub-subscriber with the sub-interface increments the working counter 223 of the data datagram 220 upon successful execution of a data exchange process with the payload field 222 of the data datagram 220. Upon successful execution of a read operation or a write operation, the sub-interface of the sub-subscriber increases the working counter 223 by the value 1 according to Table 1. During a read / write operation, the sub-interface of the sub-subscriber increases the working counter 223 by the value 1 for the successful read operation and by the value 2 for the successful write operation according to Table 1, so that the working counter 223 is incremented by the value 3 for the fully executed read / write operation.

[0091] The status datagram 210 and the data datagram 220 can be arranged anywhere in the EtherCAT data packet. Furthermore, additional datagrams can also be inserted into the EtherCAT data packet.

[0092] After passing through the sub-devices, the main device receives the status datagram 210 consistently with the data datagram, since both datagrams are in the same Ethernet telegram.

[0093] The main node can then first check whether the value in working counter 213 in status datagram 210 corresponds to the expected value. The expected value of working counter 213 in status datagram 210 is the value that results when all addressed sub-devices have successfully executed the write operation to enter the status bit into payload field 212 of status datagram 210. With this check, the main node can determine whether the sub-interfaces of the sub-devices are operating correctly. If an error is detected, the main node can react to such anomalous behavior in the fieldbus system according to a specification. For example, a diagnostic process can be triggered for precise error detection in the sub-interface of the sub-device.

[0094] The main station can further evaluate the status bits in the payload field 212 of the status datagram 210 to calculate the expected value for the working counter 223 of the data datagram 220. The main station performs this evaluation by reducing the number of addressed sub-stations by the sub-stations whose status bit indicates that the function connection is not active. Based on the corrected number of sub-stations, the main station then calculates the expected value for the data datagram 220 using the data transmission process provided in the Cmd field of the data datagram 220.

[0095] The main participant then compares the actual value in the working counter 223 of the data datagram 220 with this expected value to determine whether the payload field 222 of the data datagram 220 was successfully processed. If a processing error is detected, the main participant can then discard the data in the data datagram 220. The main participant can also perform a more detailed error diagnosis.

[0096] In the Fig.In the modular control cabinet system 400 shown in Figures 3 to 6, the eight basic sub-interfaces 415 shown can be addressed in the control data field 211 of the status datagram 210 and in the control data field 221 of the data datagram 220. The payload field 212 of the status datagram 210 would then have eight data areas for status bits, and the payload field 222 of the data datagram 220 would have eight data areas for data to be exchanged. If the data datagram 220 is identified as a read / write datagram in the command field Cmd of the control data field 221, the expected value according to Table 1 for the modular control cabinet system 400 would be 24.

[0097] Assuming that a function module is not plugged into the modular control cabinet system 400, the status bit of the associated base sub-interface 415 would then have the value 0 instead of 1 as with the plugged-in function modules. Based on a successfully processed status datagram 210, the status information would then indicate that the expected value for the data datagram 220 is not 24, but 21. The main interface would then check the actual value in the working counter 223 of the processed data datagram 220 based on this corrected expected value to determine a processing error.

[0098] Instead of using an additional status datagram in the telegram sent by the main station, the status information can also be captured using a single datagram that is also used for data transmission. The datagram, referred to as the status / data datagram, then contains an additional section for the status information in the payload field for each addressed sub-station in the data area assigned to the addressed sub-station.

[0099] Fig. Figure 9 shows an example of the structure of the status / data datagram 230 for reading status information and transmitting data. The structure of the status / data datagram 230 corresponds to that shown in Fig. 3 shown datagram structure with a control data field, a payload field and an end field.

[0100] The control data field 231 of the status / data datagram 230 includes the command field Cmd, the identification field Idx, the address field Address, the length field Length, and the interrupt field IRQ. In the command field Cmd, the main interface of the main node specifies a write operation or a read / write operation as the data transfer process.

[0101] For each sub-subscriber addressed in the address field Address of the control data field 231, there is then a section in the payload field 232 of the status / data datagram 230 in the data area assigned to the addressed sub-subscriber for a status bit. The section for the status bit can be located anywhere in the data area and is Fig.9 are shown hatched. The main device initializes the section for the status bit in the data area assigned to the addressed sub-devices in such a way that it is indicated that the function connection is not active.

[0102] The end field 233 in the status / data datagram 230 includes the working counter, which is incremented by each sub-subscriber that has processed the assigned data area in the payload field 232.

[0103] During the telegram run, the sub-interface in the addressed sub-subscriber performs at least one write operation according to the data exchange process specified in the Cmd command field of the control data field 232 of the status / data datagram 230 if the functional interface is active. The sub-interface in the addressed sub-subscriber then overwrites the section for the status bit in the data area assigned to the addressed sub-subscriber with the status bit indicating that the functional interface is active. Furthermore, the sub-interface in the addressed sub-subscriber increments the working counter 233 of the status / data datagram 230 upon successful execution of the data exchange process with the assigned data area in the payload data field 232 according to Table 1.

[0104] After receiving the processed status / data datagram 230, the main participant can then evaluate the status bits in the payload field 232 of the status / data datagram 230 to calculate the expected value for the working counter 233 of the status / data datagram 230. The main participant performs this evaluation in such a way that the number of addressed sub-participants is reduced by the sub-participants whose status bit indicates that the function connection is not active, i.e., for which the overwriting of the section for the status bit has not taken place and, according to the initialization by the main participant, the section for the status bit continues to indicate that the function connection is not active. Based on the corrected number of sub-subscribers, the main subscriber then calculates the expected value for the status / data datagram 230 based on the data transmission process provided in the command field Cmd of the status / data datagram 230.

[0105] The main participant then compares the actual value in the working counter 233 of the status / data datagram 230 with this expected value to determine whether the payload field 232 of the status / data datagram 230 was successfully processed. If a processing error is detected, the main participant can then discard the data in the status / data datagram 230. Additionally, the main participant can perform error diagnostics.

[0106] If the Fig. 3 to 6, the eight basic sub-interfaces 415 shown are addressed, in the payload field 232 of the status / data datagram 230, in the section for the status bit in each of the eight data areas, the status bit is entered which indicates that the functional interface is not active, for example the value 0.

[0107] Assuming that a function module is not plugged into the modular control cabinet system 400, the assigned basic sub-interface, in contrast to the other basic sub-interfaces, would then not overwrite the section for the status bit with the status bit that indicates that the function interface is active, i.e. with the value 1. The status information in the processed status / data datagram 230 would indicate that the expected value for the status / data datagram 230, based on Table 1 for the working counter change, would then be 21. The main interface would then check the actual value in the working counter 233 of the processed status / data datagram 230 based on this corrected expected value in order to determine a processing error. List of reference symbols 1 transmission path 2 main participants 3 sub-participants 21 Main Receiver 22 main stations 23 Main connection 24 processor 33 Sub-connection 34 Function connection 100 telegrams / Ethernet telegrams 110 Ethernet header / header data field (Ethernet telegram) 120 payload field (Ethernet telegram) 130 Check character field (Ethernet telegram) 200 datagrams 201 Control data field 202 Payload field (datagram) 203 End field / Counter field / Working Counter 210 Status datagram 211 Control data field (status datagram) 212 Payload field (status datagram) 213 Working Counter (status datagram) 220 data datagram 221 Control data field (data datagram) 222 Payload field (data datagram) 223 Working Counter (data datagram) 301 first sub-participant 302 second sub-participant 303 third sub-participant 304 fourth sub-participant 311 first sub-recipient 312 second sub-receiver 313 third sub-recipient 314 fourth sub-receiver 321 first sub-station 322 second sub-transmitter 323 third sub-channel 324 fourth sub-channel 331 first sub-connection 332 second sub-connection 333 third sub-connection 334 fourth sub-connection 341 first function connection 342 second function connection 343 third function connection 344 fourth function connection 400 control cabinet system 410 basic module 411 housing 412 Opening 413 Basic connection element 414 Contact 415 Basic sub-connection 416 data line 417 (serial) data bus 418 fieldbus connection 420 Function module 421 module housing 422 Opening 423 Module connection element 424 Contact

Claims

[1] Method for data transmission in a fieldbus system, with a transmission path (1) via which at least one main participant (2) and a plurality of sub-participants (3) which are connected to one another, wherein the sub-subscribers (3) each have a sub-connection (33) and a function connection (34) connected to the sub-connection (33), where status information is recorded in each sub-subscriber, indicating whether the function connection is active or not active, wherein the main participant (2) outputs telegrams (100) on the transmission path (1), wherein the sub-connections (33) of the sub-subscribers (3) process the telegrams (100) in a continuous process, wherein a telegram (100) output by the main subscriber (2) comprises at least one datagram (200) comprising a control data field (201), a user data field (202) and a counter field (203), wherein the control data field (201) comprises an address field and a command field, wherein the address field designates the sub-subscribers (3) that are to exchange data with the payload field (202), wherein the command field specifies the data transmission operations to be carried out by the sub-subscribers (3) with the payload data field (202), wherein, if the command field of the datagram (200) specifies a write operation as the data transmission process to be carried out by the sub-subscribers (3), data to be written into the payload field (202) of the datagram (200) are made available to the sub-interface (33) of the sub-subscriber (3) by the function interface (34) when the function interface (34) is active, wherein the counter field (203) is modified by the sub-connection (33) of the sub-subscriber (3), which has processed the user data field (202), in a manner predefined for the respective data transmission process being carried out, wherein the status information of the sub-subscribers (3) addressed in the datagram (200) is recorded with the telegram, wherein the datagram (200) is assigned an expected value for the counter field (203), which results when the user data field (202) has been processed by the addressed sub-subscribers (3) in accordance with the data transmission processes specified in the command field, wherein the main subscriber (2) determines the expected value for the counter field (203) of the datagram (200) on the basis of the status information acquired with the telegram and compares it with the value of the counter field (203) in the datagram (200) processed by the addressed sub-subscribers (3) in order to determine a processing error in the datagram (200) processed by the addressed sub-subscribers (3) in the event of a deviation. [2] Method according to claim 1, wherein the telegram (100) output by the main subscriber (2) comprises a status datagram (210) and a data datagram (220), wherein the address field of the status datagram (210) and the address field of the data datagram (220) designate the same sub-subscribers (3), wherein for each addressed sub-subscriber (3) a data area for status information is provided in the payload field (212) of the status datagram (210) and a data area for the data to be exchanged is provided in the payload field (222) of the data datagram (220), wherein the command field of the status datagram (210) specifies a write operation, wherein the main subscriber (2) determines the expected value for the counter field (223) of the data datagram (220) on the basis of the detected status information in the status datagram (210) processed by the addressed sub-subscribers (3) and compares it with the value of the counter field (223) in the data datagram (220) processed by the addressed sub-subscribers (3) in order to determine a processing error in the data datagram (220) processed by the addressed sub-subscribers (3) in the event of a deviation. [3] Method according to claim 2, wherein the main subscriber further checks whether in the status datagram (210) the value in the counter field (213) corresponds to the expected value which results when all addressed sub-subscribers have successfully carried out the write operation for entering the status information into the payload field (212) of the status datagram (210). [4] Method according to claim 1, wherein the datagram is a status / data datagram (230) which, for each addressed sub-subscriber (3), has in the payload field (232) a section in the data area assigned to the addressed sub-subscriber (3) for the status information, which the main subscriber (2) initializes with the status information indicating that the function connection is not active, wherein the data transfer operations to be performed by the sub-subscribers in the command field of the status / data datagram (230) include a write operation, wherein the main subscriber (2) determines the expected value for the counter field (233) of the status / data datagram (230) on the basis of the detected status information in the status / data datagram (230) processed by the addressed sub-subscribers (3) and compares it with the value of the counter field (233) in the status / data datagram (230) processed by the addressed sub-subscribers (3) in order to determine a processing error in the status / data datagram (230) processed by the addressed sub-subscribers (3) in the event of a deviation. [5] Method according to one of claims 1 to 4, wherein the status information indicating whether a function connection is active or inactive is a 1-bit data item. [6] Method according to one of claims 1 to 5, wherein the telegrams are Ethernet telegrams and wherein the EtherCAT protocol is used as the Ethernet protocol type for interpreting the datagrams. [7] Fieldbus system with a transmission path (1) via which at least one main participant (2) and a plurality of sub-participants (3) are connected to one another, wherein the sub-subscribers (3) each have a sub-connection (33) and a function connection (34) connected to the sub-connection (33), wherein status information is recorded in each sub-subscriber, indicating whether the function connection is active or not active, wherein the main subscriber (2) outputs telegrams (100) on the transmission path (1), wherein the sub-connections (33) of the sub-subscribers (3) process the telegrams (100) in a continuous process, wherein a telegram (100) output by the main subscriber (2) comprises at least one datagram (200) comprising a control data field (201), a user data field (202) and a counter field (203), wherein the control data field (201) comprises an address field and a command field, wherein the address field designates the sub-subscribers (3) that are to exchange data with the payload field (202), wherein the command field specifies the data transmission operations to be carried out by the sub-subscribers (3) with the payload data field (202), wherein, if the command field of the datagram (200) specifies a write operation as the data transmission process to be carried out by the sub-subscribers (3), data to be written into the payload field (202) of the datagram (200) are made available to the sub-interface (33) of the sub-subscriber (3) by the function interface (34) when the function interface (34) is active, wherein the counter field (203) is modified by the sub-interface (33) of the sub-subscriber (3) that has processed the user data field (202) in a manner predefined for the respective data transmission process being carried out, wherein the status information of the sub-subscribers (3) addressed in the datagram (200) is recorded with the telegram, wherein the datagram (200) is assigned an expected value for the counter field (203), which results when the user data field (202) has been processed by the addressed sub-subscribers (3) in accordance with the data transmission processes specified in the command field, wherein the main subscriber (2) determines the expected value for the counter field (203) of the datagram (200) on the basis of the status information acquired with the telegram and compares it with the value of the counter field (203) in the datagram (200) processed by the addressed sub-subscribers (3) in order to determine a processing error in the datagram (200) processed by the addressed sub-subscribers (3) in the event of a deviation. [8] Fieldbus system according to claim 7, wherein the telegram (100) output by the main subscriber (2) comprises a status datagram (210) and a data datagram (220), wherein the address field of the status datagram (210) and the address field of the data datagram (220) designate the same sub-subscribers (3), wherein for each addressed sub-subscriber (3) a data area for status information is provided in the payload field (212) of the status datagram (210) and a data area for the data to be exchanged is provided in the payload field (222) of the data datagram (220), wherein the command field of the status datagram (210) specifies a write operation, wherein the main subscriber (2) determines the expected value for the counter field (223) of the data datagram (220) on the basis of the detected status information in the status datagram (210) processed by the addressed sub-subscribers (3) and compares it with the value of the counter field (223) in the data datagram (220) processed by the addressed sub-subscribers (3) in order to determine a processing error in the data datagram (220) processed by the addressed sub-subscribers (3) in the event of a deviation. [9] Fieldbus system according to claim 8, wherein the main participant further checks whether in the status datagram (210) the value in the counter field (213) corresponds to the expected value which results when all addressed sub-participants have successfully executed the write operation for entering the status information into the payload field (212) of the status datagram (210). [10] Fieldbus system according to claim 7, wherein the datagram is a status / data datagram (230) which, for each addressed sub-subscriber (3), has in the payload field (232) a section in the data area assigned to the addressed sub-subscriber (3) for the status information, which the main subscriber (2) initializes with the status information indicating that the function connection is not active, wherein the data transfer operations to be performed by the sub-subscribers in the command field of the status / data datagram (230) include a write operation, wherein the main subscriber (2) determines the expected value for the counter field (233) of the status / data datagram (230) on the basis of the detected status information in the status / data datagram (230) processed by the addressed sub-subscribers (3) and compares it with the value of the counter field (233) in the status / data datagram (230) processed by the addressed sub-subscribers (3) in order to determine a processing error in the status / data datagram (230) processed by the addressed sub-subscribers (3) in the event of a deviation. [11] Fieldbus system according to one of claims 7 to 10, wherein the telegrams are Ethernet telegrams and wherein the EtherCAT protocol is used as the Ethernet protocol type for interpreting the datagrams. [12] Fieldbus system according to one of claims 7 to 11, wherein the sub-interface (33) and the functional interface (34) are implemented in separable units in the sub-subscriber (3). [13] Fieldbus system according to claim 12, comprising a base module (410) and a function module (420), wherein the base module (410) has the sub-interface (415) which is connected to a base connection element (413), wherein the function module (420) has the function interface (34) which is connected to a module connection element (423), and wherein the base connection element (413) and the module connection element (423) form a plug connection. [14] Fieldbus system according to claim 13, wherein the base module (420) has a plurality of sub-interfaces (415) which are connected to one another and to a fieldbus connection (418) via a serial data bus (417), wherein each sub-interface (415) is connected to a base connection element (413) into which the module connection element (423) of a functional module (420) can be plugged.

Images