Method for transmitting data via a CANopen bus

The invention relates to a method for transmitting data between a first automation appliance, and at least one second automation appliance, via a CANopen bus using a service data object as an SDO service, wherein an SDO client implemented in the first automation appliance is used to send a download or upload request to an SDO server implemented in the at least one second automation appliance, wherein the data are encapsulated in a CANopen frame by an application implemented in the first automation appliance or the at least one second automation appliance wherein the CANopen frame with the encapsulated data is transmitted or sent by means of an SDO service into or out of a data tunnel object defined in an object dictionary of the SDO server, and wherein the encapsulated data are decapsulated by the application implemented in the first or the at least one second automation appliance.

This application is a 371 of PCT/EP2011/054872 filed on Mar. 29, 2011, which claims priority to German patent application number 10 2010 016 283.3, filed Mar. 31, 2010.

FIELD OF THE INVENTION

The present invention relates to a method for transmitting data between a first automation device, such as a user PC or a central control device, and at least one second automation device, such as a field device, via a CANopen bus using a service data object as a SDO service, wherein an SDO client implemented in the first automation device is used to send a download or upload request to a SDO server implemented in the at least one second automation device, wherein the data are encapsulated in a CANopen frame by an application implemented in the first automation device or the at least one second automation device, wherein the CANopen frame with the encapsulated data is transmitted or sent by means of a SDO service into or out of a data tunnel object defined in an object directionary of the SDO server, and wherein the encapsulated data are decapsulated by the application implemented in the first or the at least one second automation device.

BACKGROUND OF THE INVENTION

A method of the aforementioned kind is described in US patent application US-A-2010/0007311. This application relates to a battery module comprising cells, two external connections, a message-communication-infrastructure, a module control unit with a message processing unit that is connected to the infrastructure in order to send and receive messages. A method is described for transmitting data between a control device and modules via a CANopen bus. Data is transmitted by using a service data object as a SDO service. In this configuration the modules and the control device function as the SDO client.

The US patent application US-A-2005/0002417 relates to systems and methods for executing protocol conversions in an environment, comprising a work machine with one or more modules that are coupled to one another via one or more data connections. Such systems and methods can have one or more gateways for executing “tunneling” or “bridging” operations. “Tunneling” processes can include receiving a message from a source module in a first protocol, decapsulating the messages in the transmission units of a second protocol and transmission of the decapsulated message via the second protocol.

CANopen was developed by the CiA (CAN in Automation), a user and manufacturer's association for CANopen, and available as European Standard EN 50325-4 since the end of 2002. CANopen utilizes as transmission technology the layers 1 and 2 of CAN standard (ISO 11898-2) originally developed for use in automobiles.

In CANopen, several basic services (service primitives) are defined. These basic services are:Request: Request of a CANopen service by an applicationIndication: Report to the application that a result or a specific message is presentResponse: Response of the application to an indicationConfirmation: Confirmation to the application that a CANopen service has been executed.

The manner in which CANopen devices exchange data with one another is regulated via a CANopen communication profile. As with all other field bus protocols, a distinction is made between real-time data and parameter data. CANopen assigns suitable communication elements or communication objects to each of these data types, which are completely different in character.

The communication objects can be subdivided as follows:Service data objects (SDO) for parameterizing device object dictionary entriesProcess data objects (PDO) for transporting real-time dataNetwork management objects (NMT) for status control of the CANopen device and for account monitoring,additional objects such as synchronization objects, time stamping and error messages.

All communication objects and all user objects are compiled in an object dictionary (English: Object Dictionary (OD)). The object dictionary in the CANopen device model is the link between the application and the CANopen communication unit. Each entry in the object dictionary stands for an object and is characterized by an index, such as a 16-bit index. An index can in turn contain up to 265 subindicies. In this way it is possible, independent of the “11-bit identifier”, to differentiate up to 65.536×254 elements.

In the communication profiles the allocation of communication and device object profiles for a respective index is precisely defined. Thus, the object dictionary defines a distinct interface between the application and the outward communication. For example, for each CANopen node in the network it is known that the “heart beat interval” is found at index 1017 h, and any node or any configuration program has read or write access to it.

For each communication object there exists a distinct COB-ID (communication object identifier) in the network. The CO-ID consists of 32 bit values, in which each of the first two bits can have an object-specific meaning In an 11-bit CANnetwork the following 19 bits (29to11) have the value 0 and the last bits (10to0) correspond to the CAN identifier.

Service data objects (SDO) provide a service for accessing the object dictionary. Each CANopen device requires at least one SDO server which receives and processes requests from other devices. The default settings utilize messages to the SDO server of a device, the node number of the receiver plus 1536 as COB-ID or as “identifier” for the CAN message. The node number of the transmitter plus 1408 is used as “identifier” for the response by the SDO server. These relatively high, and thus low prioritized, IDs are used to transfer entries into the object dictionary. A protocol for this SDO transfer exists which requires, for example 4 bytes in order to encode the direction of data transfer, the index and the subindex. Hence, only 4 bytes of the 8 bytes of a CAN data field remain for data content. For objects that are larger than 4 bytes there are two additional protocols for fragmented transfer of data.

In contrast to the prioritized SDO transfer overloaded with protocol data, the process data object (PDO) provides a faster option for transferring process data.

The identifiers used for PDO transfer for the default settings are in the COB-ID range of 385 to 1407, and are therefore prioritized higher than the SDO messages. In addition, they only contain user data, hence 8 bytes are available.

The content of the user data is determined via PDO mapping entries. These are objects in the object dictionary which, like an allocation table, determine which data are transmitted via a PDO. This data is in turn the content of other objects of the object dictionary. In a PDO the values of multiple objects may also be transmitted and the receivers of the PDO can in accordance with their PDO mapping entries utilize only parts of the data.

Once a PDO is received the data are in turn written, respectively, in other objects of the object dictionary in accordance with the mapping entries, for example, in a digital output object. PDOs can be transmitted cyclically, event-oriented, per request or synchronized.

The MODBUS protocol is a communication protocol based on a master-slave or client-server architecture. It was developed in 1979 by Gould Modicon for communicating with programmable logic controllers. The MODBUS, since it is an open protocol, has become a de facto standard in the industry.

A master, for example, a PC and multiple slaves (for example, measurement and control systems; field devices) can be connected by means of MODBUS. There are two versions: one for the serial interface (EIA-232 and EIA-485) and one for Ethernet.

In data transmission a distinction is made between three different types of operations:MODBUS ASCIIMODBUS RTUMODBUS TCP.

Each bus device must have a specific address.

CANopen, MODBUS, PROFIBUS and Ethernet-based networks are used in automation technology to establish communication between data processing systems and peripheral devices. For example, programmable logic controllers (PLC), fieldbus couplers, IO/-modules, drive controllers (motion controllers), display devices are coupled to one another over a local network (field bus). Field devices that are linked to a MODBUS include a MODBUS interpreter in order to interpret the MODBUS messages transmitted over MODBUS.

As a general rule, prior art systems and methods enable parameterization of field devices by means of configuration files, in which certain predefined functionalities of the respective device, depending on the need and the range of application of the device, can only be switched on or off, or are activated or deactivated.

Parameterization and/or configuration usually occurs by way of a direct connection between a data processing device such as a PC (personal computer), laptop or PDA (personal digital assistant) and the field device by transmitting a MODBUS message which can be interpreted in the field device. The configuration of each individual field device via a one-to-one connection is costly and time consuming.

When using a field device of this type with a MODBUS interface in a CANopen fieldbus, the problem arises that the CANopen messages cannot be evaluated by the MODBUS interface.

On the other hand, application data and application parameters of a CANopen device are present as objects in the CANopen that are stored in the CANopen object dictionary.

If an application requires more data/parameters than are present in the CANopen object dictionary, it is impossible to access such information via a CANopen network.

Based on the foregoing, the object of the present invention is to further develop a method of the aforementioned kind that simplifies the configuration of field devices to CANopen.

The object is achieved in accordance with the present invention inter alia in that the method is used for configuring and/or parameterizing via the CANopen bus the at least one second automation device that includes a MODBUS server, in that the data are generated as configuration and/or parameterization data in the form of a MODBUS frame and are encapsulated in the CANopen frame, and in that the CANopen frame is loaded by means of a SDO-download into the data tunnel object of the SDO server of the at least one second automation device and is decapsulated.

The method according to the present invention makes it possible to encapsulate messages such as MODBUS messages in a CANopen message. The encapsulation or tunneling of device-specific data, such as configuration and/or parameterization data enables automation devices to be configured via the CANopen bus from a central location such as a user PC or central controller, which only have access to an interface different from CANopen, such as a MODBUS interface for processing the device-specific data, and which according to the prior art would have to have been configured via a one-to-one connection.

The method according to the present invention can thus be utilized to configure and/or parameterize by way of a CANopen bus field devices that include a MODBUS server, wherein configuration and/or parameterization data are encapsulated as a MODBUS frame in a CANopen frame, which is loaded by means of a SDO-download into the data tunnel object of a field object and decapsulated.

A preferred method is distinguished by the fact that a data transmission is carried out from the first automation device to the at least one second automation device by way of a SDO download to a data tunnel object of the object dictionary, initiated by the application implemented in the first automation device.

According to another preferred method, it is provided that data transmission is carried out from the at least one second automation device to the first automation device by way of a SDO download to a data tunnel object of the object dictionary, initiated by the application implemented in the first automation device, wherein the application addresses cyclically the application in the at least one second automation device.

To transmit data, a preset SDO server channel can be preferably used, whereby a second SDO server channel is used if the transmission rates of encapsulated data are high.

The method is further distinguished by the fact that a single data tunnel object is sufficient for simplex or half-duplex data transmission. For full duplex data transmission at least two data tunnel objects are used in the object dictionary of the SDO server.

For parameterizing and/or configuring field devices by way of a CANopen bus, it is provided that the application implemented in the first automation device comprise a field device tool and at least one device type manager which are used to generate parameterization and/or configuration data in the form of a MODBUS frame, that the MODUBUS frame is encapsulated in a CANopen frame and that the CANopen frame is transmitted by means of a SDO download into the data tunnel object of the SDO server of the at least one second automation device.

When transmitting data from the at least one second automation device to the first automation device, it is necessary for a protocol-specific part of the device type manager implemented in the first automation device to regularly query the at least one second automation device with the application, wherein a CANopen communication DTM implemented in the application executes the SDO upload request.

The data tunnel object is preferably domain type.

To transmit data to a plurality of field devices linked to a CANopen bus, the CANopen frame with the encapsulated MODBUS frame is sent via a routing functionality implemented in the first automation device to the at least one second automation device with the appropriate address.

As encapsulated data, it is preferable to send parameter and/or configuration data in addition to control programs.

Data can be transmitted sequentially for each of the two automation devices and/or transmitted when one of the two automation devices is connected to the CANopen bus.

Further details, advantages and features of the invention are set forth in the claims, the features by themselves or in combination taken therefrom, as well as preferred embodiments taken from the following description of the drawings.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1shows purely schematically an automation system which, in the exemplary embodiment shown, comprises logic controllers12,14, connected to one another by way of an Ethernet network16. Also provided is an operator terminal in the form of an HMI controller18which is also connected to the Ethernet network16.

The logic controllers12,14are each connected via a CANopen bus20, fieldbus devices24,26,28,30and32,34,36,40. The fieldbus devices24,26, and32,34can be, for example, drive controllers for activating drives or motion controllers. The fieldbus devices28,30and36,40can be realized as input/output devices.

To configure the controllers12,14,18and/or the fieldbus devices24-40the controller12is connected by way of a single connection52to a configuration PC50. In the exemplary embodiment described, the connection is configured as an USB connection.

In the configuration PC50a software tool54is implemented for configuring and/or parameterizing the controllers14,15,18and/or the field devices24-40. Using the software tool, device description files56can be generated which can be transmitted via the USB connection52, the controllers12,14and the CANopen buses20,24to the fieldbus devices24-40, and there interpreted and executed.

In order to also use fieldbus devices at the CANopen bus20,22which have a MODBUS interface for interpreting a device description file and are normally configured and/or parameterized via a MODBUS interface, the present invention provides that data are transmitted, for example, in the form of device description files encapsulated via the CANopen bus20,22.

FIG. 2shows purely schematically the hardware structure of a fieldbus device as exemplified by fieldbus device24. The latter comprises essentially a data processing unit58, such as a microcontroller connected via a communication interface60, such as a CAN controller, with the CANopen bus20. A plug connector62is provided for connecting the CANopen bus20.

The microcontroller58is connected to a storage element64for storing programs and/or data. In addition, interfaces66,68are provided for peripheral devices.

In addition to the connection62for the CANopen bus20, the field device24shown also has a port70for connection with a MODBUS72by way of which the fieldbus device24can be configured. The MODBUS72is coupled to the microcontroller58via an interface74, such as UART.

Normally, application data and parameters of a CANopen device are present in the CANopen as objects, which are implemented in a CANopen object dictionary76as part of a CANopen stack78, as is shown inFIG. 3.

If, however, an application has more data or parameters than are present in the CANopen object dictionary76, such information cannot be accessed via the CANopen network20,22.

According to the present invention, a method is proposed for encapsulating data which allows transparent access to all data and parameters of the CANopen device24, regardless of whether or not the former are contained in the object dictionary76.

To carry out the method according to the present invention an object “data tunnel object” (DTO)80is defined which is implemented in the object dictionary76of the CANopen stack78of a CANopen slave82. The data and parameter prepared by the objects of the object dictionary76can be saved in the memory64and are available for an application84which is executed, for example in the FIELDBUS device24by the microcontroller58.

The transfer of data by encapsulation is based on the standardized SDO service (upload/download) in the CANopen to the novel data tunnel object (DTO)80according to the present invention which resides in the CANopen slave. Depending on the amount of data to be transmitted, the CANopen stack78includes the data tunnel object (DTO)80as a suitable type of service data object (SDO), either expedited, segmented or—as in the case of a M30master or S30slave—as a block. The data tunnel object (DTO)80is transparent to the user.

An example of a transparent data transmission via CANopen is shown inFIG. 4. In this case, the user PC50assumes the function of a CANopen master in which a SDO client and the operating software54are implemented. The fieldbus device24functions as a CANopen slave in which a SDO server and an application program84are implemented. The SDO server comprises the CANopen stack78and the object dictionary76with the implemented data tunnel object (DTO)80.

In the case of a segment SDO or block SDO, the SDO service is split into multiple SDO request/response frames.

Based on the client/server structure the user PC50always initiates transmission with the SDO client:Data transmission of application54to application84is executed with a SDO upload to DTO80, which is also initiated by application A,Data transmission of application84to application54is executed with a SDO upload from DTO80, also initiated by application54, whereby application54must cyclically address the application84in the usual manner (polling).

Since the transmissions of encapsulated data are standardized SDO transmissions, it is possible to use the preset (default) SDO server channel. Where the transmission of encapsulated data is intense, a second SDO server channel may be expedient, as is shown inFIG. 4c).

For a duplex or half-duplex data transmission a single data tunnel object (DTO)80is sufficient. Two data tunnel objects80,86should be used for a full duplex transmission, as shown inFIG. 4c), that is, an independent transmission of application54to application84and simultaneous transmission of application84to application54.

The “tunnel mechanism” described provides a means for transporting data blocks. The application54and the application84determine the exact use of the “tunnel”, that is, for example, which types of data blocks are transmitted and which protocol is used.

In the case of field device tool (FDT) and/or device type manager (DTM) technology, this technology can be implemented in the application54, through which via FDT and/or DTM a connection to a specific field device24-40is established on which the application84runs. The “tunnel” can be used to transparently transmit any standardized or private protocol that accepts the applications54,84.

The protocol-specific part of the device DTM must initiate transmission, particularly for a transmission of application84to application54. The transmission is then carried out from the CANopen communication DTM in the form of a SDO upload request.

The data tunnel object (DTO)80is of the “domain” type and is represented schematically inFIG. 5. This allows the transmission of data blocks of 1 to N bytes, in which the length of the blocks can vary from one transmission to the next. The length N of the domain object which is prepared in the object dictionary76, limits the maximum number of data bytes per block. The length N is not specified here since it is a function of the respective application.

The first byte of the data block is always a tunnel header byte, as shown inFIG. 5.

FIG. 6shows a table for describing the data tunnel object80. For example, assigned to the data tunnel object80is object index 5FFDh. Also assigned to data tunnel object is the object type “array” which allows various devices per tunnel object to be implemented. Mapping of the objects in a PDO (process data object) does not occur.

The first byte transmitted via the data tunnel object (DTO) is always the tunnel header byte88which is shown inFIG. 7. The tunnel header byte comprises a flow control bit and seven protocol ID bits.

The flow control bit can be used for a simple flow control. If the SDO server is unable to receive additional data blocks, it can display this situation by setting the bit to 1. If the protocol provided on the data bus (tunnel) provides the correct means for flow control, this bit may then be superfluous.Flow control=0 (default): The server is able to receive additional data blocksFlow control=1: The server is unable to receive additional data blocksProtocol-ID: This field marks the type of protocol used on the tunnel. The information is useful for debugging and analysis-application purposesProtocol-ID=00h: MODBUS RTU encapsulation, the data blocks contain MODBUS RTU framesProtocol-ID=01h-3Fh: These IDs are reserved for standardized protocolsProtocol-ID=40h-7Fh: device-specific; these IDs can be used for non-standardized protocols.

The tunnel mechanism according to the present invention allows the transmission of data blocks in both directions (up-/download), as is shown inFIG. 8. A download as well as an upload are both initiated by the CANopen client, in the present instance, from the user PC50. This results from the client server structure of the SDO connection.

In the case of an upload the client must request the data block. A block length of 1 byte is an indication of an empty data block since in this case the block contains only the tunnel header byte88.

If the data block is larger than 4 bytes, the segment transmission or block transmission is used. This occurs automatically by way of the CANopen stack78and the user application84does not need to be involved.

FIG. 9shows purely schematically the encapsulation of a MODBUS message or of MODBUS data. In this case only one data tunnel object (DTO)80is used. The transmitted data blocks comprise MODBUS-RTU frames. The flow control bit of the tunnel header88is not used in this case.

A MODBUS transaction always consists of one of the requests sent from the client50and one of the responses sent from the server24. An exception to this rule is a request broadcast address0, in which the response is omitted. The transaction begins with the transmission of the MODBUS request to the fieldbus device24by way of a SDO download (command: download MB REQUEST PDU PER SDO). Next the MODBUS client requests a MODBUS response (SDO response). If the fieldbus device does not immediately have the MODBUS response ready, the uploaded data block consists of just the tunnel header88and thus has a length of 1. The request (polling) is repeated until the MODBUS response is received.

MODBUS-RTU frames are limited to 254 bytes such that the 255 byte length for the domain object should be sufficient. However, the domains can also be smaller, depending on the supported MODBUS-functions.

The MODBUS client does not have to reside in the CANopen client. In the case of a remote MODBUS client the CANopen client can forward the appropriate frames.

FIG. 9is a schematic representation of a frame. In the case of segment SDO or block SDO, multiple SDO frames not shown here are transmitted.

FIG. 10shows a MODBUS-RTU frame as part of a CANopen frame. The MODBUS-RTU frame is composed of an address (1 byte), function code (1 byte) and data field (N bytes).

Based on this structure, standard MODBUS frames must be used that have at least 7 CANopen data bytes (tunnel header, address, function code), 4 bytes for start address and length (segment or block SDO).

However, MODBUS exception frames may have only 4 CANopen data bytes, namely tunnel header, address, function code and a byte error code. In such case it is also possible to use “expedited” SDO. It depends on the server device whether it responds with an “expedited” or segment SDO to a SDO upload request.

If the target device, in this case the field device24or the controller12, provides an internal routing functionality, the message can then be sent to the assigned address, taking into account the MODBUS address rules. If, for example, the address is set at 00 or if the address does not exist, then there is no response.

If the CANopen fieldbus device or the CANopen controller does not provide such a routing functionality, then the address field has no significance.

By using the aforementioned tunnel mechanism, it is possible to configure or parameterize the fieldbus devices24-40shown inFIG. 1in just one step, that is, with one command from a central location such as user computer50or controller12,14. In this configuration the controller12,14can have an internal routing functionality so that the MODBUS message can be sent to the appropriate address of the fieldbus device, taking into consideration the address rules.

Thus, it is possible to load the entire controller program as well as the hardware configuration of the fieldbus devices24-40via the single connection52between the user PC50and the controller12.

A system for integrating the fieldbus devices in an automation system is therefore provided, which comprises multiple fieldbus devices that are connected via communication links for controlling and monitoring a technical facility.

The fieldbus devices are connected via the at least one fieldbus20and22and can be (but do not have to be) connected to the control unit or controller12,14.

According to the present invention there is a parameterization and/or configuration software which runs on the user PC, namely for configuring and/or parameterizing the individual field devices24-40, which are configured to allow the data of the individual field device to be stored.

Furthermore, a single program software runs on the user PC50for configuring and/or programming the controller12,14.

The programming software that runs on the user PC50for configuring and/or programming the controller12,14is capable of starting the parameterizing software in hiding mode. With the software, it is possible to configure and/or program the respective FIELDBUS devices. Further, a direct communication connection is established between the user PC50and the fieldbus devices24-40via the controller12, in order to store the entire data configuration of the fieldbus devices in the fieldbus devices24-40. This is executed sequentially for each fieldbus device and as well as each time a fieldbus device is attached to the fieldbus (CANopen)20,22.

The controllers12,14do not need a buffer in order to create a copy of the data for configuring the fieldbus devices. Instead, the fieldbus device is capable of accepting a direct communication with the parameterizing software in order to execute a configuration and/or parameterization of each fieldbus device in the same amount of time the controllers12,14need for monitoring, operating and diagnosing each of said fieldbus devices.

For downloading with just “one click” the complete fieldbus device configuration in each fieldbus device connected to the network, it is not necessary to store information on the fieldbus device configuration in the controllers12,14. Instead, all fieldbus device configurations are downloaded in one step, that is, with one click.

An application of the above described data tunnel mechanism to the structure shown inFIG. 1is discussed with reference toFIG. 11. In the user PC50a software (FD DTM Core) is implemented with which the device description file56can be generated in MODBUS format. In addition, a software tool90is provided for encapsulating the MODBUS message in a CANopen message for purposes of generating a CANopen frame92, which can be transmitted, for example via a CANopen bus. In the exemplary embodiment shown, a further encapsulation of the CANopen frame in a carrier frame94occurs in order to transmit the MODBUS frame via a carrier protocol to the controller12. For this purpose, the configuration tool50includes an interface (COMMDTM)96.

The CANopen frames are encapsulated in the controller12and, as part of the routing function, are forwarded to each of the fieldbus devices with the corresponding addresses.

Implemented in the fieldbus device24-40is a CANopen MODBUS retriever, which encapsulates the MODBUS frame, which frame can then be interpreted and executed by a MODBUS interface (FD CORE) of each field device.