Method and apparatus for optimizing communications in a multiplexer network

An apparatus for optimizing multiplexer communications in a system having a host, a multiplexer, and a field instrument device. The host is arranged to run a host software and to transmit a message to the multiplexer, the message including an embedded message for the instrument device. The host re-transmits the message until a response to the message is received from the device via the multiplexer, with the first re-transmission occurring after a long delay and a second and all subsequent re-transmissions occurring after a second time interval. An optimizing controller is arranged to establish a count indicating the number of re-transmissions occurring before the response has been communicated to the host, assess a message turnaround time based on the communication time it takes to transmit the message from the host to the multiplexer and to transmit the response from the multiplexer to the host, establish a bracket width at least as long as the message turnaround time, establish a short delay, and vary at least one of the long delay and the short delay to minimize the count.

FIELD OF THE INVENTION

The present invention relates generally to a system having a host controller communicating with one or more field instrument devices such as a valve or sensor through a multiplexer network and, more specifically, to a method and apparatus for managing and optimizing the communications through the multiplexer.

BACKGROUND OF THE INVENTION

Large processes such as chemical, petroleum, and other manufacturing and refining processes include numerous field devices disposed at various locations to measure and control parameters of a process to thereby effect control of the process. Similarly, in such industrial processes a number of valves, sensors or other field instruments or devices may be disposed throughout the process, each of which may require periodic diagnostic operations, configuration, and or calibration. These field devices may be, for example, sensors such as temperature, pressure, and flow rate sensors as well as control elements such as valves and switches. Historically, the process control, diagnostics, configuration, and/or calibration operations in such industrial processes relied on manual operations for reading level and pressure gauges, turning valve wheels, etc. Eventually, the use of local pneumatic control became more prevalent, in which local pneumatic controllers, transmitters, and valve positioners were placed at various locations within a process plant to effect control of certain plant locations. With the emergence of the microprocessor-based distributed control system (DCS) in the 1970's, distributed electronic process control became prevalent in the process control industry.

As is known, a DCS includes an analog or a digital computer, such as a programmable logic controller, connected to numerous electronic monitoring and control devices, such as electronic sensors, transmitters, current-to-pressure transducers, valve positioners, etc. located throughout a process. The DCS computer stores and implements a centralized and often complex control scheme to effect measurement and control of devices within the process to thereby control process parameters according to some overall control scheme. The same basic system is also applicant to the above-mentioned diagnostics, configuration, and calibration operations.

In such systems, a host controller provides a variable DC control current signal of between 4 and 20 milliAmps (mA) over a two-wire communication link to the transducer or positioner or to any other controllable device or instrument. The control current level changes the state of the controllable device in proportion to the strength of the variable DC current signal. For example, a valve positioner might fully open a valve in response to a 4 mA control current, and fully close the valve in response to a 20 mA control current.

In addition to being responsive to a variable control signal, current to pressure transducers, valve positioners, or other field instruments or devices have variable parameters which may be adjusted to control the operating characteristics of such devices. Previously, these devices or process instruments were adjusted manually. However, with the advent of so-called “smart” devices capable of bi-directional communication, it has become possible for necessary adjustments, readings, etc. to be carried out automatically from a location remote from the device or field instrument. Moreover, diagnostic testing and instrument monitoring can also be conducted from a remote location. However, a mechanism must be provided for transmitting a communication signal from the communication site to the field instrument or other device in order to implement the adjustments and/or the field testing.

For a variety of reasons, it may not be feasible to install a communication network separate and independent from the two-wire control loop that interconnects the communication site with the field instrument. Thus, it is desirable to transmit the communication signal over the two-wire control loop together with the 4–20 mA control signal so that additional wiring and/or a separate communication system will not be required. Thus, a modulated digital communications signal is superimposed on the 4–20 mA DC analog control signal used to control the field instrument in order to allow serial communication of data bitstreams between the field instrument and the host controller.

In such systems, the host controller communicates with one or more field instruments or devices via a multiplexer. Typically, the system will utilize any one of a number of available standard, open communication protocols including, for example, the HART®, PROFIBUS®, WORLDFIP®, Device-Net®, and CAN protocols, which enable field devices made by different manufacturers to be used together within the same communication network. In fact, any field device that conforms to one of these protocols can be used within a process to communicate with and/or to be controlled by a DCS controller or other controller that supports the protocol, even if that field device is made by a different manufacturer than the manufacturer of the DCS controller.

As is known, communications between the host controller and the multiplexer are relatively fast, while communications between the field instrument or device are relatively slow. For a variety of reasons, the host controller desires to know the status of messages that have been sent to the field instrument or device via the multiplexer. However, repeated communications with the multiplexer regarding the status of the message sent to the field instrument or device impede the performance of other communications that must be sent through the multiplexer network.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The embodiments described herein are not intended to be exhaustive or to limit the scope of the invention to the precise form or forms disclosed. Instead, the following embodiments have been described in order to best explain the principles of the invention and to enable others skilled in the art to follow its teachings.

Referring now to FIGS.1and9–11of the drawings, a host system10is shown and includes a host controller12, a multiplexer14, and a field instrument or other device, hereinafter collectively referred to as the device16. The host controller12is in operative communication with the device16through a communications system18. The communications system18includes a two-wire control loop20having a first wire22and a second wire24extending between the host controller12and the multiplexer14. Other known communication arrangements between the host controller12and the multiplexer14may be provided. The communications system18also includes a two-wire control loop26having a first wire28and a second wire30extending between the multiplexer14and the device16. In the disclosed example, communications between the host controller12and the multiplexer14along the control loop20are significantly faster than are the communications between the multiplexer14and the device16along the two-wire control loop26. More specifically, the two-wire control loop20may support communications in the range of 9600, 19,200, or 38,400 baud, while communications along the two-wire control loop26may be limited to about, for example, 1200 baud. Other communication rates may be contemplated. As would be known, the two-wire control loop26utilizes a variable DC control current signal of between 4 and 20 mA over the two-wire link to the device16. Although only a single device16is shown, it will be understood that the host system10may include additional devices (e.g., devices16a,16b,16c, . . .16n(FIG. 1).

The host controller12is arranged to run a host software32. The host software32is arranged to forward a message34into the communications system18, with the message34including an embedded message36. As would be known, the embedded message36is ultimately intended for communication to the device16.

After the host controller12sends the message34to the multiplexer14, the multiplexer14strips the embedded message36from the message34and forwards the embedded message36along the control loop26to the device16. In a preferred form, the host system10will be arranged to operate according to the Highway Addressable Remote Transducer (hereinafter “HART”) standardized protocol. Other communications protocols may be used.

As part of the HART specification, the multiplexer14must respond to the message34received from the host controller12, and thus the multiplexer14will send a reply38to the host controller after the message34is received by the multiplexer14from the host controller12. The reply38, will, in accordance with the disclosed example, indicate to the host controller12that the message34has been received by the multiplexer14, and that the multiplexer14has forwarded the embedded message36to the device16.

As outlined above, the communication rate between the host controller12and the multiplexer14typically is significantly faster than the communication rate between the multiplexer14and the device16. Accordingly, the host controller12may receive the reply38from the multiplexer14before the device16receives the embedded message36. Further, because the communication rate on the two-wire control loop26is relatively slow, a relatively significant period of time will pass before a response40is sent to the multiplexer14from the device16. It will be understood that the response40sent by the device16to the multiplexer14will be sent after the device16has received the message36and processed the message36.

The multiplexer14preferably includes a buffer42which receives and saves the response40from the device16. Preferably, the response40will be stored in the buffer42until the response40is retrieved or otherwise communicated to the host controller12. Other mechanisms for receiving, storing and communicating the response40to the host controller12may be contemplated. It will be understood that in certain circumstances the response40stored in the buffer42may be canceled by another and different message from the host controller12.

Once the reply38is communicated between the multiplexer14and the host controller12, the host controller12is free to resend the message34at any time. However, if an immediate retry is attempted, it is virtually guaranteed that the response40from the device16has not yet been received by the multiplexer14due to the relative slowness of the two-wire communication loop26between the device16and the multiplexer14. Accordingly, the host controller12, as directed by the host software32, will not retry or resend the message34until after the expiration of a predetermined and fixed time period. This first fixed time period between the initial sending of the message34and a first resend44of the message34is termed a “long delay”46. Upon the expiration of the long delay46, the host controller12will attempt the first resend44aof the message34in an attempt to retrieve the response40from the buffer42from the multiplexer14. However, if the response40has not yet been received by the multiplexer14from the device16, the multiplexer14may send a message48to the host controller12indicating that the embedded message36has been forwarded to the device16by the multiplexer14and that the multiplexer14is still waiting to receive the response40from the device16. It will be understood that a message48will be sent to the host controller12after each re-send44(44a,44b,44c, etc.) until the response40is present tin the buffer42.

After the host controller12has received the message48, the host controller12will enter another waiting period. However, because the response40is expected relatively soon, this additional waiting period is short relative to the earlier long delay46, and thus this subsequent waiting period is indicated by a shorter time period termed a short delay51. Upon expiration of the short delay51, the host controller12will attempt a second resend44bof the message34. The host controller12, as directed by the host software32, will engage in an ongoing cycle of waiting the bracket width50(e.g.,50a,50b,50c, . . .50n), followed by a resend44of the message34until a valid response40is received from the multiplexer14. In the alternative, the re-sends44a,44b,44c, . . .44nmay cease upon receipt by the multiplexer14of an error code from the device16. Stated another way, the host controller12may vary the duration of the short delay51based on the size of the message in such a manner that the bracket width50remains consistent. As a further alternative, the ongoing cycle may be interrupted upon the expiration of a predetermined time-out period. Thus, the host controller12will initiate a plurality of resends44a,44b,44c. . .44n, with the first resend occurring after the expiration of the long delay46. The second resend44bwill occur after the expiration of the first bracket width50a, with all subsequent resends, if necessary, occurring upon the expiration of the subsequent bracket widths50b,50c,50d. . .50n.

The use of fixed time periods for the long delay46and the short delay51may yield satisfactory communications performance in certain applications, although certain additional improvements in the areas of throughput and efficiency may be desirable. However, there may be some shortcomings in the use of fixed period delays. For example, a message intended for the device16may contain a message number and data unique particular to that message. Further, there may be in excess of several dozen different unique messages (e.g.,34a,34b,34c, . . .34n), with varying amounts of data contained in each unique message. Moreover, each unique message may have a different appropriate response from the device16. Sometimes the data that is received in the response can vary in length for the same unique message. The size of the messages (e.g., the size of the message being sent as well as the size of the response) determines the total transmission time for the message, which accounts for over 90% of the time it takes to complete a message with (e.g., receive a response from) the device16.

Because there is a wide variance in the size of messages sent and received, a fixed time period for the long delay46may result in inefficiencies in communications performance in certain applications. If the long delay46is too long, the response40may sit in the buffer42of the multiplexer14waiting to be retrieved for an undesirably long and thus inefficient time period. On the other hand, if the long delay46is too short, an undue number of round trip communications between the host controller12and the multiplexer14may be required in order to retrieve the response40.

Further, it is known that there may be slight variability in hardware performance from one device to another device, and from one multiplexer to another multiplexer. A fixed time period for the long delay46does not account for these slight variations in performance, nor will the use of a fixed time period for the long delay46allow for the host system10to make adjustments to account for these performance variations. Moreover, in certain applications the baud rate of the multiplexer14may be adjusted, which affects the time it takes to complete a message cycle. The use of a fixed time period for the long delay46does not take into account variations in the baud rate of the multiplexer14.

Accordingly, the host controller12is arranged to perform an optimization cycle52, which is shown schematically inFIGS. 9 through 11. According to the disclosed example, the optimization cycle52allows the host software32to, according to the disclosed example, maximize communication throughput and efficiency when communicating with the device16(or with a number of individual devices16) on a multiplexer network.

The optimization cycle52, according to the disclosed example, adjusts the long delay46and/or the short delay51in order to retrieve the response40from the buffer42of the multiplexer14. These adjustments in the long delay46and/or the short delay51may be made unique to each multiplexer14/device16/message34combination. The adjustments may be based on, for example, the number of re-sends (44a,44b,44c, etc.) that were required the previous time that particular unique message34was sent to that particular device16, or upon any other unique historical data.

In order to gain a more thorough understanding of the optimization cycle52, the following terms and concepts that apply to the underlying algorithm will hereinafter be described.

(1) Message Turnaround Time (MT)—This is the transmission time required (based on the relevant baud rates, for example) for the host controller12to send the message34and receive the response40from the multiplexer14. For example, the host controller12may send a particular message X that is 28 bytes long to the multiplexer at 9600 baud. The multiplexer may respond almost immediately (within about 2 byte times) with a reply message that is 30 bytes long. Based on the applicable baud rate and messages sizes, it takes approximately 70 milliseconds to complete this round-trip message for the message X.

After the host controller12sends a message to the multiplexer14, the host controller12preferably will not send another message (e.g., a re-send) until the host controller12either receives a response or a hardware timeout occurs. Therefore, the MT is the shortest time interval between outgoing messages from the host controller12for a particular command or message. MT is calculated at send time based upon the size of the outgoing command message and the anticipated size of the response.

(2) Bracket Width (BW)—The Bracket Width is the Message Turnaround time (MT) corrected for message length variability. For example, a command or message X, as described previously, may have an MT of 70 milliseconds. A command or message Y, however, with less content may have an MT of only 30 milliseconds. Further, a command or message Z, with more message content, may have an MT of 100 milliseconds. Thus, the BW will preferably be set to a value greater than or equal to the largest MT for the messages X, Y, and Z, sent to a particular instrument or device16. The BW provides for a known, fixed interval between message transmissions, corrects for message length variability, and provides a consistent baseline for adjustment of the value for the long delay46as will be outlined below.

When the response40is eventually obtained from the buffer42it is guaranteed that this retrieval occurred within a BW period of arriving in the buffer42. For example, if the BW is 100 ms, when the response40is eventually retrieved from the buffer42it is guaranteed that the response40has been there no more than 100 milliseconds.

(3) Long Delay (46)—The Long Delay46is the amount of time that the host controller12will wait before resending a message to the multiplexer14after receiving the “DR_INITIATE” (the message38) response code from the multiplexer14. A Long Delay value is maintained for every command of every instrument that uses the multiplexer delayed response mechanism, with this historical data preferably being suitably stored. The time value of the long delay46is constantly updated and is central to the optimization algorithm as the adjustments to the long delay46are what allows the host controller12/the host software32to optimize communications efficiency by obtaining the response40from the buffer42of the multiplexer14as soon as possible after the response40arrives in the buffer42.

(4) Short Delay (51)—The Short Delay51is the amount of time added to the MT time needed to arrive at the Bracket Width50. The short delay51is applied whenever a “DR_RUNNING” response code (the message38sent to the host controller12by the multiplexer indicating that the embedded message36has been forwarded to the device16). The Short Delay51is calculated as follows:
Short Delay 51= Bracket Width−Message Turnaround;
Or, short delay 51= bracket width 50− MT
FIG. 3illustrates the relationship between the Short Delay51, the Message Turnaround time MT and the Bracket Width50.

(5) Delayed Response Count (DR Cnt)—A Delayed Response Count58indicates the number of DR_RUNNING responses (e.g., the message48) received by the host controller12from the multiplexer14before finally obtaining the device response40from the buffer42of the multiplexer14for a given command or message. This value is set to zero when the message34is first sent, and is incremented each time a “DR_RUNNING” response code (the message48) is received from the multiplexer14. This Delayed Response Count58is then used to adjust/calculate the Long Delay46that will be used the next time this same command is sent to this same device.

(6) Dead Time—The amount of time the response40sits in the buffer42waiting to be retrieved by the host controller12.

Given this background, exemplary goals of the algorithm embodied on the optimization cycle52include:

(1) To obtain the message response from the multiplexer as soon as possible after it arrives there (minimizes Dead Time).

(2) To do so with as few message retries as possible.

In accordance with the disclosed example, the optimization cycle52works as follows: Prior to sending the message34, the host software32calculates an initial value for the short delay50. The initial value for the short delay50will be indicated by501, with all subsequent values for the short delay50indicated by502,503. . .50n. The host software32also looks up a value for the long delay46, with this initial value for the long delay46indicated by461. Again, all subsequent values for the long delay46will be indicated by462,463. . .46n. SeeFIG. 6) The initial value461may be an existing value that was computed the previous time that this particular message34was sent to this particular device16. In the event that this is the first time that this particular command or message34has been sent to this particular device16, the initial value461may be calculated in much the same manner that the message turnaround time is calculated.

Referring toFIG. 4, when the message34has been sent from the host controller12to the multiplexer14, and when the reply38has been received by the host controller12, the host controller12will enter the waiting period indicated by the long delay46, which in this case is the initial long delay461. After the expiration of the long delay46i, the host controller12will initiate the first re-send44a. In the event the response40is not yet in the buffer42of the multiplexer14, the multiplexer14will send the message48indicating that the response40has not yet been received from the device16. If necessary, the host software32will wait the short delay period50before re-sending another message, e.g., the re-send44b. Upon the expiration of the first short delay period501, the host controller12will send the second re-send44b. This process of re-sending the message followed by a short delay period will be continued until the response40is present in the buffer42of the multiplexer14. As shown inFIG. 4, the response40is received at the buffer42during the fourth short delay period504, which occurs shortly after the fourth re-send44d.

For a variety of reasons, it may be undesirable to have so many communications occurring between the host controller12and the multiplexer14, as evidenced by the need for sending the initial message38and for re-sends44athrough44b. Accordingly, in referring now toFIG. 5, the optimization cycle52involves adjusting the long delay46. In this case, the long delay46will be indicated by the second long delay period46ii. As shown inFIG. 5, the response40is present in the buffer42of the multiplexer14after one re-send44a. However, the response40is not communicated to the host controller12until the occurrence of the second re-send44b. The response40is communicated to the host controller12after the expiration of the initial short delay50i. Note that the response40is present in the buffer42for a period of time prior to the second re-send44bbeing sent, with this period of time being referred to as a “dead time”54.

From a re-try count efficiency standpoint (the re-try count being indicated by the number of re-sends required44a,44b, etc.), it would seem more logical to attempt to retrieve the response40with no re-sends44a,44b, etc. Although this is possible, there is no guarantee how long the response40has been waiting in the buffer42to be retrieved. Ideally, the response40will be present in the buffer42with minimal dead time. However, if the initial value461(or any of the subsequent values462,463, etc.) for the long delay are sufficiently long, it can practically be guaranteed that the response40will be present in the buffer42upon the occurrence of the first re-send44a. However, simply lengthening the long delay period46may result in a situation where the dead time54is unduly long, as the message response40may have been sitting in the buffer42for almost the entire long delay period46, which would be a worst-case scenario. Such a situation may be exacerbated by volatile environmental conditions, such as having a secondary master or having the device in burst mode, which tends to cause significant increases in the long delay period.

Referring now toFIG. 6, throughput and efficiency may be further maximized beyond simply lowering the number of delayed responses. Accordingly, the optimization cycle52will further optimize the long delay46in order to minimize dead time54. Once the long delay46has been set at a value that results in the response40being present in the buffer42upon the first re-send44a, the long delay46becomes optimization-eligible. Once the long delay46is optimization eligible, the optimization cycle52searches for an optimization fail-point56. The optimization fail-point is found by continuously shortening the long delay46over time, as shown inFIG. 6. As the long delay46is shortened, eventually the long delay46will become sufficiently short that a second re-send44bis required. This fail-point56is found by gradually reducing the long delay46on each successive message which causes the brackets indicated inFIG. 5to gradually shift toward the left (for discussion purposes, the point at which the response40is received in the buffer42is assumed to be constant). As the brackets shown inFIG. 5shift toward the left, the dead time54is gradually reduced. Preferably, each subsequent long delay period is slightly shorter than the preceding long delay period, with the interval shown inFIG. 6being equal to approximately 2 milliseconds. Other intervals may be chosen by the user. However, according to the disclosed example the interval of approximately 2 milliseconds has yielded favorable experimental results.

Referring now toFIG. 7, after the long delay46has been sufficiently shortened, it is evident that a second short delay50is required in order to retrieve the response40from the buffer42, which response40is not retrieved until the third re-send44c. This is an indication that the fail-point56has been reached.

Once the fail-point56has been calculated, the long delay46is increased by a pre-determined amount, which in the disclosed example is approximately 25% of the bracket width. Referring to either ofFIG. 4,5, or7, it will be understood that increasing the long delay46will again shift the brackets toward the right when viewing the figures. This 25% increase in the long delay46will once again shift the long delay46back to an optimization-eligible state, at which point the long delay46will again enter the optimization cycle52.

The optimization cycle52according to the disclosed example will account for the fact that the reply times for the exact same message are not actually constant. In actuality, the reply times may vary slightly, even in a stable environment, and will vary significantly in an unstable environment. Thus, the optimization cycle52will account for changing environmental conditions and enable the host system10to operate efficiently while minimizing the dead time54. Because of the varying environmental conditions which affect the communication times, the fail-point56can never be established with absolute certainty. Accordingly, exactly when the response40is received by the buffer42within the initial short delay period50i, can never be known with absolute certainty. However, the optimization cycle52provides a reasonable guarantee that all communications are actually completed within 25% or less of the fail-point56. Ideally, the fail-point56would be indicative of zero dead time.

The optimization cycle52functions similarly to the optimization-eligible state in that the long delay46is reduced until the fail-point56is reached. However, the algorithm for reducing the long delay46is more logrithmic in nature. The closer the optimization cycle52gets to achieving a zero dead time (e.g., the closer the optimization cycle52gets to the fail-point56), the optimization cycle52will send more messages in any given long delay period46. As shown inFIG. 8, the long delay period46is adjusted downward relatively quickly early on in the optimization cycle52. On the other hand, as the number of subsequent messages increases, the more subsequent messages will be sent using any particular long delay period46. Stated in another way, as the optimization cycle52approaches the fail-point56, more and more subsequent messages are sent for any given shortened long delay period46. Thus, according to the disclosed algorithm, the optimization cycle52will seek to maximize the number of messages being sent with the long delay being set as close as possible to the fail point56.

The transition from one to two delayed responses (e.g., the transition between requiring only a single re-send44aand requiring at least a second re-send44b) is expected during the operation of the optimization cycle52. However, if zero re-sends are required, or if more than two re-sends are required, the optimization cycle52may be canceled, and a more significant correction to the long delay46may be applied in order to return the communication cycle to the status reflected inFIG. 5in which only a second re-send44bis required. Once this transpires, the optimization-eligible state is established and the search for the fail-point56begins again. Subsequently, the optimization cycle may be started again after the fail-point56has been established. According to the disclosed example, the optimization cycle52may constantly adjust to changing environmental conditions and “learns” how to communicate any particular unique command to any particular unique device in a manner that seeks to maximize efficiency.

Referring now toFIGS. 9–11, the system10according to the present invention may be further explained as follows. As shown inFIG. 9, the host system10initiates the sending of a message34at60. At62, the message34is inserted in a message queue64based upon the priority of the message and the send time of the message. Once the message34is in the HART message queue64, the time to send the message is signaled at68, after which the message34is obtained from the message queue at70. The steps at66,72,74,76,78and80are optional and need not be performed in order to carry out the optimization cycle52.

Proceeding now to block A ofFIG. 10, the message34is sent at82, after which a determination is made whether the reply38has been received at84. If the reply38has been received, then the status is updated at86to reflect that the reply38has been received. At this point, the host software32runs the optimization cycle52. The optimization cycle52sets the delayed response flag at88followed by obtaining the initial value for the long delay46and the short delay51at 90. The send time is then established at 92 to equal the long delay46, after which the message is reinserted in the message queue based upon the priority and send time at 94 (FIGS. 9 and 10).

At 96 it is determined whether the status indicates that the delayed response count is still being counted. If the answer is “yes”, then at 98 the delayed response count is incremented, and the send time is set to be equal to the short delay51at 100. This information is communicated to 94, for establishing the priority and send time. If the status of the DR running code is indicated as “no”, then at 102 it is determined whether the status of the message is successful. If the answer is “yes”, then at 104 the host controller12will adjust the long delay46and the short delay51and store this information for the next time that this unique message34is sent. If the answer to the status inquiry at 102 is “no”, then at 106 an error condition is handled in an appropriate manner. Each of the determinations made at 84, 104, and 106 are then communicated at 108 back to the controller12.

The output of the status determination at 102 is next communicated via block C inFIG. 10to block C inFIG. 11. As shown inFIG. 11, the baud rate and message size are used at 110 in order to calculate the MT. Next, at 112, the short delay51is set to be equal to the bracket width (BW) minus the message turnaround time (MT). At 114, the short delay51is adjusted for any known variability in the message response size for this type of message (based on historical data for this particular message and/or any other historical data for the particular field of the unique field device for which the unique message is intended). At 116, the current delayed response count is compared with the previous delayed response count, and at 118 the long delay46is adjusted up or down as necessary in order to arrive at a delay response count of 1 the next time that this unique message is sent. It will be understood that the magnitude and direction of the adjustment depends on the difference between the delay response count and how far the current delay response count is from the target bracket. In the disclosed example, the target is a delay response count of 1. At block D this information is then communicated back to 108 for transmission to the host controller12.

In accordance with the disclosed example, the HART multiplexer communications optimization cycle52allows the host software32run by the host controller12to retrieve responses40from the device16as soon as possible after the response40has arrived in the response buffer42of the multiplexer14, with the dead time being, on average, in the neighborhood of about 6–10 milliseconds. This arrangement serves to seek additional efficiencies in communications performance over a multiplexer network.

Those skilled in the art will appreciate that, although the teachings of the invention have been illustrated in connection with certain embodiments, there is no intent to limit the invention to such embodiments. On the contrary, the intention of this application is to cover all modifications and embodiments fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents.