Multi-protocol field device interface with automatic bus detection

Abstract

A multi-protocol interface for coupling a field device to a general purpose computer is disclosed. The interface includes measurement circuitry to perform a plurality of measurements on a connected process communication loop to determine a process communication loop type. Then, if the interface includes a protocol interface module that matches the detected loop type, the protocol interface module can be engaged. A method for coupling a field device to a general purpose computer is also provided. In one aspect, power from the general purpose computer is used to power the process communication loop, if the interface determines that the loop is not powered.

Description

BACKGROUND OF THE INVENTION

Field devices are used in industries to control operation of a process such as an oil refinery. A field device, such as a transmitter, is typically part of a process communication loop and is located in the field to measure and transmit a process variable such as pressure, flow or temperature, for example, to control room equipment. A field device such as a valve controller can also be part of the process communication loop and controls position of a valve based upon a control signal received over the process control loop, or generated internally. Other types of controllers control electric motors or solenoids, for example. The control room equipment is also part of the process communication loop such that an operator or computer in the control room is capable of monitoring the process based upon process variables received from transmitters in the field and responsively controlling the process by sending control signals to the appropriate control devices. A process communication loop sometimes includes a portable communicator which is capable of monitoring and transmitting signals on the process communication loop. Typically, such portable communicators are used to configure field devices which form the process communication loop. As used herein, the term “process communications loop” is intended to mean any physical connection and media that carries process signals, regardless of whether the connection forms an actual loop. Thus, a process communication loop can be a HART® or FOUNDATION™ Fieldbus segment, even though such a segment is not strictly considered a loop.

With the advent of low-power microprocessors, field devices have undergone significant changes. Years ago, a field device would simply measure a given process variable, such as temperature, and generate an analog indication in the form of a current varying between 4 and 20 (mA) to indicate the measured temperature. Currently, many field devices employ digital communication technology as well as more sophisticated control and communication techniques. Field devices often employ low-power electronics because in many installations they are still required to run on as little as 4 mA. This design requirement prohibits the use of a number of commercially available microprocessor circuits. However, even low-power microprocessors have allowed a vast array of functions for such field devices.

There has been a dramatic increase in the availability of such microprocessor-based field devices. Such field devices are sometimes termed “smart” or “intelligent.” There has also been a dramatic increase in the availability of software applications that are used to configure, test, and diagnose these smart field devices. Connection of a general purpose computing device, such as a personal computer (PC) or a portable laptop computer is typically accomplished using a modem between the computing device and the intelligent field devices. There is a significant array of process communication protocols such as the HART®, FOUNDATION™ Fieldbus, Modbus®, and Profibus protocols that support the various process control tasks. Moreover, it is common to find multiple communication protocols in use in the very same process installation.

One technique for coupling a general purpose computing device to process communication networks having various process communication protocols is found in U.S. Pat. No. 6,839,790. The '790 patent reports an interface device that includes a re-configurable circuit which provides access to a selected fieldbus network from among several optional fieldbus networks. However, the techniques taught by the '790 patent generally require a user to have a priori knowledge of the particular type of fieldbus to which he or she is connecting. Thus, if a user wants to connect to a Profibus network, the user must make that selection known, and then the interface will reconfigure itself. However, if the user does not know what type of process communication protocol is being used, or if the user's selection is erroneous, the interface may begin communicating using a protocol that is not compatible with the actual protocol in use. This may introduce dangerous signaling levels that may damage, or otherwise degrade communication on the process control loop; damage or otherwise degrade the interface module itself, or potentially interfere with the proper operation of the process control loop.

SUMMARY OF THE INVENTION

A multi-protocol interface for coupling a field device to a general purpose computer is disclosed. The interface includes loop measurement circuitry to perform a plurality of measurements on a connected process communication loop to determine a process communication loop type. Then, if the interface includes a protocol interface module that matches the detected loop type, the protocol interface module can be engaged. A method for coupling a field device to a general purpose computer is also provided. In one aspect, power from the general purpose computer is used to power the process communication loop, if the interface determines that the loop is not powered.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagrammatic view of a multi-protocol interface coupling a field device to a general purpose computing device in accordance with an embodiment of the present invention.

FIG. 2 is a block diagram of modem module 18 in accordance with embodiments of the present invention.

FIG. 3 is a flow diagram of a method of coupling a general purpose computer to a process communication loop using a multi-protocol process communication module in accordance with an embodiment of the present invention.

FIG. 4 is a flow diagram of a method of coupling a general purpose computer to a process communication loop in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

FIG. 1 is a diagrammatic view of a multi-protocol interface coupling a field device to a general purpose computing device in accordance with an embodiment of the present invention. Multi-protocol interface 10 couples field device 12 to general purpose computing device 14, which is illustrated as a laptop computer. The coupling between multi-protocol interface 10 and field device 12 may be effected via direct connection, such as via wiring terminals within the field device, or through process communication loop 16. Multi-protocol interface 10 includes network connection circuitry 18 that is configured to couple to process communication loops, and a connector module 20 that is configured to couple to general purpose computing device 14. Connector module 20 may include any suitable form of connector for connecting to computer 14. Suitable examples include, but are not limited to, universal serial bus (USB) connections, standard serial connections such as those that employ DB9 or DB25 connectors, parallel connections, PCMCIA connections, PCI connections, and firewire connections. In embodiments of the present invention where connector module 20 includes a wired connection to general purpose computing device 14, it is preferred that multi-protocol interface 10 be powered through the wired communication interface. Embodiments of the present invention can also be practiced where the data communication between multi-protocol interface module 10 and general purpose computing device 14 is a wireless connection. Examples of suitable wireless connections include infrared communication, Bluetooth communication, and WIFI communication (such as IEEE 802.11b or IEEE 802.11g). Further, as the art of general purpose computing devices advances, embodiments of the present invention can be practiced using any suitable data communication for which the general purpose computer is adapted, whether now known, or later developed.

FIG. 2 is a block diagram of network connection circuitry 18 in accordance with embodiments of the present invention. As illustrated, network connection circuitry 18 includes microprocessor 38 that is configured to couple, via line 46, to connector module 20 (show in FIG. 1). Circuitry 18 also includes analog-to-digital converter 36 which is coupled to microprocessor 38. Converter 36 is coupled to measurement circuitry 32 via control logic 34. Microprocessor 38 is also coupled to external data bus 40 through which it interacts with read only memory 42 and random access memory 44. Through data bus 40, microprocessor 38 is also able to interact with first protocol interface module 26 and a protocol interface module 28. Each of modules 26 and 28 is designed to communicate in accordance with a standard process communication protocol. For example, first protocol interface module 26 may be configured to communicate in accordance with the HART® protocol while second protocol interface module 28 is configured to communicate in accordance with the FOUNDATION™ Fieldbus protocol. Additionally, while FIG. 2 illustrates a pair of modules, embodiments of the present invention can be practiced by employing three or more such protocol interface modules. Each protocol interface module allows communication in accordance with its respective process communication protocol.

As described above, if the wrong type of protocol interface module communicates over a process communication loop, incompatible signal levels, data, interference, or other undesirable effects can diminish the communication capabilities of the process communication network, or even damage the associated devices. In accordance with an embodiment of the present invention, network connection circuitry 18 includes loop measurement circuitry 32. As illustrated in FIG. 2, module 18 includes a pair of terminals 50, 52 with each of terminals 50, 52 being coupled to each of protocol interface modules 26 and 28, and to loop measurement circuitry 32. Utilization of loop measurement circuitry 32 allows network connection circuitry 18 to make various measurements to connected process communication loops, before engaging one of protocol interface modules 26 or 28.

The circuitry of multi-protocol interface 10 preferably facilitates compliance with intrinsic safety requirements. Compliance with intrinsic safety requirements means compliance with an intrinsic Safety specification such as one or more of the portions of the standard promulgated by Factory Mutual Research in October 1998, entitled APPROVAL STANDARD INTRINSICALLY SAFE APPARATUS AND ASSOCIATED APPARATUS FOR USE IN CLASS I, II AND III, DIVISION 1 HAZARDOUS (CLASSIFIED) LOCATIONS, CLASS NUMBER 3610.

When operating with a HART® process control loop, interface 10 must not sink or source a direct current (DC). To meet intrinsic safety requirements for FOUNDATION™ Fieldbus, interface 10 must not inject any energy into the process control loop. Because these two protocols have two fundamentally different (and conflicting) ways of communicating, the circuitry of interface 10 must never sink a current in a HART® process control loop nor inject energy (impose a voltage) in a FOUNDATION™ Fieldbus segment.

As illustrated in FIG. 2, network connection circuitry 18 includes loop measurement circuitry 32 that includes one or more individual measurement signal conditioning circuits. Preferably, circuitry 32 includes a circuit that can sink a small amplitude short duration current from the network. In another embodiment, circuitry 32 may include three or more individual measurement conditioning circuits that scale the voltage signal on the FOUNDATION™ Fieldbus network connector to measure DC voltage, communications signal amplitude, and network or loop noise. Measurement circuitry 32 may also include a measurement circuit that measures DC voltage on the network. These various signal conditioning circuits all feed control logic block 34. Control logic block 34 includes a multiplexer that is connected to analog-to-digital converter 36. Control logic block 34 is accessed by microprocessor 38 via bus 40. Although FIG. 2 illustrates the connection between microprocessor 38 and converter 36 separate from data bus 40, embodiments of the present invention can be practiced with converter 36 coupled to microprocessor 38 any suitable external bus including a Serial Peripheral Interface (SPI). When interface 10 is first turned on, or provided with power, microprocessor 38 commands analog-to-digital converter 36 to monitor the DC voltage on network connection terminals 50 and 52. During this state, interface 10 will not disturb the network (also referred to as process control loop) in any way (i.e., sink/source current or impose a voltage). If there are no network connections, the voltage measured will be near zero on the loop connection. When a process control loop is coupled to terminals 50 and 52, a DC voltage will be measured. A HART® process control loop will cause a voltage between approximately 12 and 50 volts DC to be measured while a FOUNDATION™ Fieldbus loop connection will cause a voltage between 9 and 32 volts DC to be measured. Once a DC voltage is recognized, the polarity is measured to determine whether the loop connection leads are correctly connected. Specifically, if the DC voltage measured between common lead 50 and lead 52 has a negative polarity, that means that the loop connection leads are reversed. Microprocessor 38 then preferably sends a message informing the user that the loop connection leads must be reversed. In one embodiment, when interface 10 determines that the polarity is reversed, interface 10 ensures that when a protocol interface module is later engaged, that it is engaged in such a way that the reversed polarity is automatically corrected using circuitry of the interface. This correction can be effected simply using switches that essentially reverse the terminals before entering each protocol interface unit. However, other forms of circuitry and/or approaches can be utilized to automatically correct the polarity.

As indicated above, there is an overlap between the operating DC voltages used on both HART® and FOUNDATION™ Fieldbus process communication loops. Therefore, DC voltage alone cannot be used to reliably indicate the type of loop to which device 10 is connected. To determine loop type, interface 10, using measurement circuitry 32 actually measures the DC impedance of the process control loop (preferably having a reasonable DC voltage and correct lead polarity). Interface 10 measures network DC impedance by sinking a small amount of current, for example, 1 mA, for a very short duration, such as 5 milliseconds, and then measuring the shape and amplitude of the resultant voltage pulse on the process communication loop. This disturbance generates a voltage pulse along the process control loop that is proportional to the DC impedance of the process control loop itself. There is a distinguishing range of impedance between HART® and FOUNDATION™ Fieldbus process control loops. The signal that interface 10 observes in response to the disturbance it generates also contains any HART® or FOUNDATION™ Fieldbus communication signals that may be present on the process control loop. The communication signals themselves are filtered using the suitable low pass filter so that only the effect of the short-duration pulse is observed by device 10. Analog-to-digital converter 36 measures the amplitude of the associated disturbance to determine the network type from this voltage measurement. A FOUNDATION™ Fieldbus network will have a computed impedance of approximately 50 ohms. A HART® network will have a computed impedance greater than approximately 125 ohms. If the network or process control loop type detected accords with one of protocol interface modules 26 or 28, then communications can proceed by engaging that respective protocol interface module.

FIG. 3 is a flow diagram of a method of coupling a general purpose computer to a process communication loop using a multi-protocol process communication module in accordance with an embodiment of the present invention. Method 100 begins at block 102 when the multi-protocol interface is first powered. This step may occur when the interface is first coupled to a general purpose computer and receives electrical operating energy from the computer, or simply when a user engages a switch or other suitable object on the interface module to turn the device on. Method 100 continues at block 104 where the multi-protocol interface monitors the voltage across its process communication terminals. This step continues until a non-zero voltage is observed across the process communication or loop terminals. Once this occurs, control passes to block 106 where the multi-protocol interface performs one or more loop-related measurements using loop measurement circuitry as described above. The loop-related measurements are performed until the type of process communication loop can be discerned, or until all available measurements are exhausted. FIG. 3 indicates optional block 108 that can be employed in accordance with embodiments of the present invention. Specifically, once loop-related measurement(s) are performed, a suggestion regarding the type of process communication loop can be automatically provided to the user. The user can then confirm the process communication selection and the associated media access unit will be engaged. Providing an automatic suggestion to a user is unlike allowing a user to simply select a media access unit. For example, if the user erroneously believes that he or she is interacting with a HART® process communication loop, but the multi-protocol interface reports, through its connection with general purpose computing device 14, that the loop-related measurements actually indicate a FOUNDATION™ Fieldbus loop, the user's options are to either acquiesce to the FOUNDATION™ Fieldbus suggestion, or to not engage interface 10 on the loop. Thus, the user's erroneous belief that the process communication loop is a HART® loop is kept from damaging or degrading the communications and/or devices. At block 110, the associated protocol interface module that corresponds to the loop-related measurements and optionally with the user's acknowledgment of the autosuggestion as indicated in block 108 is engaged.

Embodiments of the present invention generally include detection circuitry that automatically detects the communication protocol of a process communication loop. Additionally, embodiments of the present invention also preferably automatically detect parameters of the communication protocol in order to enable appropriate communications. Embodiments of the present invention generally advise users of incompatible protocols, and protect users from using the wrong communication protocol for the connected devices. For example, when connected to a powered HART® loop, the device automatically detects HART® protocol parameters, and automatically enables HART® communication between the general purpose computing device and the HART® field devices on the loop. When connected to a powered FOUNDATION™ Fieldbus segment, the device automatically detects FOUNDATION™ Fieldbus protocol parameters, and automatically enables FOUNDATION™ Fieldbus communication between the general purpose computing device and FOUNDATION™ Fieldbus field devices on the segment.

FIG. 4 is a flow diagram of a method of coupling a general purpose computer to a process communication loop in accordance with an embodiment of the present invention. Method 200 begins at block 202 when the interface is first powered. Block 202 can occur when the interface is first coupled to a general purpose computer, or when a user engages a switch on the interface. At block 204, the interface makes at least one measurement relative to the process communication terminals. Suitable measurements include attempting to detect a voltage, attempting to detect continuity between the process communication terminals, or any other suitable measurement. At block 206, the interface determines, using the results of the loop-related measurement(s), whether a process communication loop has been connected to the interface. If not, control returns to block 204, and the method continues waiting for a loop connection. However, if block 206 determines that a process communication loop has been coupled to the terminals of the interface, then control passes to block 208, where the interface determines if the loop is already powered. This step may be accomplished by using measurement circuitry, such as circuitry 32, to measure a voltage and/or impedance of the newly connected loop. If the newly connected loop is not powered, control passes to block 210 where the interface uses energy received from its connection to the general purpose computer (such as through a USB connection) to provide power to the process control loop. Once the interface has powered the process communication loop at block 210, control passes to block 212. If block 208 determines that the process communication loop is powered, control passes to block 212 from block 208. At block 212, measurement circuitry of the interface is again employed to make a plurality of measurements to determine the type of process control loop to which the interface is connected. Once sufficient measurements have been made, or if all measurements have been exhausted, control passes to block 214 where the protocol interface module that matches the detected loop type is engaged. If the detected loop type does not match any available protocol interface modules, then the interface will simply register an error, but will not engage an erroneous protocol interface module.

Although the present invention has been described with reference to preferred embodiments, workers skilled in the art will recognize that changes may be made in form and detail without departing from the spirit and scope of the invention.

Claims

1. A multi-protocol interface for coupling a field device to a general purpose computer, the interface comprising: a connector module wirelessly coupled to the general purpose computer;a plurality of process communication terminals coupled to a process communication loop;a first protocol interface module coupled to the plurality of process communication terminals and configured to communicate in accordance with a first protocol;a second protocol interface module coupled to the plurality of process communication terminals and configured to communicate in accordance with a second protocol different from the first protocol;loop measurement circuitry operably coupled to the process communication terminals; anda microprocessor coupled to the first and second protocol interface modules and coupled to the measurement circuitry, the microprocessor determining a process communication loop type based at least in part upon a plurality of loop-related measurements made by the measurement circuitry when a process communication loop is coupled to the process communication terminals; andwherein the multi-protocol interface is configured to provide a loop type suggestion to a user in accordance with the process communication loop type, and wherein a protocol interface module having a protocol that matches the determined process communication loop type is engaged for communication only if the user acquiesces to the suggestion.

2. The interface of claim 1, wherein the wireless coupling is in accordance with Bluetooth communication.

3. The interface of claim 1, wherein the wireless coupling is in accordance with WiFi communication.

4. The interface of claim 1, wherein at least one of the loop-related measurements includes voltage across the process communication terminals.

5. The interface of claim 4, wherein at least one of the loop-related measurements includes measurement of loop impedance.

6. The interface of claim 1, wherein the interface is intrinsically safe.

7. The interface of claim 1, wherein the microprocessor determines process communication loop type based at least in part upon a user's response to a loop type suggestion provided to the user.