Abstract: To meet the requirements of bus-based intelligent valve positioners, a communication interface based on the FF protocol was developed. The OEM development concept of a dual-processor architecture was explained, and detailed steps and development tools for implementing FF communication were provided. Testing confirmed that the valve positioner successfully implemented FF bus communication, demonstrating the feasibility of the development scheme.
Keywords: Fieldbus, Foundation Fieldbus, Communication Interface, Round Card, Valve Positioner
1 Introduction
Foundation Fieldbus (FF) is a fieldbus technology that enjoys widespread support and promising development prospects in the field of process automation. It consists of two parts: low-speed (FF-HI) and high-speed (FF-HSE), both of which are adopted by the international fieldbus standard IEC 61158. Because the FF protocol combines communication and control functions, its architecture is very complex. From an implementation perspective, although the FF protocol itself is publicly available, it does not involve the implementation of the protocol; therefore, much work remains to be done regarding implementation.
This article describes the development of the communication interface for the FF-HI bus intelligent valve positioner, which can serve as a reference for the development of Foundation Fieldbus communication interfaces for other 4-20mA devices or intelligent devices.
2 Overall Design
2.1 Development Plan
Based on the analysis and comparison of different field equipment development approaches, an original equipment manufacturer (OEM) development scheme with a dual-processor (CPU) architecture was adopted. This means the hardware of the intelligent valve positioner mainly consists of an instrument card and a circular card. Its principle structure is shown in Figure 1.
The instrument card uses an MSP430 microcontroller as the main chip to realize basic functions such as initialization, valve position feedback, alarm, and display of the intelligent valve positioner. The development of this part of the hardware and software has been completed. The communication round card is the data transmission and control part, which needs to complete the fieldbus communication and various control algorithms. This design uses a certified communication round card to simplify the hardware development of the round card. Only the software development of functions such as the communication interface between the instrument card CPU and the round card CPU, the communication between the round card and the FF bus, and the calling of device function blocks needs to be completed.
2.2 Development Tools
This paper utilizes the Field Device Development Kit (FDM) provided by Fielbus Inc. for communication interface development. This kit contains the necessary elements for device development and network operation, allowing users to easily design new bus products without requiring in-depth knowledge of low-level fieldbus protocols. The development kit includes: a round card, a serial programming daughter card, a PC interface card, round card programming tools, FF-HI communication stack software, FI function block application software, power supply, cables, and other tools.
The HI fieldbus round card is a hardware interface for developing FF-compatible devices. It is bus-powered and can interface to networks compliant with the FF-HI protocol. The round card uses an MC68331 embedded processor and a programmable 128KB×16 flash memory to run the communication stack interface library, function block shells, and user applications. It also has a 128KB×16 SRAM for volatile memory to store bus management information library parameters and block parameters. Connection between the round card and the instrument card's measurement components is achieved through a serially programmed daughter card. The daughter card can perform DIO, A/D, and D/A functions and connects to the round card via a 2×21-pin WI connector.
3. Communication Scheme Design
This paper implements communication between the circular card and the instrument card using a serial communication interface. The circular card acts as the calling party, initiating communication, while the instrument card acts as the slave, responding to the circular card's communication. The circular card completes the calling, sending, and receiving data functions through serial functions, while the instrument card uses a serial interrupt method for serial communication processing.
Serial functions provide a general way to transfer data between the round card and serial devices. It is independent of the communication stack protocol and function block shell calling functions used for communication with serial devices. For communication using three-wire serial communication, serial functions provide two data formats: the general serial format is a general master/slave command/response serial protocol, which requires the user to encode and decode command and response data packets.
Serial functions can be configured to continuously send/receive a defined sequence of commands, defined by the `nihDefineSequence` and `nihSendCommand` functions. `nihDefineSequence` defines the number of command lines in the sequence sent to the device, and `nihSendCommand` defines the commands in the sequence. A command is a serial interaction that includes a send, a receive, or both. After the last command in the sequence is defined, the sequence sends all commands in the order they were defined. The `nihDefineSequence` or `nihSendCommand` functions can be used to cancel the execution of a sequence. The `nihDefineSequence` and `nihSendCommand` functions can be used to modify command data and retain the last response data in the command sequence. `nihPutData` can be called directly to set the current value of the data to be changed in the send buffer, or `nihGetData` can be called to retain the data packet received from the serial device during the last execution of the sequence. The `nihsetparam` function can be used to set the communication parameters of the circular card, such as the number of command retransmissions, the number of preambles, timeout, serial protocol type, baud rate, parity type, and stop bits.
4. Round Card Application Development
The round card executes NI's communication stack software, specifically designed for front-end networks (FF) and tested for FF compliance, enabling communication between the link master device (LAS) and basic devices. Additionally, the round card executes NI function block shell software, which provides an application programming interface (API) for developing the blocks required for FF. The development steps for round card applications are as follows.
4.1 Write the device template and convert it into C code.
The device template is an ASCII file containing device identification, physical blocks and function blocks within the device, and device parameters. The template file consists of several parts, each composed of a keyword and its description, in the following order: VFD, UDER_TYPE, BLOCKS, TRENDS, VARLISTS. Based on the function of the valve positioner, this design selects PID and AO function blocks.
The device template is converted into C code by the device code generator. The command line for the device code generator codegen.exe is:
The codegen file is named devicetemplate.dat, outputfile.c, and nifb.sym. Here, devicetemplate.dat is the device template filename, and outputfile.c is the output filename after conversion.
4.2 Writing User Application Files
The user application is the main part that implements the locator function. It utilizes the high-level interface with the FF communication stack provided by the function block shell to handle parameter reading and writing related to network communication and complete bus communication functions. It also implements the standard FF function block functions by registering callback functions and executing specific function block algorithms. The block diagram of the user application is shown in Figure 2.
(1) Write the callback function of the function block, the userStart function, and the registration callback function.
The callback function performs two functions: executing the function block algorithm and handling alarm confirmation and identification. When a function block is scheduled for execution, the function block shell calls the callback execution function defined by the development device. The algorithm is written in the callback execution (CB_EXE) function to complete the actions required by the function block. The definition format of the CB_EXE function is: void (CB_EXE(HDL_BLOCK hBlock).
The `userStart` function is automatically called when the communication stack starts. It initializes the function block shell and registers the device's callback functions through it. The function block application process uses the registration function to inform the function block shell of the user application's characteristics, including user-defined data types, physical blocks, transmitter blocks, function blocks, block parameters, etc. The `shRegistCallback` function is called back within `userStart` to register the callback functions.
(2) Specify the system clock and RAM size, and define and install the interrupt handler.
In the round card application and source code, declare and define two global variables: SystemCleckSpeed and Ramsize, with their initial valid values as follows: SystemCleckSpeed, with a value of 1 representing a 4MHz clock; Ramsize, with a value of 2 representing 256KB.
The circular card provides interrupt pins with priority numbers 3, 4, and 6, which can be used by any interrupt source on the circular card, and can also generate necessary interrupts using the CPU's internal modules. If interrupts are used in a device application, an interrupt handler must be installed in the user application, and `niInstallIntHandler` must be used for stack function calls. No interrupt handler is used in this design.
4.3 Generate device configuration and convert the device configuration into C code.
The device configuration file includes data link configuration and system management configuration, which define the device type (basic device or link master device), node address, device ID number, device tag number, device scheduling time unit, and scheduling time table.
Run the configuration generator to convert the ini file into a linkable .e file. The command line is:
efggen device.ini devicecfg.c
In this context, device.ini represents the device configuration file, and devicecfg is the name of the output .c file.
4.4 Edit, link, and download the program
In the debugging environment, the linker output file is downloaded to RAM for debugging. After full debugging, a binary format is generated, and the program code is downloaded to flash memory using the biBum.exe command. The first step is editing, converting the .c files generated by the device code generator and the configuration generator (including the userStart and callback functions) to .o format. The second step is linking them with NI's communication stack software nistack.lib. This circular card library file contains the communication stack protocol and function block shells. Finally, after the user application is linked with the library, object bytes are extracted from the linker's output file and converted to binary format. This allows them to be downloaded to the target processor's memory.
4.5 Programming Memory
The round card uses the niBurn.exe command to program the memory via the RS-232 port on the host and the serial port on the serial programming daughter card, without the need for an external PROM programmer.
5. Conclusion
Using the provided NI-FBUS configurator and NI-FBUS monitor, the AT-FBUS board was used as the link master device to conduct a complete system test on the circular card. The test results show that after the self-developed valve positioner is connected to the circular card, it can realize the function of an electrical intelligent valve positioner and may interoperate with other bus devices. It can accept function block scheduling, parameter reading and writing, and parameter transmission from the link master device. This shows that the instrument can run normally on the FF bus and has the functions of an FF bus instrument. At the same time, it proves that the overall design scheme and the development method adopted are feasible.
References
1. Yang Xianhui. Fieldbus Technology and Its Applications [M]. Beijing: Tsinghua University Press, 1999: 70-186.
2. National Instruments Corporation.MC68331-BasedFieldbusRoundCardUserManual[R].USA: 1998
3. Pang Yanbin, Wang Sheng, Cheng Wei. Development of intelligent pneumatic valve positioner based on FF protocol [J]. Journal of Instrumentation, 2001, 22(3): 34-37
