MXPA99003075A - Local device and process diagnostics in a process control network having distributed control functions. - Google Patents

Abstract

A field device for use in a process control network having a plurality of devices communicatively coupled by a two-wire, all-digital communication bus includes a connector that connects the field device to the two-wire, all-digital bus to enable all-digital communication over the bus, a memory that stores a diagnostic test routine having a series of device or process diagnostic test instructions, and a controller that performs the device or process diagnostic test instructions stored in the memory to implement a device or process diagnostic test using the field device. A data collection unit within the field device collects diagnostic data generated during the diagnostic test and a communication unit communicates the collected diagnostic data over the bus to a host device for processing. The controller may include a program language interpreter adapted to interpret the diagnostic test instructions which may be provided to the field device from another one of the devices via the bus.

Description

DIAGNOSTICS OF LOCAL DEVICE AND PROCESS IN A NETWORK OF PROCESS CONTROL THAT HAS CONTROL FUNCTIONS DISTRIBUTED RELATED APPLICATION This is a continuation in part of the United States Patent Application Serial Number 08 / 726,262 filed October 4, 1996.

FIELD OF THE INVENTION The present invention relates generally to process control networks and, more specifically, to a method of, and an apparatus for performing local device and process diagnostics in a process control network having functions. of distributed control.

DESCRIPTION OF THE RELATED TECHNIQUE Large processes, such as chemical, petroleum and other manufacturing and refining processes, include different field devices placed in different places to measure and control the parameters of the process to effect the control by means of the same ones. process. These field devices can be, for example, detectors such as temperature, pressure and flow rate detectors, as well as control elements such as valves and switches.

Historically, the process control industry used manual operations such as manual level reading and pressure indicators, turning valve wheels, etc., to operate the measurement and control field devices within a process. At the beginning of the 20th century, the process control industry started using local pneumatic control, in which local pneumatic controllers, transmitters, and valve positioners were placed in different places within a process plant to perform the control of cen places on the floor. With the emergence of the distributed control system (DCS, for its acronym in English) based on microprocessor in the 70s, it became frequent the control of distributed electronic process in the process control industry. As is known, a distributed control system includes an analog or digital computer, such as a programmable logic controller, which is connected to numerous electronic verification and control devices, such as electronic detectors, transmitters, current-to-pressure transducers. , valve positioners, etc., which are located through a whole process. The computer of the distributed control system stores and implements a centralized and often complex control scheme to perform the measurement and control of the devices within the process in order to control the parameters of the process according to some general control scheme. . Usually, however, the control scheme that implements a distributed control system is owned by the controller manufacturer of the distributed control system which, in turn, makes the distributed control system difficult and expensive to expand, improve, return to program, and give service as the provider of the distributed control system must be fully involved to perform any of these activities. In addition, equipment that can be used by, or connected to, any particular distributed control system, may be limited due to the patented nature of the controller of the distributed control system and the fact that the supplier of a controller of the Distributed control may not support cen devices or functions of devices manufactured by other vendors. To overcome some of the problems inherent in the use of patented distributed control systems, the process control industry has developed a number of standard, open communication protocols that include, for example, the HART®, PROFIBUS®, WORLDFIP protocols. ® ,. LO WORKS®, Device-Net®, and CAN, which facilitate the use of field devices manufactured by different manufacturers together within the same process control network. In fact, any field device conforming to one of these protocols can be used, within a process, to communicate with and be controlled by a distributed control system controller or other controller that supports the protocol, even if the field was made by a manufacturer different from the manufacturer of the distributed control system controller, on the other hand, there is now a movement within the process control industry to decentralize process control, and, thereby, to simplify the controllers of the process controller. distributed control system or eliminate the need for controllers of the distributed control system to an extensive degree.Decentralized control is obtained by making process control devices, such as valve positioners, transmitters, etc., perform a or more process control functions and by then communicating the data through the structure of the collective bar Pray for them to be used by other process control devices when performing other control functions. To implement these control functions, each process control device includes a microprocessor that can perform one or more control functions, as well as communicate with other process control devices using a standard and open communication protocol. In this way, field devices made by different manufacturers can be interconnected within a process control network to communicate with one another and to perform one or more process control functions, forming a control cycle without the intervention of a distributed control system controller. The all-digital, two-wire bus bar protocol currently promulgated by the Fieldbus Foundation, known as the FOUNDATION Fieldbus protocol ^ (hereinafter "Fieldbus"), is an open communication protocol that allows interoperability of devices made by different manufacturers and that communicate with each other through a standard busbar to perform decentralized control within a process. As noted earlier, the decentralization of process control functions simplifies and, in some cases, eliminates the need for a patented distributed control system controller which, in turn, reduces the need for a process operator to trust in which the manufacturer of the distributed control system controller changes or improves a control scheme that the controller of the distributed control system implemented. However, decentralized control also makes it difficult to perform diagnostics, such as process diagnostics, which are typically performed by the controller of the distributed control system. Performing regular diagnostics, such as device and process diagnostics, is very important, however, when using field devices such as fluid control valves in harsh environments in which, for example, ranges of temperature and pressure are widely variable. In these environments, substantial maintenance is necessary, including periodic preventive maintenance, maintenance due to breakage of the valve, and tests to verify that the valves are functioning properly. In a standard distributed control system environment, a computer (such as a personal computer) is coupled to the network and performs device diagnostics on, for example, a valve or a combination of positioner / valve, by means of sending a signal Diagnostic control to the positioner, which then forces the valve through a test stroke or test cycle associated with the diagnostic control signal. During this time, the computer measures the positions of the positioner and / or the valve, such as changes in the position of the valve, which occur in response to the diagnostic control signal and, after the same, perform the analysis on the outputs that were measured, to determine the operation condition of the valve or the device. positioner / valve. In a known diagnostic system for fluid control valves, such as pneumatically activated valves, a pressure sensor is provided for detecting the varying pressure at the inlet of a valve and a position detector is provided for detecting the pressure. shutter movement of a valve. The valve is operated through a test operation cycle by supplying a controlled variable pneumatic pressure to the inlet terminal of a pneumatic valve. During, for example, the test operation cycle of a dynamic scan, the valve plug moves through a desired range, normally from a fully open position to a fully closed position and is returned from the fully closed position to the completely open position. Alternatively, step tests can move the valve plug into a series of individual steps to test certain valve parameters. During the test operation cycle, the pressure detector provides an output signal that corresponds to the variable pressure at the valve inlet, and the position detector provides an input signal corresponding to the movement of the valve plug . The respective input or output signals of the air pressure in the actuator and the valve plug or the position of the valve stem are then processed to derive the data representing the variation in the pressure at the inlet of the valve. valve as a function of movement of the valve plug during the test operation cycle. The t is derived 8 load of the valve stem by means of multiplying the air pressure by the effective area of the actuator diaphragm. The diagnostic system receives the diagnostic commands and communicates the diagnostic information that was obtained from the detectors through a communication line to an external control console or the processor / computer. The external control console or the processor / computer requests a single diagnostic test and waits for a result while the diagnostic system performs the test. When the test is complete, the diagnostic system sends the result of the test to the external control console. Many different diagnostic tests are performed for each valve and a control system usually includes many valves, so that the time of the diagnostic test may be prolonged. As is also known, in a standard distributed control system environment, a computer such as a distributed control system controller performs the process diagnostics using, for example, a valve or a combination of positioner / valve, by means of send a diagnostic control signal to the positioner, which then forces the valve through a test sequence. In a standard distributed control system environment, device or process diagnostics can be performed without rewiring or reconfiguring the system to a significant degree, because the controller of the distributed control system or the external computer is already configured to control the determined points (or other inputs) of the different devices within the process and to measure the outputs of the device or other process parameters to implement a control strategy associated with the normal operation of the process. ' As a result, performing diagnostics in a standard distributed control system environment is really a matter of using the controller of the distributed control system or another external computer in a slightly different way to control one or more devices within the process, and use the controller of the distributed control system or another external computer to measure the process or device parameters. In this way, in the environments of the standard distributed control system, a centralized distributed control system controller or other centralized external computer, you can store and use the diagnostic routines to perform almost any device or process diagnosis and can be used These diagnostic routines without reconfiguring the process control network in any meaningful way. Unfortunately, due to the centralized nature of these diagnostic routines, they do not provide very detailed information about field devices. However, in a process control network that has distributed control functions, a centralized system controller is not configured, to the extent that it exists, to individually control all field devices within a process and is not configured to receive the data that corresponds to all the appropriate device or process parameters needed to perform the device and process diagnostics. Instead, different control-process cycles of the control strategy are implemented, through a number of communicatively linked devices that are located in distributed locations within the process control network. Typically, these devices are configured to use scheduled periodic communications to communicate the data necessary for the implementation of the specific control functions associated with a process control cycle and to communicate other data (such as changes of 'established point), using the aperiodic or asynchronous communications. As a result, have a process control network that has distributed control functions that are implemented using scheduled periodic communications, a host device can not send a strictly deterministic diagnostic control signal to a process control device while the system is configured to implement the normal control strategy, because the host device must use the asynchronous communications to send the diagnostic control signal and, therefore, has no way to control the precise moment at which the diagnostic control signal arrives (or the different portions of it) to the device being tested. In fact, when using asynchronous communications, a host device has no way of knowing when the diagnostic control signal (or a particular part of it) arrives at the input of the device being controlled. As a result, for a host device to send a deterministic diagnostic control signal to a device in a process control network having distributed control functions, the control configuration of the network must be reconfigured, which requires that the process be taken offline. In addition, process control devices that can perform self-diagnostics are typically limited to performing only internally encoded diagnostics within the device by the device manufacturer and, therefore, can not perform the routines or diagnostic tests generated by a device. guest or a user (which may include the routines developed by different manufacturers of the devices). This situation prevents a user from running the same test in all types I 12 different devices inside a plant. Still further, process control devices that perform self-diagnostics generally can not perform process diagnostics. Therefore, a guest device must be set up to perform the process diagnostics even on a system that has field devices that can perform some self diagnostics (ie, device diagnostics). As noted above, however, it is difficult for a host device to perform process diagnostics on a process control system that has distributed functions, because the control configuration must be reconfigured to allow the host to control a device. synchronous way. In addition, the use of the different control schemes during the process diagnostics could produce results that are erroneous or inaccurate with respect to the control scheme that is run during the normal operation of the process. Also, field devices with diagnostic capabilities have not been able to diagnose other field devices without local diagnostic capabilities.

COMPENDIUM OF THE INVENTION The present invention is directed to a method of a device for performing device and process diagnostics on and from a particular process control device within a process control network and, preferably, within a network Process control that has distributed control functions. In accordance with the present invention, a process control device stores and implements a diagnostic test routine (which can be a routine diagnostic device or process test) to perform diagnostics on that monitoring device. process without the need to reconfigure the control scheme associated with the process control network. As a result, the routine of the diagnostic test according to the present invention can be implemented, while a process is being controlled under essentially the same control strategy as that implemented during the normal operation of the process. In addition, a user can generate the routine diagnostic device or process test that implemented the process control device according to the present invention, on a host device and send it to the process control device before it is run the routine of the diagnostic test, which facilitates that the process control device implements any routine of the desired diagnostic test, including the routines provided by other manufacturers of the device. In accordance with one aspect of the present invention, a field device, which can be used in a process control system having a plurality of field devices coupled to each other by a two-wire, energized bus bar, includes. pneumatically operated fluid control valve, a positioner coupled by a pneumatic pressure line to the fluid control valve, to generate a pneumatic pressure that causes the fluid control valve to move to a position that fluctuates from a open position to a closed position and a position detector coupled to the positioner and to the fluid control valve, to detect the position of the fluid control valve. A pressure detector is coupled to the pneumatic pressure line to detect the pneumatic pressure that is applied to the fluid control valve and an electric to pneumatic transducer is coupled to the positioner by the pneumatic pressure line, to control the pneumatic pressure in the pneumatic pressure line as a function of an electrical signal. An electronic controller is coupled to the electric to pneumatic transducer, to the pressure detector, and to the position detector, and includes the control logic that determines the electrical signal that is based on the feedback signals that indicate a pressure detected by the detector. pressure and a position detected by the position detector and based on the control signal of the field device. further, a digital interface is coupled to the energized two-wire busbar, digital and to the electronic controller and includes a circuit to supply the energy that is derived from the energized busbar to the field device and a two-way communication circuit which receives the signals, including the control signal of the field device from the busbar and which transmits the signals indicating a state of the field device to the busbar. In accordance with another aspect of the present invention, a field device for use in a process control network having a plurality of devices communicatively coupled by a two-wire communication bus, all digital, includes a connector that it is connected to the two-wire busbar, all digital to facilitate all digital communication over the busbar, a memory that stores a diagnostic test routine that has a series of diagnostic test instructions, and a controller that performs the instructions of the diagnostic test stored in the memory, to implement a diagnostic test using the field device. The field device also includes a data collection unit that collects the diagnostic data that was generated during the diagnostic test on the busbar in an all digital format. Preferably, the controller includes a program language interpreter that is adapted to interpret a program language and the diagnostic test instructions are stored in the program language and are sent to the field device controller from the second of a program. plurality of devices through the busbar. Likewise, the diagnostic test instructions can perform a device and / or process diagnosis, as desired. If the diagnostic test instructions specify a process diagnosis, the data collection unit is adapted to receive the data generated by other devices during the diagnostic test. According to yet another aspect of the present invention, a field device for use in a process control network having a plurality of communicatively coupled devices by means of a busbar, includes, a memory that stores a test routine of diagnostic that has a series of diagnostic test instructions, a device driver that performs diagnostic test instructions stored in memory, to implement one. diagnostic test, a data collection unit that collects the diagnostic data that was generated during the diagnostic test and a communication unit that receives the instructions of the diagnostic test from the second of the plurality of devices through the bus bar , which stores the diagnostic test instructions that are received in the memory and that communicate the diagnostic data collected on the busbar. In accordance with yet another aspect of the present invention, for use in performing a process diagnostic test in a process control network having a plurality of devices that are communicatively coupled by a busbar, includes a memory that stores a process diagnostic test routine that has a series of diagnostic test instructions that must be implemented by the field device and a device driver that performs the process diagnostic test instructions stored in memory , to implement a process diagnostic test. The field device also includes a data collection unit that collects the diagnostic data that was generated by the field device during the process diagnostic test and that receives additional process diagnostic data from the second of the plurality of devices through the busbar. A communication unit within the field device communicates the collected diagnostic data and the additional process diagnostic data on the busbar after the process diagnostic test is completed.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a schematic block diagram of a process control network using the Fieldbus protocol; Figure 2 is a schematic block diagram of a Fieldbus device having a set of three function blocks therein; Figure 3 is a schematic block diagram illustrating the function blocks within some of the devices of the process control network of Figure 1; Figure 4 is a graph of the control cycle for a typical process control cycle within the process control network of Figure 1; Figure 5 is a timing chart for a macrocycle of a busbar segment of the process control network of Figure 1; Figure 6 is a schematic block diagram showing a digital field device having a two-wire positioner, energized per cycle, communicating digitally in two directions; Figure 7 is a block diagram illustrating a field device controller suitable for use in the control of the digital field device of Figure 6; Figure 8 is a flow chart illustrating a technique for performing diagnostic tests; Figure 9 is a flow diagram illustrating a diagnostic test protocol for testing the digital field device of Figure 6; Figures 10A, 10B, and 10C are graphical representations describing different diagnostic test signals that are used to perform device diagnostics, in accordance with the present invention; Figures 11A and 11B are graphs of the control cycle including a diagnostic data collection function block, in accordance with the present invention; and Figure 12 is a flow diagram illustrating a diagnostic test protocol for performing a process diagnostic test using the diagnostic data collection function block of Figure 11.

DESCRIPTION OF THE PREFERRED MODALITIES Although the device and process diagnostics of the present invention are described in detail, in conjunction with a process control network that implements the process control functions in a decentralized or distributed manner using a set of devices Fieldbus, it should be noted that the diagnostics of the present invention can be used with process control networks that perform distributed control functions, using other types of field devices and communication protocols, including protocols based on other bus bars of two wires and the protocols that support only analog communications or both analog and digital. In this way, for example, the device or process diagnostics of the present invention can be used in any process control network that performs distributed control functions, even if this process control network uses the HART communication protocols, PROFIBUS, etc. or any other communication protocols that currently exist or that may be developed in the future. In addition, the diagnostics of the present invention can also be used with standard process control networks that do not perform distributed control functions, such as HART networks, etcetera, and can be used within any desired process control device, including valves , positioners, transmitters, etc. Before discussing the details of the diagnostics of the present invention, a general description of the Fieldbus protocol will be provided, of the field devices configured in accordance with this protocol, and of the manner in which the communication occurs in a control network of process that uses the Fieldbus protocol. However, it should be understood that, although the Fieldbus protocol is a relatively new all-digital communication protocol that was developed for use in process control networks, this protocol is known in the art and is described in detail in numerous articles, brochures and specifications that are published, distributed, and available with, among others, the Fieldbus Foundation, a nonprofit organization with general offices in Austin, Texas . In particular, it describes in detail the Fieldbus protocol, and the way to communicate with, and to store data in devices that use the Fieldbus protocol, in the manuals that are titled Communications Technical Specification and User Layer Technical Specification of the Fieldbus Foundation, which are expressly incorporated herein by reference in their entirety. The Fieldbus protocol is an all-digital, two-way serial communication protocol that provides a standardized physical interface to a two-wire cycle or busbar that interconnects the "field" equipment such as detectors, actuators, controllers, valves, etc., located in an environment of instrumentation or process control, for example, a factory or a plant. The Fieldbus protocol provides, in effect, a local area network for field instruments (field devices) within a process installation, which makes it easier for these field devices to perform control functions at distributed locations throughout a process and that they communicate with each other before and after the realization of these control functions, to implement a strategy of total control. Because the Fieldbus protocol allows control functions to be distributed throughout a process control network, it reduces the complexity of, or completely eliminates the need for, the centralized process controller typically associated with a distributed control system. With reference to Figure 1, a process control network 10 using the Fieldbus protocol can include a host 12 connected to a number of other devices, such as a program logic controller (PLC) 13, a number of controllers 14, another host device 15 and a set of field devices 16, 18, 20, 22, 24, 26, 28, 30, and 32 by a two-wire Fieldbus collector loop or bar 34. The manifold bar 34 includes different sections or segments, 34a, 34b, and 34c, which are separated by the bridge devices 30 and 32. Each of the sections 34a, 34b, and 34c interconnects a subset of the devices attached to the bus 34 collector to facilitate communications between the devices in a manner that is described herein. Of course, the network of Figure 1 is only illustrative, there being many other ways in which a process control network can be configured using the Fieldbus protocol. Typically, a configurator is located in one of the devices, such as the. guest 12, and is responsible for the establishment or configuration of each of the devices (which are "ready" devices since each one includes a microprocessor that can perform the communication and, in some cases, the control functions) as the recognition when new field devices are connected to the collection bar 34, when the field devices are removed from the collection bar 34, which receive some of the data generated by the field devices 16-32, and which interface with one or more user terminals, which may be located on the guest 12 or on any other device that connects the guest 12 in any way. The collector bar 34 supports or allows two-way, purely digital communication and can also provide an energy signal to any of the devices that are connected to it, such as field devices 16-32. Alternatively, any of all 12-32 devices may have their own power supplies or may be connected to external power supplies by separate wires (not shown). Although in Figure 1 the devices 12-32 are illustrated as being connected to the busbar 34 in a standard busbar type connection, in which multiple devices are connected to the same pair of wires that form the segments 34a, 34b and 34c of the busbar, the Fieldbus protocol allows other device / cable topologies that include point-to-point connections, in the which each device is connected to a controller or a host by a pair of two separate wires (similar to typical 4-20 mA analog control systems), and tree or "spur" connections in which each device connects to a common point in a busbar of two wires which may be, for example, a junction box or a termination area in one of the field devices within a process control network. The data on the different segments 34a, 34b, and 34c of the busbar can be sent at the same or different speeds of impulse per second of communication, in accordance with the Fieldbus protocol. For example, the Fieldbus protocol provides a communication speed (Hl) of 31.25 Kbit / second, which is illustrated as being used by segments 34b and 34c of the busbar of Figure 1, and a communication speed of 1.0 Mbit / second and / or 2.5 Mbit / second (H2), which will typically be used for advanced process control, remote input / output, and high-speed factory automation applications and is illustrated as being used by the segment 34a of the busbar of Figure 1. Likewise, the data on the segments 34a, 34b, and 34c of the busbar can be sent in accordance with the Fieldbus protocol, using the voltage mode signaling or the signaling of current mode. Of course, the maximum length of each segment of the collecting bar 34 is not strictly limited, but instead, it is determined by the speed of the communication, the type of cable, the size of the wire, the power option of the busbar, etcetera, of each section. The Fieldbus protocol classifies the devices that can be connected to the bus 34 in three categories, namely, basic devices, master link devices, and bridge devices. The basic devices (such as devices 18, 20, 24, and 28 of Figure 1) can communicate, that is, send and receive communication signals on or from the collection bar 34, but they can not control or order nor the regulation of the communication that takes place in the collecting bar 34. The master link devices (such as devices 16, 22, and 26, as well as guest 12 of Figure 1) are devices that communicate over the bus 34 and that can control the flow and regulation of the signal communication in the bar 34 collector. Bridge devices (such as devices 30 and 32 of Figure 1) are devices that are configured to communicate over, and to interconnect individual segments or branches of a Fieldbus bus, to create larger process control networks. If desired, bridging devices can be converted between different data rates and / or different data signaling fos that are used in the different segments of the collection bar 34, can amplify the signals traveling between the segments of the bar 34 collector and pass only those signals intended to be received by a device in one of the segments of the busbar to which the bridge is coupled and / or may take other actions necessary to link different segments of the collecting bar 34. The bridge devices that connect the segments of the bus that operate at different speeds must have link master capabilities on the side of the lowest speed segment of the bridge. Guests 12 and 15, the program logic controller 13, and the controllers 14 can be of any type of Fieldbus device but, typically, they will be master link devices. Each of the devices 12-32 can be communicated on the collecting bar 34 and, importantly, can independently perform one or more process control functions using the data acquired by the device, from the process, or from a different device by means of communication devices in the collecting bar 34. Fieldbus devices can, therefore, directly implement portions of a total control strategy which, in the past, was accomplished by a centralized digital controller of a distributed control system. To perform the control functions, each Fieldbus device includes one or more standardized "blocks", which are implemented in a microprocessor inside the device. In particular, each Fieldbus device includes a resource block and can include zero or more function blocks, and zero or more transducer blocks. These blocks are referred to as block objects. A resource block stores and communicates device-specific data that corresponds to some of the characteristics of a Fieldbus device including, for example, a device type, a device revision indication, and indications of where other specific information can be obtained of device within a device memory. Although different device manufacturers can store different types of data in the block of a field device, each field device that complies with the Fieldbus protocol includes a resource block that stores some data. A function block defines and implements an input function, an output function, or a control function associated with the field device and, in this way, reference is made to the function blocks as input, output, and blocks of function. control function. However, other categories of function blocks, such as hybrid function blocks, may exist or may be developed in the future. Each input or output function block produces at least one process control input (such as a variable process from a process measurement device) or process control output (such as a valve position that is sent to a drive device), while each control function block uses an algorithm (which may be patented in nature) to produce one or more process outputs from one or more process inputs and control inputs. Examples of standard function blocks include analog input (AI), analog output (AO), voltage (B), control selector (CS), discrete input (DI) function blocks; Discrete output (DO), manual charger. (ML), proportional / derivative (PD), proportional / integral / derivative (PID), radio (RA), and signal selector (SS). However, there are other types of function blocks and you can define or create new types of function blocks to operate in the Fieldbus environment. A transducer block couples the inputs and outputs of a function block to local hardware devices, such as device detectors and actuators, to make it easier for the function blocks to read the outputs of the local detectors and to order the local devices that perform one or more functions such as moving a. valve member. The transducer block typically contains information that is necessary to interpret the signals that a local device sends and to appropriately control the local hardware devices including, for example, the information that identifies the type of a local device, the associated calibration information with a local device, etcetera. A single transducer block is typically associated with each input or output function block. Most function blocks can generate alarm or event indications based on previously determined criteria and can operate differently in different ways. Generally speaking, function blocks can operate in an automatic mode, in which, for example, the algorithm of a function block operates automatically; an operator mode in which the input or the output, for example, a function block, is controlled manually; an out-of-service mode in which the block does not operate; a cascade mode in which the operation of the block is affected from (determined by) the output of a different block. However, there are other modes of operation in the Fieldbus protocol. Importantly, each block can communicate with other blocks in them or in different field devices on the Fieldbus collection bar 34, using standard message formats defined by the Fieldbus protocol. As a result, the combinations of the function blocks (on the same or different devices) can communicate with each other to produce one or more decentralized control cycles. In this way, for example, a proportional / integral / derivative function block can be connected to a field device via the bus 34 to receive an output of an analog input function block in a second field device, to send the data to an analog output function block in a third field device, and to receive an output of an analog output function block as feedback to create a separate process control cycle apart from the distributed control system sonucleor . In this way, the combinations of the function blocks move the control functions out of a centralized distributed control system environment, which allows the multi-function controllers of the distributed control system to perform supervision or coordination functions or that they are eliminated completely. In addition, the function blocks provide a graphical structure, oriented by block for the simple configuration of a process, and allow the distribution of the functions among the field devices from different suppliers because these blocks use a consistent communication protocol . In addition to containing and implementing block objects, each field device includes one or more objects that include link objects, address objects, alert objects, and view objects. The objects e link define the links between the inputs and outputs of the blocks (such as the function blocks), both inside the field device, and through the fieldbus collector bus 34. The address objects allow the local address of the parameters of the function block for access by other devices, such as the guest 12 or the controllers 14 of Figure 1. The address objects retain the short-term historical data corresponding to some, for example, block parameter and report this data to other devices or function blocks by means of the bus 34 collector in an asynchronous manner. The alarm objects report the alarms and events on the collecting bar 34. These event alarms can be related to any event that occurs within a device or one of the blocks of a device. View objects are pre-defined groupings of block parameters that are used in the standard human / machine interface and can be sent to other devices to be viewed from time to time. With reference to Figure 2, a Fieldbus device is illustrated, which may be, for example, any of the field devices 16-28 of Figure 1, as including three resource blocks 48, three function blocks 50, 51 , and 52 and two transducer blocks 53 and 54. One of the function blocks 50 (which may be an input function block) is coupled through the transducer block 53 to a detector 55, which may be, for example , a temperature detector, an established point indication detector, and so on. The second function block 51 (which may be an output function block) is coupled through the transducer block 54 to the output device, such as a valve 56. The third function block 52 (which may be a control block function) has an address object 57 associated therewith for directing the input parameter of the function block 52. The link objects 58 define the block parameters of each of the associated blocks and the alert objects 59 provide alarm or event notifications for each of the associated blocks. The view objects 60 are associated with each of the function blocks 50, 51, and 52 and include or group the data lists for the function blocks with which they are associated. These lists contain the necessary information for each set of different defined views. Of course, Figure 2 is merely exemplary and other numbers of, and types of block objects, link objects, alert objects, address objects, and view objects can be provided in any field device. Referring now to Figure 3, a block diagram of process control network 10 describing devices 16, 18, and 24 as positioner / valve devices and devices 20, 22, 26, and 28 as transmitters, also illustrates the function blocks associated with the positioner / valve 16, the transmitter 20, and the bridge 30. As illustrated in Figure 3, the positioner / valve 16 includes a resource block (RSC) 61, a transducer block (XDR) ) 62, and a number of function blocks that include an analog output function block (AO), two proportional / integral / derivative function blocks 64 and 65, and a signal selector function block (SS) 69 . The transmitter 20 includes a resource block 61, two transducer blocks 62, and two analog input function blocks 66 and 67 (AI). Also, the bridge 30 includes a resource block 61 and a proportional / integral / derivative function block 68. As will be understood, the different function blocks of Figure 3 can operate together (by means of communicating on the collecting bar 34). ) in a number of control cycles and in Figure 3 the control cycles in which the function blocks of the positioner / valve 16, the transmitter 20 and the bridge 30 are located, are identified by means of a cycle identification block which it connects to each of the function blocks. In this manner, as illustrated in Figure 3, the analog output function block 63 and the proportional / integral / derivative function block 64 of the positioner / valve 16 and the analog input function block 66 of the transmitter 20 are connected., within a control cycle that is indicated as LOOP1, while the signal selector function block 69. of the positioner / valve 16, the analog input function block 67 of the transmitter 20, and the function block are connected. i proportional / integral / derivative 68 of bridge 30, in a control cycle that is indicated as L00P2. The other proportional / integral / derivative function block 65 of the positioner / valve 16 is connected within a control cycle indicated as L00P3. The interconnected function blocks forming the control cycle indicated as LOOP1 in Figure 3 are illustrated in more detail in the diagram of this control cycle which is described in Figure 4. As can be seen from the Figure 4, the LOOP1 control cycle is completely formed by the communication links between the analog output function block 63 and the proportional / integral / derivative function block 64 of the positioner / valve 16 and the analog input function block 66 of the transmitter 20 (Figure 3). The control cycle diagram of Figure 4 illustrates the communication interconnections between these function blocks using the lines joining the process and the control inputs and outputs of these function blocks. In this way, the output of the analog input function block 66 is coupled in a communicative manner, which can comprise a process parameter or process parameter signal, by means of segment 34b of the busbar at the input of the function block proportional / integral / derivative 64, which has an output comprising a control signal coupled communicatively to an input of the analog output function block 63. An output of the analog output function block 63 is connected, which comprises a feedback signal indicating, for example, the position of the valve 16, to a control input of the proportional / integral / derivative function block 64. The proportional / integral / derivative function block 64 uses this feedback signal together with the process measurement signal from the analog input function block 66 to implement the appropriate control of the A 63 function block. The internal connections can be made internally, indicated by the lines in the control cycle diagram of Figure 4, within a field device, as in the case of the analog and analog output function blocks. proportional / integral / derivative 63 and 64, the function blocks are within the same field device (eg, the positioner / valve 16), or these connections can be implemented on the two wire communication bus 34, using the standard fieldbus synchronous communications. Of course, other control cycles are implemented by other function blocks that are communicatively interconnected in other configurations. To implement and carry out communication and control activities, the Fieldbus protocol uses three general categories of technology that are identified as a physical layer, a communication "group", and a user layer. The user layer includes control and configuration functions that are provided in the form of blocks (such as function blocks) and objects within a particular process control device of the field device. The user layer is typically designated in a manner patented by the device manufacturer, but it must be able to receive and send messages in accordance with the standard message format that defines the Fieldbus protocol and can be configured by the user in standard ways. The physical layer and the communication group are necessary to make the communication between the different blocks of the different field devices in a standardized way, using the bar.34 collector of two wires and can be molded by the well-known communication model in Open System Inerconnect layers (OSI). The physical layer, which corresponds to layer 1 of the Open System Inerconnect, is fixed in each field device of the collector bar 34 and operates to convert the electromagnetic signals received by the Fieldbus transmission medium (the two-wire collector bar 34) into messages that can be used by the communication group of the field device. One can think of the physical layer as the collecting bar 34 and the electromagnetic signals present in the collecting bar 34 at the inputs and outputs of the field devices. The communication group, which is present in each Fieldbus device, includes a data link layer, which corresponds to layer 2 of the Open System Inerconnect, a fieldbus access sublayer, and a Fieldbus message specification layer, the which corresponds to layer 6 of the Open System Inerconnect. There is no corresponding structure for layers 3-5 of the Open System Inerconnect in the Fieldbus protocol. However, the applications of a Fieldbus field device comprise a layer 7, while a user layer is a layer 8, which is not defined in the Open System Inerconnect protocol. Each layer in the communication group is responsible for encoding or decoding a portion of the message or signal that is transmitted in the Fieldbus collector bus. As a result, each layer of the communication group adds or removes certain portions of the Fieldbus signal such as the preambles, the start delimiters, and the end delimiters and, in some cases, decodes the non-isolated portions of the Fieldbus signal, to identify where the rest of the signal or message should be sent, or if the signal should be discarded because, for example, it contains a message or data that is not inside the receiving field device. The data link layer controls the transmission of messages on the collection bar 34 and achieves access to the collection bar 34 in accordance with a deterministic centralized bus controller that is called an active link scheduler, which will be described in more detail later . The data link layer removes a preamble from the signals in the transmission medium and can use the preamble that was received to synchronize the internal clock of the field device with the incoming Fieldbus signal. Similarly, the data link layer converts the messages in the communication group into physical Fieldbus signals and encodes these signals with the clock information to produce a "synchronous series" signal having a suitable preamble for the transmission of the signal. bar 34 collector of two wires. During the decoding process, the data link layer recognizes the special codes within the preamble, such as start delimiters and end delimiters, to identify the start and end of a particular Fieldbus message and can perform a sum of verification to verify the integrity of the signal or of the message that was received from the collection bar 34, In a similar manner, the data link layer transmits the Fieldbus signals in the collection bar 34 by means of adding start and end delimiters to the messages in the communication group and placing these signals in the transmission medium at the appropriate time. The specification layer of the Fieldbus message allows the user layer (i.e., function blocks, objects, etc., of a field device) to be communicated through the collection bar 34 using a standard set of message formats and describes the communication services, the message formats, and the protocol behaviors that are required to construct messages that will be placed on the communication group and that will be provided to the user's layer. Because the Fieldbus message specification layer provides standardized communications for the user layer, the Fieldbus message specification communication services are defined for each type of object described above. For example, the Fieldbus message specification layer includes object dictionary services, which allows the user to read an object dictionary of a device. The object dictionary stores descriptions of the object that describe or identify each of the objects (such as block objects) of a device. The Fieldbus message specification layer also provides context management services, which allow the user to read and change communication relationships, which are known as virtual communication relationships (VCRs) that are described later in the present, associated with one or more objects of the device. Still further, the Fieldbus message specification layer provides the variable access services, the event services, the upload and download services, and the program invocation services, all of which are known in the Fieldbus protocol and , therefore, will not be described in more detail herein. The Fieldbus access sub-layer maps the Fieldbus message specification layer within the data link layer. To allow or facilitate the operation of these layers, each Fieldbus device includes a management information base (MIB), which is a database that stores virtual communication relationships, dynamic variables, statistics, timing schedules of the active link programmer, timing of execution execution of the function block and device labels and address information. Of course, you can access or change the information within the management information base at any time, using the standard Fieldbus messages or commands. In addition, a description of the device with each device is usually provided to give the user or host an extended view of the information in the VFD. A description of the device, which should typically be indicated to be used as a guest, stores the information necessary for the guest to understand the meaning of the data in the VFDs of a device. As will be understood, in order to implement any control strategy using distributed demodition blocks throughout a process control network, the execution of the function blocks must be precisely programmed, with respect to the execution of other function blocks in a particular control cycle. In the same way, communication between the different function blocks in the collector bar 34 must be precisely programmed, so that the appropriate data is provided to each function block before the block is executed. Now we will describe the way in which the different field devices (and the different blocks within the field devices) are communicated on the Fieldbus transmission medium, with respect to Figure 1. For the communication to occur, one of the link master devices in each segment of the bus 34 (eg, devices 12, 16, and 26) operates as an active link scheduler (LAS), which programs and controls actively communication in the associated segment of the collector bar 34. The active link programmer for each segment of the collection bar 34 stores and updates a communication schedule (an active link time) that contains the periods in which each function block of each device is programmed to start the activity of Periodic communication in the collector bar 34 and the length of time during which this communication activity should take place. Although there may be one and only one active active link programmer device in each segment of the bus 34, other link master devices (such as device 22 in segment 34b), can serve as active back-link schedulers and become active when, for example, the current active link scheduler fails. Basic devices do not have the capacity to become an active link programmer at any time. Generally speaking, communication activities on the collecting bar 34 are divided into repeating macrocycles, each of which includes a synchronous communication for each active function block in any particular segment of the collecting bar 34 and one or more asynchronous communications for one or more of the function blocks or active devices in a segment of the collecting bar 34. A device can be active, that is, send data to, and receive data from, any segment of the collecting bar 34, even if it physically connects to a different segment of the collecting bar 34, through the coordinated operation of the bridges and the active programmers of link in the bar 34 collector. During each macrocycle, each of the active function blocks in a particular segment of the collecting bar 34 executes, usually at a different time, but precisely programmed (synchronous) and, at another precisely programmed time, locates its data output in that segment of the collection bar 34 in response to a demand data command that was generated by the appropriate active link scheduler. Preferably, each function block is programmed to publish its output data shortly after the end of the function block execution period. In addition, the publication periods of the data of the different function blocks are programmed in series, so that there are no two function blocks publishing data in a particular segment of the collection bar 34 at the same time. During the time synchronous communication is not occurring, each field device is allowed, in turn, to transmit alarm data, view data, and so on, in a synchronous manner using symbolic driven communications. Periods are stored. of execution and the amount of time necessary to complete the execution of each function block, in the management information base (MIB) of the device in which the function block resides, while, as noted above, the periods for sending the demand data commands to each of the devices in a segment of the collecting bar 34 are stored in the management information base of the active link programmer's device for that segment. These periods are typically stored as compensation periods because it identifies the periods in which a function block must execute or send the data as compensation from the beginning of an "absolute link schedule start period", which all the users know about. devices connected to the bus 34 collector. To carry out communications during each macrocycle, the active link scheduler, for example, the active link scheduler 16 of bus segment 34b, sends a demand data command to each of the devices in segment 34b of the bus. bus, in accordance with the list of transmission periods that are stored in the active schedule of link. After rec. 'go a demand data command, a function block of a device publishes its output data in the collection bar 34 during a specific amount of time. Because each of the function blocks is typically programmed to run, so that the execution of that block is completed shortly before the block is programmed to receive a command of demanding data, the data that is published in response a demand data command should be the most recent output data of the function block. Nevertheless, if a function block is running slowly and has not closed new outputs when- it receives the requirement data command, the function block publishes the output data that was generated during the last run of the function block and indicates that the data that were published are old data that use a timestamp. After the active link scheduler has sent a demand data command to each of the function blocks in the particular segment of the collection bar 34 and during the periods in which the function blocks are executing, the active programmer of link can cause asynchronous communication activities to occur. To perform asynchronous communication, the active link scheduler sends a symbolic pass message to a particular field device. When a field device receives a symbolic pass message, that field device has full access to the collection bar 34 (or a second segment thereof) and can send asynchronous messages, such as alarm messages, address data, changes of established points of the operator, etc., until the messages are complete or until a "period of symbolic support" has expired. After this, the field device releases the collector bus 34 (or any particular segment thereof) and the active link scheduler sends a symbolic pass message to another device. This process is repeated until the end of the macrocycle or until the active link programmer has been programmed to send a demand data command to perform the synchronous communication. Of course, depending on the amount of message traffic and the number of devices and blocks coupled to any particular segment of the collection bar 34, not all devices will be able to receive a symbolic pass message during each macrocycle. Figure 5 illustrates a timing diagram describing the periods in which the function blocks in the bus segment 34b of Figure 1 run during each macrocycle of the bus segment 34 and the periods in which the buses occur. synchronous communications during each macrocycle associated with segment 34b of the busbar. In the timing of Figure 5, the time on the horizontal axis is indicated and the activities associated with the various function blocks of the positioner / valve 16 and the transmitter 20 (of Figure 3) are illustrated on the vertical axis. The control cycle in which each of the function blocks operates is identified in Figure 5 as an index designation. In this way, AIL00P1 refers to the analog input function block 66 of the transmitter 20, PIDL00p2 refers to the proportional / integral / derivative function block 64 of the positioner / valve 16, and so on. The execution period of the block of each of the function blocks that are illustrated is described by a cross shading box, while each programmed synchronous communication is identified by a vertical bar in Figure 5. In this way, in accordance with the timing of Figure 5, during any particular macrocycle of segment 34b (Figure 1), the aiLOOPI function block executes first for the period of time specified in table 70. Then, during the indicated period of time by means of vertical bar 72, the output of function block AIL00P1 is published in segment 34b of the busbar, in response to a demand data command from the active link programmer for segment 34b of the busbar. Similarly, tables 74, 76, 78, 80, and 81 indicate the execution periods of the function blocks PIDL00P1, | AIL00P2, A0LOOP1, SSL00P2, and pI ° LOOP3 'respectively (which are different for each of them). the different blocks), while the vertical bars 82, 84, 86, 88, and 89 indicate the periods in which function blocks PIDL00P1 'AIL00P2' AOLOOPl 'SSLOOP2' V PIDLOOP3 'respectively, publish the data in segment 34b of the busbar. As will be apparent, the timing chart in Figure 5 also illustrates the periods available for asynchronous communication activities, which may occur during the execution periods of any of the function blocks and during the time at the end of the macrocycle, during which no function block is executing and when no synchronous communication is taking place in segment 34b of the busbar. Of course, if desired, different function blocks can be intentionally programmed to execute at the same time and not all function blocks should publish the data in the busbar if, for example, no other device subscribes to the data. that were produced by a function block. The field devices may publish or transmit the data and messages about the collection bar 34, using one of the three virtual communication relations (VCRs) that are defined in the fieldbus access sublayer of the group of each field device. A virtual client / server communication relationship is used for braided communications, without programming, initiated by the user, one by one, between the devices in the collection bar 34. These twisted messages are sent and received in the order that was presented for transmission, according to their priority, without overwriting previous messages. In this way, a field device can use a virtual client / server communication relationship when it receives a symbolic pass message from an active link scheduler, to send a request message to another device in the bar. 34 collector. The requester is called the "client" and the device that receives the request is called the "server". The server sends a response when it receives a symbolic pass message from the active link scheduler. The client / server virtual communication relationship is used, for example, to perform the requests initiated by the operator such as changes of the established point, access and changes of the tuning parameter, alarm acknowledgments, and uploads and downloads Of the device. The virtual communication relationship of report distribution is used for braided communications, without programming, initiated by the user, from one to many. For example, when a field device with an event or address report receives a symbolic step from an active link scheduler, that field device sends its message to a "group address" that is defined in the access sublayer. Fieldbus of the communication group of that device. The devices that are configured to listen in that virtual communication relationship will receive the report. Fieldbus devices typically use the type of report distribution virtual communication relationship to send alarm notifications to operator consoles. A type of publisher / subscriber virtual communication relationship is used for buffered communications, from one to many. The dampened communications are unaa that store and send only the most current version of the data and, therefore, the new data write completely on the previous data. The outputs of the function block, for example, comprise buffered data. A field device of the "publisher" publishes or transmits a message, using the type of virtual communication relationship of the publisher / subscriber to all field devices of the "subscriber" in the collection bar 34 when the publisher's device receives a message from Demand data from the active link scheduler or from a subscriber device. The publisher / subscriber relationships are previously determined and defined and stored within the Fieldbus access sublayer of the communication group of each field device. To ensure the appropriate communication activities on the collecting bar 34, each active link scheduler periodically sends a time distribution message to all field devices that are connected to a segment of the collection bar 34, which facilitates the receiving devices to adjust their local application time so that they are in synchronization with each other. Among these synchronization messages, the clock time is maintained independently in each device, based on its own internal clock. Clock synchronization allows field devices to time-stamp data across the entire Fieldbus network to indicate, for example, when the data was generated. Additionally, each active link programmer (and another master link device) in each bus segment stores a "live list", which is a list of all the devices that connect to that segment of the bus 34 , that is, all the devices that respond appropriately to a symbolic message of passage. The active link scheduler continuously recognizes new devices that are added to a bus segment, by periodically sending probe node messages to addresses that are not on the live list. In fact, each active link programmer is required to scrutinize at least one address after completing a cycle of sending symbolic messages to all field devices on the live list. If a field device is present in the address that was scanned and receives the probe node message, the device immediately returns a probe response message. After receiving a probe response message, the active link scheduler adds the device to the live list and confirms it by means of sending a nodule activation message to the field device that was scrutinized. A field device remains in the live list as long as that field device responds appropriately to the symbolic pass messages. However, an active link programmer removes a field device from the live list if the field device does not use either the symbolic or immediately returns the symbolic to the active link programmer, after three successive attempts. When a field device is added to, or removed from the live list, the active link scheduler transmits the changes in the live list to all other link master devices in the appropriate segment of the bus 34, to allow Each link master device maintains a current copy of the live list. As noted above, the communication interconnections between the field devices and the function blocks thereof are determined by a user and implemented within the process control network 10, using a configuration application that is located at, for example, the host 12. However, after having been configured, the process control network 10 operates without any consideration for the device or process diagnostics and, therefore, interfaces with the guest 12 to perform standard I / O functions, but not diagnostic functions.

When a user wishes to perform diagnostics, the user can cause the guest 12 to send changes from the set point to, for example, the analog output function block 63 of the control L00P1 and record the feedback in the analog output function block 63 , using an address object associated with the analog output function block 63. However, to perform this type of communication, the guest 12 must use asynchronous communications (not published), which allow the guest 12 to access the the collecting bar 34 only when the guest 12 receives a symbolic pass message from an active link scheduler. As a result, the different parts of the diagnostic signal that the guest 12 generated might not reach the analog output function block 63 in the precisely determined periods (or the precisely programmed periods), which means that the The diagnostic signal that is received in the analog output function block 63 will have a shape that is determined, at least in part, by the communication backup record in the collection bus 34 at any particular time. For this reason, any diagnostic signal that is sent using asynchronous communications will not be strictly deterministic and, therefore, may not be very effective in performing diagnostics on a device or process. In addition, the guest 12 has no way of guaranteeing that the feedback data collected by the address objects will not be lost, due to overwriting, and so on. Also, host 12 has no way to control the mode of the other function blocks in L00P1, such as the proportional / integral / derivative function block 64, without changing the mode of that block in a specific manner. Until now, in order to ensure the complete and strictly deterministic diagnosis in a process, a user had to take the process control network 10 offline and reconfigure the communication interfaces in it, so that the guest 12 could send changes from the established point to the appropriate devices and receive the data that measured the appropriate devices through synchronous communications. However, as noted above, this procedure shuts down the process and requires an operator to reconfigure the process control network whenever the diagnostics are to be made, all of which is undesirable. In addition, the control that host 12 implemented during this diagnostic procedure is different from the control that implemented function blocks linked communicatively during the normal operation of the process and, therefore, the process data that was collected might not indicate the operation of the process while the process is being controlled in a normal way.

To overcome these disadvantages in, for example, a Fieldbus process control network, a device or process diagnostic procedure is stored in, and implemented from, a field device and can be used to perform device diagnostics and / or process on that device or using that device. The diagnostic procedure, which can be implemented as a function block, is configured to communicate with the function blocks or other components of the device in which it is located and to receive data, such as the -measurements of the device parameters. or other process parameters, for example, the collection bar 34, using synchronous periodic communications (for example, the virtual communication relationship of publisher / subscriber of the Fieldbus protocol). In this way, the diagnostic routine can deterministically control the device in which it is located and receive and store the data corresponding to a device or process parameter in a periodic manner. With reference to Figure 6, a schematic block diagram illustrates the digital field device 16 (of Figure 3) which is a combination of positioner / valve, two wires, low energy, two-way digital communication. The digital field device 16 includes a field device controller 102, an I / P transducer 104, a pneumatic relay 106, an actuator 108, and a valve 109, which are interconnected by different pneumatic and electric lines. The field device 16 receives the operation signals and transmits the status and data information digitally via the segment 34b of the two-wire busbar, preferably in accordance with the Fieldbus standard, and is, therefore, , a two wire positioner. Similarly, the field device 16 receives energy, mainly to drive the controller 102 of the device and the I / P transducer 104, by the bus segment 34b of the two-wire continuous cycle and is therefore a device energized per cycle. As illustrated in Figure 6, the I / P transducer 104 is electrically connected to the controller 102 of the device via a control line 110 of the I / P transducer and, in the illustrated embodiment, communicates with the controller 102. of the device using analog control signals. The I / P transducer 104 generates a pneumatic signal which causes the activation of the valve 109 and is very useful in the electromechanical devices for converting the electrical signals to air pressure for a pneumatic positioner. The actuator 108 controls the position of a valve member 114 (which may be a valve stem) of the valve 109, while a position detector 116 detects the position of the valve member 114 | and generates a signal. of feedback that is communicated to the controller 102 of the device by a signal line 117. This position signal can be used by the controller 102 of the device to control the operation of the field device 16, so that the I / P transducer 104 drives the pneumatic pressure in a manner that causes the valve member 114 to be in a desired position. The position and other feedback information can be stored in a storage unit or a memory of the controller 102 of the device and accessed externally by the busbar 34. As is standard, the field device 16 receives a supply of pressurized air from an external source (not shown) by a pneumatic line 118 which is connected to the I / P transducer 104 and the pneumatic relay 106. An input detector 120 typically placed between the external air source and the I / P transducer 104, measures the pressure of the pneumatic input supply in the pneumatic line 118 and sends this measurement to the controller 102 of the device. The I / P transducer 104 is connected to the pneumatic relay 106 via a pneumatic control line 122 and an I / P detector 124 is placed between the I / P transducer 104 and the pneumatic relay 106 to measure the pneumatic supply pressure in the line 122. Likewise, the pneumatic relay 106 is connected to the actuator 108 by a pneumatic activation line 126 and a relay detector 128 is placed between the pneumatic relay 106 and the actuator 108 to measure the pneumatic supply pressure on the line 126 The pneumatic lines 118, 122 and 126 are considered parts of a single pneumatic line interconnecting the transducer 104 and the valve 109. During operation, the controller 102 of the device controls the activation of the valve 109 by means of controlling the transducer I / P 104 to adjust a controlled valve that operates the pressure in the pneumatic control line 126. The controller 102 of the device sends a signal of trol to the I / P transducer 104 by the control line 110 of the I / P transducer to control an output pressure of the I / P transducer combination and relay 106 to be between about 3-100 psi (0.21-7.06 kscm ), which is applied to an actuator control input 108. The actuator 108 generates an output pressure that is applied to operate the valve 109. In this way, as is known, the I / P transducer 104 converts the electrical signals into a pneumatic air pressure signal. In U.S. Patent Number 5,439,021, entitled "Electro-Pneumatic Converter," issued to B.J. Burlage et al., August 8, 1995, which is incorporated herein by reference in its entirety, describes an example of an appropriate I / P 104 transducer. Likewise, the pneumatic relay 106, which serves as a pneumatic amplifier, is controlled by the I / P transducer 104 as directed by the controller 102 of the device, to increase the air pressure of the pneumatic activation signal line 126, a controlled amount. Thus, generally speaking, the pneumatic relay 106 supplies a controlled output pressure to a charging or operating device, such as an actuator or a piston, in response to a control signal from the controller 102 of the device. In U.S. Patent Number 4,974,625, entitled "Four Mode Pneumatic Relay," issued to S.B. Paullus et al., December 4, 1990, which is incorporated herein by reference in its entirety, describes a suitable relay. In the embodiment illustrated, relay 106 is a four-mode multifunctional pneumatic relay that can be configured for any combination of direct / spring, direct / proportional, reverse / spring, or inverse / proportional operation. In the proportional mode, the pneumatic relay 106 develops a pressure output that is proportional to a pressure or force input. In an on / off or spring mode, pneumatic relay 106 generates a constant pressure output, usually equal to the applied supply pressure, in response to the application of a defined range of force or pressure control inputs . In a direct mode of operation, the output pressure of the pneumatic relay 106 is increased with an increasing input signal. In a reverse operating mode, the output pressure of the relay decreases with an increasing input signal. The input detector 120, the I / P detector 124, and the detector 128 of the relay are pressure transducers that contain a signal converter pressure-to-electrical to convert a pressure signal to an electrical signal and supply feedback signals to the controller 102 of the device via a line 130. The I / P detector 124 is diagnostically useful for detecting faults of either the transducer I / P 104 or pneumatic relay 106, and to determine, for example, whether the fault is a mechanical failure or an electrical fault. The I / P detector 124 is also useful for detecting some system problems, including a determination of whether the air pressure input to the digital field device 16 is sufficient. As a result, the I / P detector 124 allows the status of the I / P transducer 104 and the pneumatic relay 106 is quickly diagnosed, so that these devices can be quickly replaced, if necessary. In one embodiment, a valve 109 suitable for use in the digital field device 16 is a valve and actuator assembly that uses a spring and diaphragm actuator in a slide valve stem which is used in an analog device that is described in FIG. U.S. Patent No. 4,976,144, entitled "Diagnostic Apparatus >.; and Method for Fluid Control Valves, "issued to WV Fitzgerald, December 11, 1990, which is hereby incorporated by reference in its entirety In this exemplary embodiment, a pressure signal of approximately 3 psi is provided (0.21. ksc) to the actuator 108, in response to a signal of approximately 4 mA which applies the controller 102 of the device to the I / P transducer 104, resulting in a corresponding pressure in the pneumatic activation signal line 126 which is insufficient to move the valve 109 from a fully open position If the controller 102 of the field device changes the control current that is applied to the I / P transducer 106 to approximately 20 mA, the I / P transducer 104 generates a pressure in the pneumatic activation line 126 about 15 psi (1.06 kscm), which forces the valve 109 to a fully closed position, different positions of the valve 109 are obtained between the position Fully open ion and completely closed position, through the operation of the controller 102 of the device controlling the input current that is applied to the I / P transducer 104 in the range of 4 mA to 20 mA. The controller 102 of the device performs relatively high speed digital communications to receive control signals and to transmit position and pressure information to an external processor or workstation in the process control network 10 via the bus 34. The controller 102 of the device includes storage or memory for storing the results of the multiple diagnostic tests, so that the pertinent data is available for analysis. Diagnostic operations, such as device diagnostics, are generally in the form of software program codes and are typically coded, stored and executed in the controller 102 of the device of the field device 16, in combination with the codes of the program running on an external device such as a processor or host workstation 12. A diagnostic evaluation of the valve device 109 can be performed through the operation of the controller 102 of the device controlling the input current which is applied to the I / P transducer 104 in a sufficient range to test the valve 19 between fully open and fully closed positions. During the diagnostic evaluation of the device, the outputs of the input detector 120, the i / P detector 124, and the detector of the relay 128 are verified by the controller 102 of the device, to detect the pneumatic pressure in the pneumatic lines 118, 122 and 126, respectively, are used for the analysis. The output of the position detector 116 is also verified to detect the position or movement of the valve stem 14, which corresponds to a position or movement of a valve plug (not shown), inside the valve 109 In this way, a test operation cycle of the valve 109 is performed under the control of the controller 102 of the device by means of applying a controlled variable current to the I / P transducer 104, detecting the pressure within the pneumatic lines 118, 122 and 126 and detecting the position of the valve stem 114, using the position detector 116. In this way, the controller 102 of the device simultaneously receives the time-varying electrical signals indicating the pressures in the illustrative locations and the valve position 109, and can use these signals to determine any number of diagnostic parameters of the device in any way that is want or that is known. Conventional field devices typically do not include a position detector, such as detector 116, and do not use the results of the position detector for diagnostic evaluations. As well, conventional field devices do not include detectors such as the input detector 120, the I / P detector 124, or the relay detector 128 for measuring the pressure in the pneumatic control and for converting the pressure signal to an electrical signal for facilitate diagnostic evaluation. However, these detectors and, in particular, the I / P detector 124, improve the diagnostic capabilities by facilitating the location of the fault, error or defect conditions in the field device 16. In particular, the I / P detector 124 helps in the differentiation between valve faults 109, other faults in field device 16, and external faults to field device 16, including faults of the pneumatic line feeding field device 16 The I / P detector 124 is also useful for performing a diagnostic test to determine the operational status of the I / P transducer 104, the pneumatic relay 106, the field device 16 and the process control system 10 in general. In one embodiment, the I / P transducer 104 and pneumatic relay 106 are tested using a diagnostic test procedure that drives the I / P transducer 104 to be fully open to measure the complete air pressure that is provided to the valve 109 While the I / P transducer 104 is opened, the I / P detector 124 constantly measures the pressure in the pneumatic control line 122. If the pressure starts to decrease, the test indicates that the air supply may be insufficient . An additional diagnostic test of the sufficiency of the air supply is performed by pumping the valve 109 by applying an oscillatory signal to the I / P transducer 104 so that the valve 109 starts a suction action with respect to the supply of air and then measuring the maximum flow and maximum pressure values using the I / P detector 124. As illustrated in Figure 7, the controller 102 of the device includes a microprocessor 140, an interface 142, an isolation cycle 144 of the busbar, a plurality of storage devices- such as random access memory (RAM) 146, a read-only memory (ROM) 148 and a non-volatile random access memory (NVRAM) 150, and a plurality of devices signal processing such as an analog / digital converter 152, a digital / analog converter 154 and a multiplexer 15fi. Interface 142 (which is a bus connector) is a circuit that performs serial-to-parallel protocol conversion and parallel-to-serial protocol conversion, and is used to aggregate assembly information to conformance data packets with any desired protocol definition, such as the Fieldbus protocol. The isolation circuit 144 of the busbar is a circuit that is used to convert a two-wire media communication signal in the bus 34 to a digital representation of the communication signal and supplies the energy received from the bus 34 collector to other circuits in the controller 102 of the device, as well as to the I / P transducer 104. The isolation circuit 144 of the busbar can also perform wave and signaling formation in the bus 34. The analog / digital converter 152 is connected to the transducers such as the position and pressure transducers of the position detector 116 and the pressure sensors 120, 124 and 128 of Figure 6, as well as to any other desired analog input devices . Although the analog / digital converter 152 may have a limited number of input channels, the multiplexer 156 may be used to allow it to be displayed on multiple signals. If desired, multiplexer 156 may include a bank of amplifiers that connect between signal lines 117 and 130 (Figure 6) to amplify the position, pressure and other feedback signals that are sent thereto. The digital / analog converter 154 performs the digital-to-analog conversion in the signals developed by the microprocessor 140 to send them to the analog components, such as the I / P transducer 104. In a typical diagnostic test application, the controller 102 generates an output test signal of 0-30 mA to the I / P transducer 104 in, for example, a programmed feed, a step change, a form of on / off (or otherwise desired), to operate the valve 109 over a certain range - prior to pneumatic pressures, and receive the. output signals of the diagnostic test developed by the pressure input detector 120, the I / P detector 124, the detector of the relay 128 and the position detector 116. The specific test procedures can be specified in, and they are generally initiated externally to the field device 16 using an input / output device such as a workstation, although the procedures (and the necessary information, associated therewith) can also be input directly to the controller 102 using a device input such as a keyboard. If desired, however, the test procedures can be stored in the controller 102. Similarly, the information of the diagnostic test result that was collected or that occurred in the controller 102 of the field device was it typically transfers to an external input / output device, although this information can also be displayed directly from the controller 102 of the device using, for example, a CRT display or a printer. The field device 16 performs diagnostic test operations, such as device or process diagnostics, using a program language interpreter embedded within the controller 102, which interprets commands such as those requesting the execution of the steps of the diagnostic process. The language interpreter is preferably implemented in a program code stored in PROM 148 and executed in microprocessor 14.0. In some embodiments, a test definition or procedure (diagnostic) is downloaded on or before the time at which the procedure is to be run and is stored in, for example, the random access memory 146 for execution by the microprocessor 140. In a typical mode, some diagnostic functions are internally encoded within the PROM 148 and other functions are downloaded, allowing the design and implementation of new diagnostic tests, without modifying the permanent software or internally encoded in the device 16. Although describes the language interpreter within the context of the performance of the process diagnostics or the device diagnostics in a Fieldbus device (such as a Fieldbus valve), the language interpreter can be implemented in any type of embedded controller, allowing the same the use of common diagnostic test operations in any another type of embedded driver. During operation, the field device 16 receives instructions via the collection bar 34 from an operator console or a guest workstation 12 in the process control network 10. The language interpreter running in the controller 102 of the device, interprets the instructions and executes the operations that define the instructions. In an illustrated mode, the definition of language in an Interface Command Table is described. of the User shown in Table 1, as follows: TABLE 1 In this diagnostic language specification, a user can use a command name to specify the command for execution. A comment line is any line that starts with two diagonals (//), in accordance with the standard C / C ++ rule. A label is any word followed by a colon. A diagnostic test procedure can be defined in an operator console, such as in host 12, which generates a sequence of instructions, in accordance with the language definition designed to implement the diagnostic test procedure. Then the operator's console transmits the instruction sequence, encoded in the interpretive language via the collector bar 34 to the digital field device 16 using, for example, asynchronous communications in the Fieldbus protocol. The language interpreter running in the controller 102 of the device stores the received instructions, and interprets the instructions sequentially, to control the valve 109, as indicated by the instructions for, by means of the same, performing the diagnostic test. The diagnostic test procedures may, for example, control the field device 16 to repeatedly stagger the valve 109, move the valve 109 up or down, move the valve 109 a selected amount in a selected direction, and so on. The diagnostic test procedure also controls the collection of data from the detectors in the field device 16 (as well as from other devices), and controls the transmission of data to the control console or host work station 12, by means of the bus 34 collector. Of course, if desired, the diagnostic test procedures implemented by the instructions provided to the controller 102, may also process the received data to determine the diagnostic results, and may send these results to the host 12, or to another deployment device. visual. In this way, the interpreter of the diagnostic language inside the controller 102 of the device controls the operation of the device. 16 of field, in accordance with the instructions programmed to enable diagnostic test procedures that will be defined external to the device 16 of the digital field, in such a way that the diagnostic tests can be defined and modified freely, without the modification of the device 16 of countryside. In the same way, new diagnostic control procedures can be developed and sent to the field device 16, after the field device 16 has been installed in the process control network 10. If desired, however, the device 16 may alternatively or alternatively implement the device and / or the process diagnostic test instructions stored in the device, at the time of manufacture or at some other time. A control console (such as host 12) typically includes diagnostic development tools, such as editors and language simulators to develop the control routines in the diagnostic language for execution by the field device 16. The control console also typically includes analysis tools for analyzing the data that is received from the field device 16 via the bus 34. For reasons of integrity, the diagnostic program codes of the example are illustrated in interpretive language as follows, to control valve 109: Program Code (1) Definition of Static Test SAMA // CYCLE 0 TO 100% 3 TIMES Data Speed 1 CYCLE: Cycle 3 Move Absolute 0.0 Pause 10000 Move Absolute 100.0 Pause 10000 End of Cycle // MOVE AT 50% INCREASE 4 TIMES Move Absolute 50.0 Pause 10000 Set Increment 10.0 UP: CYCLE 4 Increment Up Pause 10000 End of Cycle // DECREASE 8 TIMES DOWN: Cycle 8 Increase Down Pause 10000 End of Cycle // INCREASE 4 TIMES UP2: Cycle 4 Increment Top Pause 10000 End of Stop Cycle (2) Definition of Step Change Test Data Speed 1 Move Absolute 50.0 Pause 10000 Move Absolute 60.0 Pause 10000 Stop (3) Definition of Staggered Ramp Test Data Speed 1 Move Absolute 50.0 Set Increment 0.5 // INCREASE AT 0.5 FOR 10 TIMES UP1: Cycle 10 Increase UP Pause 10000 End of Cycle // DECREASE AT 0.5 FOR 10 TIMES ABAJOl: Cycle 10 Increase Down Pause 10000 End of Cycle Set Increment 1.0. // INCREASE IN 0.5 FOR 10 TIMES UP2: Cycle 10 Increase Top Pause 10000 End of Cycle // DECREASE IN 0.5 FOR 10 TIMES DOWN2: Cycle 10 Increment Down Pause 10000 End of Cycle Set Increment 2.0 // INCREASE TO 0.5 FOR 10 TIMES UP3: Cycle 10 Increment Top Pause 10000 End of Cycle // DECREASE IN 0.5 FOR 10 TIMES ABAJ03: Cycle 10 Increase Down Pause 10000 End of Stop Cycle (4) Definition of Step Study Test Data Speed 1 // INCREASE, DECREASE, DOWN, UP, AFTER INCREASE THE SCALE SIZE AND // REPEAT UNTIL CHANGES ARE DETECTED. Set Increment 0.5 'Increase Up Pause 100 Increase Down Pause 100 Increase Down Pause 100 Increment Up Pause 100 Set Increment 1.0 Increase Up Pause 100 Increase Down Pause 100 Increase Down Pause 100 Increment Up Pause 100 Set Increment 2.0 Increase Above Pause 100 Increase Below Pause 100 Increase Below Pause 100 Increment Above Pause 100 Set Increment 5.0 Increase Above Pause 100 Increase Below Pause 100 Increase Below Pause 100 Increment Above Pause 100 Stop The first test (1) identified above cycles three times, performs four steps from the middle open position, decreases eight times and increases four times. The second test (2) performs a step change from 50 to 60 percent of the absolute position of the valve. The third test (3) performs three cycles of a stepped ramp waveform, starting at 50 percent of the absolute position of the valve. The fourth test (4) repeats a series of steps with increasing magnitudes, until a change in the valve is detected. In these routines, the controller 102 of the field device implements a Conditional pause to stop recording, and sets a bit in a storage location to indicate where a test stops. Controller 102 of the field device also implements a Branch / IR A statement, a Cycle declaration forever, and a forced stop when an out-of-service flag is established. The pauses are synchronized with servo execution times, in such a way that the test does not get out of sync with the valve.

The illustrative program code represents only a few examples of the types of diagnostic tests that can be performed by the field device 16, there being many other diagnostic tests that can be performed by program instructions provided to the field device 16 including, by example, a static cycle test in which the valve 109 moves 10 percent up, 10 percent down, 10 percent up, 10 percent down, and so on during a plurality of cycles. In the same way, any diagnostic measurements of the device can be made, including,. for example, simple measurements of valve travel, or of pressures within device 16, as revealed by detectors 116, 120, 124 and 128 and / or any desired parameters arising from these or other measurements, including, for example, (1) a dynamic error band, which is a travel plane (e.g., the output of the position detector 116) against the input (e.g., the control signal sent to the controller 102), (2) a plane of the impulse signal (which is the output of the controller 102, as transmitted to the transducer 104 I / P) against a pressure measurement, (3) a plane of the pulse signal against the input signal, (4) output signal, which is a plane of travel against the signal of impulse, (5) valve identification signal, which is a plane of pressure against travel, and so on. Of course, the pressure signals that are specified in these tests can be any desired pressure signals, such as those that are measured by any of the detectors 120, 124 and / or 128. Although the diagnostic language and the interpreter of the The diagnostic language is implemented conveniently in a process control network 10, using Fieldbus communications for communication with a digital field device 16 in the form of a two-wire positioner, energized by cycle, two-way, digitally communicated, the language interpreter can be implemented in other modalities. For example, the interpreter of the diagnostic language can be implemented in any embedded controller that communicates using any desired communication technology such as digital, analog, optical and the like. In addition, although the interpreter of the illustrated diagnostic language communicates in accordance with the standard Fieldbus protocol, alternative embodiments of the diagnostic language interpreter can be implemented in an embedded controller that communicates using other communication protocols including, for example, the HART protocol, Profibus, etc., and in systems that use other bus bars apart from those of two wires, such as systems that use four-wire bus bars, in the same way, the interpreter of the diagnostic language can be implemented and used in other types of valves including, for example, electronic and hydraulic valves, as well as in other types of devices in addition to valve devices, on the other hand, although the diagnostic language and interpreter of the diagnostic language are described as defining a set of particular instructions, other set can be implemented s of instructions, in accordance with the specifications of the embedded controller, within which the language and interpreter are defined. Of course, both the device and the process diagnostic tests may be performed by issuing a command that requires one or more specific diagnostic test procedures in an operator console, such as the host work station 12. In the illustrated embodiment, the diagnostic test procedures are implemented in two software program codes. A first code is executed in a processor external to the field device 16, for example, in the working station 12 host, to create or initiate a diagnostic test, and to receive the collected data and perform analyzes on them, while a second code is executed in the controller 102 of the device to implement a diagnostic test stored therein, or provided by the host 12, in the form of program instructions. In contrast, diagnostics in a conventional control system network are performed only by executing the software in a processor of a control console. Many advantages are obtained by running diagnostic tests at the field device level, rather than at a control console level. For example, the diagnostic test can be performed in parallel, and can be distributed among many field devices, by running these tests at the device level, in the same way, you can perform a more accurate test on networks of process control having distributed control functions, such as in the Fieldbus protocol, where a host may not be able to deterministically control the operation of the field device, due to the fact that the host must communicate with the field device of an asynchronous tracker to perform a diagnostic test. The implementation of digital communication in two directions, defined by the Fieldbus protocol, is highly convenient to improve the speed of diagnostics, both through an increase in data throughput, and by facilitating the parallel execution of diagnostics. between a plurality of field devices. Using the Fieldbus protocol, regularly scheduled messages are transferred to previously programmed times, and unscheduled messages, including diagnostic and data messages, calibration information and other information such as status indications, are transferred when the messages or data are ready, and the collector bar 34 of the field device is not otherwise occupied. Diagnostic request messages are received by target field devices, and field devices perform diagnostic tests asynchronously with respect to the operations of other field devices. When a diagnostic test operation is complete, a field device returns a response, such as data from. result, when the collector bar 34 of the field device is available. In accordance with the above, as noted above, a plurality of field devices can perform diagnostic tests in parallel. Referring now to Figure 8, a flow diagram 200 illustrates a technique for performing diagnostic tests within the field device 16. In a step 202, the field device 16 receives a request to perform a sequence of instructions that implement one or more diagnostic tests. Of course, the host station 12 can broadcast those requests to any or a multiplicity of field devices simultaneously, and allows each field device to collect diagnostic data in parallel. If a multiplicity of field devices are performing tests simultaneously, the station 12 work can collect data over a range of spread so quickly time as the diagnostic tests are performed, and the results are made available on the bar 34 bus by the individual field devices. Conventional devices that use a single set of wires to communicate with each field device only have access to only one field device at a time, and only perform a single test for the single field device at a time. In a step 204, the field device 16 performs a series of instructions to implement the one or more diagnostic tests as instructed by the request. Of course, as noted above, the instructions can be stored in the memory of the field device 16, or they can be provided to the field device via the host 12 by, for example, asynchronous communications. While the test is being implemented, one or more parameters such as valve travel, pressure, etc., are measured in parallel. In this way, while conventional field devices typically receive a command for a single diagnostic test measurement, they perform measurement serially, and respond to the request with a single measurement value, due to the bandwidth of limited communication, and the lack of storage capacity in these field devices, the device or field 16 can receive a request for a plurality of tests, using a flexible test protocol, can perform the plurality of tests, and then respond with. the results collected during the tests. In a step 206, the field device 16 stores the parametric results of the plurality of tests measured for each of the diagnostic tests in a memory and, in a step 208, transmits the data to the external request devices. Digital communication of two wires, in two directions, in accordance with the standard Fieldbus, substantially improves the performance of the test result of the digital field device 16. In fact, digital communications using the Fieldbus protocol improve the transmission time by approximately thirty times over HART systems, so that when the Fieldbus protocol is used to perform diagnostic tests on multiple field devices in parallel, The amount of diagnostic test time is greatly reduced for a process control network that includes many field devices. Whereas conventional field devices typically have a separate pair of wires that connect each field device to a network, such that each field device has exclusive access to the wires, in the illustrated embodiment, the results of the tests of Diagnostics are transmitted to the operator's console or to the host work station 12, through the bus 34, using the standard Fieldbus protocol, which reduces the amount of wire required to communicate with the host 12. As will be understood , during a diagnostic test procedure, the microprocessor 140 controls the 154 D / A converter to supply a variable control signal to the 104 G /? transducer. For each particular control signal value, and sampling time, the microprocessor 104 instructs the converter 152 A / D to measure the related electrical pressure and / or position signals, revealed by the detectors 116, 120, 124 and 128 ( as well as any other signals from other detectors). As the microprocessor 104 directs the controller 102 of the field device through an operation measurement cycle, the pressure and travel information of the valve is accessed by the controller 102 of the device, and is. process or store. Frequently collected data is stored in RAM 146, and communicated to an external device, such as a host work station 12, often for subsequent processing, analysis and visual display. Of course, if desired, the microprocessor 140 can also perform analyzes. For example, the pressure information measured by the detector 128 of the relay, and the position information measured by the position detector 116, can be analyzed in combination to determine the change in the diaphragm pressure of the valve as a function of the valve position. Similarly, one can analyze each of the "pressures measured by the input detector 120, the detector 124 I / P and the detector 128 of the relay, in combination with the position measured by the position detector 116, to generate a Deflection cycle showing a complete analysis of the operation of valve 109, including linearity, hysteresis and range characteristics. Referring to Figure 9, a flow chart 300 illustrates a diagnostic test protocol implemented in the field device 16 to perform a diagnostic test. An operator generates a sequence of diagnostic instructions in an operator console, such as the work station 12, and transmits the diagnostic instructions to the field device 16 which stores these instructions in memory. Alternatively, or in addition, the diagnostic instructions can be stored in the memory of the field device 16 during the manufacture of the device. In one step 302, the field device 16 receives a diagnostic command by the collector bar 34 of the field device. If desired, the diagnostic command may be in the form of instructions in an interpretative diagnostic language, coded for execution in the controller .102 of the field device, or it may be an instruction to initiate instructions already stored inside the device. The controller 102 of the device executes the different instructions to cause the control elements in the digital field device 16 such as the transducer 104 I / P, and the trigger 108, to manipulate the valve 109, and to cause the detectors as the input detector 120, the detector 124 I / P, the detector 128 of the relay and the position detector 116, perform the measurements. The control instructions may also include instructions to process the measurements and format the data for presentation to a user. The additional instructions may cause the controller 102 of the field device to send processed or formatted data to the requester, via the collector bar 34 of the field device. In a step 304, the digital field device 16, after the request, performs a test procedure in which, for example, the valve is exercised from a fully closed to a fully open state, and then back to a fully closed state. closed. In the same way, the digital field device 16 can, after the request, perform a plurality of step tests including, for example, a one-step movement and analysis, and a ten step movement and response measurement. . A stepped ramp test can also be used, and involves a series of steps from a light opening to a large opening in the valve, such as a ramp ranging from 10 percent to 90 percent in steps of, for example , increases of 10 percent. A stepped study involves opening the valve in previously defined steps, such as 1 percent, 2 percent, 5 percent and 10 percent, moving the valve in a first direction, a specified step size, stabilizing, and then moving the valve in a second direction to the specified step size. In a step 306, the physical configuration of a diagnostic test is established, by means of commands that are communicated to the digital field device 16. The variables of the physical configuration include a pulse signal applied to the trigger 108, a pressure setting applied to the 104 I / P transducer, as well as trigger pressure and a reading of the valve travel. The variables of the physical configuration can be established as independent test variables in some diagnostic tests, and inspected as dependent parameters in other tests. In a step 308, the field device 16 measures parameters previously determined for a particular physical test configuration. For many diagnostic tests, many parameters are measured for a single test configuration. Typical parameters that are measured using a single test configuration include the valve position, the process variable, the actuator air pressure, the supply pressure, the impulse signal, the transducer set point, and the I / P air pressure, to allow the determination of, for example, the valve identification signal, the output signal, the dynamic error band, the impulse against pressure, and the trip against the amplitude of the signal of entry. In a step 310, the field device 16, through the operation of the controller 102 of the device, stores the multiple parameters for a single test configuration in, for example, RAM 146. In a step 312, they communicate the data to the host 12 or another device. If you are going to perform the test using a different diagnostic test configuration, the field device 16, through the operation of the controller 102 of the device in a conditional step 314, turns back to step 306 to modify the test configuration. The diagnostic tests in the illustrated field device 16 are substantially improved compared to conventional field devices, in part through improvements in the structure of the diagnostic protocol, partly through improvements in communication, and in part through the implementation of additional detectors in the field device 16. Improvements in the structure of the diagnostic protocol enable the field device 16 to measure multiple parameters for a single test configuration. The distribution of diagnostic control operations to the field devices allows the diagnostic tests to be completely controlled, after the request, inside a device. field, in such a way that multiple requests can be made to multiple field devices, with the individual field devices controlling the diagnostic tests independently and in parallel with each other. Improvements in the structure of the diagnostic protocol also conveniently allow test procedures to be modified externally to the field device by means of programming changes. In accordance with the above, new diagnostic capabilities can be added, and mass changes can be made in diagnostic operations, without modifying the field device. Modifying a field device is highly convenient due to the tremendous expense of stopping a process line. Improvements in communication allow the field device 16 to measure multiple parameters for a single test configuration. Conventional field devices receive a request in the communication lines that are dedicated to a specific field device, establish a test configuration in accordance with the specifications of the request, and return a single test measurement, in accordance with the request . A subsequent measurement is made under the same test configuration, by repeating the step, including the redundant step of establishing the test configuration. The improved communications of the illustrated field device 16 conveniently allows the diagnostic testing of multiple devices in parallel, increasing the performance of the diagnostic test. In addition, enhanced digital communications allow a plurality of data types, where analog communications (of conventional field devices) do not. Although the invention has been described with reference to different embodiments, it will be understood that these embodiments are illustrative, and that the scope of the invention is not limited thereto. Many variations, modifications, additions and improvements of the described modalities are possible. For example, field device 16 is but an illustration of a suitable combination of control valve and actuator. Other suitable types of valve include slide stem, rotary plug, rotary ball, butterfly, eccentric disc valves, as well as other known valve types. Other suitable activators include spring and diaphragm actuators, spring and piston, double acting piston, hydraulic, electrohydraulic, electric or other known activator types, using a rod valve whether rotating or sliding. In this way, the field device 1S is merely illustrative of different types of positioners, or other devices for controlling an activator and valve to modulate the energy. On the other hand, the field device in which the diagnoses of the present invention are used or located may be a device other than a valve including, for example, a pump controller, a variable speed transmission, etc. Still further, field device 16 is not limited to operation in accordance with the Fieldbus standard, but may also be applied to other digital communication standards including HART, ORLDFIP, LON ORKS, Profibus and the like. Of course, the device and process diagnostic tests can be stored in the controller 102, in the form of function blocks or other software, and can be made in such a way that these diagnostic tests are accessible to the public, using any host device, such as a personal computer, in such a way that they can, implement these tests without requiring much knowledge on the part of the user. In one embodiment, one or more easily accessible diagnostic routines are stored in the device (e.g., device 16) and can be executed by issuing a single command from a host, specifying which test is to be executed. All data necessary for the test is stored in the device, and all output data collected for the test is sent to the host after the test is complete. Generally speaking, you can order that "public" device and process diagnostics write to the transducer blocks to perform the movement of, for example, valve components, and to read and store the data produced by the detectors, using a trend direction block in the Fieldbus protocol. Because all the information required by the host is located in the device description of the field device, no proprietary knowledge is required to implement any of these public diagnoses. With the use of these public diagnoses, the operation of a field device can be compared with the operation of any other field device made by other manufacturers, which has the same diagnoses in it. The exemplary waveforms used in these public diagnostics are illustrated in Figures 10A-10C. As indicated in Figure 10A, a public diagnosis can cause the valve 109 to move in a ramp fashion in steps in the direction of opening, at individual steps of, for example, one percent for a particular number of steps (eg. example, five steps), and then moves as a ramp in steps in the closing direction, at individual steps of one percent, until the value or initial position of the valve has been reached, preferably one step The new set point is instantaneous, ie, no speed limit is in effect, and the delay time at each new set point is fixed, and is determined by the size and response characteristics of the valve / actuator device. Alternatively, as indicated by Figure 10B, a public diagnosis can move a valve through a five percent ramp in the opening direction, and then immediately move the valve through a five percent ramp. in the closing direction. The speed of the ramps will. fixed and set preferably at a speed determined by the size of the valve / activator. More preferably, the ramp rate is approximately half the maximum rate of speed for the device. On the other hand, as indicated by Figure 10C, a public diagnosis can move a valve in the opening (or closing) direction in a single step, eg, five percent from the valve position in progress, with the time of the instantaneous step established in such a way that no speed limit is in effect. This' test concludes with the valve in a new position of baseline valve five percent up (or down) from the initial point.

To implement the public diagnostics illustrated in Figures 10A-10C, using the Fieldbus protocol, the host 12 sends an execution command to the device that stores the public diagnostics, which establishes a list of trend direction in the device (for example, example, the device 16), and then establishes an appropriate VCR in the device 16 for the trend direction. Then, the link object of the device 16 for the trend direction is established and, after the same, the diagnostic test proceeds. At this time, the host can visually display a message to the user, indicating that the diagnostics are in process, and the host can read the status or progress of the diagnostics, to determine if an error condition occurs. After the device 16 has finished diagnosing, the host reads and stores the trend address data and turns off the trend direction. After the host can perform the analysis on the recovered data. If a state of, say, 200 percent or more of device 16 is received, an error has occurred in the diagnostics, and the host may indicate that error to the user, after analyzing the received data, the host may display visually the diagnostic data revealed from the stored trends directions, or any results determined from them, to the user. For example, host 12 can graphically represent the actual movement of the valve in response to one or all of the public diagnostic waveforms described above, along with the input waveform to represent the response of device 16 to the form of wave. When a public diagnosis or other diagnosis is made, the device 16 first determines whether a diagnostic command signal has been received and, if so, verifies that the transducer block of the device is operating satisfactorily. If so, then device 16 establishes the updated pointers for the trend direction data, to indicate which data should be stored in the trend direction block, and verifies that a sufficient set point range is available to perform the diagnosis. For example, to run a test that requires a five percent movement of the valve in the opening direction, the valve must be at or below 95 percent of its maximum movement. If this range is not available, the device 16 can send back an error message to the host 12. If no error has occurred, the device 16 executes a selected test, using the test times and the determined tilt speeds of a search table (based on the size of the valve / activator) stored in the device 16, and take the desired measurements such as the position of the valve. During the test, the valve updates the test status with a full percentage of 0-100 percent and, if an error is detected, writes an error code greater than 200 percent to a diagnostic status variable that reads the host 12. At the end of the test, assuming that no error has been reached, the diagnostic test writes a 100 percent state in the diagnostic test status variable and, after the same, reports the diagnostic data. Trend direction collected from the host, using normal stacking operations set to make the trend direction, in accordance with standard Fieldbus protocols. Preferably, the cycle speed of the diagnostic test is set to be relatively high compared to the changes within the input waveform, such that sufficient trend direction data is collected to adequately model the response of the device 16 to the diagnostic waveform. In this way, in a Fieldbus protocol, where the frequency of data sampling in a trend direction object is tied to the execution speed of the function blocks, the speed of execution of the cycle must be much higher than the speed of changes in the input waveform, to enable the object of the trend direction to collect data, to observe the response of the device 16 to the input waveform after each significant change in it. Of course, the public diagnoses illustrated in, for example, Figure 10, are better suited to perform diagnostics of the device, in the sense that they can be conveniently used to cause a particular device to go through one or more steps or diagnostic operations, during which the outputs of the transducers inside the device are measured, to determine the characteristics of that device. When used in a Fieldbus protocol for device diagnostics, these tests do not require the use of any additional function blocks but, rather, can be executed by an individual device driver (such as controller 102 of Figure 6) , to control the transducer blocks apart from the normal operation associated with the function blocks that operate inside the device. Of course, if desired, a function block can be used to analyze the data collected in some way, and to provide the analyzed data to the host. Referring now to Figure 11A, a control cycle 400 is illustrated in detail. process, capable of implementing device or process diagnostics locally from a device in a Fieldbus process control network, the cycle 400 includes the control cycle, CICL01 of Figure 4, which has the function block 66 of the device 20, communicatively connected by bus 34 with block 64 of PID function and block 63 of function A / 0, both of device 16. Cycle 400 also includes a block 401 of data collection function, configured to receive the data from the AO function block 63, the AI function block 66 and, if desired, other function blocks such as AI function blocks 402 and 404, which may be located in other devices field devices connected inside the process control network 10. Of course, the function blocks 66, 402 and 404 are configured to communicate with the data collection function block 401, using standard synchronous communications, such as publi-cal / subscriber communications defined within the Fieldbus protocol. During operation, the controller 102 inside the field device 16 interrupts the normal operation of the cycle formed by the function blocks 66, 64 and 63, and sends a diagnostic waveform to the input of the function block 63. At that time, the AO function block 63 changes its state mode to, for example, a local control mode, which cascades back to the PID function block 64, causing the PID function block 64 to change its state so as to, for example, manual, which in turn prevents the PID function block 64 from producing an output signal based on the inputs received by the same. As noted above, the diagnostic waveform can be stored in controller 102 of device 16, or it can be provided by host 12, prior to the implementation of the diagnostic test. Of course, the waveform or other instructions cause the valve associated with the device 16 to pass through a series of movements associated with a device or a process diagnostic test. During a device diagnosis, the data collection function block 401 receives data from the AO function block 63, as well as data from other transducers inside the device 16., such as the transducers associated with the position detectors and / or any of the pressure detectors like those illustrated in Figure 6. During a process diagnosis, the data collection function block 401 also, or alternatively receives data related to the process variables as revealed by the AI function blocks 66, 402, 404, as well as any other function blocks within the process control network 10. The data collection function block 401 can collect this data together with data concerning the timing and magnitude of the diagnostic waveform sent to the AO function block 63, and can store this data for future sending to the host 12, in where these can be processed and illustrated to a user.

After the device or process diagnostic test has been completed, the data collected via the function block 401 is sent to the host 12, and the controller 102 releases control of the AO function block 63 back to the function block 64. PID, to return the cycle comprising blocks 66, 64 and 63 to normal operation. Of course, at this time, the status mode of blocks 64 and 63 is returned to normal operation. It should be noted that, although the data collection function block 401 does not necessarily require any scheduled synchronized execution time, the communication interconnections of the function block 401 must be established, when the process control cycle 400 is configured and, therefore, these communication interconnections exist even when no diagnosis is being executed. In other words, when the data collection function block 401 needs to have data published to it, through the collection bar 34, it must be configured to receive that data (i.e., the data published by other devices) in the data collection function. initialization of the process control network 10, to avoid asking a user to reconfigure the network 10 simply to perform diagnostics. However, as noted above, because the data collection function block 401 will generally collect only the process variable data that has already been published in the collection bar 34, or it will collect the data generated internally within the device in the collection device. that the data collection function block 401 is present, the operation of the data collection function block 401 will not generally add to the amount of synchronous communications in the collection bar 34, nor will it require additional scheduled execution times for the network 10 of process control. If desired, however, the data collection function block 401 can be configured to receive the data that is not usually published in the bus, which requires that the publication block be configured to publish the data in the start of the process control network 10. Referring now to Figure 11B, a process control cycle 406 capable of implementing local diagnostics within a device in a Fieldbus process control network is illustrated in detail. Similar to the 400 cycle of the. Figure 11A, cycle 406 includes the control cycle, CICLOl of Figure 4, which has block 66 of function AI of device 20, communicatively connected, via bus 34, with block 64 of PID function and block 63 of A / O function, both of device 16. Cycle 406 also includes a data collection function block 408 (located on device 16) that operates essentially the same as data collection function block 401, except that it is configured only to receive data locally from, for example, block 63 of function AO, block 64 of function PID or. any other transducers or detectors inside the device, such as pressure detectors, position detectors, and so on. The data collection function block 408 is especially useful for performing diagnostics of the device where the required data is generated locally within a device. Because the data collection function block 408 does not need to receive data from the collection bar 34, it does not have to be initially configured at the start of the process control network. Of course, the data collection function blocks 401 and 408 are only two ways of collecting diagnostic data inside a process control device, there being many other methods for collecting that data in different types of networks and control devices. process. For example, you can collect the data for a device or a 'process, through other parasitic software located in a device that does not conform to the definition of a Fieldbus function block. Referring now to Figure 12, a flow diagram 500 illustrates the steps that a typical process diagnosis performs using, for example, cycle 400 of Figure 11. In a step 502, a data collection arrangement is provided for the block 401 of data collection function, and other data necessary for a diagnostic test is sent from a host (e.g., host 12) to device 16 at which the diagnosis is to be executed. After the above, a user initializes the diagnosis to isolate the cycle that is being tested from the rest of the process control network. After initialization, the device 16 changes the state of the AO function block 63 to, for example, a local control mode, which causes the PID function block 64 (or other upstream function blocks) to change the mode automatically, in accordance with the Fieldbus control standards. After the above, a block 506 performs a diagnostic instruction stored inside the memory of the device 16, and the data collection function block 401 collects the diagnostic and process data in the block 508. A block 510 determines whether the The test is complete and, if not, returns the control to the .506 block, which performs the following diagnostic instruction. Of course, the following instruction can be a repetition of the previous one, causing, for example, that a device move in a single direction until a limit has been reached. The cycle performed by blocks 506, 508 and 510 is repeated until the test is complete, or until an error has occurred or been detected in block 510, at which time block 512 terminates the diagnostic test, and a block 514 restores the normal operating state to, for example, the AO function block 63 which causes the PID function block 64 to change again and control the A / O function block 63 in accordance with the operation of normal control. The data collected by the data collection function block 401 is provided to the host 12, which analyzes and / or visually displays the data. If desired, analyzes can be performed on the device 16, and the host 12 can provide the results of the analyzes to a visual display unit for visual display. Using the diagnostic method of the device according to the present invention, the device 16 collects data from both the device and the process, without requiring separate control by a host to implement or receive the data. Because the diagnosis is made inside a device, and controlled by the controller of that device, instead of a separate host device, the timing of the test can be controlled pre-cisa, and can be aligned by time Easily collect data collected during a diagnostic test, with the operation performed by the device to provide exact correspondence between the test waveform and the test results. When implemented to perform a process diagnosis, the data collection function block 401 of cycle 400 (or any similar cycle having a data collection function block configured to collect data from one or more) may be used. process control cycles) to direct the operation of the cycle, rather than just the operation of the device, and can be used to indicate whether or not a valve is appropriate for a cycle, or if there are other issues with the cycle that would limit its global operation. The process and / or device test can be implemented periodically, without requiring that a process be stopped or placed in a non-operational state. Of course, when the data collection function block 401 is configured to collect only the data already published in the cycle, this is limited by the control program in terms of the data that can be collected and used for diagnostics. Although diagnostic functions have been described herein as operating diagnostics in, or by using a block 63 of downstream AO function (which is a block of output function), and as inputs for receiving, and sending feedback to a block 64 of upstream PID function (which is a control function block) connected in a simple control cycle configuration, the data collection function block 401 or other diagnostic function routine of the present may be used, in conjunction with other functions or output function blocks, and other functions or control function blocks, as desired, and may be implemented in control cycles having different configurations than those illustrated in Figure 11. For another part, although some of the diagnoses described here have been implemented in the form of a "function block" Fieldbus, it is noted that the diagnoses can be implemented of the present invention using other types of blocks, programs, hardware, firmware, etc., associated with other types of control systems and / or communication protocols. In fact, although the Fieldbus protocol uses the term "function block" to describe a particular type of entity capable of performing a process control function, it is noted that the term function block as used herein is not so limited and includes any kind of device, program, routine, or other entity capable of performing a process control function in any way, in distributed locations within a process control network. In this way, the diagnostic function blocks described and claimed herein can be implemented in other process control networks, or using other process control communication protocols or schemes (which may exist at present, or which could be developed). in the future) that do not use what the Fieldbus protocol strictly identifies as a "function block". Still further, although the process and device diagnostics have been described herein, as being used to perform diagnostics on (or using) positioner / valve devices, it is noted that these diagnostics can be performed on (or using) other types of devices, such as those that have mobile elements such as shock absorbers, fans, and so on. In the same way, although the diagnostics described herein are preferably implemented in software stored in a process control device, these can be implemented alternatively or additionally in hardware, firmware, etc., as desired. If implemented in software, the diagnoses of the present invention can be stored in any computer-readable memory, such as on a magnetic disk, a laser disk, or other storage medium, in a RAM, ROM, EPROM, and so on, of a computer, and the like. In the same way, this software can be sent to a user or to a device by any known or desired method of sending, including, for example, through a communication channel such as a telephone line, the internet, and so on. Thus, although the present invention has been described with reference to specific examples, which are intended to be illustrative only, and not to be limiting of the invention, it will be apparent to those of ordinary skill in the art that changes can be made. , additions, or deletions to the described modalities, without departing from the spirit and scope of the invention.

Claims (53)

1. CLAIMS field to be used in a process control system, which includes a plurality of field devices mutually coupled by a digital, energized two-bar busbar, the busbar supplying a control signal of the device field to the field device, the field device comprising: a pneumatically operated fluid control valve, having an activator connected to a pneumatic pressure line, to cause the fluid control valve to move to a position that varies from an open position to a closed position; a position detector coupled to the fluid control valve to detect the position of the fluid control valve; a pressure detector coupled to the pneumatic pressure line, to detect a pneumatic pressure inside the pneumatic pressure line; an electric to pneumatic tracer coupled to the actuator by the pneumatic pressure line, to control the pneumatic pressure in the pneumatic depression line, as a function of an electrical signal; an electronic controller coupled to the electric to pneumatic tracer, to the pressure detector, and to the position detector, the electronic controller including a control logic that determines the electrical signal, based on feedback signals that indicate a pressure detected by the pressure detector , and a position detected by the position detector, and based on the control signal of the field device; and a digital interconnection coupled to the digital, energized two-wire busbar and coupled to the electronic controller, the digital interconnection including: a circuit to supply energy derived from the busbar to the field device, including the electronic controller and the tracer electric to pneumatic, and a two-way communication circuit for receiving signals, including a control signal from the field device from the busbar, and transmitting signals indicating a state of the field device to the busbar.
2. 2. A field device, according to claim 1, characterized in that it also includes a pneumatic relay coupled in the pneumatic pressure line between the electric to pneumatic tracer and the valve, and the pressure detector is coupled to the pressure line pneumatic between the electric to pneumatic tracer and the pneumatic relay.
3. 3. A field device, according to claim 2, characterized in that it includes another pressure sensor coupled to the pneumatic pressure line between the pneumatic relay and the valve.
4. 4. A field device, according to claim 1, characterized in that it also includes a pneumatic relay coupled in the pneumatic pressure line between the electric to pneumatic tracer and the valve, and the pressure detector is coupled to the pressure line pneumatic between the pneumatic relay and the valve. 5. A field device, according to claim 1, wherein the pneumatic pressure line includes a pressure supply line that is coupled to an input of the electric to pneumatic tracer, and the pressure sensor is coupled to the pneumatic pressure supply line, to measure the pressure supplied to the input of the electric to pneumatic tracer. 6. A field device, according to claim 1, characterized in that it also comprises: a second control logic for execution in the electronic controller to execute and control a diagnostic valve test protocol in response to a test request Diagnostic data received from the busbar, and to generate diagnostic data of the valve corresponding to the variations in the pressure measured by the pressure detector, and the variations in the position of the valve measured by the position detector, and storage coupled to the electronic controller, to store the diagnostic data of the valve. 7. A field device, according to claim 6, characterized in that it also comprises: a third control logic for execution in the electronic controller for digitally transmitting the diagnostic data from the valve to the busbar. 8. A field device, according to claim 7, wherein the field device executes the diagnostic test protocol ^ independently of the operations of other field devices in the busbar. 9. A field device, according to claim 1, wherein the digital interconnection is communicated by the digital, energized two-wire busbar, using a standard Fieldbus communication protocol. 10. A process control system that includes: a control console to generate commands and receive data; a two-wire, digital, energized busbar coupled to the control console; Y . a plurality of field devices mutually coupled by the digitally energized two-bar busbar, the busbar supplying commands that include a control signal from the field device to the field devices, one of the field devices including: a pneumatically operated fluid control valve, having an actuator coupled to a pneumatic pressure line to cause the fluid control valve to move to a position ranging from an open position to a closed position; a position detector coupled to the fluid control valve to detect the position of the fluid control valve; a pressure detector coupled to the pneumatic pressure line to detect pneumatic pressure within the pressure line; an electric to pneumatic transducer coupled to the valve by the pneumatic pressure line, to control the pneumatic pressure in the pneumatic depression line as a function of an electrical signal; an electronic controller coupled to the electric to pneumatic transducer, to the pressure detector, and to the position detector, the electronic controller including a control logic that determines the electrical signal based on feedback signals that indicate a pressure detected by the pressure detector , and a position detected by the position detector and based on the control signal of the field device; and a digital interconnection coupled to the digitally energized two-wire busbar and coupled to the electronic controller, the digital interconnection including: a circuit for supplying energy derived from the energized busbar to the field device, including the electronic controller and the electrical to pneumatic transducer, and a two-way communication circuit for receiving signals, including the control signal of the field device from the busbar, and transmitting signals indicating a state of the field device to the busbar. A process control system, according to claim 10, characterized in that it also includes a pneumatic relay coupled in the pneumatic pressure line between the electric to pneumatic transducer and the valve, and the pressure detector is coupled to the line of pneumatic pressure between the electric to pneumatic transducer and the pneumatic relay. 12. A process control system, according to claim 10, characterized in that it also includes a pneumatic relay coupled in the pneumatic pressure line between the electric to pneumatic transducer and the valve, and the pressure detector is coupled to the line of pneumatic pressure between the pneumatic relay and the valve. A process control system, according to claim 10, wherein the pneumatic pressure line includes a pressure supply line that is coupled to an input of the electric to pneumatic transducer, and the pressure sensor is coupled to the pressure supply line, to measure the pressure supplied to the input of the electric to pneumatic transducer. A process control system, according to claim 10, characterized in that it also comprises: a second control logic for execution in the electronic controller for executing and controlling a diagnostic valve test protocol in response to a request for diagnostic test received from the busbar, and to generate valve diagnostic data corresponding to variations in the pressure measured by the pressure sensor, and variations in the position of the valve measured by the position detector; and a storage coupled to the electronic controller, for storing the diagnostic data of the valve. 15. A process control system, according to claim 14, characterized in that it also comprises: a third control logic for execution in the electronic controller for digitally transmitting diagnostic data from the valve to the busbar. 16. A process control system, in accordance with claim 15, wherein the field device executes the. Diagnostic test protocol independent of the operations of others - field devices in the busbar. A process control system, according to claim 10, wherein: the control console includes an operation logic for generating and transmitting a plurality of diagnostic test commands for a plurality of field devices; and the plurality of two field devices also includes the operating logic to execute the diagnostic test commands independently of the operations of other field devices in the busbar, in such a way that the operations are executed in parallel. 18. A field device for use in a process control network, having a plurality of devices communicatively coupled by a fully digital communication bus, the field device comprising: a connector that connects the fully digital bus bar to enable fully digital communication through the busbar; a memory that stores a diagnostic test routine that has a series of diagnostic test instructions; a controller performing the diagnostic test instructions stored in the memory to implement a diagnostic test, using the field device; a data collection unit that collects diagnostic data generated during the diagnostic test; and a communication unit that communicates the diagnostic data collected through the busbar in a fully digital format. 19. The field device of claim 18, characterized in that it also comprises a positioner actuated to the valve, having a movable valve member and wherein the diagnostic test instructions specify the movement of the valve member. The field device of claim 19, characterized in that it also includes a position detector that detects the position of the mobile valve member during the diagnostic test, and that sends a position signal indicating the position of the valve member to the data collection unit. The field device of claim 20, wherein the positioner includes a pneumatic pressure line coupled to a current-to-pressure transducer, and which further includes a pressure sensor coupled to the pneumatic pressure line, which detects the pressure in the pneumatic pressure line, and that sends a pressure signal that indicates the pressure, in the pneumatic pressure line a. the data collection unit. 22. The field device of claim 21, characterized in that it also includes a pneumatic pressure relay coupled in the pneumatic pressure line between the electric to pneumatic transducer and a valve, and the pressure sensor is coupled to the pneumatic pressure line between the electric to pneumatic transducer and pneumatic relay. The field device of claim 21, characterized in that it also includes a pneumatic pressure relay coupled in the pneumatic pressure line between the electric to pneumatic transducer and a valve, and the pressure sensor is coupled to the pneumatic pressure line between the Pneumatic relay and valve. The field device of claim 21, wherein the pneumatic pressure line includes a pressure supply line that is coupled to an electrical-to-pneumatic transducer inlet, and the pressure sensor is coupled to the power supply line. pneumatic pressure, to measure the pressure supplied to the input of the electric to pneumatic transducer. 25. The field device of claim 18, wherein the controller includes a program language interpreter, adapted to interpret a program language, and wherein the diagnostic test instructions are stored in the program language. The field device of claim 25, wherein the communication unit is adapted to receive the diagnostic test instructions in the program language from a second of a plurality of devices via the busbar, and to store in the memory the diagnostic test instructions received. 27. The field device of claim 18, wherein the field device includes a member that is movable in an opening and closing direction, and wherein the diagnostic test instructions cause ".?" the member to move through a ramp by steps in the legs. opening and closing directions. 28. The field device of claim 27, wherein the stepped ramp includes steps equal to about one percent of a range of member movement. 29. The field device of claim 18, wherein the field device includes a member that is movable in an opening and closing direction, and wherein the instructions of the diagnostic test cause the member to move to through a linear ramp in the opening and closing directions. 30. The field device of claim 29, wherein the diagnostic test instructions cause the member to move at a ramp rate equal to about half the maximum speed of movement of the member. The field device of claim 18, wherein the field device includes a member that is movable, and wherein the instructions of the diagnostic test cause the member to move in a step. 32. The field device of claim 31, wherein the step has an amplitude of about five percent of a range of member movement. 33. A field device for use in a process control network, having a plurality of devices communicatively coupled by a bus bar, the field device comprising: a memory storing a diagnostic test routine having a series of diagnostic test instructions; a device controller that performs the diagnostic test instructions stored in the memory / to implement a diagnostic test; a data collection unit that collects diagnostic data generated during the diagnostic test; and a communication unit that receives the one-second diagnostic test instructions from a plurality of devices via the bus bar, which stores the diagnostic test instructions received in the memory, and which communicates the collected diagnostic data to through the busbar. 34. The field device of claim 33, wherein the diagnostic test instructions are written in a program language, and the device driver includes a program language interpreter that interprets the diagnostic test instructions for perform the diagnostic test. 35. The field device of claim 34, characterized in that it also comprises a positioner coupled to a valve having a movable valve member, and wherein the diagnostic test instructions specify the movements of the valve member. 36. The field device of claim 35, characterized in that it also includes a position detector that detects the position of the valve member during the diagnostic test, and that sends a position signal indicating the position of the valve member to the data collection unit. 37. The field device of claim 36, wherein the positioner includes a pneumatic pressure line coupled to a current-to-pressure transducer, and further includes a pressure sensor coupled to the pneumatic pressure line, which senses the pressure in the pneumatic pressure line and sending a pressure signal that indicates the pressure in the pneumatic pressure line to the data collection unit. 38. The field device of claim 33, wherein the communication unit is configured to communicate through the bus, using a Fieldbus protocol. 39. The field device of claim 33, wherein the instructions of the diagnostic test implement a process diagnosis, and the communication unit is adapted to receive data through the bus bar, related to the process variables measured by other of the plurality of devices. 40. A field device to be used to perform a process diagnostic test in a control network. process having a plurality of devices communicatively coupled by means of a busbar, the field device comprising: a memory that stores a diagnostic routine of the process, which has a series of instructions of the diagnostic test that are going to implement through the field device; a device driver that performs the diagnostic process test instructions, stored in the memory to implement a process diagnostic test; a data collection unit that collects the diagnostic data generated by the field device during the process diagnostic test, and that receives more process diagnostic data from a second of a plurality of devices via the busbar; and a communication unit that communicates the collected diagnostic data and the other diagnostic data of the process through the busbar, after the diagnostic test of the process is completed. 41. The field device of claim 40, wherein the communication unit is configured to communicate through the bus, using a Fieldbus communication protocol, and wherein the data collection unit is a configured function block. to receive the other diagnostic data, of the process from the second of the plurality of devices through the busbar. 42. The field device of claim 41, where the function block is configured to receive the other process diagnostic data through the busbar, using synchronous communications. 43. The field device of claim 40, wherein the device controller includes a handling unit so as to control the mode of the components within a process control cycle that performs the process diagnostic test. 44. A process control network comprising: a host device that generates commands and receives data; a plurality of field devices; and a busbar that communicatively interconnects the host device and the plurality of field devices; wherein one of the plurality of field devices includes a memory that stores a diagnostic test routine that has a series of diagnostic test instructions, to be implemented by the device, a controller of the device that performs the instructions of the diagnostic test stored in the memory, to implement a diagnostic test, a data collection unit that collects the diagnostic data generated by the device during the diagnostic test, and a communication unit that communicates the data. of the diagnosis collected through the busbar to the host device after the diagnostic test has been completed. 45. The process control network of claim 44, wherein the diagnostic test routine is a routine diagnostic process test, and the data collection unit receives the diagnostic data from the process from a second of the plurality of field devices through the busbar. 46. The process control network of claim 44, wherein the controller includes a program language interpreter adapted to interpret a program language, and wherein the diagnostic test instructions are stored in the program language. 47. The process control network of claim 46, wherein the communication unit is adapted to receive the diagnostic test instructions in the program language from the host device, via the busbar, and to store the instructions of the diagnostic test received in the memory, before the implementation of the diagnostic test. 48. The process control network of claim 44, wherein each of the plurality of field devices is capable of performing a process control function, and communicating in the bus, using scheduled periodic communications and communications. not periodic. 49. The process control network of claim 44, wherein the one of the plurality of field devices includes a member that is movable in an opening and closing direction, and wherein the diagnostic test instructions cause that the member moves through a ramp by steps in the opening and closing directions. 50. The process control network of claim 49, wherein the stepped ramp includes steps equal to about one percent of a range of member movement. 51. The process control network of claim 44, wherein the. one of the plurality of field devices includes a member that is movable in an opening and closing direction, and wherein the diagnostic test instructions cause the member to move through a linear ramp in the opening directions and close. 52. The process control network of claim 51, wherein the diagnostic test instructions cause the member to move at a ramp rate equal to about half the maximum speed of movement of the member. 53. The process control network of claim 44, wherein the one of the plurality of field devices is mobile, and wherein the diagnostic test instructions cause the member to move in a step.
5. 5 . The process control network of claim 5-3, wherein the step has an amplitude of about five percent of a range of member movement. 55. A field device for use in conducting a diagnostic test in a process control network having a plurality of devices communicatively coupled by a bus bar, and using the Fieldbus communication protocol, the device field comprising: a memory storing a diagnostic test routine having a series of diagnostic test instructions to be implemented by the field device; a device controller that performs diagnostic test instructions stored in memory, to implement a diagnostic test; a data collection function block that collects diagnostic data generated during the diagnostic test; and a communication unit that communicates the diagnostic data collected through the busbar, after the diagnostic test has been completed. 56. The field device of claim 55, wherein the diagnostic test is a diagnostic device test, and wherein the data collection function block collects data from the field device. 57. The field device of claim 55, wherein the. Diagnostic test is a diagnostic test of the process, and where the data collection function block collects at least part of the diagnostic data from another field device, through communications through the busbar.