1 Introduction With the further popularization of Profibus bus technology in China, bus products based on the Profibus-DP protocol are occupying an increasing share of the market. Developing slave products with DP interfaces independently is of significant practical importance. Many domestic units are involved in the research and development of DP bus products; however, reports of self-contained systems are rare. The main reason for this is that several core issues have not been adequately addressed during development. These issues mainly focus on understanding the Profibus-DP interrupt mechanism, analyzing the SPC3 solid-state program, compiling GSD files, and configuring the Profibus-DP network. This paper will discuss these issues one by one. 2 Profibus-DP Interrupt Mechanism 2.1 Interrupt Mechanism Interrupt control in the Profibus-DP protocol is implemented through the interrupt controller within the SPC3 protocol chip. When an instruction message arrives or various error events occur, the CPU is notified and performs corresponding processing. This interrupt controller can manage 16 predefined interrupt events, which are managed uniformly through an interrupt output. This interrupt controller does not have interrupt priority or provide interrupt vectors. The interrupt controller primarily consists of four registers: the Interrupt Request Register (IRR), the Interrupt Mask Register (IMR), the Interrupt Register (IR), and the Interrupt Acknowledge Register (IAR). The internal working principle of this interrupt controller is illustrated in Figure 1. All interrupts awaiting processing are stored in the IRR register; individual interrupts can be disabled by setting the IMR register. The inputs to the IRR register are unaffected by interrupt masking; unmasked interrupt signals are summed to trigger X/INT interrupts. When debugging DP slaves, various interrupt signals can be set in the IRR register for debugging purposes. All interrupts processed by the microprocessor can only be deleted through the IAR register; correspondingly, the corresponding bit must be set to "1". If a new interrupt event is applied to the input of the IRR register simultaneously with a previous interrupt event, the new event will be retained. If the processor subsequently enables a masked interrupt, it must ensure that no interrupt signal has previously been applied to the input of the IRR register. For safety, the corresponding bit in the IRR register must be deleted before enabling interrupt masking. [align=center] Figure 1 Profibus-DP Interrupt Mechanism[/align] 2.2 Interrupt Response Although there is no need to modify the Profibus-DP interrupt mechanism when developing DP products, a thorough understanding of this interrupt mechanism is of great significance for analyzing the SPC3 solid-state program, because the framework of the solid-state program is based on the interrupt mechanism defined by the Profibus-DP protocol. In actual operation, the microprocessor in the DP slave station mainly responds to the following types of interrupt events of the protocol chip SPC3. (1) Diag_Fetched: Diagnostic data is taken away by the master station. At this time, the MCU should issue a User_Diag_Read_Cmd command (implemented by reading the User_Diag_Read_Cmd unit in RAM) to swap the user diagnostic buffer with the MAC buffer, so as to provide the updated user diagnostic data to the MAC layer for the master station to use when necessary; (2) IndQ_Entry: New event information enters the indicator queue. During interrupt processing, the MCU should read the event information code from the indicator queue and react according to different events. For example, if a watchdog timer expires, the program will jump out of the data exchange state and stop sending input data; (3) Go/Leave_Data_Exchange: Enter or leave the data exchange state. At this time, the MCU should read the status register of SPC3 to know whether it is entering or leaving. If it is entering the data exchange state, it should prepare input data to send to the master station; if it is leaving, it should stop sending input data; (4) New_Prm_Data: New parameter message. The MCU reads the parameter data from the user parameter buffer, and then sets the parameters that the slave station needs to set. According to whether the setting result is correct, it sends a positive User_Prm_OK_Cmd or a negative User_Prm_Not_OK_Cmd command to SPC3. SPC3 will then respond positively or negatively to the master station for this parameter message; (5) New_Cfg_Data: New configuration message. The MCU reads the configuration data from the user configuration buffer, then sets the slave station according to the configuration information, and sends a positive User_Cfg_OK_Cmd or a negative User_Cfg_Not_OK_Cmd command to the SPC3 according to whether the configuration result is correct. The SPC3 will then respond positively or negatively to the master station for this configuration message; (6) Get_Cfg_Buffer_Change: The read configuration buffer is changed, that is, the user read configuration buffer and the MAC read buffer are swapped. During interrupt handling, the MCU should obtain the pointer of the new user read configuration buffer by reading User_Cfg_Buffer_Ptr so as to write the configuration information of the slave station into the new user read configuration buffer. This interrupt is caused by the User_Get_Cfg_Read_Cmd command confirming the User_Cfg_OK_Cmd of the master station configuration message; (7) Diag_Buffer_Changed: The diagnostic buffer is changed, that is, the user diagnostic buffer and the MAC diagnostic buffer are swapped. In interrupt handling, the MCU should obtain the pointer to the new user diagnostic buffer by reading User_Diag_Buffer_Ptr, so as to write the diagnostic information of the slave station into the new user diagnostic buffer. This interrupt is caused by the User_Diag_Read_Cmd command; (8) DX_OUT: new output data. At this time, a User_New_Dout_Cmd command should be issued and a pointer to the new U buffer should be obtained. The user can obtain the new output data stored in it according to this pointer. At the same time, the MCU should issue a User_New_Din_Cmd to change the U input data buffer to an N input data buffer and obtain a pointer to the new U buffer. In this way, the user's input data is sent to the master station and a new U buffer is obtained to prepare for the new input data. All interrupt events are coordinated and combined to form the Profibus-DP state machine, as shown in Figure 2: [align=center] Figure 2 Profibus-DP State Machine Model[/align] 3 Analysis of SPC3 Solid State Program Using the SPC3 protocol chip provided by Siemens, the hardware circuit of the Profibus-DP slave station can be designed relatively easily. However, the software design of the slave station is relatively complex. The key to the software design is utilizing the SPC3 protocol chip solid state program provided in the development kit. Therefore, analyzing this solid state program is another issue that needs attention. 3.1 SPC3 Solid State Program Flow Since the registers within the SPC3 chip are fully formatted, the solid state program can realize the connection between the internal registers of the SPC3 and the application interface, providing users with a macro interface. Using the solid state program can greatly save users' development time. The SPC3 solid state program package eliminates the need for users to directly manipulate registers and calculate storage space. The solid-state program includes the following modules: (1) Main program SERSPC3.C, which mainly completes SPC3 initialization, startup, external signal processing, data transmission and reception, and diagnostics; (2) Interrupt module INTSPC3.C, which mainly handles slave parameter allocation, configuration data checking, and slave address setting; (3) Function DPS2SPC3.C, which calculates input and output data lengths based on configuration data, allocates auxiliary buffers, initializes buffers, sets IO data lengths, and updates various buffers; (4) Variable definition and macro interface DPS2USER.h, which allows users to easily access the various registers of SPC3. When SPC3 receives different output data transmitted by the Profibus-DP master station, it generates an output flag bit (located in the interrupt request word unit). The CPU receives master station data by querying the flag bit in the application loop. For systems with strict real-time requirements, the interrupt method should be used to process the output data. The main program first initializes the SPC3 using DPS2 from the development kit, enabling external interrupt INT0, setting INT0 to high priority and enabling interrupts, and then starts the SPC3. Data exchange and diagnostic processing between the master and slave stations are then performed through the SPC3. The flowchart of the SPC3 solid-state program is shown in Figure 3: [align=center] Figure 3 SPC3 Solid-State Program Flowchart[/align] 3.2 SPC3 Initialization Subroutine Before the SPC3 can operate normally, it needs to be initialized to configure the necessary registers, including setting interrupt enable for the protocol chip, writing the slave identification number and address, setting the SPC3 mode register, setting the diagnostic buffer, parameter buffer, configuration buffer, address buffer, initialization length, and deriving pointers to each buffer and auxiliary buffer based on the above initial values. The output buffer, input buffer, and pointers are determined according to the length of the transmitted data. The initialization program is used to implement the following functions: (1) SPC3 hardware reset: The application uses RESET to reset SPC3, initialize the internal RAM and reset the microprocessor; (2) Compiler settings: Select the appropriate compiler for the selected microprocessor and activate the DPS2 interface with #define DPS2_SPC3; (3) Set SPC3 interrupt mask register: The macro DPS2_SET_IND() activates SPC3 interrupt triggering, including slave address change, configuration data check, and parameter check interrupts; (4) SPC3 internal watchdog setting: The user watchdog is used to ensure that when the microprocessor fails, SPC3 can perform data communication within the time set by DPS2_SET_USER_WD_VALUE(X). After the time expires, it leaves the data exchange communication state. As long as the microprocessor is not faulty, the watchdog circuit needs to be retried by DPS2_RESET_USER_WD continuously; (5) Device identification code setting: During the startup process, the application reads the identification code and transmits it to the SPC3 chip; (6) Setting Response Time: If required by certain applications, users can set the minimum slave response time for SPC3 using DPS2_SET_MINTSDR(X); (7) Buffer Initialization Settings: Users must determine the length of each buffer used for information exchange defined in the DPS2_BUFINIT structure. The length of these buffers determines the length of each data buffer in SPC3. These buffers occupy the space of the SPC3 dual-port RAM, so they cannot exceed the total length of the buffers. Use the macro SPC3_INIT() or Dps2_buf_init() function to take the pointer of the structure initialized by DPS2_BUFINIT as a parameter, allocate each buffer in the RAM of SPC3 according to the data in the structure, check the maximum length of each buffer, and return the test information after buffer initialization; (8) Baud Rate Control Settings: The baud rate control mode can be set using the DPS2_SET_BAUD_CNTRL() macro. After this monitoring time value, if no valid information is received, SPC3 will start the BAUT RATE RESEARCH function. If the timer monitor is enabled and the DP slave detects a fault in the DP master, the local output data is deleted or the specified safe state is entered. The time base of the watchdog timer is 10ms, and its time range is 10ms to 650s. 3.3 Subroutine for receiving master output data The Profibus-DP master and SPC3 exchange data through the default service access point. In this process, the tasks that SPC3 needs to complete mainly include the following three steps: (1) SPC3 writes the output data into the D buffer and swaps the data in the D and N buffers; (2) Generates the DX-Out interrupt; (3) The user obtains the output data from the U buffer by swapping the data in the N and U buffers. Step 1 is completed automatically by SPC3. The interrupt request register of SPC3 is read using DPS2_POLL_IND_DX_OUT() to query the interrupt event. When it is true, it means that SPC3 has received the Write_Read_Data message and made the output data in the N buffer valid. The macro `DPS2_OUTPUT_UPDATE()` updates the output buffer, which moves the data in buffer N to buffer U. The output data does not include the length of the output data, but it must match the length defined by `DPS2_SET_IO_DATA_LEN()`. If the lengths do not match, the slave will return to the waiting state for parameter assignment. The length of the output data buffer is determined in the initialization part of the program. The core code of this part is as follows: `if (DPS2_POLL_IND_DX_OUT()) { DPS2_CON_IND_DX_OUT(); user_output_buffer_ptr = DPS2_OUTPUT_UPDATE(); for (i=0; i outp_data_len; i++） { (＊((io_byte_ptr)+i))=(＊(((UBYTE SPC3_PTR_ATTR＊) user_output_buffer_ptr) + i)); } } 3.4 Subroutine for Sending Input Data Before sending input data, the user main program must first obtain the pointer to the input buffer using the macro DPS2_GET_DIN_BUF_PTR(). The macro DPS2_INPUT_UPDATE() allows the user to repeatedly send input data from the user end to DPS2 and obtain a pointer to the available input buffer for receiving new input data. The input data does not include the length of the input data, but the input data must be consistent with the length defined by DPS2_SET_IO_DATA_LEN(). The core program segment for processing input data and writing it from the peripheral to the buffer is as follows: for (i=0; i inp_data_len; i++） { * (((UBYTE SPC3_PTR_ATTR*) user_input_buffer_ptr) + i) = * ((io_byte_ptr) + i); } user_input_buffer_ptr = DPS2_INPUT_UPDATE(); 3.5 Diagnostic Data Sending Subroutine The main station and SPC3 process diagnostic data through the service access point SAP60. The main tasks that SPC3 needs to complete include the following: (1) The user saves the external diagnostic data in diag_buffer; (2) The transmission of diagnostic data is started by NEW_DIAG_CMD; (3) The diagnostic data is confirmed to have been transmitted with "Diag_buffer_changed"; (4) Diag_Flag is set, and the next read/write cycle will respond to the new diagnostic request with high priority. Before inputting external diagnostic data, the diagnostic user needs to obtain a pointer to an available user diagnostic data buffer using the macro `DPS2_GET_DIAG_BUF_PTR()`. User diagnostic information and status information can be written to this buffer starting from the 7th byte. The first 6 bytes are the diagnostic header specified by the bus standard. The length of the diagnostic data is specified using the macro `DPS2_SET_DIAG_LEN()`. The diagnostic buffer length ranges from 6 to 244 bytes, including 6 bytes of fixed diagnostic data and external user diagnostic data starting from the 7th byte. The macro for setting the diagnostic data length can only be called after receiving a pointer to an available diagnostic buffer. The macro `DPS2_DIAG_UPDATE()` can be used to pass new external diagnostic data to the user diagnostic buffer in SPC3 and returns a new diagnostic data buffer pointer. After receiving the `New_Diag_Cmd` diagnostic send request, SPC3 sends the data from the user diagnostic buffer to the diagnostic send buffer and makes the original user diagnostic buffer available. Since the SPC3's diagnostic buffer does not automatically become active after data transmission is complete, the user needs to set the diagnostic buffer's availability flag after querying the diagnostic buffer using `DPS2_POLL_IND_DIAG_BUFFER_CHANGED()`. If no external diagnostic data is transmitted, or if the diagnostic data is deleted before being transmitted, the SPC3 responds to diagnostic requests from the PROFIBUS-DP master with 6 bytes of slave diagnostic data. This 6-byte diagnostic data includes 3 bytes of slave status data, the master address that sent the diagnostic request, and the slave device identifier. The core program segment of the diagnostic processing procedure is as follows: if (DPS2_POLL_IND_DIAG_BUFFER_CHANGED()) { DPS2_CON_IND_DIAG_BUFFER_CHANGED(); user_diag_buffer_ptr = DPS2_GET_DIAG_BUF_PTR(); user_diag_flag = TRUE; } 4. Compilation of Field Device GSD Files To achieve rapid configuration of Profibus-DP field devices, a reliable Electronic Device Data Sheet (GSD) for the product must be provided. The characteristics of Profibus-DP devices are detailed in the GSD, also known as the Electronic Device Database File (GSD). Standardized GSD data extends communication to the operator control level. Using GSD-based configuration tools, devices from different manufacturers can be integrated into the same bus system, which is both simple and reliable. The GSD file can be broadly divided into three parts: 4.1 General Specifications: This section includes the manufacturer and equipment name, hardware and software version information, supported baud rates, possible monitoring intervals, and signal assignments for bus connectors; 4.2 DP Master-Related Specifications: This section includes parameters applicable only to the DP master (such as the maximum number of connected slaves or upper-end and lower-end capabilities), and does not specify requirements for slaves; 4.3 DP Slave-Related Specifications: This section includes all specifications related to slaves (such as the number and type of input/output channels, interrupt test specifications, and input/output data consistency information). The GSD file consists of several lines, each beginning with a keyword, including the keyword and parameters (unsigned numbers or strings). Keywords in the GSD file can be standard keywords (defined in the PROFIBUS standard) or custom keywords. Standard keywords can be recognized by any PROFIBUS configuration tool, while custom keywords can only be recognized by specific configuration tools. The GSD file is primarily used to provide configuration data for slaves to configuration tools. The GSD file standard defines keywords to identify different functions for configuration software recognition. A GSD file for a DP slave module that implements 16-channel switch output is shown below (only the most important parameters are listed; the definitions of other parameters can be found in reference 2): #Profibus-DP ; Supports Profibus-DP protocol Model_Name="16_DO" ; Slave device name Ident_Number=0x18 ; Slave device identification number (obtained during authentication) Protocol_Ident=0 ; Supports only DP protocol 12M_Supp=1 ; Supports 12M baud rate Max_Tsdr_12M=800 ; Maximum response time at 12M baud rate is 800μs Max_Diag_Data_Len=8 ; Maximum user diagnostic data length Unit_Diag_Bit(0)=“external device not present” ; Diagnostic information represented by diagnostic bit 0 Unit_Diag_Bit(1)= “external device detects fault” ; Diagnostic bit 1 indicates diagnostic information Module="Module1" 0x23 ; Defines a 16-channel switch output module EndModule ; Module definition end marker Similarly, users can compile GSD files based on equipment-related parameters provided by the equipment manufacturer. GSD files extend the data communication network to the operator control level, and configuration software based on GSD files provides a user-friendly interface. 5 Profibus-DP Network Configuration Before commissioning and verifying Profibus-DP products, a bus network must be established and configured. There are generally two configuration methods: one is to use COMPROFIBUS configuration software, which is simpler but only allows for simple applications, suitable for novice users or when developing slave products; the other is to use STEP7 software, which is more complex but allows for more complex applications, and the configuration itself becomes part of the user program. In practical applications, the appropriate configuration method should be selected according to different needs. Due to space limitations, this article only discusses the commonly used STEP7 configuration method. 5.1 Network Hardware Configuration The modules required to configure a basic Profibus-DP network include: power supply (PS307/10A), CPU (S7-300 series), CP342-5 (Profibus-DP master/slave interface module), IM365 (data input/output module for multi-rack systems), and central rack (for installing various modules). After the hardware connection is completed, you need to install the self-compiled GSD file. In the menu bar, select OPTIONS→INSTALL NEW*.GSE FILES. Before configuring the hardware, you must first create a STEP7 project. To create a new STEP7 project, you should first open SIMATIC Manager and then perform the following steps: (1) In the menu bar, select FILE-New… to open the dialog box to create a new project; (2) Select the “New Project” button and set the “storage location (path)” for this new project; (3) Log in the name of the new project (e.g., S7-Profibus-DP), confirm with “OK” and exit. Return to the SIMATIC Manager main menu. The creation of the S7-Profibus-DP object folder has automatically generated an MPI object. This MPI (Multipoint Interface) object can be seen on the right side of the project screen. STEP7 automatically generates an MPI object each time a new project is created. MPI is the standard programming and communication interface for the CPU. Return to the main menu of the project named S7-Profibus-DP, select the Profibus object, and right-click to open the shortcut menu. Select OPEN OBJECT to invoke the graphical configuration tool Net Pro. Select the Profibus subnet at the top of the screen, right-click to open the shortcut menu, and select the command OBJECT PROPERTIES… In the “Properties-Profibus” dialog box, open the “Network Settings” tab. Here you can set all the relevant network parameters for the Profibus subnet. The main parameters that need to be set are: transmission rate, bus profile, and bus parameters; the remaining parameters can be left at their default settings. The selected transmission rate will apply to the entire Profibus subnetwork; therefore, all stations used on the Profibus subnetwork must support the selected baud rate, which can be selected between 9.6 kbit/s and 12,000 kbit/s. A baud rate of 1500 kbit/s is recommended as the default setting; the bus profile provides a baseline (default setting) for different Profibus applications. Each bus pattern contains a set of Profibus bus parameters, which are calculated and set by the STEP7 program, taking into account special configurations, patterns and baud rates. These bus parameters apply to the entire bus and all nodes connected to this Profibus subnetwork. All bus parameter values ​​are expressed in tBIT (bit runtime), which is related to the baud rate. The relationship between the two can be listed in the appendix: [align=center]Appendix: Relationship between Bit Run Time and Baud Rate[/align] 5.2 Building a Profibus-DP Network It is also very convenient to build a Profibus-DP network using STEP7 software. The main steps are as follows: (1) Enter the Hardware configuration environment and add the modules to the corresponding positions in the rack by dragging and dropping with the mouse; (2) Build a Profibus-DP network, set the master station, and connect each slave station to the network; (3) Set the addresses of each master and slave station; (4) If a rack cannot accommodate all the modules, the number of racks should be increased accordingly; (5) Select Save and under the Station menu If the Compile command is error-free, the Download command can be used to download the hardware configuration to the PLC. Figure 4 shows a schematic of a Profibus-DP network configured using CPU314, PS307/10A, IM365 (SEND/RECEIVE), and CP342-2. [align=center]Figure 4 Profibus-DP Network Configuration Schematic[/align] When setting the addresses of each station, it should be noted that some types of DP slaves do not provide hardware switches for setting Profibus addresses; their bus addresses are specified using the Type 2 DP master function Set_Slave_Add. Since it is an integrated MPI online interface, the STEP7 configuration software can handle this addressing function. This address allocation method is only applicable to DP slave devices that support the Set_Slave_Add function. Furthermore, the default address of the slave device is set to 126 by the manufacturer. In the European standard EN 50170, this address has been reserved and cannot be used by Profibus-DP users, but if the slave is a new device obtained directly from the manufacturer, this default value can still be seen. 6. Conclusion The hardware design for developing a Profibus-DP slave is relatively simple; the software design and online debugging are more complex. During the development of DP slaves, the author found that many failures were due to problems with the GSD file or network configuration errors. This article discusses these issues and provides solutions with examples, offering valuable insights. These issues must be given close attention during the development of DP slave products.