Description

The Profibus slave driver is controlling a CIFX 50E-DP PC card designed by Hilscher. This card family is the unified standard supporting all Real-Time Ethernet and Fieldbus systems for PC based automation. In order to use the Profibus slave communication interface, this card must be connected to the target through the PCI express link. The complete protocol stack is executed on the CIFX card and data exchange with the target is done via Dual-Port-Memory or DMA.

Then, the Profibus slave driver is responsible for initializing the CIFX card and loading the appropriate kernel module to achieve typical Profibus slave device operations, according to the user requirements.

A connection file must be used to bind the model signals to the driver variables. This file is a text file named 'connections.opal'.Three other configuration files must be used to configure each Profibus slave communication interface with the number of incoming and outgoing data. All four files are described in the configuration section below.

The configuration of the data within the simulated Profibus slave is completely handled by a Windows application, called SYCON.net that is delivered with the board. The application is used to export a '.nxd' file that will be loaded by the CIFX firmware during the driver initialization sequence to allocate the required space in the Dual-Port-Memory. A '.xml'file is also generated and is used by the driver to make the connections between the different I/Os and the model signals.
For more information on how to inport another slave device's .gsd file or other general uses of SYCON.net, please consult SYCON.net's user manual, provided by Hilscher.

The configuration flow is described in the configuration section below.

As shown in the image above, the CIFX card has a single RS-485 connector. In the current implementation, it has to be connected directly to the master. Daisy-chained topology will be supported in a future release. An RS-485 cable compatible with the Profibus standards must be used to establish the physical communication between the master and the slave. The following cable has been used during the development of the Profibus slave and Profibus master interface:

To create a daisy-chained system, an additional cable must be connected to the output port of the RS-485 cable connector. For more information about the Profibus protocol itself, please refer to the PROFIBUS and PROFINET International (PI) website.

Driver Configuration

A configuration file must be used to instantiate the driver, here is a typical example related to Profibus DPV1 slave (profibus_dpv1_slave_cfg):

OPAL-1.0 Object
ProfibusSlave::Configuration {
    board_id=0
    cifx_path=/Hilscher/ProfibusSlave
    nxd_file=profibus_dpv1_slave.nxd
    xml_file=profibus_dpv1_slave.xml
    acyclicSlots {
        item {
            id=20
            indicesList {
               item {
                    id=0
                    byteLen=210
               }
               item {
                    id=1
                    byteLen=4
               }
           }
        }
        item {
            id=40
            indicesList {
                item {
                    id=1
                    byteLen=4
                }
                item {
                    id=3
                    byteLen=4
                }
                item {
                    id=2
                    byteLen=4
                }
            }
        }
    }
}

The lines in bold style are related to the slave acyclic slots and will have to be properly modified in accordance with your application.Each acyclic slot can have an ID. This allows you, as a user, to configure only the slots that you need. The same situation applies to the indices within a slot.

For OPAL-RT Profibus DPV0 slave example, the configuration file name is profibus_dpv0_slave_cfg.opal and the corresponding files will be:

nxd_file=slave_all_data_types_config.nxd

xml_file=test_xml_slave.xml

The following table explains each driver configuration parameter:

It is typical to find the configuration of the inputs and outputs in the driver configuration files. However, it is not the case for the Profibus slave implementation because the slave is entirely defined by SYCON.net tool provided with the CIFX card. As explained above, the slave pinout has to be exported by SYCON.net to be loaded by the driver.

The tool can be installed from the Hilscher CD provided with the CIFX card. The SYCON.net documentation,also provided with the CD, should be used to configure correctly the slave device. However the following procedure describes how to perform a typical configuration.

• Open SYCON.net and start a new project. It is possible to save the project at any time and re-open it later. The center window is showing the bus where the master and/or slave devices need to be added by drag & drop.

• In the Fiedbus window, browse to the Profibus DPV0/Gateway / Stand-Alone Slave section or Profibus DPV1/Gateway / Stand-Alone Slave section and locate the 'CIFX DP/DPS' item. It corresponds to the CIFX card required by the Profibus slave implementation.

• Drag & drop the 'CIFX DP/DPS' to the netDevice window bus line. In case the SYCON.net tool is used to configure a Profibus master having connected Profibus slaves, the 'CIFX DP/DPS' can also be drag & dropped to the corresponding master bus line. Please refer to the master documentation for a complete example of such a configuration.

• Double click on the added 'CIFX DP/DPS' item. Nothing has to be changed in the 'Settings' section and in the 'Device Description' sections. Click on the 'Configuration/General' section. This panel allows the user to set the 'Slave Address' of the Profibus slave that will be simulated.

• Click on the 'Modules' section. The top window lists all the different modules that are allowed to be added to customize the inputs and outputs of the simulated Profibus slave. The user must add the modules to be configured in the simulated slave by using the Insert/Append buttons. It is important to understand that the mapping of the data in the transmission and the reception buffer will respect the order in which the modules are added. The maximum number of bytes that can be transmitted from the slave to the master is 244 and the maximum number of bytes that can be received by the slave from the master is also 244 bytes. It is also important to notice that the direction in the module names is always from the master point of view. As an example, '1 Byte In' is a byte that will travel from the slave to the master and '1 Byte Out' is a byte that will travel from the master to the slave.

• The screenshot below shows an example of a given number of modules that have been added for the Profibus slave example model. The maximum payload data is used (244 bytes in and out).

• The types of data that are included in each module have to be defined in the 'Signal Configuration' section. The screenshot below shows the signal configuration for two of the configured modules ('16 Bytes In' and '20 Bytes In'). The '16 bytes In' module has been customized so that the first byte is a 'Boolean', the second one is an 'Unsigned8', the next two bytes are representing an 'Unsigned16', the next four bytes are representing an 'Unsigned32' and the next eight bytes are representing an 'Unsigned64'. Remember that these data will travel from the slave to the master. Each module can be customized with the data types required by the user to reproduce the pinout of any real Profibus slave device. It is important to note that a 'Boolean' is actually taking 8 bits in the transmit or receive buffer instead of a single one. This is a limitation from the SYCON.net tool.

• The 'CIFX DP/DPS' item does not allow configuration with any custom parameters in the 'Parameters' section. If required, the 'Groups' section can be used to assign the simulated Profibus slave to a specific group.

• If required, the 'Extensions' section can be used to configure specific Profibus slave parameters.

• In the 'DPV1' panel, you can choose to check 'Enable DPV1' checkbox to enable acyclic communications. However, if you want to only use cyclic data transfer or DPV1 is not supported by your card, you have to uncheck 'Enable DPV1' checkbox.

If 'Enable DPV1' is checked, choose the maximum channel data length you desire between 4 and 244 along with the maximum alarm PDU length between 4 and 64. Therefore, you can check the different types of alarm and choose the number of alarms in total that you require.
Moreover, you can select if you want to acknowledge alarms via SAP 50 or SAP51. When SAP 50 is selected, make sure that the slave supports it because this feature requires it.

• The 'Address Table' panel can be used by the user to validate that the address mapping of the transmission and reception buffer is configured as expected.

• In the 'Device Settings' section, the 'Start of bus communication' must be set to 'Controlled by application' and the 'Configuration data flag' option must be set to 'Fixed configuration'. If required, the other settings can be changed by the user.

• At this point, the Profibus slave configuration is done. The SYCON.net tool must now generate the '.nxd' file to be loaded by the firmware and the '.xml' file to be loaded by the driver. For the '.nxd' file, right click on the 'CIFX DP/DPS' item and select Additional Functions/Export/DBM/nxd. The file must be placed in the model folder and the RT-LAB project will have to be configured to transfer the file to the target before the model loads. This is explained in the 'RT-LAB usage' section.

• The same operation must be used to generate the '.xml' file but with the Additional Functions/Export/DBM/XML command. The file must also be placed in the model folder and transferred to the target before the model loads.

RT-LAB Usage

In RT-LAB, the three files described in the configuration section must be transferred to the target before the model loads. It is important to set the transfer mode to binary for the '.xml' and the '.nxd' files. A fourth file named 'connections.opal' must also be written by the user and transferred to the target in ASCII mode. The following screenshot shows a typical example for Profibus DPV1 slave.

The 'connections.opal' file is required to bind model signals to driver variables. This is how all drivers implemented with the Data Interchange Layer work. In RT-LAB, model signals that need to reach the driver have to be connected to 'OpOutput' blocks. It is the case for the data and the alarms sent by the Profibus slave to the Profibus master.

Signals traveling from the driver to the simulation model have to be connected to 'OpInput' blocks. It is the case for the data sent by the Profibus master to the simulated slave.

Here is what the connections file looks like for the Profibus slave defined as an example with SYCON.net, above in the 'Configuration' section. Remember that the last 25 double data configured to be sent by the slave and the last 25 double data configured to be received by the slave have been added just to provide an example with full payload transmission (244 bytes in, 244 bytes out). Further, 59 bytes of data (maximum number allowed in Hilscher's documentation), specific to each alarm, have been added to simulate the behavior of the card with the acyclic transmission. However, a DPV0 slave can be configured to send and receive cyclically any number of bytes, from 0 to 244 inclusively, as per user requirements. Also, a DPV1 slave can be configured to read and write acyclically any number of bytes, from 0 to 240 inclusively, as per user requirements.

For Profibus DPV1 slave, some connections have been added to enable the acyclic alarms and these lines are in bold style. They are not required for Profibus DPV0 slave. Please, note that this connections file is only an example.

OPAL-1.0 Object
List {
  item {
    id {
      ProfibusSlave
      profibus_dpv1_slave_cfg.opal
    }	
    outputs {
      item {
        dataInProcess=OpOutput:dataToMaster[0]
        dataInExchanger=profibus_0.in_boolean[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[1]
        dataInExchanger=profibus_0.in_uint8[0]
      } 
      item {
        dataInProcess=OpOutput:dataToMaster[2]
        dataInExchanger=profibus_0.in_uint16[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[3]
        dataInExchanger=profibus_0.in_uint32[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[4]
        dataInExchanger=profibus_0.in_uint64[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[5]
        dataInExchanger=profibus_0.in_byte[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[6]
        dataInExchanger=profibus_0.in_int8[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[7]
        dataInExchanger=profibus_0.in_int16[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[8]
        dataInExchanger=profibus_0.in_int32[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[9]
        dataInExchanger=profibus_0.in_int64[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[10]
        dataInExchanger=profibus_0.in_float[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[11]
        dataInExchanger=profibus_0.in_double[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[12]
        dataInExchanger=profibus_0.in_double1[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[13]
        dataInExchanger=profibus_0.in_double2[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[14]
        dataInExchanger=profibus_0.in_double3[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[15]
        dataInExchanger=profibus_0.in_double4[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[16]
        dataInExchanger=profibus_0.in_double5[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[17]
        dataInExchanger=profibus_0.in_double6[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[18]
        dataInExchanger=profibus_0.in_double7[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[19]
        dataInExchanger=profibus_0.in_double8[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[20]
        dataInExchanger=profibus_0.in_double9[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[21]
        dataInExchanger=profibus_0.in_double10[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[22]
        dataInExchanger=profibus_0.in_double11[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[23]
        dataInExchanger=profibus_0.in_double12[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[24]
        dataInExchanger=profibus_0.in_double13[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[25]
        dataInExchanger=profibus_0.in_double14[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[26]
        dataInExchanger=profibus_0.in_double15[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[27]
        dataInExchanger=profibus_0.in_double16[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[28]
        dataInExchanger=profibus_0.in_double17[0]
      }	
      item {
        dataInProcess=OpOutput:dataToMaster[29]
        dataInExchanger=profibus_0.in_double18[0]
      }	 	  
      item {
        dataInProcess=OpOutput:dataToMaster[30]
        dataInExchanger=profibus_0.in_double19[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[31]
        dataInExchanger=profibus_0.in_double20[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[32]
        dataInExchanger=profibus_0.in_double21[0]
      }	
      item {
        dataInProcess=OpOutput:dataToMaster[33]
        dataInExchanger=profibus_0.in_double22[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[34]
        dataInExchanger=profibus_0.in_double23[0]
      }
      item {
        dataInProcess=OpOutput:dataToMaster[35]
        dataInExchanger=profibus_0.in_double24[0]
      }	
      item {
        dataInProcess=OpOutput:dataToMaster[36]
        dataInExchanger=profibus_0.in_double25[0]
      }
      item {
        dataInProcess=OpOutput:alarmDataToMaster[0]
        dataInExchanger=profibus_0.alarm_trigger[0]
      }	 	 
      item {
        dataInProcess=OpOutput:alarmDataToMaster[1]
        dataInExchanger=profibus_0.alarm_type[0]
      }	 	 
      item {
        dataInProcess=OpOutput:alarmDataToMaster[2]
        dataInExchanger=profibus_0.alarm_slot_number[0]
      }	 	 
      item {
        dataInProcess=OpOutput:alarmDataToMaster[3]
        dataInExchanger=profibus_0.alarm_seq_number[0]
      }	 	 
      item {
        dataInProcess=OpOutput:alarmDataToMaster[4]
        dataInExchanger=profibus_0.alarm_add_ack[0]
      }	 	 
      item {
        dataInProcess=OpOutput:alarmDataToMaster[5]
        dataInExchanger=profibus_0.alarm_specifier[0]
      }	 	 
      item {
        dataInProcess=OpOutput:alarmDataToMaster[6:64]
        dataInExchanger=profibus_0.alarm_data[6:64]
      }	 	 	  
    }
    inputs {
      item {
        dataInExchanger=profibus_0_status.init[0]
        dataInProcess=OpInput:init_status[0]
      }    
      item {
        dataInExchanger=profibus_0_status.tx[0]
        dataInProcess=OpInput:tx_status[0]
      }
      item {
        dataInExchanger=profibus_0_status.rx[0]
        dataInProcess=OpInput:rx_status[0]
      }
      item {
        dataInExchanger=profibus_0.status[0]
        dataInProcess=OpInput:status[0]
      }
      item {
        dataInExchanger=profibus_0.cmd_rcv[0]
        dataInProcess=OpInput:cmd_rcv[0]
      }
      item {
        dataInExchanger=profibus_0.out_boolean[0]
        dataInProcess=OpInput:dataFromMaster[0]
      }
      item {
        dataInExchanger=profibus_0.out_uint8[0]
        dataInProcess=OpInput:dataFromMaster[1]
      }
      item {
        dataInExchanger=profibus_0.out_uint16[0]
        dataInProcess=OpInput:dataFromMaster[2]
      }
      item {
        dataInExchanger=profibus_0.out_uint32[0]
        dataInProcess=OpInput:dataFromMaster[3]
      }
      item {
        dataInExchanger=profibus_0.out_uint64[0]
        dataInProcess=OpInput:dataFromMaster[4]
      }
      item {
        dataInExchanger=profibus_0.out_byte[0]
        dataInProcess=OpInput:dataFromMaster[5]
      }
      item {
        dataInExchanger=profibus_0.out_int8[0]
        dataInProcess=OpInput:dataFromMaster[6]
      }
      item {
        dataInExchanger=profibus_0.out_int16[0]
        dataInProcess=OpInput:dataFromMaster[7]
      }
      item {
        dataInExchanger=profibus_0.out_int32[0]
        dataInProcess=OpInput:dataFromMaster[8]
      }
      item {
        dataInExchanger=profibus_0.out_int64[0]
        dataInProcess=OpInput:dataFromMaster[9]
      }
      item {
        dataInExchanger=profibus_0.out_float[0]
        dataInProcess=OpInput:dataFromMaster[10]
      }
      item {
        dataInExchanger=profibus_0.out_double[0]
        dataInProcess=OpInput:dataFromMaster[11]
      }
      item {
        dataInExchanger=profibus_0.out_double1[0]
        dataInProcess=OpInput:dataFromMaster[12]
      }
      item {
        dataInExchanger=profibus_0.out_double2[0]
        dataInProcess=OpInput:dataFromMaster[13]
      }
      item {
        dataInExchanger=profibus_0.out_double3[0]
        dataInProcess=OpInput:dataFromMaster[14]
      }
      item {
        dataInExchanger=profibus_0.out_double4[0]
        dataInProcess=OpInput:dataFromMaster[15]
      }
      item {
        dataInExchanger=profibus_0.out_double5[0]
        dataInProcess=OpInput:dataFromMaster[16]
      }
      item {
        dataInExchanger=profibus_0.out_double6[0]
        dataInProcess=OpInput:dataFromMaster[17]
      }
      item {
        dataInExchanger=profibus_0.out_double7[0]
        dataInProcess=OpInput:dataFromMaster[18]
      }
      item {
        dataInExchanger=profibus_0.out_double8[0]
        dataInProcess=OpInput:dataFromMaster[19]
      }
      item {
        dataInExchanger=profibus_0.out_double9[0]
        dataInProcess=OpInput:dataFromMaster[20]
      }
      item {
        dataInExchanger=profibus_0.out_double10[0]
        dataInProcess=OpInput:dataFromMaster[21]
      }
      item {
        dataInExchanger=profibus_0.out_double11[0]
        dataInProcess=OpInput:dataFromMaster[22]
      }
      item {
        dataInExchanger=profibus_0.out_double12[0]
        dataInProcess=OpInput:dataFromMaster[23]
      }
      item {
        dataInExchanger=profibus_0.out_double13[0]
        dataInProcess=OpInput:dataFromMaster[24]
      }
      item {
        dataInExchanger=profibus_0.out_double14[0]
        dataInProcess=OpInput:dataFromMaster[25]
      }
      item {
        dataInExchanger=profibus_0.out_double15[0]
        dataInProcess=OpInput:dataFromMaster[26]
      }
      item {
        dataInExchanger=profibus_0.out_double16[0]
        dataInProcess=OpInput:dataFromMaster[27]
      }
      item {
        dataInExchanger=profibus_0.out_double17[0]
        dataInProcess=OpInput:dataFromMaster[28]
      }
      item {
        dataInExchanger=profibus_0.out_double18[0]
        dataInProcess=OpInput:dataFromMaster[29]
      }
      item {
        dataInExchanger=profibus_0.out_double19[0]
        dataInProcess=OpInput:dataFromMaster[30]
      }
      item {
        dataInExchanger=profibus_0.out_double20[0]
        dataInProcess=OpInput:dataFromMaster[31]
      }
      item {
        dataInExchanger=profibus_0.out_double21[0]
        dataInProcess=OpInput:dataFromMaster[32]
      }
      item {
        dataInExchanger=profibus_0.out_double22[0]
        dataInProcess=OpInput:dataFromMaster[33]
      }
      item {
        dataInExchanger=profibus_0.out_double23[0]
        dataInProcess=OpInput:dataFromMaster[34]
      }
      item {
        dataInExchanger=profibus_0.out_double24[0]
        dataInProcess=OpInput:dataFromMaster[35]
      }
      item {
        dataInExchanger=profibus_0.out_double25[0]
        dataInProcess=OpInput:dataFromMaster[36]
      }
    }
  } 
}

In this file, it is important to understand that the second field of the 'id' item contains the name of the driver configuration file described in the 'Configuration section'. Also, each string used in the 'dataInExchanger' tags must have the same prefix defined by 'profibus_', concatenated with the board index '0'. Next, if the point is a data, the tag continues with a dot '.' followed by the name of the element defined in SYCON.net (as shown in Step 7 of the 'Configuration' section). In the case of status connections, the tag continues with '_status' concatenated with a dot '.' and the name of the status flag.

For the Profibus slave, three status flags are defined: init_status, tx_status, and rx_status. It means that the value of these status flags, coming from the Profibus driver, can be read inside the simulation to notify the user if a specific issue occurs. Two statuses have been added for the Profibus DPV1 example which allows the user to track if an error occurred in the acyclic transmission as well as the command number of the last received message.

If an acyclic transmission error occurs, the hexadecimal error code can be found in Hilscher's documentation. In the Simulink model, two 'OpInput' blocks are required, named 'status' and 'cmd_rcv' to receive these statuses.

To receive the cyclic data from the Profibus master in the model, four 'OpInput' blocks are required. In the case of the example above, the first block must be named 'dataFromMaster' because this is the name given in the connections file for the 'dataInProcess' fields. The next three blocks must be named 'init_status', 'tx_status' and 'rx_status', as seen in the above 'connections.opal' file.

To send cyclic data to the Profibus master through the connection points, two 'OpOutput' blocks must be used. In the case of the example above, they must be named 'dataToMaster'. In order to easily understand how the connections from the model to the driver are made, an overview of the Profibus slave example model is recommended.

One 'OpOutput' block, named 'alarmDataToMaster', is required to send alarm related data to the Profibus master.

As explained above, three connection points can be used in the inputs section to receive status information from the CIFX card (status.init, status.tx and status.rx). The table below describes each initialization status value that might be returned by the driver.

The table below describes each transmission status value that might be returned by the driver.

The table below describes the acyclic transmissions status value that might be returned by the driver.

The table below describes the last acyclic command number received from the Profibus master that might be returned by the driver.

The Profibus DPV1 slave example model shows how to perform the connections using 'OpInput' and 'OpOutput' blocks. An example model is provided. It is located in the following directory:

YOUR_RT_LAB_INSTALLATION_FOLDER/Examples/IO/Profibus/Hilscher/Slave/DPV1/simulink

The example model is also accessible from the New Project wizard in RT-LAB. Select the Profibus_DPV1_Slave template under IO/Profibus/Hilscher/Slave. Here is a screenshot of the master subsystem:

The Profibus_DPV0_slave template is also accessible under IO/Profibus/Hilscher/Slave and the corresponding model is located in the following directory :

YOUR_RT_LAB_INSTALLATION_FOLDER/Examples/IO/Profibus/Hilscher/Slave/DPV0/simulink

HYPERSIM Usage

The driver is not yet available in Hypersim but can be ported upon request.

Limitations

The current version of the Profibus slave communication interface has the following limitations:

• On 64bit platforms, enabling the XHP mode is not possible; if the driver is part of a model that requires XHP enabled, it is advised to group the OpInputs/OpOutputs used by Profibus slave in a separate subsystem that will operate with XHP = off.
• Number of boards: Only supports one Profibus board per target.
• Memory alignment: Data can be aligned on a byte or word boundary in the CIFX Dual Port Memory. (See SYCON.net documentation).
• Offline mode: Driver does not work offline.
• Platform: Driver can only be used on Linux (OPAL-RTLinux x86-based 32bit and OPAL-RTLinux x64-based 64bit platforms).
• Data types: uint8, int8, uint16, int16, uint32, int32, uint64, int64, float, double. The SYCON.net tool allows to define 'Boolean' types but actually maps them as bytes. It means that if the user wants to configure a 'Boolean' type, he/she has to limit this value to 0 or 1 in the model before sending it to the master.
• Maximum cyclical transmission size: The driver can only send 244 bytes at once in a cyclic transmission.
• Maximum cyclical reception size: The driver can only receive 244 bytes at once in a cyclic transmission.
• Maximum number of acyclic read/write: The driver can only read/write 240 bytes at once per slave and acyclic telegram.
• Maximum number of active alarms: The driver can only handle 32 alarms in total by the Profibus DP Master.
• Maximum number of alarms specific data: The driver can only handle 59 bytes of specific data in total per alarm.
• Configuration: the SYCON.net tool must be used to configure the driver.
• Connectivity: only direct connection with the master is supported for the moment.