Patent Description:
Ethernet for Control Automation Technology (EtherCAT) is a protocol which is implemented based on Ethernet. According to the high speed and real-time communication capability, EtherCAT is getting more and more important in the field of industrial automation which pursues extremely accurate.

<CIT> provides a communication data processor easily adaptable to network configurations required for industrial Ethernet. The apparatus successively analyzes received packets. The apparatus uses a register to determine whether or not to transmit the received packet as transmission data to another port. Rewritable memory saves a program code that provides control for analyzing a reception packet and generating a transmission packet. The apparatus is capable of complying with various communication protocols by changing the program code.

Please refer to <FIG>, which is a schematic diagram showing packets transmission based on EtherCAT. As shown in <FIG>, an EtherCAT bus may include one EtherCAT master device <NUM> and one or more EtherCAT slave devices <NUM> (respectively referred to as the master device <NUM> and the slave device <NUM> hereinafter) according to different network topology adopted. An EtherCAT packet <NUM> (referred to as the packet <NUM> hereinafter) will be delivered to all of the slave devices <NUM> on the EtherCAT bus after being sent from the master device <NUM>. After receiving the packet <NUM>, each of the slave devices <NUM> may retrieve self-related data from the packet <NUM> or insert feedback data needed to be replied into the packet <NUM>, and then transmit such packet <NUM> to a next slave device <NUM> which is connected afterward. After being delivered to last one of the multiple slave devices <NUM> on the bus, the packet <NUM> will be then returned to the master device <NUM> through all of the slave devices <NUM> that have been passed, and a communication cycle will be finished after the packet <NUM> returns to the master device <NUM>.

Under a standard structure of EtherCAT protocol, each controller of each slave device <NUM> can only retrieve the self-related data from the packet <NUM> during a single communication cycle, but they are incapable of obtaining additional data with respect to other slave device(s) <NUM> at the same time. In other words, each slave device <NUM> cannot obtain all necessary data for operation during one single communication cycle. In conclusion, asynchronization problems will be caused when performing lower layer applications.

For example, the EtherCAT bus may be applied on a server driver of a processing equipment. The processing equipment requires multiple shafts thereon to be synchronized when processing (wherein, each shaft is respectively corresponding to one EtherCAT slave device <NUM>), if any of the shafts cannot obtain other shaft's data (i.e., the shaft(s) needed to be operated synchronously), then the multiple shafts will be incapable of operating synchronously due to the time interval before control commands respectively arrive each of the slave devices <NUM> after being sent out from the master device <NUM>. Therefore, components of the processing equipment may drag each other while working, therefore, energy of the processing equipment will be wasted, temperature of the processing equipment will be raised, lifetime of the processing equipment will be reduced, and processing quality of the processing equipment will be affected.

By the teaching or suggestion of current technologies, a master device has to send another command packet(s) to each shaft in a next communication cycle for each shaft to obtain necessary data with respect to related shaft(s). Then, the processing equipment may perform sychronized operation after all of the shafts obtain their necessary data. Therefore, the shafts of the processing equipment can work accurately and synchronously. However, such operation may extend the whole processing time, reduce the processing speed, and raise the processing cost. Besides, different command packets are used and sent at different communication cycles, a risk of getting inaccurate data may be noticed.

The present invention is defined in the appended independent claim <NUM> to which reference should be made.

In comparison with related art, the present invention may help an EtherCAT slave device to simultaneously obtain self-related data as well as data with respect to other slave devices without sending additional command packets, without affecting the content of the received/transmitted packets, under an unchanged EtherCAT protocol. Besides, by using the technical solution of packet diversion procedure, an EtherCAT slave device simultaneously obtains the self-related data as well as the data with respect to other slave devices within one single communication cycle. Therefore, multiple EtherCAT slave devices under such structure accurately performs synchronized operations when being applied in lower layer applications.

The present invention discloses a method for data hand-shaking based on EtherCAT (Ethernet for Control Automation Technology) protocol, the method for data hand-shaking base on EtherCAT protocol of the present invention will be referred to as the hand-shaking method hereinafter. The hand-shaking method is mainly applied by one or more slave devices on an EtherCAT bus, so the multiple slave devices achieves data synchronization with each other without additional command packets and interference from an EtherCAT master device. Besides, the data synchronization is achieved within one single communication cycle, therefore, synchronization rate is exetremly improved without affecting communication speed of the slave devices.

Refers to <FIG>, which is a block diagram of an EtherCAT slave device according to a first embodiment of the present invention. <FIG> discloses multiple EtherCAT slave devices <NUM> (referred to as the slave device <NUM> hereinafter), the multiple slave devices <NUM> are in series connection with each other, for delivering EtherCAT packets.

As mentioned, one of the technical features of the present invention is that, without amending and changing the standard structure of EtherCAT protocol, multiple slave devices <NUM> achieve data synchronization without using additional command packets. Further, multiple slave devices <NUM> achieve data synchronization within one single communication cycle under specific conditions without the interference of an EtherCAT master device (referred to as the master device hereinafter).

In particular, the master slave (not shown) is in series connection with the multiple slave device <NUM> under the standard structure of EtherCAT protocol, and is the first device arranged on the EtherCAT bus. During a packet transmission procedure, the master device sends an EtherCAT packet to each slave device <NUM> on the EtherCAT bus in an order for each slave device <NUM> to retrieve self-related data from the EtherCAT packet or to insert feedback data needed to be replied to the master device into the EtherCAT packet. During a packet returning procedure, a last one of the multiple slave devices <NUM> on the EtherCAT bus transmits a processed EtherCAT packet forward, so the processed EtherCAT packet will eventually returns to the master device through all slave devices <NUM> that has been passed before. In general, the time duration from one EtherCAT packet being sent out from the master device to the EtherCAT packet (i.e., the processed EtherCAT packet) being returned to same master device, is defined as one communication cycle.

As shown in <FIG> for details, a slave device <NUM> mainly includes an EtherCAT slave controller (referred to as the ESC hereinafter) <NUM>, an input port <NUM> and an output port <NUM>, wherein the ESC <NUM> is connected with the input port <NUM> and the output port <NUM>. The slave device <NUM> connects a previous data processing device (such as a master device or other slave device, not shown in the drawing) through the input port <NUM>, and connects a next slave device <NUM> through the output port <NUM> on the EtherCAT bus.

During a packet transmission procedure, the slave device <NUM> receives a data packet P1 through a previous data processing device (e.g., previous slave device <NUM>) through a first receiving route. The slave device <NUM> processes the received data packet P1 by the ESC <NUM> therein for transforming the data packet P1 into a processed data packet P2, and then transmits the processed data packet P2 to a next slave device <NUM> through a first transmission route on the EtherCAT bus.

During a packet returning procedure, the slave device <NUM> receives a returned packet P3 from the next slave device <NUM> through a second receiving route, and then directly transmits the returned packet P3 to the previous data processing device through a second transmission route.

As shown in <FIG>, the first receiving route at least includes a connection circuit (first connection circuit) between previous data processing device and the input port <NUM>, and includes a first receiving circuit (Rx1) between the input port <NUM> and the ESC <NUM>, the first transmission route at least includes a first transmission circuit (Tx1) between the ESC <NUM> and the output port <NUM>, and includes a connection circuit (second connection circuit) between the output port <NUM> and a next slave device <NUM>, the second receiving route at least includes a connection circuit (third connection circuit) between the next slave device <NUM> and the output port <NUM>, and includes a second receiving circuit (Rx2) between the output port <NUM> and the ESC <NUM>, the second transmission route at least includes a second transmission circuit (Tx2) between the ESC <NUM> and the input port <NUM>, and includes a connection circuit (fourth connection circuit) between the input port <NUM> and previous data processing device <NUM>.

One of the technical features of the present invention is that the slave device <NUM> performs a packet diversion procedure to the received/transmitted EtherCAT packets on at least one of the first receiving route, the first transmission route, the second receiving route and the second transmission route, therefore, necessary data related to other slave device <NUM> is retrieved by the slave device <NUM> directly from a packet generated by the packet diversion procedure. As a result, each slave device <NUM> simultaneously obtains self-related data as well as necessary data related to other slave device(s) <NUM> without generating and sending additional command packet(s). A slave device <NUM> simultaneously obtains self-related data which records information about itself and necessary data with respect to synchronization operation of one or more slave devices <NUM> which has been designated to be synchronized with, directly from the packet generated by the packet diversion procedure, and without sending/receiving additional command packet(s). Besides, each of the slave devices <NUM> simultaneously obtains the self-related data as well as data related to other slave device <NUM> within one single communication cycle, so as to achieve the purpose of accurate synchronization.

Refers to <FIG>, which is a hand-shaking flowchart according to a first embodiment of the present invention. <FIG> discloses each substantive step of the hand-shaking method, and the hand-shaking method is mainly implemented by one or more slave devices <NUM> as disclosed in <FIG>.

First, the slave device <NUM> receives a data packet P1 from previous data processing device connected to the input port <NUM> of the slave device <NUM> through the first receiving route (step S10). In particular, the slave device <NUM> in step S10 uses the input port <NUM> to receive the data packet P1 from previous data processing device through external circuit, and then uses the ESC <NUM> to receive the data packet P1 from the input port <NUM> through internal circuit. In other words, the first receiving route includes a connection circuit (first connection circuit) between the previous data processing device and the input port <NUM>, and also includes the first receiving circuit (Rx1) of the ESC <NUM> (which connects the input port <NUM> and the ESC <NUM>).

After the step S10, the ESC <NUM> obtains self-related data which records information about the slave device <NUM> itself from the data packet P1, or inserts feedback data which needs to be replied into the data packet P1, for transforming the data packet P1 into a processed data packet P2 (step S12). After the processed data packet P2 is generated, the slave device <NUM> then transmits the processed data packet P2 to a next slave device <NUM> connected to the output port <NUM> of the slave device <NUM> through the first transmission route (step S14).

In particular, the slave device <NUM> in step S14 uses the ESC <NUM> to transmit the processed data packet P2 to the output port <NUM> through internal circuit, and then uses the output port <NUM> to transmit the processed data packet P2 to a next slave device <NUM> through external circuit. In other words, the first transmission route includes the first transmission circuit (Tx1) of the ESC <NUM> (which connects the ESC <NUM> and the output port <NUM>), and also includes a connection circuit (second connection circuit) between the output port <NUM> and the next slave device <NUM>.

During a packet returning procedure, the slave device <NUM> receives a returned packet P3 from the next slave device <NUM> connected to the output port <NUM> of the slave device <NUM> through the second receiving route (step S16). In this embodiment, the ESC <NUM> of the slave device <NUM> will not process the returned packet P3, instead, the ESC <NUM> directly transmits the returned packet P3 to previous data processing device connected to the input port <NUM> of the slave device <NUM> through the second transmission route (step S18). In the end of the packet returning procedure, the returned packet P3 will be returned to a master device (not shown) on the EtherCAT bus.

In one embodiment, the slave device <NUM> in step S16 uses the output port <NUM> to receive the returned packet P3 from the next slave device <NUM> through external circuit, and uses the ESC <NUM> to receive the returned packet P3 from the output port <NUM> through internal circuit. In other words, the second receiving route includes a connection circuit (third connection circuit) between next slave device <NUM> and the output port <NUM>, and also includes the second receiving circuit (Rx2) of the ESC <NUM> (which connects the output port <NUM> and the ESC <NUM>). The slave device <NUM> in step S18 uses the ESC <NUM> to transmit the returned packet P3 to the input port <NUM> through internal circuit, and uses the input port <NUM> to transmit the returned packet P3 to previous data processing device through external circuit. In other words, the second transmission route includes the second transmission circuit (Tx2) of the ESC <NUM> (which connects the ESC <NUM> and the input port <NUM>), and also includes a connection circuit (fourth connection circuit) between the input port <NUM> and previous data processing device.

One of the technical features of the present invention is that the slave device <NUM> performs a packet diversion procedure to at least one of the data packet P1 (which is transmitted in the step S10), the processed data packet P2 (which is transmitted in the step S14) and the returned packet P3 (which is transmitted in the step S16 or the step S <NUM>), so as to generate a backup packet P4 based on the data packet P1, the processed data packet P2 or the returned packet P3 (step S20).

In one embodiment, the slave device <NUM> is to retrieve a part of the content from the data packet P1, the processed data packet P2 or the returned packet P3 in the step S10, the step S14, the step S <NUM> or the step S <NUM>, and then generates the backup packet P4 according to the retrieved content. In this embodiment, a part of the content of the backup packet P4 is identical to the content of the data packet P1, the processed data packet P2 or the returned packet P3.

In another embodiment, the slave device <NUM> duplicates the data packet P1, the processed data packet P2 or the returned packet P3 directly for generating the backup packet P4 upon the first receiving route, the first transmission route, the second receiving route or the second transmission route. In this embodiment, the content of the backup packet P4 is entirely identical to the content of the data packet P1, the processed data packet P2 or the returned packet P3.

After the step S20, the slave device <NUM> analyzes the backup packet P4 through the ESC <NUM> for filtering the content of the backup packet P4 and remaining designated application data related to other slave devices on the EtherCAT bus (step S22). After the step S22, the slave device <NUM> not only performs self function according to the self-related data obtained from the step S12, but also combines the self-related data with the designated application data obtained from the step S22 for accomplishing additional functions (step S24). As a result, the efficiency of synchronization operation among multiple slave devices <NUM> on the EtherCAT bus is improved.

It should be mentioned that, the single communication cycle discussed in the present invention is indicating a time duration that a packet being sent out from a master device on an EtherCAT bus, then passing through all of the slave devices <NUM> on the same EtherCAT bus, and eventually being returned to the master device. The aforementioned step S10 to the step S24 are done in one single communication cycle.

Please refer back to <FIG>. The slave device <NUM> further includes an exchange self-slave data module <NUM>, self-application function module <NUM>, packet diversion module <NUM>, designated data obtaining module <NUM> and extended application function module <NUM>. In one embodiment, the above modules <NUM>-<NUM> can be implemeted by hardware, such as an integrated circuit (IC). In another emobidment, the above modules <NUM>-<NUM> can be implemeted by firmware being pre-edited and recorded in chips, but not limited.

The slave device <NUM> of the present invention is implemented by a field programmable gate array (FPGA), an application specific integrated circuit (ASIC) or a microcontroller unit (MCU). A user of EtherCAT bus may accomplish each function of each module <NUM>-<NUM> through firmware, and records the firmware to FPGA, ASIC or MCU, so as to perform the hand-shaking method of the present invention by using the firmware as well as the ESC <NUM> in the chips.

More specific, the exchange self-slave data module <NUM> is used to obtain data from the ESC <NUM> retrieving from the the data packet P1. Besides, the slave device <NUM> may obtain such data from the exchange self-slave data module <NUM> through a communication interface of a digital signal processor (DSP), therefore, the self-application function module <NUM> may accomplish the slave device's <NUM> lower layer function according to the obtained data.

For example, the slave device <NUM> of the present invention can be applied in drivers of panel testers, computer numerical controllers (CNCs), multiple axes robots, etc., so as to control one or more axes of such devices. According to aforementioned data, each slave device <NUM> may respectively execute corresponding operation that has been designated to each driver by the self-application function module <NUM>. In one embodiment, such data can be, for example but not limited to, position feedback data, speed feedback data or torque feedback data of each driver with respect to each slave device <NUM>.

In the present invention, the packet diversion module <NUM> may be arranged on the first receiving route, the first transmission route, the second receiving route or the second transmission route.

In the embodiment shown in <FIG>, the packet diversion module <NUM> is arranged inside the slave device <NUM>, i.e., the packet diversion module <NUM> is arranged on the first receiving circuit (Rx1), the first transmission circuit (Tx1), the second receiving circuit (Rx2) or the second transmission circuit (Tx2), so that the packet diversion module <NUM> retrieves content of such packets (including the data packet P1, the processed data packet P2 and the returned packet P3) or duplicate such packets P1-P3 directly for generating the backup packet P4. However, in another embodiment, the packet diversion module <NUM> can also be arranged outside the slave device <NUM> (detailed discussed in the following).

The designated data obtaining module <NUM> obtains the backup packet P4 from the packet diversion module <NUM>, and then obtains the designated application data with respect to other slave devices <NUM> from the backup packet P4 according to an initial setting parameter of the slave device <NUM>.

More specific, a user may preset the initial setting parameter of the slave device <NUM> before the slave device <NUM> is activated, so as to designate one or more other slave devices <NUM> that have cooperation relationship with this slave device <NUM> (e.g., one or more slave devices <NUM> needed to be operated synchronously), and also designates the necessary data type.

For an instance, if one slave device <NUM> is implemented in a gantry main shaft of a panel tester, a user may set the initial setting parameter for this slave device <NUM>, so that the designated data obtaining module <NUM> of the slave device <NUM> obtains the designated application data of other slave device <NUM> which is corresponding to a gantry slave shaft from the backup packet P4, such as position feedback data, speed feedback data, torque feedback data, etc., but not limited thereto.

In this embodiment, the slave device <NUM> further obtains the designated application data from the designated data obtaining module <NUM> through the communication interface of the DSP. Therefore, the extended application function module <NUM> can combine the self-related data of the slave device <NUM> with the designated application data of other slave devices <NUM> for further operation, so as to improve the efficiency of synchronization operation among multiple slave devices <NUM>, and to be capable of extended applications (such as real-time controlling input points/output points among multiple slave devices <NUM>). In such a matter, the present invention assists multiple slave devices <NUM> which have cooperation relationship with each other to accomplish accurately synchronization operation.

It should be mentioned that, if the packet diversion module <NUM> is arranged on the first receiving circuit (Rx1) or the first transmission circuit (Tx1), the backup packet P4 obtained and generated by the packet diversion module <NUM> will not include data of the next slave device <NUM> connected to the output port <NUM> (which is arranged behind this slave device <NUM> on the EtherCAT bus) because the next slave device <NUM> has not yet written its feedback data into the data packet P1 or the processed data packet P2. In other words, if a slave device <NUM> is designated to obtain necessary data related to one or more slave devices <NUM> arranged behind, the packet diversion module <NUM> of this slave device <NUM> cannot be implemented on the first receiving circuit (Rx1) or the first transmission circuit (Tx1), and can only be implemented on the second receiving circuit (Rx2) or the second transmission circuit (Tx2).

According to the standard structure of EtherCAT protocol, the ESC <NUM> will not process the returned packet P3, and the returned packet P3 has already included all the feedback data from all the slave devices <NUM> on the EtherCAT bus. As a result, no matter a slave device <NUM> has to perform synchronization operation with one or more previous slave devices <NUM> or with one or more slave devices <NUM> arranged behind, the packet diversion module <NUM> of this slave device <NUM> can be implemented directly on the second receiving circuit (Rx2) and the second transmission circuit (Tx2).

<FIG> is a block diagram of an EtherCAT slave device according to a second embodiment of the present invention. As discussed above, the slave device <NUM> is implemented at least by FPGA, ASIC or MCU. In the embodiment shown in <FIG>, the hand-shaking method of the present invention is written as firmware and recorded in an FPGA, so as to implement the aforementioned slave device <NUM> through the FPGA, but not limited thereto.

As disclosed in <FIG>, the ESC <NUM> is arranged with a first MAC (media access control) unit <NUM> and a second MAC unit <NUM>. During a packet transmission procedure, a previous data processing device (a master device or a slave device <NUM>) transmits the data packet P1 to the first MAC unit <NUM>, so that the ESC <NUM> may receive the data packet P1. After retrieving the self-related data from the data packet P1 or inserting the feedback data into the data packet P1, and generating the processed data packet P2, the ESC <NUM> may transmit the processed data packet P2 to an address assigned and used currently by a next slave device <NUM> connected thereto through the second MAC unit <NUM>.

During a packet returning procedure, the ESC <NUM> of the slave device <NUM> may receive the returned packet P3 from the next slave device <NUM> through the second MAC unit <NUM>, and then transmit this returned packet P3 to an address assigned and used currently by previous data processing device (a master device or a slave device) through the first MAC unit <NUM>, so as to complete the packet returning procedure.

It should be mentioned that, if a slave device <NUM> is the last slave device <NUM> on the EtherCAT bus, the ESC <NUM> of this slave device <NUM> don't have to transmit packets afterward, so that the arrangement of the second MAC unit <NUM> is only an option for this slave device <NUM>. In particular, after such processed data packet P2 is generated, this slave device <NUM> may regard this processed data packet P2 as the returned packet P3 directly, and then transmits the returned packet P3 to an address assigned and used currentlt by previous data processing device (a master device or a slave device) through the first MAC unit <NUM> of the ESC <NUM>, so as to initiate the packet returning procedure.

One of the technical features of the present invention should be mentioned is that the packet diversion module <NUM> can be arranged with a third MAC unit <NUM> which is different from the first MAC unit <NUM> and the second MAC unit <NUM>.

In a first embodiment, the packet diversion module <NUM> is implemented on the first receiving circuit (Rx1) of the ESC <NUM>. When executing the packet diversion procedure, a previous data processing device transmits the data packet P1 simultaneously to the first MAC unit <NUM> of the ESC <NUM> and the third MAC unit <NUM> of the packet diversion module <NUM> through the input port <NUM>. Therefore, the packet diversion module <NUM> regards the data packet P1 received by the third MAC unit <NUM> as the backup packet P4, so as to complete the packet diversion procedure.

In a second embodiment, the packet diversion module <NUM> is implemented on the first transmission circuit (Tx1) of the ESC <NUM>. When executing the packet diversion procedure, the ESC <NUM> transmits the processed data packet P2 simultaneously to the address used by a next slave device <NUM> and the third MAC unit <NUM> of the packet diversion module <NUM> by the second MAC unit <NUM>. Therefore, the packet diversion module <NUM> regards the processed data packet P2 received by the third MAC unit <NUM> as the backup packet P4, so as to complete the packet diversion procedure.

In a third embodiment, the packet diversion module <NUM> is implemented on the second receiving circuit (Rx2) of the ESC <NUM>. When executing the packet diversion procedure, the next slave device <NUM> transmits the returned packet P3 simultaneously to the second MAC unit <NUM> of the ESC <NUM> and the third MAC unit <NUM> of the packet diversion module <NUM> through the output port <NUM>. Therefore, the packet diversion module <NUM> regards the returned packet P3 received by the third MAC unit51 as the backup packet P4, so as to complete the packet diversion procedure.

In a fourth embodiment, the packet diversion module <NUM> is implemented on the second transmission circuit (Tx2) of the ESC <NUM>. When executing the packet diversion procedure, the ESC <NUM> transmits the returned packet P3 simultaneously to the address used by previous data processing device and the third MAC unit <NUM> of the packet diversion module <NUM> by the first MAC unit <NUM>. Therefore, the packet diversion module <NUM> regards the returned packet P3 received by the third MAC unit <NUM> as the backup packet P4, so as to complete the packet diversion procedure.

The aforementioned packet transmission procedure, packet returning procedure and packet diversion procedure are completed in one single communication cycle.

It is worth saying that, after obtaining/generating the backup packet P4, the packet diversion module <NUM> can save the backup packet P4 directly to a storage <NUM> inside the slave device <NUM>. Also, the packet diversion module <NUM> can only save the designated application data to the storage <NUM> after the backup packet P4 has been filtered and the designated application data has been obtained from the backup packet P4 by the designated data obtaining module <NUM>.

As discussed above, the slave device <NUM> is implemented by using ASIC or MCU. In this embodiment, the packet diversion module <NUM> can be arranged on any of the aforementioned routes. Before receiving or transmitting such data packet P1, processed data packet P2 or returned packet P3, the ESC <NUM> may directly duplicate each of the packets P1-P3 and store to the storage <NUM> for directly generating the backup packet P4.

As mentioned above, the packet diversion procedure of the present invention can be implemented on the first receiving route, the first transmission route, the second receiving route or the second transmission route. As shown in <FIG> & <FIG>, the packet diversion module <NUM> can be implmeneted inside of the slave device <NUM> by way of firmware. In particular, the packet diversion module <NUM> in <FIG> & <FIG> can be arranged on the first receiving circuit (Rx1) of the first receiving route, the first transmission circuit (Tx1) of the first transmission route, the second receiving circuit (Rx2) of the second receiving route, or the second transmission circuit (Tx2) of the second transmission route. However, the packet diversion procedure can also be implemented outside of the slave device <NUM> by way of hardware.

<FIG> is a schematic diagram showing a structure for a packet diversion procedure according to a first embodiment of the present invention. In the embodiment shown in <FIG>, the packet diversion procedure is arranged outside of an EtherCAT slave device <NUM> (referred to as the slave device <NUM> hereinafter) and is implemented by a real chip (referred to as a packet diversion processor <NUM> hereinafter). As shown in <FIG>, the packet diversion processor <NUM> can be, particularly, arranged directly on a printed circuit board (PCB, not shown in the drawing), and connected to the slave device <NUM> which needs to perform the packet diversion procedure through the PCB.

It should mentioned that, if there are a plurality of slave devices <NUM> needs the packet diversion procedure, each of the slave devices <NUM> may be respectively arranged with an individual packet diversion processor <NUM>, however, one packet diversion processor <NUM> can also be electrically connected with multiple slave devices <NUM> for performing the packet diversion procedure for all of the multiple slave devices, but not limited thereto.

As shown in <FIG>, the packet diversion processor <NUM> can be connected to a first connection circuit <NUM> between the slave device <NUM> and previous data processing device (e.g., a master device or other slave device <NUM>), wherein the first connection circuit <NUM> is a part of the aforementioned first receiving route, or a part of the aforementioned second transmission route. Also, the packet diversion processor <NUM> in this embodiment can also be connected to a second connection circuit <NUM> between the slave device <NUM> and next slave device <NUM>, wherein the second connection circuit <NUM> is a part of the aforementioned first transmission route, or a part of the aforementioned second receiving route.

In this embodiment, the packet diversion processor <NUM> has been written with firmware which can implement the hand-shaking method of the present invention, so the packet diversion processor <NUM> is capable of performing the aforementioned packet diversion procedure for the connected slave device <NUM>, and the packet diversion processor <NUM> can then generate the backup packet P4, and obtains the designated application data with respect to other slave devices <NUM> from the backup packet P4 according to the packet diversion procedure. The further description of the applied hand-shaking method is omitted there.

Please refer to <FIG> and <FIG>, wherein <FIG> is a schematic diagram of a panel tester according to a first embodiment of the present invention, <FIG> is a schematic diagram showing gantry shaft current according to a first embodiment of the present invention.

As shown in <FIG>, a panel tester <NUM> includes a gantry main shaft <NUM> and a gantry slave shaft <NUM> which can be controlled to move along a Y-axis direction of the panel tester <NUM>. A parallel shaft <NUM> which is parallel to an X-axis direction of the panel tester <NUM> is arranged above the gantry main shaft <NUM> and the gantry slave shaft <NUM>, and a vertical shaft <NUM> which is parallel to a Z-axis direction of the panel tester <NUM> is further arranged on the parallel shaft <NUM>. One end of the vertical shaft <NUM> is arranged with an image sensor <NUM> for capturing an image of a tested panel <NUM>, and a side of the vertical shaft <NUM> is arranged with a light emitter <NUM> for improving the quality of the captured image.

In one embodiment, the drivers of both the gantry main shaft <NUM> and the gantry slave shaft <NUM> are implemented respectively by different EtherCAT slave devices (such as the above discussed slave device <NUM> in <FIG>), in other words, two slave devices <NUM> are respectively controlling the operation of the gantry main shaft <NUM> and the gantry slave shaft <NUM>. Because the gantry main shaft <NUM> and the gantry slave shaft <NUM> have to work synchronously for leading the image sensor <NUM> as well as the light emitter <NUM> to move along the Y-axis direction, the testing quality of the panel tester <NUM> will be extremely affected if each of the slave devices <NUM> cannot obtain the data related to other slave device <NUM> and finish an operation compensation during one single communication cycle without sending additional command packets.

<FIG> discloses current variations of the gantry main shaft <NUM> while it is operating, including a first main shaft current I1a without applying the hand-shaking method of the present invention, and a second main shaft current I2a after applying the hand-shaking method of the present invention. <FIG> discloses current variations of the gantry slave shaft <NUM> while it is operating, including a first slave shaft current I1b without applying the hand-shaking method of the present invention, and a second slave shaft current 12b after applying the hand-shaking method of the present invention.

As discussed, the slave device <NUM> for controlling the gantry main shaft <NUM> cannot obtain the data with respect to other slave device <NUM> that controls the gantry slave shaft <NUM> without applying the hand-shaking method of the present invention, and vice versa. When a superior controller of the panel tester <NUM> (not shown in the FIGS. ) controls the gantry main shaft <NUM> as well as the gantry slave shaft <NUM> to operate, the control commands sent from the controller may have a time interval while they respectively arrive the gantry main shaft <NUM> and the gantry slave shaft <NUM>. As a result, the operation speed of the gantry main shaft <NUM> will exceed the operation of the gantry slave shaft <NUM>. As shown in <FIG>, the gantry slave shaft <NUM> has not yet moved when the gantry main shaft <NUM> starts moving, so the gantry main shaft <NUM> will drag the gantry slave shaft <NUM> when it is moving, and the first main current I1a being generated thereupon will be larger. On the other hand, the gantry slave shaft <NUM> starts to move after being dragged by the gantry main shaft <NUM>, so its output will be against the gantry main shaft <NUM>, and the first slave current I1b being generated thereupon will be opposite to the direction of the first main current I1a.

According to above description, without applying the hand-shaking method of the present invention, the gantry main shaft <NUM> and the gantry slave shaft <NUM> cannot accurately perform synchronization operation. As a result, the panel tester <NUM> has to spend more energy during testing, the test quality of the panel tester <NUM> will be reduced due to dragging and shaking caused by the gantry main shaft <NUM> and the gantry slave shaft <NUM>, and the lifetime of the panel tester <NUM> will be affected eventually.

After applying the hand-shaking method of the present invention, both of the slave devices <NUM> for controlling the gantry main shaft <NUM> and the slave device <NUM> for controlling the gantry slave shaft <NUM> can respectively obtain the data with respect to other slave device <NUM> within one single communication cycle without additional command packets. As a result, each of the slave devices <NUM> can finish operation compensation right after receiving a control command from the controller. For example, the slave device <NUM> for controlling the gantry main shaft <NUM> may obtain the data related to other slave device <NUM> which is in charge of the gantry slave shaft <NUM> (such as position feedback data, speed feedback data or torque feedback data of the gantry slave shaft <NUM>) before operating, so that it can adjust the content of a control command received from the controller according to the obtained data for compensating the operation to the gantry main shaft <NUM>.

When a superior controller of the panel tester <NUM> controls the gantry main shaft <NUM> and the gantry slave shaft <NUM> to operate, it can send control commands respectively to each of the slave devices <NUM>, and each of the slave devices <NUM> can compensate the received control command according to the obtained data with respect to other slave device <NUM> in charge of another shaft. It can be seen from <FIG> that the operations of the gantry main shaft <NUM> and the gantry slave shaft <NUM> are synchronized, turns out smooth and consistent second main current I2a as well as second slave current I2b are generated. As shown in <FIG>, the hand-shaking method of the present invention can ensure multiple slave devices <NUM> to reach optimized synchronization, so as to reduce unnecessary energy wasting and extend devices' lifetime.

As mentioned above, after obtaining the backup packet P4 by the packet diversion module <NUM>, the slave device <NUM> may analyze the backup packet P4 through the designated data obtaining module <NUM>, so as to filter out unnecessary content of the backup packet P4 (i.e., undesignated data) and keep only necessary content of the back packet P4 (i.e., designated data).

<FIG> is a packet processing flowchart according to a first embodiment of the present invention. <FIG> is provided here to detailed describe the step S22 as disclosed in <FIG>, i.e., to describe how to analyze the backup packet P4 for filtering and obtaining necessary data.

First, the slave device <NUM> obtains the backup packet P4 generated by the packet diversion procedure (step S220), and then determines whether the backup packet P4 is an EtherCAT packet (step S222), i.e., the slave device <NUM> determines whether the backup packet P4 is a packet complying with format of EtherCAT protocol. If the backup packet P4 is not an EtherCAT packet, it will not include data of other slave devices <NUM> on the EtherCAT bus, so that the slave device <NUM> may directly abandon this backup packet P4 (step S224).

If the backup packet P4 is an EtherCAT packet, the slave device <NUM> further determines if the backup packet P4 is a periodical packet (step S226), i.e., if the foundation of the backup packet P4 (i.e., the data packet P1, the processed data packet P2 and the returned packet P3) are transmit within one single communication cycle. As discussed above, one of the purposes of the present invention is to make multiple slave devices <NUM> to directly obtain data with respect to other slave device <NUM> having cooperation relationship within one single communication cycle without sending additional command packet, so as to achieve optimized synchronization. According to this manner, if the backup packet P4 is not a periodical packet but a non-periodical packet, it may not be used for the present invention in accomplishing the above purpose, so the slave device <NUM> can also abandon this backup packet P4 (step S224).

In this embodiment, the step S222 and the step S226 do not have a specific execution order.

If the backup packet P4 is an EtherCAT packet and also a periodical packet, the slave device <NUM> may analyze this backup packet P4 according to a preset initial setting parameter (not shown) for obtaining therefrom the designated data with respect to one or more other slave devices <NUM> designated by a user (which is the slave device(s) <NUM> have to operate synchronously with this slave device <NUM>).

When analyzing the backup Packet P4, the slave device <NUM> can confirm the identity, such as quality, number, position, etc., of one or more other slave devices <NUM> needed to hand-shaking with according to the content of the initial setting parameter, and identifies a data area used to record the data related to the other slave devices <NUM> in the backup packet P4 (step S228). Next, the slave device <NUM> obtains all data recorded in the data area from the backup packet P4 (step S230), and filters the designated application data indicated by the initial setting parameter from the obtained data (step S232). In one embodiment, the designated application data can be, but not limited to, position feedback data, speed feedback data, torque feedback data, etc..

Claim 1:
A method for data hand-shaking based on EtherCAT protocol, implemented by an EtherCAT slave device (<NUM>) having an EtherCAT slave controller (<NUM>), ESC, and comprising:
a) receiving a data packet (P1) from a previous data processing device through a first receiving route, wherein the previous data processing device is an EtherCAT master device or another EtherCAT slave device;
b) obtaining self-related data of the EtherCAT slave device (<NUM>) from the data packet (P1) or inserting feedback data of the EtherCAT slave device (<NUM>) to the data packet (P1) by the ESC (<NUM>) for generating a processed data packet (P2);
c) delivering the processed data packet (P2) to a next slave device (<NUM>) through a first transmission route, wherein the next slave device (<NUM>) is another EtherCAT slave device, and the previous data processing device, the EtherCAT slave device (<NUM>), and the next slave device are in series connection with each other;
d) receiving a returned packet (P3) from the next slave device (<NUM>) through a second receiving route, and delivering the returned packet (P3) to the previous data processing device through a second transmission route;
e) performing a packet diversion procedure to at least one of the data packet (P1), the processed data packet (P2) and the returned packet (P3) for generating a backup packet (P4), wherein at least a part of the content of the backup packet (P4) is identical to the content of the data packet (P1), the processed data packet (P2) or the returned packet (P3); and
f) analyzing the backup packet (P4) by the ESC (<NUM>) for filtering and obtaining a related data from the backup packet (P4), wherein the related data is a designated application data with respect to one or more other EtherCAT slave devices designated to be synchronized with the EtherCAT slave device (<NUM>);
wherein the step a) to the step f) are completed within one single communication cycle.