Exemplary embodiments of the present invention are directed to systems and methods for supporting two different protocols on the same physical connection in a network of master and slave field bus devices. As used herein, master and slave field bus devices are those that can be connected in a line or ring topology and where the protocol has strict timing requirements. The strict timing requirements can be due to a short time lapse between sending a request and receiving the response in a polled network or due to pre-assigned time slots for the packets in a cyclic network. Additionally, such devices are configured so that there is at least one master device and it either polls the slave devices or else sets up a schedule of cyclic communication.
There are known several field bus communication protocols in this category, including but not limited to EtherCAT (IEC 61158 and IEC 61784-2), SynqNet (such as those disclosed in U.S. Pat. Nos. 7,969,985, 7,460,471, 7,406,354, 7,143,301, and 7,024,257) and Varan (as specified by the Varan Bus User Organization). These field busses all use the Ethernet physical layer (ANSI X3.263: 1995 TP-PMD and section 25.2 of IEEE802.3-2002). These field busses are well-known in the art and will not be described in further detail. Although the following discussion focuses on EtherCAT, the present invention can be implemented with any other type of field bus.
FIG. 1 is a block diagram of a conventional master-slave arrangement. As illustrated in FIG. 1, a master device 100 is connected to a first slave device 110 via cable 103, which in turn is connected to an intermediate slave 120 via cable 113. Intermediate slave 120 is connected by cable 123 to final slave 130. The cables 103, 113, and 123 can be conventional Ethernet cables, which carry the field bus packets. As illustrated in FIG. 1, each slave has two full-duplex, bi-directional, field bus ports designated X and Y. Thus, the master 100 is connected to the X port 111 of the first slave 110 and the Y port 112 of the first slave 110 is wired to the X port 121 of the second slave 120 and so on until the last slave of the network 130, where X port 131 is connected to the final slave 130, but the Y port 132 of the final slave is unused. For ease of understanding, and not for purposes of limitation, FIG. 1 and subsequent figures illustrate only a first slave, intermediate slave and final slave. One skilled in the art, however, would recognize that such field bus arrangements can include more than one intermediate slave, in which case the operation of further intermediate slave devices would be the same as the disclosed intermediate slave.
During their service life and especially during commissioning, field bus slave devices typically require programming while connected in a network, which is achieved using a device known in the art as a configurator. FIG. 2 is a block diagram illustrating a conventional arrangement for programming field bus slave devices using a configurator. Specifically, each slave device includes an auxiliary port 211, 221, 231, which can be coupled to an Ethernet switch 250. Configurator 240 is also coupled to the Ethernet switch 250, which allows configurator 240 to program slave devices 110, 120 and 130 using TCP/IP formatted packets. This arrangement provides a separate and distinct physical transmission path for configuration programming from the field bus data, which is important given that the field bus data is formatted with a protocol that is time-sensitive.
FIG. 3 is a block diagram illustrating the some of the internal components of a conventional first, intermediate or final field bus slave device. As illustrated in FIG. 3, the X port 111, 121, 131, Y port 112, 122, 132 and auxiliary port 211, 221, 231 have a similar structure, including a physical connector, a pair of transformers and a PHY device, which is a transmitter and receiver circuit. Field bus logic module 311 is coupled to the X port 111, 121, 131 and Y port 112, 122, 132 in order to interact with field bus packets, which includes reception, transmission and modification (if necessary) of field bus packets. The field bus logic module 311 is typically implemented as field programmable gate array (FPGA) or an application specific integrated circuit (ASIC). For ease of explanation, and not limitation, the following discussion will refer simply to an FPGA. However, an ASIC can be used as an alternative. FIG. 3 also shows the auxiliary port 211, 221, 231 which allows TCP/IP communication with microcontroller 312. In this case, the microcontroller itself has a built-in Ethernet MAC. The auxiliary port is essential for connecting the configurator in the manner of FIG. 2, however it will be omitted from all further figures as this invention renders the auxiliary port unnecessary.
The overall operation of the slave is typically controlled by microcontroller 312, which is coupled via processor bus 313 to field bus logic module 311. It should be recognized that the microcontroller 312 can be a microprocessor, a digital signal processor or similar device, any of which may be integrated into the same FPGA or ASIC as the field bus logic module 311. Processor bus 313 can be a conventional parallel processor bus or a serial connection such as SPI, so that microcontroller 312 can respond to commands transmitted via the field bus. For ease of explanation, the sensor/actuator aspects of the slave device have been omitted as the invention is not concerned with these aspects.
FIG. 4 is a block diagram of some of the internal components of a conventional first or intermediate slave device handling field bus packets. In the case of EtherCAT, field bus packets arriving at X port 111, 121 pass into the field bus logic module 311, where the packets are modified (if required) or otherwise acted upon and then pass out to the next downstream slave device via Y port 112, 122. Conversely, packets arriving from a downstream slave device at Y port 112, 122 are the forwarded to X port 111, 121 via field bus logic module 311.
It should be recognized that other field busses behave slightly differently. For example, SynqNet also allows a slave to originate packets that are normally sent via the X port. The variations in the operation of the field bus logic module 311 do not affect the essential operation of the present invention.
FIG. 5 is a block diagram of some of the internal components of a conventional final slave device handling field bus packets. As is evident from FIG. 1, the final slave device, unlike other slave devices, does not have a downstream slave device connected on its Y port 132. Accordingly, field bus logic module 311 in the final slave 130 is able to detect, using the link or activity signals from the PHY in the Y Port 132, that there is nothing attached to its Y port 132, and the final slave 130 puts itself into loop-back mode. In this mode, packets that would otherwise be transmitted via the Y port 132 to a downstream slave are instead returned to the master via the X port 131 of the final slave. Accordingly, as illustrated by the dashed representation of Y port 132 in FIG. 5, if the slave is at the end of the chain then the Y port 132 is unused.
Thus, as illustrated in FIG. 6, where the field bus nodes are connected in a line, the Y port 132 of the final slave 130 is deactivated.