MXPA00005508A - Messaging application layer (modbus) over ethernet to transport layer (tcp) communications method and apparatus - Google Patents

Abstract

A communications adapter (10) is provided for interfacing between a master device (12) and an I/O device (14) (body) having an output and/or an input. In the case of the I/O body (14) having an output, the adapter has a TCP port for coupling to the master device via a trasmission path for receiving a request message. The adapter (10) also has a connector for operable coupling to the I/O device (14) for receiving the output of the I/O device. The adapter (10) further has an interface circuit operably connected to the TCP port and the connector for transmitting a response message over the transmission path in response to the request message, the response message correlating to the output received from the I/O device. The request message and the response message is limited to a length that is less than a TCP transaction length and/or a maximum transmission unit limit, or both, depending on the embodiment of the present invention.

Description

METHOD AND APPARATUS OF LAYER COMMUNICATIONS APPLICATION OF MESSAGING ÍMODBUS) BY ETHERNET TO LAYER OF TRANSPORTATION (TCP) Description Technical Field The present invention relates to terminal input and output (I / O) interfaces for communication between input and output field devices, and programmable logic controllers (PLCs), and for communication between input field devices and output, and other field master devices, such as a host device. More specifically, the present invention relates to a modular I / O terminal interface for ETHERNET communication encoded MODBUS to TCP. BACKGROUND OF THE INVENTION Within the market of industrial automation systems, there are various types of communications network protocols that were developed for products, such as PLCs, to run on products to be connected together in a network, and for field devices to be monitored and controlled from various places within the particular automation systems. In this way, various types of input and output communications devices have been produced to communicate within the various types of communication protocols for the various types of communication networks for the automation systems. For example, Figure 2 shows various types of communication protocols, such as Interbus-S, Profibus DP, Modbus Plus, Echelon, Seriplex, CAN DeviceNet, CAN SDS, and CANCAL, to name a few. An additional protocol is FIPIO. Each of these various types of communication network requires specific input and output devices for communication with input and output field devices based on the various types of communication protocols, each having specific and different communications requirements. Furthermore, not only each network protocol requires different input and output communications devices for communication with the various previous protocols, but there is also a need to have input and output communications devices for communication directly with the PLCs. The communication between the PLCs and the input and output communications devices may still have another type of communication protocol, which may require different types of input and output communications devices for each different type or PLC brand. The present invention is provided to solve these and other problems. SUMMARY OF THE INVENTION The present invention is a communication adapter for interface between MODBUS by ETHERNET to TCP for the communication of information between field devices and a field master using these types of protocols. Field devices can include devices such as digital or binary inputs, digital or binary outputs, analog inputs, analog outputs, QPR units or other special units, and INTIO devices, to name a few. Field masters can include programmable logic controllers (PLCs) (sometimes referred to as process control devices or PCDs), application-specific controllers, and host computers / devices such as a personal computer, with industrial automation software running on they. For example, U.S. Patent No. 5,611,059 discloses various types of controllers within a control structure for interfacing with field devices, as well as the user interface of a personal computer having industrial automation software running on it. The communications adapter is to provide an interface between a master device and an I / O device (body) having an output and / or an input. In the case of the I / O body having an output, the adapter has a TCP port to be coupled to the master device via a transmission path to receive a request message. The adapter also has a connector to operatively couple to the I / O device to receive the output of the 1/0 device.

The adapter further has an interface circuit operatively connected to the TCP port and the connector for transmitting a response message along the transmission path in response to the request message, the response message correlating with the output received from the 1/0 device. The request message and the response message are limited to a length that is less than a TCP transaction length and / or a maximum limit of transmission unit, or both, depending on the embodiment of the present invention. The present invention also includes a method for providing a connection between a master device and an I / O device having an output and / or an input. In the case of the method for providing a connection between a master device and an I / O device having an output, the method includes receiving via a transmission path a request message on a pre-registered TCP port selected from a plurality of TCP ports. The method also includes receiving the output of the I / O device. The method further includes transmitting a response message along the transmission path in response to the request message, the response message correlating with the output of the I / O device. The request message and / or the response message are limited to a length that is less than both a TCP transaction length and / or a maximum transmission unit limit, or both, depending on the embodiment of the present invention. . In the case of a method for providing a connection between a master device and a 1/0 device having an input, the method includes receiving via a transmission path a request message on a pre-registered TCP port selected from a plurality of TCP ports. The method also includes transmitting a response message along the transmission path in response to the request message. The method further includes transmitting data to the input of the I / O device in response to the request message. The request message and / or the response message are limited to a length that is less than a TCP transaction length and / or a maximum limit of transmission unit, or both, depending on the embodiment of the present invention. The communication adapter (adapter or adapter COM) is attached to an entry / exit body, as described in U.S. Patent Application Serial No. 09 / 036,565 and / or German Patent No. DE 196 15 093, which are incorporated herein by reference . Specifically, the communication adapter is configured to directly connect and configure through at least one input data port, the output data port, and the identification port of the input / output body. In addition, the communications adapter is also configured to communicate with MODBUS by ETHERNET field masters. The communications adapter may have an input multiplexer to accept data from the input data port and the identification port, an output multiplexer to provide data to the output data port, and a processor to communicate with the input multiplexer and the output multiplexer. The processor is also provided to convert the data received from the input multiplexer and the output multiplexer. Field bus (bus) circuits are also connected between the processor and the field bus (bus), inside the communication adapter, to allow the processor to communicate with the field master on the field bus (bus) . Alternatively, the communication adapter has at least one application-specific integrated circuit (ASIC) to accept data from the input data port and the identification port, and to provide data to the output data port. The ASIC converts the data to and from MODBUS through an ETHERNET communications protocol of a PLC type field master. The present invention can take the form of a communication adapter adapted to only one input body or only one output body having the same advantages and the total input / output body, as will be understood with reference to the antecedents previously incorporated. In this way, the invention allows using standard, inexpensive network components instead of specialized, real-time field bus bar components to communicate with industrial sensing devices and actuators. This allows for greater cost and complexity savings when connecting simple devices to a network solution involving programmable controllers or other industrial computer systems, since the same network infrastructure components can be shared. Other advantages and other aspects of the present invention will become apparent upon reading the following description of the drawings and the detailed description of the invention. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a perspective view of the entry / exit body, with the communication adapter of the present invention attached thereto. Figure 2 is a graph of modularity showing the flexibility of the present invention. Figure 3 is a block diagram of the internal structure of the present invention. Detailed Description Although this invention is susceptible of embodiments in many different ways, a preferred embodiment of the invention will be described in the drawings herein and will be described in detail, with the understanding that the present disclosure should be considered as a preferred embodiment of the invention. exemplification of the principles of the invention and is not intended to limit the broad aspects of the invention to the illustrated embodiments. With reference to Figure 1, the present invention is a communications adapter (COM adapter) for connecting to and communicating with an input / output body (10) 2. The body of 10 2 forms an interface between field devices (not shown) in figure 1) and a field teacher (not shown in figure 1). The communication adapter will allow a base of 10 (body) to reside in an ETHERNET network and communicate using MODBUS messages over the TCP / IP protocol. Some abbreviations for this description can be defined as follows: MIÓ: ARP momentum terminal exit input: address resolution protocol, used to obtain the ETHERNET physical address, given the IP address MI interface: internal interface of 10 B00TP moment: protocol used when starting to associate a MAC address with an IP address COM adapter: ICMP communications adapter: indication and error control protocol Body 1/0: input / output body (base unit) IP: Internet network layer providing global addressing capability MODBUS: messaging application layer (read / write services) TCP: transport layer for point-to-point STP: shielded twisted pair The COM 10 adapter is to provide an interface between a master device 12 and an I / O device (body) 14 having an output and / or an input. In the case of the I / O device 12 having an output, the adapter 10 has a TCP port 16 to be coupled to the master device 12 via a transmission path 18 to receive a request message. The adapter 10 also has a connector 20 to operatively couple to the I / O device 14 to receive the output of the I / O device 14. The adapter 10 further has an interface circuit 22 operatively connected to the TCP port 16 and the connector 20 for transmitting a reply message on the transmission path 18 in response to the request message, the request message correlating with the output received from the I / O device 14. The request message and the response message are limited to a length that is less than a TCP transaction length and / or a maximum limit of transmission unit, or both, depending on the embodiment of the present invention. The TCP port selected in the COM adapter must be TCP port number 502, in accordance with the design assumptions for an embodiment of the present invention, which are provided further below. In addition, the assumptions also provide that the interface circuit ignores a connection request received by the transmission path for another TCP port. In addition, the interface circuit discards a message of unknown significance received by the TCP port. The interface circuit closes the transaction path in response to an error received by the TCP port. In addition, the interface circuit transmits an address resolution protocol response along the transmission path if an Internet protocol address encoded with the request message matches the Internet protocol address associated with the I / O device. The interface circuit also transmits a connection confirmation in response to a TCP connection request. The present invention also includes a method for providing a connection between a master device 12 and an I / O device 14 having an output and / or an input. In the case of the method for providing a connection between a master device and an I / O device having an output, the method includes receiving via a transmission path 18 a request message on a pre-registered TCP port 16 selected. of a plurality of TCP ports. The method also includes receiving the output of the I / O device. The method further includes transmitting a reply message along the transmission path in response to the request message, the request message correlating with the output of the 1/0 device 14. The request message and / or the response message are limited at a length that is less than either a TCP transaction length or a maximum transmission unit limit, or both, depending on the embodiment of the present invention. In the case of the method for providing a connection between a master device 12 and a 1/0 device 14 having an input, the method includes receiving via a transmission path 18 a request message on a selected pre-registered TCP port 16. of a plurality of TCP ports. The method also includes transmitting a response message along the transmission path in response to the request message. The method further includes transmitting data to the input of the I / O device 14 in response to the request message. The request message and / or the response message are limited to a length that is less than a TCP transaction length and / or a maximum limit of transmission unit, or both, depending on the embodiment of the present invention. MODBUS is an industrial control protocol that is a widely implemented standard where each transaction is independent and comprises a couple of request message and response message, each of limited length. The length of the request and response messages is such that the encapsulated message, when sent as part of a standard TCP connection, is less than both the TCP "window" and the maximum transmission unit (MTU) limits. In addition, because the response of a previous transaction must be received before the request for the next transaction can be sent, there is no reason to break, or "fragment," a MODBUS message when it is transmitted over TCP. The result is that there is a direct relationship between the encoding of the MODBUS message and the TCP frame coding in any given network. By making several simplifying assumptions about the relationship between the target "slave" device and its interrogation "master" device, the obligations of the reception software (see Appendix A) can be reduced from the traditional "network protocol stacking" consisting of in several interaction software components (see Appendix A) to a simpler "state machine" where the correct response to an incoming request can be quickly determined from the content of the start of the request message. For an embodiment of the present invention, the following are the significant assumptions: -All the requests will be initiated in the "master". This means that the slave has no need to initiate connections or resolve domain name service (DNS) names. -All requests will appear on TCP port number 502, which is already registered with the Internet Assigned Numbers Authority (IANA) in order to be a MODBUS traffic carrier. This means that connection requests tried on other ports can be ignored. -The slave can assume that a valid return path to the master is either "direct" or can use the network bridge device that was the last to process the request message on its way to the device. This means that it is not necessary to maintain IP routing tables or understand ICMP redirection messages. -It is appropriate, if presented with a message of unknown meaning, to discard the message because the device is hiding behind a "network fire wall" device. -The appropriate response to any MODBUS protocol or coding error is to unilaterally close the TCP connection. As a result, the MODBUS / TCP / ETHERNET implementation, as an example, can implement largely pre-calculated responses to the following messages: - Address resolution protocol request (ARP) - send ARP response if the IP address is the same. - Internet control administration protocol echo request (ICMP PING) - send PING response (to assist in the installation and resolution of standard network problems). - TCP connection request (SYN) - send connection confirmation (SYN ACK) if the port requested is number 502, ignore in other cases. - Request for TCP disconnection (FIN) - send disconnection confirmation (END ACK). - MODBUS request as TCP data box - send MODBUS response as a TCP data box, generating most of the protocol prefix information from the equivalent information in the request. As a result, performance is increased by at least two significant respects compared to a traditional implementation: -The amount of network traffic is reduced because each MODBUS transaction typically involves only two messages (the encoded request and response) . A traditional protocol stack generates four messages (adding an ACK message for each transmitted data unit). This results in a saving of 20 to 50% of network traffic, allowing the same network components to handle an additional performance of 25 to 100% at no additional cost. The calculation time in the slave is drastically reduced, allowing less expensive and simpler microprocessors to be replaced by more expensive ones and still achieve the same effective response performance. At the same time, compatibility with conventional protocol stacks in large computers is maintained, because compliance with the standard coding for MODBUS by TCP has not been violated.

In the present invention, the ETHERNET (MAC) address for the COM adapter may be stored in flash memory. The COM adapter can operate on a standard ETHERNET network that must include a BOOTP server. A commercially available BOOTP server can be used for this purpose. The COM adapter communicates using MODBUS messages over TCP / IP to a N0E2X1 module, a host computer, or any device that uses the MODBUS protocol over the Internet. The COM adapter will be compatible with at least host programs running on Windows 95, Windows NT, and UNIX TCP / IP stacks. The COM adapter must meet the main international standards: U.L., C.S. ., F.M., and CE. The COM adapter allows the connection of all MIÓ cards with ETHERNET. Used with the COM adapter, the MIÓ cards will provide at least the following functions: exchanges of input and output data; administration of parameters (at the time of initialization and run time); diagnostic information (LEDs, communications statistics); and download new operating software (see Appendix A) for the ETHERNET connection. The external accesses to the ETHERNET COM adapter are: - RJ45 female connector for connection to the 10-BASE network T. -2 LEDs - run: green LED. They indicate the operating status of the module. Communication: Green LED. Indicates the activity of the network. The mode of operation is as follows: Initialization: when turned on, kernel firmware (see Appendix A, which is incorporated herein by reference) will perform internal initialization and self-tests. If the self-tests fail, a run LED will flash, if possible, indicating a reason for the failure. In this state, the COM adapter does not attempt to communicate over the network. If the initialization is successful, the COM adapter then requests its IP parameters (IP address, default gateway, and subnet mask) using the BOOTP protocol over the ETHERNET network and the MAC address stored in a non-volatile memory. The COM adapter will wait ten seconds for a BOOTP server to respond before trying again. The COM adapter will retry six times, three times using ETHERNET II frame type, and three times using the SNAP 802.2 header. If a server does not respond, the COM adapter will use the last valid IP address stored in flash memory. If there is no valid IP data, the COM adapter will flash the run LED in a specific pattern and retry the BOOTP request every 30 seconds. If the IP parameters are obtained successfully, the kernel (firmware) perform a checksum test on the executable image. If the image is invalid, the kernel will put the I / O base in a safe mode, the run LED will flash with a pattern indicating its condition and wait for a sequence of unload command at the ETHERNET port. After receiving its network parameters, the COM adapter runs an identification procedure with the body of 1/0. If the identification procedure fails, the run LED flashes a fault code. When the initialization phase is completed successfully, the COM adapter is ready to communicate using the MODBUS protocol over TCP / IP. The run LED will be on steady. The COM adapter will enter the fault state if the I / OERR signal is pulled by a complex 1/0 body for more than one second. If the I / OERR signal is pulled by a simple I / O card, the COM adapter remains in a stable state. The run LED will indicate the fault condition and the I / O base will be forced to a safe state. Regarding the download, at any time after successfully obtaining your IP information, the adapter COM will accept MODBUS commands with function code 125 to download executive code. Downloading the executive code should be understood in the matter. When kernel software is captured (see Appendix A), the unit will place the I / O in a secure state and enter the kernel. The run LED will flash the code, indicating that a download is in progress. During download of the kernel, only MODBUS 125 commands will be accepted. When the download is complete, the unit will flash the sequence of the LED, indicating that a download is required. The following describes the I / O operating modes.

The COM adapter will not support point or global data. The COM adapter has three groups of internal registers: module data, configuration, and status. The three groups of registers can be accessed by the ETHERNET network through standard MODBUS commands to ensure compatibility with existing devices (ie user's logical MSTR block). The COM adapter will restrict write access to the first node that communicates with it. The COM adapter will maintain this lock until communication with the master expires. The COM adapter will allow the master to specify up to three other "owners" in order to facilitate the efficient implementation of hot standby systems. The user can access various registers to obtain I / O module information via the ETHERNET network. These internal registers are mapped to emulate 4xxxx registers that allow to use read / write 4xxxx registration commands (ie, using an MSTR block). Below is a table that shows data flow between the ETHERNET network and the internal registers of the COM adapter: The data group information is as follows: the input buffer scheme captures a slide of all the input data. The output damper scheme ensures that the most recent copy of the output data (only one buffer) is written to the output modules. A special algorithm is also used to ensure that no old data is lost, during a single word update of a multiple word output header field.

The configuration group records are as follows: the configuration group contains three records that are used by the COM adapter: a module retention time record, a write privilege record, and a save IP parameter record. A block of records in this area is reserved for use by distributed I / O. Module retention: the module retention time expiration is the amount of time that the output modules are kept in their current state without being updated by MODBUS writing commands. The expiration of module time is a word in offset F001. This record can be read from and written to using MODBUS commands, and the default value is 100 (1 second). The module time expiration word is in increments of 10 msec, with a minimum value of 30 (300 msec) and a maximum value of 6,000 (60sec). All values outside this range will be recorded as illegal data address errors. The write access is restricted to the current "master". Another timer is the expiration of reservation time. The COM adapter is dedicated to an ETHERNET device. The expiration of reservation time is the amount of time (60 seconds) that the output module will be dedicated to an ETHERNET device that is no longer communicating with it. If the time expires, the COM adapter will be dedicated to the next ETHERNET device that writes to it. If two ETHERNET devices wanted to write data to the same COM adapter, an ETHERNET device would have to wait for the expiration of the reservation time before it could write its data. This expiration of time is a fixed value, preferably 60 seconds, and is not accessible by the user (it is not changeable). Property registration: property registration is used so that more than one MODBUS device can have write access to the COM adapter. Up to three remote ETHERNET devices can have write access at the same time. This special case exceeds the reservation time limit. The property record is formed by six 'words beginning at the F401 place, two words for the IP address of each ETHERNET device. The default reading for each property record is zero (without owner). Register F401 contains the IP address of the first owner, register F403 the IP address of the second owner, and F405 contains the IP address of the third owner. The three owners have the same writing privileges. A fourth controller (ETHERNET device) can write to the COM adapter if the three known owners (ETHERNET devices) have ceased communication for more than the expiration of sixty seconds of reservation time. Record of saving IP parameter: this Boolean record is located in the F410 offset and determines the behavior of the COM adapter if a BOOTP server is not found at the time of initialization. If a one is written to the record, the current values of the IP parameters will be written to a non-volatile storage (memory). If a BOOTP server can not be found during the next initialization, these values will be used. If a zero is written to this record, any saved IP parameters will be deleted. A change in the status of this record will cause the COM adapter to be reset. Writing the record of saving IP parameter is restricted to the owner or owners (ETHERNET devices). MBP status group records: there are two records in the status group: the internal status record starts at offset F801 and the ASCII header record starts at offset FC01. Module status register (COM adapter): The following table shows the contents of the module status register: For purposes of this table: X = four upper bits reserved for station management commands, the four upper bits in this word will always be zero; R = (module revision number) REV 1.00 - lOOhex.

ASCII header block: There is an ASCII header block starting at offset F001. This heading is used to give a brief description of the module. The length of this block can be between one and sixty-four bytes. The length is contained in word six of the state register. This area is read only. Compatibility: The COM adapter is compatible with the ATI interface and will work with all 1/0 bodies operating in accordance with the ATI interface, as described in United States Patent Application Serial No. 09 / 036,565. MTBF quality specification: the mean time between failure (MTBF) reliability calculation model is based on MIL-HDBK-217 (a military standard). MTBF = 1 / failure rate. The specified value is calculated at 30'C, GB (benign earth). The MTBF goal is 200,000 hours. Performance: the stacking of communications is optimized to obtain the best possible performance for the MODBUS response time (time in issuing a response after receiving a TCP MODBUS request). The COM adapter will support a MODBUS / TCP transaction rate of one per millisecond, providing a function response code of 23 for a simple 32-bit input / output module (2 words) in 500 microseconds. A master can recover from a TCP disturbance by closing and reopening the plug connection. This sequence will not take more than 5 milliseconds due to delays in the COM adapter. Electrical specifications: For the ATI interface: Logic supply Vcc: 5V / ± 5% / 500 ma Max, supplied from the 1/0 body to the interface. The levels, the load and the timing will be in accordance with the other specifications of the ATI interface. For the ETHERNET interface: It complies with the 100 ohm STP connection. Tolerance of 5V ± 5% Current consumption 5V 200 ma max @ lOOμF load capac. Processor AMD186ER Memory 128 kbytes EPROM, 32 kbytes SRAM ETHERNET Crystal CS8900 Controller EMC Requirements: The COM adapter must satisfy the EMC tests described in the applicable standards. The COM adapter is considered as open equipment, which means that it must be inside a housing. The following tests can be carried out with shielded cable: Pass / fail criteria B for communications ports are acceptable. The COM adapter must meet the following agency standards: U.L. 508, 746C, 94. IEC 1131-2 (where applicable) CSA22.2 No. 142 CE Mark FM Class 1 Div. 2 The COM adapter in operation shall be maintained within the following ranges: Temperature: 0-60 'C , operation -40 to + 85'C, storage Humidity: 5-95% RH (without condensation) Vibration: 10.57 Hz @ 0.075 mm da 57-150 Hz @ 19 Impact: ± 15 G peak, 11 ms, half sine wave The COM adapter can have two LEDs, and use a shielded or unshielded ETHERNET RJ45 female connector. The shielding must be provided in 360 °, and good contacts must be provided with the external metal parts of the RJ45 male connector. The ETHERNET RJ45 output tip is: Tip 1: TX + Tip 2: TX Tip 3: RD + Tip 4: RD-MODBUS: the COM adapter will accept MODBUS messages via TCP / IP using the MBAP protocol to communicate with certain cards. The MODBUS 9 (read registers), 16 (multiple write registers) and 23 (read / write) function codes, which will be processed by software (see Appendix A), which is attached to the present one, and which is incorporated by reference in this, and they are passed to the ATI interface. Message 8, sub-function 21 (get / delete statistics), will return ETHERNET statistics similar to N0E2X1. MODBUS 125 commands will be processed by the kernel for executive download. The COM adapter will respond to all MODBUS messages with exception code 01 (illegal function). TCP / IP: the COM adapter will run an optimized communications stack. This stacking will allow the COM adapter to respond to MODBUS messages with minimum response time. You must also handle other network traffic, such as ARP requests and ICMP echo requests, in a manner consistent with the associated protocols. The COM adapter will receive its network parameters from a BOOTP-type server or use those held in non-volatile storage, if available. The MODBUS handler will manage requests from the network and respond directly or pass the request to the ATI interface. The handler will maintain the internal configuration and status registers, and arbitrate access to the COM adapter. The stacking of TCP / IP communications must be optimized in terms of performance. However, these optimizations should not affect their ability to function as a standard TCP / IP node in an integrated network. The kernel will provide basic services for the operation of the unit. These include timer services, interrupt handling, and controllers for peripherals such as the ETHERNET controller. Initialization and faults will also be handled by this code.

The application that served as the basis for the priority claim in the present application was filed in the United States simultaneously with the United States patent application with attorney's file No. 401 P 129, both having been assigned to Schneider Automation, the Assignee of the present application, whereby the other application is incorporated herein by reference to the extent necessary for the understanding of the present invention. Although specific embodiments have been illustrated and described, numerous modifications will occur without significantly departing from the spirit of the invention and the scope of the protection will only be limited by the scope of the accompanying claims.

Claims (18)

1. CLAIMS 1. A method for providing a connection between a master device and an I / O device having an output, the method comprising the steps of: receiving a request message on a selected pre-registered TCP port by a transmission path of a plurality of TCP ports; receive the output of the I / O device; transmitting a response message along the transmission path in response to the request message, the response message correlating with the output of the I / O device; and limiting the request message and the response message to a length that is less than tango a TCP transaction length as a maximum transmission unit limit. The method of claim 1, further comprising the step of receiving the incoming request message on a TCP port number 502. 3. The method of claim 1, further including the step of ignoring a connection request received from a device other than the master device. The method of claim 1, further comprising the step of discarding a message of unknown significance received by the transmission path. The method of claim 1, further including the step of closing the transaction path in response to an error. The method of claim 1, further comprising the step of sending an address resolution protocol response if an Internet protocol address encoded within the request message equals an Internet protocol address associated with the device of 1 / 0 The method of claim 1, further comprising the step of sending a connection confirmation along the transmission path in response to a TCP connection request. 8. An adapter for providing an interface between a master device and an I / O device having an output, comprising: a TCP port for coupling to the master device via a transmission path to receive a request message; a connector for operatively coupling to the I / O device to receive the output of the I / O device; an interface circuit operatively connected to the TCP port and the connector for transmitting a response message along the transmission path in response to the request message, the response message correlating with the output received from the I / O device, where the message of The request and the response message are limited to a length that is less than both a TCP transaction length and a maximum transmission unit limit. The adapter of claim 8, wherein the TCP port is the TCP port number 502. The adapter of claim 8, wherein the interface circuit ignores a connection request received by the transmission path on another TCP port. The adapter of claim 8, wherein the interface circuit discards a message of unknown significance received by the TCP port. The adapter of claim 8, wherein the interface circuit closes the transaction path in response to an error received by the TCP port. The adapter of claim 8, wherein the interface circuit transmits an address resolution protocol response along the transmission path if an Internet protocol address encoded with the request message matches an Internet protocol address associated with the I / O device. The adapter of claim 8, wherein the interface circuit transmits a connection confirmation in response to a TCP connection request. 15. A method for providing a connection between a master device and an I / O device having an input, the method comprising the steps of: transmitting a response message along the transmission path in response to the request message; transmit data to the input of the 1/0 device in response to the request message; and limiting the request message and the response message to a length that is less than a TCP transaction length and a maximum transmission unit limit. The method of claim 15, further comprising the steps of ignoring a connection request received from a device other than a master device, discarding a message of unknown significance received by the transmission path, and closing the transmission path in response to a transmission error. The method of claim 15, further comprising the step of sending an address resolution protocol response if an Internet protocol address encoded within the request message matches an Internet protocol address associated with the I / O device. OR. The method of claim 15, further comprising the step of sending a connection confirmation on the transmission path in response to a TCP connection request.