System and method for relative addressing based on physical topology

Abstract

A device and method for communicating between network-connected devices defining a path having multiple device locations includes specifying a source device for a communication stream, the source device having a first port that communicates in a first direction of the path and a second port that communicates in a second direction of the path with a device network-connected to the source device. The port is selected from one of the first port or the second port of the source device to define the direction of the communication stream from the source device. A hop count is provided that indicates a relative location of a destination device for the communication stream, the hop count being an integer number of network device locations from the source device to the destination device along the path from the selected port.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 104,991, filed October 23, 2020, which is pending, and the disclosure of which is incorporated herein by reference.

[0002] The present invention generally relates to control and communication between elements of a network - connected system, particularly control and communication between elements based on the location and layout of the elements within the overall system.

Background Art

[0003] For example, in a network - connected control system used within a larger Internet system, such as a conveyor system within a warehouse facility, various elements or nodes within the system rely on various control connections for interconnecting with each other. The control connections between the various elements may be distributed. That is, any node may be able to open a connection to another node within the system. Alternatively, the control connections may be centralized, and one node may control and open control connections to some or all of the other nodes within the system. The setup and maintenance of such control connections are typically managed by a technician or system operator who can configure the various connections and devices within the system, or the addresses of the elements, such as Ethernet addresses or MAC addresses, for proper communication.

[0004] The concept of properly addressing various nodes within a system becomes particularly problematic when a node fails and needs to be replaced. Specifically, other nodes that need to connect to the replacement node must be able to recreate their previous connection paths. This is usually only possible if the new node or element has the same element address as the old node or element being replaced. Alternatively, the connections of various other nodes may need to be manually updated to reflect the new address of the new replacement node. Therefore, such replacement scenarios typically need to be resolved by system operators or technicians. This is time-consuming and thus costs not only system downtime but also the time required to resolve the problem. In such replacement scenarios, automatic address assignment, such as that used in the DHCP protocol, is not permitted, as such connections cannot be established without prior knowledge of the addresses of all other nodes. Therefore, maintaining proper control connections in a node network system is a cumbersome task, and often requires the attention of trained network operators / technicians when nodes and devices malfunction and need to be replaced.

[0005] Many such control systems exist as larger, more holistic factory systems, such as conveyor systems, and have redundant or overlapping machine elements or conveyor sections that need to be managed and replaced over time. That is, a factory using a conveyor system typically has multiple machines or sections of the same type that are duplicated. These overlapping elements are interconnected within a larger, common plant network. These multiple machines may consist of multiple control nodes. Since all these different control nodes are connected to the same plant network, they need to have unique network addresses.

[0006] For machine manufacturers, it is desirable to create redundant or duplicate machine systems and associated network elements and controls so that the system can be replicated multiple times in larger systems. When initially creating the original single machine system, the process of assigning various addresses to the various control nodes of the single machine is relatively straightforward. However, when the machine is duplicated and those multiple machine systems each need to be connected to a common plant network, the duplication scenario of the system creates various duplicate addresses on the network. Therefore, when assembling a large system from duplicate elements, additional control and programming steps are required to deal with various duplicate addressing scenarios. Such additional steps include manually configuring all duplicate machines to have unique control node addresses in the large network. Another solution is not to connect multiple duplicate machines to a common network. [Overview of the project] [Problems that the invention aims to solve]

[0007] None of these are desirable solutions for utilizing redundant, similar machine systems assembled into large-scale systems. Firstly, the requirement to manually configure all systems to have unique addresses is laborious and requires constant attention to faulty elements, replacement elements, nodes, and repair scenarios. Secondly, the need to keep machines and systems isolated on the network negates the purpose of using redundant network elements and control nodes within a facility. Therefore, the need to address machine system networking, particularly networking of machine systems with various redundant systems and subsystems connected to the network, still exists in the art. [Means for solving the problem]

[0008] Methods, devices, and systems for communication between network-connected devices use various devices that are referenced relatively based on their location and topology within the network. For a communication stream, a source device is specified, which has a first port and a second port for communicating with devices network-connected to the source device. One of the first or second ports of the source device is selected to define the direction of the communication stream from the source device. A hop count is then provided, indicating the relative location of the destination device in the communication stream. The hop count is an integer representing the location of the network devices from the source device to the destination device within the network. At the start of the communication stream, the network addresses of the network-connected devices coupled to the first and second ports of the source device are obtained.

[0009] When determining the final destination device of a communication stream, the present invention advances a single hop from the source device to another network-connected device in the defined direction of the communication stream. The next network-connected device is then designated as the new relative device for the communication stream. The network addresses of the network-connected devices coupled to the first and second ports of the new relative device are then obtained, and the hop count is decremented. The present invention then iteratively advances an additional single hop in the defined direction of the communication stream, designating additional network-connected devices as new relative devices. The hop count is continuously decremented with each step toward the destination device. When the hop count is equal to 1, the next additional network-connected device from the current relative device is designated as the destination device for the communication data stream, and its address is used for network communication.

[0010] The accompanying drawings incorporated herein and constituting part thereof illustrate embodiments of the present invention and, together with the general description of the present invention set forth below, are useful in illustrating the principles of the present invention. [Brief explanation of the drawing]

[0011] [Figure 1] This is a block diagram of a networked system for implementing a relative addressing system and method according to one embodiment of the present invention. [Figure 2] This is a flowchart of a relative addressing method and flow according to one embodiment of the present invention. [Figure 3] Figure 1 is a block diagram of one embodiment of the system controller of the system shown in Figure 1. [Figure 4A] This is a block diagram of one embodiment of a network-connected device used in the system shown in Figure 1. [Figure 4B] This is a block diagram of another embodiment of a network-connected device used in the system shown in Figure 1. [Figure 5] This is a block diagram of an exemplary conveyor system implementing one embodiment of the present invention. [Figure 5A] Figure 5 is a block diagram of the connection table for the control elements of the conveyor system. [Figure 5B] Figure 5 is a block diagram of exemplary controller elements used in the conveyor system. [Figure 6] Figure 5 is a flowchart of the application of one embodiment of the present invention. [Modes for carrying out the invention]

[0012] It should be understood that the accompanying drawings are not necessarily to a fixed scale and are somewhat simplified representations of various features illustrating the fundamental principles of the present invention. For example, certain design features of the sequence of operations disclosed herein, including specific dimensions, orientations, positions, and shapes of the various components shown, are partly determined by the specific intended use and operating environment. Certain features of the illustrated embodiments are enlarged or distorted compared to other features to facilitate visualization and clear understanding. In particular, thin features may be thickened, for example, for clarity or explanation.

[0013] This invention addresses the shortcomings of the prior art by establishing a control system and methodology that provides network connectivity between multiple devices in a network with fixed addresses, such as fixed-numerical Ethernet and MAC addresses, without requiring prior knowledge of the specific addresses of the devices involved. Rather, various devices are referred to relatively based on their location and topology within the network. More specifically, devices are referred to relatively based on the direction of a device or element in the network from another element in the network, and the number of incremental steps or "hops" by which each element is located within the network from another element in the network. This invention provides the ability to network various similar devices into a network without the need to use device-specific numerical addresses by providing addressing based on the predetermined location of devices in the overall network system relative to other devices. In this way, devices are addressed by their relative location to each other. If an element fails and needs to be replaced, the relative addressing scheme of this invention ensures that the replacement can be reliably performed with minimal reprogramming.

[0014] More specifically, in systems where control devices are networked to control a single multi-axis or multi-mechanism machine, the use of historical addressing protocols for nodes on a point-to-multipoint network may not be optimal. For example, while the usage history of unique addresses, pre-assigned names, and pre-assigned numeric addresses is generally useful, it is less useful in situations where the functionality of a device is predetermined by its actual physical location on the network. The relative addressing scheme of the present invention is particularly useful for multiple overlapping network-enabled devices configured to communicate over an Ethernet network for the control of a multi-axis or multi-mechanism machine. In such scenarios, multiple machines may be connected to the same Ethernet network and located in multiple overlapping configurations. Any device, such as a controller device of a particular machine, may need to communicate with any other device, such as another controller device on the same machine. In yet another scenario, there may be a master device that is part of the machine and controls all other devices associated with the machine.

[0015] In one embodiment of the present invention, a device addresses other devices in a network not by unique names or unique numerical addresses, but by their physical location in the network. More specifically, a device addresses various communication targets, such as other network devices, by specifying a particular network egress port or exit port from a source device, and a specific number of hops or device steps required to reach a target device in the network. The present invention utilizes such an overlapping system having a linear network of devices, where a particular device is coupled to a plurality of other devices located on a first or second network path from that particular device. In one use scenario, such as a conveyor system, the first and second paths may be physical paths that are considered upstream and downstream paths in a system of a particular device. That is, a source device may communicate with one or more upstream devices and one or more downstream devices. In this way, a particular direction of communication is defined based on the path, and the communication proceeds through a single egress port from the source device, which can be designated as the egress port of that particular path. The location of the target device relative to the location of the source or initiating device is used to provide the number of location hops used from the egress port to the target device in order to provide the desired communication flow.

[0016] Figure 1 shows one exemplary system for incorporating embodiments of the present invention. For example, system 10 includes a plurality of machines 12, shown in Figure 1 as 12a, 12b, 12c, etc. The machines 12 may be coupled together in a larger system 10 network through one or more network switches 14, or other network hardware that facilitates communication between various elements of the network, such as various machines 12. One suitable switch element 14 could be, for example, a typical Ethernet switch.

[0017] Each of the machines 12a, 12b, 12c, etc., may include various other network elements or devices 20, such as control devices or controllers used to control parts of their respective machines. One particular, but not limited, application of the present invention lies in the control of a system of conveyor machines having multiple different parts or sections, each controlled by its respective control device 20. Such conveyor machines are often arranged end-to-end to form a conveyor line. Thus, the devices 20 are arranged within the machines in a substantially linear fashion along the conveyor line. Each machine may include its respective "master" device or actuator 20a, 20b, 20c coupled with one or more other slave devices or "actuators" 20, as shown in Figure 1. The present invention provides improved communication between various devices 20, such as machines 12a, 12b, 12c, etc.

[0018] In one example of the present invention, the master actuator 20b of machine 2 may need to communicate with or read or retrieve data from another device designated as “actuator 2” within the same machine 2. Conventionally, in existing systems, the communication connection was opened by specifying the name of the element or the associated IP address of the actual device considered to be “actuator 2”. However, as mentioned above, in such a path, the master device needs to know the specific name of the “actuator 2” device or its unique numeric IP address. However, if device 20 in machine 12 is defective or fails and is replaced with another off-the-shelf unit, the new replacement device that will act as a replacement for “actuator 2” needs to be assigned a specific name or a specific numeric IP address. Thus, a human operator needs to manually assign the original name / numeric address from the failed old device to the new replacement device. Alternatively, if a new name / numeric address is used for the replacement device, a human operator needs to manually adjust / modify the software protocols or programs running on all other devices in the system, which will facilitate the connection with the failed old device and thus target the new replacement device. As can be understood, such a process for dealing with each alternative device within a large number of machines or devices on a large number of machines in a system can be time-consuming and costly, and requires special programming expertise from the facility housing the system 10. Various numerical addresses throughout the system need to be tracked using the present invention, so that various devices such as the master device 20b can be connected to new alternative devices such as actuator 2 without human intervention or reprogramming, which is not possible with conventional network topologies.

[0019] As described herein, instead of opening a connection to a specific named device 20 or an associated numerical IP address, the master device 20b uses a relative designation such as "second device connected to port B from the master device 20b" to open a communication connection to the device 20. In this way, any device 20 can open a unique connection to any other device using the output port of the source device and the designation of the destination device reflected by the number or position of "hops" of the destination device from that output port of the source device. According to the present invention, the machine 12 can be replicated in normal production, and all of the various devices 20 such as the machine 12 and some control modules of the machine can utilize the exact same program and network connection settings without interference. That is, each device is accessed relatively in each machine based on the output port or direction of communication from the source device and the relative number of position spots or hops from the source, so there is no interference in the network due to duplicate names and / or duplicate numerical IP addresses.

[0020] For example, in a conventionally network-connected system, when a manufacturer produces identical or replicated machines consisting of at least one master device and a plurality of slave devices, as shown in FIG. 1 for example, those machines must each have a unique numerical IP address for all of their devices 20, and the master device must be configured to communicate with the unique numerical addresses of the slave devices. The addresses between duplicate machines also duplicate, and as a result, if multiple machines are connected to the same network, the addresses will duplicate, resulting in a situation that is unacceptable for the purpose of network communication.

[0021] In the present invention, addressing between various devices is provided in the form of "X hops through a specific output port Y". Therefore, even when multiple identical machines are connected to the same Ethernet switch 14, each possible destination device has a different position relative to the source device, so the connection of one machine 12 does not interfere with the connection of another machine.

[0022] According to one aspect of the present invention, the devices of a specific machine are arranged in a linear communication arrangement as shown in FIG. 1, and thus the direction of communication is established according to the specified output port of the source device. Furthermore, the system 10 must have knowledge of the routing of the documented Ethernet cables since the manufacture of the machines 12, and that routing must match the method of configuring and arranging the connections between the replicated machines. This is generally true since wiring diagrams are an integral part of the design and manufacture of machines.

[0023] According to one feature of the present invention, the system 10 executes programs for the management and operation of the various machines 12 and the system 10 as a whole based on the position parameters of the various devices within the system. Specifically, the software of the operating system of the system controller 16, and the software of the various control applications on the system controller 16 or the various devices 20, set up a communication connection between one specific node or source (starting node or source device) and another adjacent node or destination (target node or destination device) based on a specific device or node, the specific output port of the starting node, and the relative number of hops to the target node or destination device. The selected output port defines the direction of the communication stream.

[0024] According to one aspect of the present invention, a particular device or node uses one or more network protocols and a database to obtain information about connected neighboring devices from each device 20 of the system 10. As shown in Figure 1, each device may have a specific output port A / B, or port 1 / 2 as further described herein, depending on the direction in which the network communication stream flows to other devices in the system. That is, various devices in the network of system 10 may be connected to one or more other specific devices through port A for communication, and to other different devices through port B. The system 10 is configured to collect data about various neighboring devices in the system through the system controller 16 and / or through each device 20, and to provide a database of its information used in the present invention to establish appropriate communication, based on knowing the output port for reaching a particular destination device and the relative number of hops from that output port to the location of the destination device. To facilitate communication between devices, the source device or initiating node in the software code does not need to know the specific configured numeric Ethernet address of the destination device or target node. In this way, control programs for various devices or nodes can be replicated among each of the machines 12 without using specific numeric IP addresses or other network addresses. Therefore, even if various machines are implemented on the same network via the same Ethernet switch, interference due to overlapping numerical addresses does not occur. Furthermore, various devices 20 can be easily replaced as needed without needing to ensure that the replacement device has the same conventional numerical address as the old device in order to reflect the new numerical address of the replacement device, and without needing to modify the various control programs on all other devices 20 or the system controller 16.

[0025] According to one aspect of the present invention, system 10 needs to have information about each of the nodes 20 and their neighboring nodes 20 for use in the relative addressing program of the present invention. The unique addressing and communication protocols of the present invention use such information when implementing the relative addressing protocol of the present invention, as described herein. In one embodiment of the present invention, the information is obtained using a protocol designed to obtain such information for use in other network protocols, such as the Ethernet protocol. Such information is then stored in a suitable accessible database for use in the relative addressing method disclosed herein.

[0026] In one embodiment of the present invention, the Link Layer Discovery Protocol (LLDP) (IEEE 802.1AB) may be used, which allows a device to collect and access data about other neighboring nodes or devices. Information collected using the LLDP protocol, etc., is stored in a Device Management Information Database (MIB) and can be queried and retrieved using the Simple Network Management Protocol (SNMP). The topology of an LLDP-enabled network can be discovered by navigating within a host and querying the MIB database. Using such a protocol, each device 20 can obtain a Media Access Control Address (MAC) and / or a physical address such as the logical address or Internet Protocol (IP) address of each directly neighboring device on each port it has.

[0027] In the current example, referring to Figure 1, each device 20 includes a pair of ports, indicated by port A30 and port B32, which can function as outbound or outbound ports for various communications involving a particular device. Such outbound ports are used in the relative addressing scheme of the present invention. Because this knowledge exists in all devices 20, each device can incrementally query its neighbors for information about its neighbors, so that all devices can create a suitable MIB database or tree describing the interconnections of all devices across the entire network. With relative addressing in the present invention, a programmer can replicate each program and communication step of machine 20, for example, as shown in Figure 1, and the program does not need to know or use a specific numerical MAC address or IP address of the target device in a particular communication stream. Rather, all that needs to be specified in the control program is the initiating device or "relative node" and a specific path from the initiating device or node, or an "outbound port" from the device, to define the direction of communication. Then, the number of steps or "hops" from the outbound port to the destination device or node is used. The present invention uses this information in conjunction with information obtained from a suitable database, such as an MIB database, to determine the appropriate communication path and destination device without the control program having to hardset the numerical IP, MAC, or other address of the destination device. Whenever a device or node 20 is removed and replaced in machine 12 or the networked system 10, the communication program does not need to be modified, and the new replacement device does not need to be assigned the same numerical IP or MAC address as the original device. Therefore, the present invention is not limited to a program that must be reconfigured each time a new device 20, such as a replacement device, is implemented in the networked system 10, or when the MAC address or IP address of various devices changes.The device's control program does not need to incorporate a specific numerical address as the destination address. Rather, communication may be directed to a device that is only three hops or three locations away from the source device.

[0028] Referring to Figure 2, a flowchart of an exemplary embodiment of the present invention is shown. In the case of a networked system 10 as shown in Figure 1, in the case of machine 12 such as machine 12a, a program running on a device on that machine may need to initiate and continue communication with all other devices or actuators. For example, master device 20a may need to communicate with device 20 designated as "actuator 1". In a network database such as an MIB database, various devices 20 or nodes may have MAC numerical addresses such as: Master node - 192.168.1.1 Actuator 3 - 192.168.1.2 Actuator 2 - 192.168.1.3 Actuator 1 - 192.168.1.4

[0029] For the purpose of communication according to the present invention, a program executed on a device or master node 20a does not address the destination device of actuator 1 by MAC numerical address, but rather provides the following input parameters for a communication path to an actuator 1 node having a master node 20a (as a source) designated as a "relative node". In flow 40 of Figure 2, in step 42, connection parameters for the communication connection are shown. The "relative node" or initiating device or source device can be any specific device in the system and can be set to any name, MAC address, or IP address. "Relative node" = local (192.168.1.1) "Output port" = B "Hop count" = 3

[0030] The “output ports” 30, 32 specify selected interface ports, which specify the direction of the communication stream in system 10, or a first or second path in machine 20a. Depending on the system layout, such as a conveyor system, the direction may be considered upstream or downstream in the flow. According to one embodiment of the present invention, using the communication parameters noted in the program, the algorithm of the present invention first retrieves local LLDP data or other network data from a table or database (step 44). In the present example, the retrieved sample LLDP data from the source device may show its source port information, such as the IP addresses of devices connected to those particular ports 30, 32 in either of the two directions to travel from the source device. Port A - 192.168.77.88 Port B - 192.168.1.2

[0031] The path from output port B to the "actuator 1" device involves a "hop" count of 3 due to the relative position of the elements, so the hop count is set to 3 in the initial starting step 42. In step 46, the hop count is tested, and as long as there are more devices to hop to in the communication (hop count > 1), the program enters the main loop in the program flow. Since the hop count of 3 is greater than 1, the process proceeds past the starting node or source device node or relative node of master node 20a, and since the relative node or source device is in the past, it is now assigned as the previous node. That is, in step 48, the new relative node is the device or node 20 of "actuator 3", which is one hop away from port B, and its IP address is then obtained for the device at output port B as the flowchart and communication stream proceed down (step 50). The next device in output port B and LLDP data is determined and used or assigned as the new relative node. "Previous node" = 192.168.1.1 "Relative node" = 192.168.1.2

[0032] Next, the algorithm enters the main loop in step 52, where data for the current relative node is retrieved from the LLDP data database. Since the current relative node is the "actuator 3" device, the data determined for actuator 3 will show the previous master device 20a at one port (the original source device) in the desired flow direction of the communication stream, and actuator 2 at the other port. Port A - 192.168.1.1 Port B - 192.168.1.3

[0033] Since the program of the present invention requires only a first or second path to the target destination node for a suitable number of hops to the destination device, a test is performed in step 54 to confirm that such a binary condition exists for selecting only one path direction. If there are two or more ports and multiple first and second paths and each port, the program records a failure condition in step 56. Since device 20a, i.e., the first relative node or source node of the master device, has been previously addressed, its address information is not needed, and the data for port A device 20a matches the "previous node," and is therefore excluded or deleted in step 58. In this way, the communication flow moves to the next node in the desired direction.

[0034] Next, the "hop count" is reduced by 1 in step 60 because one device or node is already addressed. In this example, the "hop count" becomes 2. A test is performed again in step 62 to determine if the hop count has been reduced to equal 1. If so, the flow path is tracked as described below. Furthermore, in the flow, the current "relative node" becomes the current "previous node," as described in step 64. That is, the "previous node" is set to the node of the "actuator 3" device. 192.168.1.2

[0035] The remaining network data from the current "relative node" or "actuator 3" node's LLDP data is the next address or device data in the flow path, originating from port B of the "actuator 3" device (the downstream port in Figure 1). This information is the IP address of the next device in the flow path, i.e., the "actuator 2" device. Port B - 192.168.1.3

[0036] Next, the address information of the actuator 2 device is assigned as a new “relative node,” as shown in step 66. The program then loops again in the main loop. In step 52, the new LLDP data or other network data obtained is for the current “relative node,” which is actuator 2, or the device with the IP address 192.168.1.3. The port address information obtained includes the devices and addresses associated with the various flow passports A and B of the “actuator 2” device. Port A - 192.168.1.2 (formerly "Actuator 3") Port B - 192.168.1.4

[0037] Again, as in step 54, the first and second paths are defined and decisions are made to ensure that there are only two possible reflectable output ports or directions for the flow. As described in step 58, the data for port A in the opposite direction to the hop-progressing communication stream flow is removed because it matches the “previous node” address data. The hop count is again reduced by 1. At this point, the “hop count” decreases to a value of 1. Then, according to the test performed in the program flow in step 62, if the result is “yes”, the loop terminates and the flow proceeds to step 72. The flow has arrived at the destination device. The port B data from the LLDP database or the remaining address information from the table data reflecting the location of actuator 1 is specified as the “result” of the destination node or device of the communication path. The remaining IP address is 192.168.1.4 as shown above, which matches the IP address of the “actuator 1” device, which is the final destination device.

[0038] In the program flow, and in the program code associated with the communication connection of machine 1 shown in Figure 1, no specific numerical address or name information is used or required in the code for specifying the destination device. Therefore, the communication protocol of the present invention does not use or require any specific numerical address in the program code for the communication process. Rather, the destination device only needs to indicate the direction to travel in the network and the number of relative positions in that direction. The flow arrives at the desired destination regardless of the actual numerical IP address or MAC address that the destination device has. Essentially, a program running on the master device wants to open a connection to a relative device three hops away from port B, and the method of the present invention opens a connection to the appropriate device, which has the IP address 192.168.1.4. The "actuator 3" device could have had a completely different IP address through an alternative or through a dynamic change in the addressing of the machine device, and the present invention could have created a connection to the correct destination device using the relative addressing scheme of the present invention. The master device did not need to know the MAC address or IP address of actuator 3 as the destination. It only needed to hop three positions in the path direction. Therefore, the present invention reduces the need for a programmer programming devices and machines and other elements of a networked system 10 to know in advance all IP addresses or other numerical addresses associated with a particular device at a specific location within a networked machine. The programmer only needs to know the device layout of the machine or a sub-part of the larger network, and if the machine or network part is duplicated, only one program using the relative addressing of the present invention is sufficient. To understand the location of a device or node, the programmer can use a wiring diagram of the machine to define the relative location of the target device for the communication connection that needs to be opened.

[0039] The present invention also works when the “relative node” for initiating communication is set to any device name or IP address from a node outside a particular machine, as used, for example, in the example. In this case, the first retrieval of LLFP data is performed from the device or node specified by the “relative node,” rather than from a local database or table. Therefore, the initiating “relative node” can use a device name, IP address, MAC address, or any other addressing convention used in the network.

[0040] Similarly, the examples described herein show “relative node” and “previous node” data with IP addresses configured within a flow. However, the present invention may use other addressing schemes or identifiers to connect to remote nodes or devices to which this identifier is assigned, as long as the node or device on the network can use that identifier. Therefore, in implementations of the present invention, the information obtained from the MIB database may change. However, it always occupies the same relative position specified by the hop from the source, regardless of the final IP address or MAC address of the destination device. Therefore, if an alternative device is introduced into the system, that device may have a different IP address, MAC address, or other address.

[0041] One of the special advantages of the relative addressing scheme of the present invention is that there can be multiple instances of a particular network-connected system or subsystem, such as machine 12, connected to the same network. A program running on various devices 20 of machine 12 may be exactly the same on any machine. True duplication may exist. If there are multiple machines of type "machine 1" 20a within a network-connected system 10, each device, node, or other module will have a unique IP address that would conventionally have to be programmed into the program running on that machine. Replacing such a device or node would require reprogramming based on a different numerical IP address or other addresses of the alternative elements. Even more beneficial is that the present invention can also address scenarios of machines or systems where addresses may change over time due to dynamic addressing schemes such as DHCP. In such cases, a programmer creating a program to run on the master node of all machines would have a very difficult time setting up connections from all master nodes to their respective actuator nodes. If the addresses of all modules change dynamically, all the programming work would have to be redone.

[0042] This invention addresses these problems by allowing programmers to specify various communication connections between machines and devices not by name or numerical addresses such as IP addresses or MAC addresses, but by the relative position of an element on a network path or direction relative to another element. This provides consistent results regardless of the number of machines connected to the network and regardless of how the names or addresses of node elements may change. Normally, when an IP address changes, existing connections are broken. However, the method of this invention can be repeated to increment hops, place the new address of the device, and automatically create new connections based on the relative step, without the programmer having to reconfigure or edit the program with the numerical address of the new device.

[0043] Figures 4A and 4B show schematic diagrams of hardware and software environments for exemplary devices such as controllers 120, 200, and similar devices 20 that may be used in a machine such as machine 12, such as a conveyor machine or system, consistent with embodiments of the present invention. Various controllers may be addressed as one or more nodes in a networked machine 12 using relative addressing methods as disclosed herein. Thus, while the controller elements 120, 200 shown in the drawings may be used to implement the present invention, the invention is not limited to other environments and processes or controller elements in which the present invention can be utilized.

[0044] Returning to Figure 4A, the controller 120 for conveyor elements and the like includes at least one central processing unit ("CPU") 122 coupled to the memory 124. Each CPU 122 is typically implemented in hardware using circuit logic located on one or more physical integrated circuit devices or chips, and may consist of one or more microprocessors, microcontrollers, field-programmable gate arrays ("FPGA"), or ASICs. The memory 124 may include random access memory ("RAM"), dynamic random access memory ("DRAM"), static random access memory ("SRAM"), flash memory, electronically erasable programmable read-only memory ("EEPROM"), and / or other digital storage media, and is typically implemented using circuit logic located on one or more physical integrated circuit devices or chips. Therefore, memory 124 may be thought to include memory storage physically located elsewhere within the controller 120, such as any cache memory in the CPU 122, as well as any storage capacity used as virtual memory, such as stored on a computing system 90 (Figure 3), or another controller coupled to the controller 120 through at least one network interface 126a, 126b (indicated as “Network A Interface” 126a and “Network B Interface” 126b). The network interface reflects, for example, ports A30 and B32 as described herein with respect to Figure 1.

[0045] The controller 120 is configured to couple to various devices controlled within the machine, such as conveyor rollers or other mechanisms (not shown). The controller can couple to up to two electric rollers or other motor elements through their respective motor interfaces 128a, 128b (indicated as “motor A interface” 128a and “motor B interface” 128b). In particular, the CPU 122 is configured to control the electric rollers not only by determining the rotational state of the electric rollers but also by selectively supplying power to the motors. For example, in the case of electric conveyor rollers, each motor interface 128a, 128b allows the CPU 122 to supply power to the motors of the electric rollers 18 and to determine information about the motors of the electric rollers 18. In particular, the motor interfaces 128a, 128b can generally be used, in one example, for brushless DC (“BLDC”) motor rectification control to control the rotational speed of the motors in the electric rollers. More specifically, the motor interfaces 128a and 128b include the functions of selectively energizing specific windings of a connected motor to rotate an electric roller, sensing the current consumed by the connected motor, and detecting the rotational state of the connected motor. The motor interfaces 128a and 128b may also include the function of controlling a brake (not shown) associated with the roller.

[0046] In addition to controlling elements such as electric rollers, the CPU 122 may be configured to couple to other elements, such as up to two sensors (not shown), through their respective sensor interfaces 130a, 130b (referred to as "Sensor A Interface" 130a and "Sensor B Interface" 130b). The controller 120 may also be configured to couple to additional parts of additional hardware (not shown) through their respective hardware interfaces 129a, 129b (referred to as "Hardware A Interface" 129a and "Hardware B Interface" 129b). The controller 120 is configured to receive power from an appropriate power supply unit through a power input and adjustment interface 132.

[0047] The CPU 122 is further configured to receive input from a user and / or provide human-perceptible output to the user through an input / output device interface 134 (hereinafter referred to as "I / OI / F" 134). In some embodiments, the I / OI / F 134 is configured to receive data from a user through at least one user interface 136 (e.g., including one or more soft keys, a keyboard, a mouse, a microphone, and / or other user interfaces) and / or provide human-perceptible output to the user through at least one output device 138 (e.g., including one or more LEDs, a display, a speaker, a printer, and / or another output device that provides specific information). In some embodiments, the I / OI / F 134 communicates with a device that operates as a combination of the user interface 136 and the output device 138, such as a touchscreen display (not shown). In certain embodiments, at least one user interface 136 includes a soft key that, when activated for a first predetermined time, allows the CPU 122 to determine that the user wants to automatically configure a plurality of controllers 120, and when activated for a second predetermined time, allows the CPU 122 to determine that the user wants to reset the controllers 120. In even more certain embodiments, at least one output device 138 includes a plurality of LEDs that indicate, respectively, network connectivity through network interfaces 126a, 126b, network traffic through network interfaces 126a, 126b, the status of the network to which the controllers 120 are connected, the status of one or more motors of each electric roller connected to motor interfaces 128a, 128b, the status of one or more sensors connected to sensor interfaces 130a, 130b, the status of one or more hardware connected to hardware interfaces 129a, 129b, the power status to the controllers, and / or the status of the controllers.

[0048] The controller 120 is typically under the control of firmware 140, as well as an operating system, application, and / or other program code (hereinafter referred to as "control code") 142 configured to control the controller 120. Thus, the controller 120 performs, or otherwise relies on, various computer software applications, sequences of operations, components, programs, files, objects, modules, etc., consistent with embodiments of the present invention. In certain embodiments, firmware 140 contains data for controlling components of the controller 12 while control code 142 is executed to perform various operations consistent with embodiments of the present invention. The controller 120 also includes a network server 144, which may include a web server and / or a DHCP server. Thus, the network server 144 enables a separate computing system 90 (Figure 3) to directly access information from the controller 12 through a network 82 (Figure 3), and / or enables the separate computing system 90 to connect directly to the controller 120 to automatically configure a TCP / IP connection.

[0049] The controller 120 is also configured to include a mass storage device 146 that can store data for operating the controller 120, or other controllers 120 coupled to each other, similar to device 20 in Figure 1. In certain embodiments, the mass storage device 146 includes not only the configuration data of the controller 120, but also the configuration data of adjacent controllers 120 in a configuration data structure 148. The mass storage device may also store operational parameters such as its IP address, subnet mask, gateway, and configuration and / or operation of the controller 120, as well as other data structures such as lists or lookup tables that can be used in the use of the relative addressing method of the present invention. Parameters may be stored in a parameter data structure 150.

[0050] Controller 120 may be configured to operate independently or in conjunction with at least one additional controller 120. Furthermore, controller 120 may be configured to be controlled externally by the computing system 90 described above or by the system controller 16 shown in Figure 1, etc. Accordingly, consistent with embodiments of the present invention, Figure 3 is a schematic diagram showing the interconnection of multiple controllers 120 via communication links 80a-b, such as Ethernet cables, and the connection of one or more controllers 120 to at least one network 82 for control by the computing system 90. In certain embodiments, each communication link 80 between controllers 120 is realized through a network cable, such as a Category 5 cable used for Ethernet network communication. Similar to device 20, the master device, and other actuators shown in Figure 1, controller 120 may be configured to communicate directly (e.g., from the master device to actuator 3) or indirectly (e.g., from the master device to actuator 1) with other distinct controllers 120, such as by using a relative addressing protocol and a series of hops described herein, according to one embodiment of the present invention.

[0051] Referring to Figure 4B, another exemplary device for implementing the present invention is in the form of a controller 200, such as a conveyor element. The controller 200 includes at least one central processing unit ("CPU") 202 connected to a memory 204. Each CPU 202 is typically implemented in hardware using circuit logic located on one or more physical integrated circuit devices or chips, and may consist of one or more microprocessors, microcontrollers, field-programmable gate arrays ("FPGA"), or ASICs. The memory 204 may include random access memory ("RAM"), dynamic random access memory ("DRAM"), static random access memory ("SRAM"), flash memory, electronically erasable programmable read-only memory ("EEPROM"), and / or other digital storage media, and is typically implemented using circuit logic located on one or more physical integrated circuit devices or chips. Therefore, memory 204 may be thought to include memory storage physically located elsewhere within the controller 200, such as any cache memory in the CPU 202, as well as any storage capacity used as virtual memory, such as stored on a computing system 90 (Figure 3), or another controller coupled to the controller 200 through at least one Ethernet port 224, 226, or other network interfaces (indicated as “Ethernet port 1” 224 and “Ethernet port 2” 226). The Ethernet ports reflect, for example, ports A30 and B32 as described herein with respect to Figure 1, or ports 1 and 2 in Figure 5 disclosed herein.

[0052] The controller 200 is configured to couple to various devices controlled within a machine such as a conveyor (see, for example, Figure 5). The controller may couple to the motorized parts of a conveyor, such as conveyor rollers, through a three-phase power inverter bridge 210 for supplying power to each motor. The controller 200 can also provide brake control to the motors through the brake output 208, using the power 210 and brake output 208, respectively, controlled by the safety subsystem 212. In particular, the CPU 202 is configured to control the motor rollers by selectively supplying power to the motors and determining the rotation state of the motor rollers through a motor position interface 214, etc. More specifically, the controller provides the functions of selectively energizing specific windings of the connected motors, sensing the current consumed by the connected motors, and detecting the rotation state of the connected motors in order to rotate the motor rollers.

[0053] In addition to controlling elements such as electric rollers, the CPU 202 may be configured to couple to other elements such as up to two sensors and additional hardware (not shown) through its respective analog I / O interfaces 230 and digital I / O interface 232. The controller 120 is configured to receive power from a suitable power supply unit through a power input interface 236 coupled with a sufficient power adjustment circuit 238. Various safety inputs may also be provided to the controller 200 via interface 234.

[0054] The CPU 122 is further configured to receive input from the user and / or provide the user with human-perceptible output through interfaces 230, 232. In certain embodiments, the interfaces may include soft keys that, when activated for a first predetermined time, allow the CPU 202 to determine that the user wants to automatically configure multiple controllers 200, and when activated for a second predetermined time, allow the CPU 202 to determine that the user wants to reset the controllers 200. The controllers 200 may also include one or more LEDs for output to the user indicating network connectivity through network ports, network traffic through network ports, the state of the network to which the controllers 200 are connected, the state of each motor of each of the motor rollers connected to motor interfaces 208, 210, the state of each sensor of each of the one or more connected to the controllers, the state of each piece of hardware of each of the one or more connected to the controllers, the power status to the controllers, and / or the state of the controllers, respectively.

[0055] Controller 200 is typically under the control of firmware 205, as well as an operating system, application, and / or other program code or control logic 206 configured to control the controller. Thus, controller 200 performs, or otherwise relies on, various computer software applications, sequences of operations, components, programs, files, objects, modules, etc., consistent with embodiments of the present invention. In certain embodiments, firmware 205 contains data for controlling components of controller 12 while control logic 206 is executed to perform various operations consistent with embodiments of the present invention. Controller 120 is also configured with a mass storage device 218 that can store data for operating controller 200, or other controllers 200 coupled to each other, similar to device 20 in Figure 1. In certain embodiments, the mass storage device 146 contains not only the configuration data of controller 120, but also the configuration data of adjacent controllers 120 in the configuration data structure. The mass storage device can also store operational parameters such as its IP address, subnet mask, gateway, and configuration and / or operation of controller 200, as well as other data structures such as lists or lookup tables that can be used in the use of the relative addressing method of the present invention.

[0056] Controller 200 may be configured to operate independently or in conjunction with at least one additional controller 200. Furthermore, controller 200 may be configured to be controlled externally by the computing system 90 described above or by the system controller 16 shown in Figure 1. Accordingly, consistent with embodiments of the present invention, Figure 3 is a schematic diagram showing the interconnection between multiple controllers 200 via communication links 80a-b, such as Ethernet cables, and the connection of one or more controllers 200 to at least one network 82 for control by the computing system 90. In a particular embodiment, each communication link 80 between controllers 120 is realized through a network cable, such as a Category 5 cable used for Ethernet network communication coupled to various ports 224, 226 of the controllers. The network port of the actual controller 222 is thought to be port 0. Various Ethernet or other network ports 0, 1, and 2 may be part of an Ethernet switch 221. Similar to device 20, the master device, and other actuators shown in Figure 1, the controller 200 may be configured to communicate directly (for example, from the master device to actuator 3) or indirectly (for example, from the master device to actuator 1) with other separate controllers 200, such as by using a series of hops described herein, including relative addressing and ports such as port 1 or port 2 designated as output ports.

[0057] As discussed above, various machines 12, such as parts of a conveyor system, may include a system controller 16 or computing system 90 capable of controlling the device 12 or controller 120 and thus the operation of the larger system 10 (see Figure 3). The computing system 90 includes at least a CPU 92 coupled to memory 94. Each CPU 92 is typically implemented in hardware using circuit logic located on one or more physical integrated circuit devices or chips, and may be one or more microprocessors, microcontrollers, field-programmable gate arrays ("FPGA"), or ASICs. Memory 94 may include RAM, DRAM, SRAM, flash memory, and / or other digital storage media, and is typically implemented using circuit logic located on one or more physical integrated circuit devices or chips. Therefore, memory 94 may be thought to include memory storage physically located elsewhere in the computing system 90, such as any cache memory in at least one CPU 92, as well as any storage capacity used as virtual memory, such as stored on a mass storage device 96, another computing system (not shown), a network storage device (e.g., a tape drive) (not shown), or another network device (not shown) connected to the computing system 90 via at least one network interface 98 (hereinafter referred to and used as "Network I / F" 98) through at least one network 82. The Network I / F 90 may be connected to the network 92 wirelessly (e.g., via one of several IEEE 802 standards) or via a wired link (e.g., an Ethernet cable). It will be understood that at least one network 82 may include at least one private communication network (e.g., an intranet) and / or at least one public communication network (e.g., the Internet).

[0058] Therefore, in certain embodiments, the computing system 90 is a computer, computer system, computing device, server, disk array, or programmable device such as a multi-user computer, single-user computer, handheld computing device, network-connected device (including computers in a cluster configuration), mobile telecommunications device, telecommunications-enabled device, video game console (or other game system).

[0059] The computing system 90 is coupled to at least one peripheral device through an input / output device interface 102 (hereinafter referred to as "I / OI / F" 102). In particular, the computing system 90 receives data from a user through at least one user interface 104 (including, for example, a keyboard, mouse, microphone, and / or other user interfaces) and / or outputs data to the user through at least one output device 106 (including, for example, a display, speaker, printer, and / or other output device). Furthermore, in some embodiments, the I / OI / F 102 communicates with a device that operates as a combination of the user interface 104 and the output device 106, such as a touchscreen display (not shown).

[0060] The computing system 90 is typically under the control of the operating system 108 and performs, or otherwise depends on, various computer software applications, sequences of actions, components, programs, files, objects, modules, etc., consistent with embodiments of the present invention. In certain embodiments, the computing system 90 performs, or otherwise depends on, a control application 110 to manage the operations of the controllers 120, 200 and system 10.

[0061] According to embodiments of the present invention, controllers 120, 200 can be configured to operate autonomously, collectively autonomously, or dependently. When operating autonomously, controllers 120, 200 are not controlled by the computing system 90 and operate independently of one or more controllers 120, 200 located on a specific path from the starting controller. Thus, controllers 120, 200 simply control a portion of machine 12, regardless of additional controllers 120. When operating collectively, multiple controllers 120 are configured to share information upstream and / or downstream, but are otherwise not controlled by the computing system 90. Such controllers may communicate with each other using the relative addressing methods described herein. When operating dependently, one or more controllers 120, 200 are configured to be controlled by the computing system 90. Even in the dependent configuration, communication to various controllers may be performed using the relative addressing methods described herein.

[0062] In any case, controllers 120 and 200 include many operations, operating modes, and functions that assist in the operation of the machine. For example, controllers 120 and 200 are configured to automatically determine information about the connected machine 12, more specifically, information about the machine's components and / or additional hardware configured on it. Meanwhile, controller 12 controls machine parts such as rollers in the conveyor system.

[0063] Multiple networked controllers 120, 200 (in a conveyor system, for example) can be automatically configured if they are set up in an uninterrupted path of one or more larger machines or assemblies. This arrangement is more commonly referred to as a “linear” arrangement, as shown in Figure 1. Thus, the controllers 120, 200 or other devices 20 are configured along a linear machine and interconnected via communication links 80, 15.

[0064] Controllers 120, 200 communicate with each other via communication links 80, 15 to access information about the machine or part of the machine, and controllers 120, 200 located in a first or second path along the system, in order to dynamically coordinate the operation of the machine and the entire system 10. Controllers 120, 200 can also store the configurations of each adjacent controller 120, 200. For example, if machine 12 includes controllers for multiple devices, a first controller or device (e.g., the first device in the path, such as a master device) stores its configuration data and the configuration data of a second controller 120, 200, such as actuator 3 (see Figure 1), and then the second controller 120, 200 stores its configuration data and the configuration data of a third controller 120, 200, such as the first controller 120, 200 (master device) and actuator 2 (if present), along with the last controller 120, 200, which stores its configuration data and the configuration data of the second to last controller 120, 200. Therefore, if controller 12 is removed, the replacement controller 12 can automatically access the configuration data properly stored in the adjacent controllers 120, 200. Furthermore, even if the controllers have different numerical IP addresses or MAC addresses, the replaced controller can communicate with the other controllers using the method of the present invention without the need to reprogram the controller or computing system 90. In one embodiment, controllers 120, 200 may use UDP for transferring configuration data, Modbus TCP for inter-controller communication, and Ethernet / IP for other communications.

[0065] Those skilled in the art will recognize that the environments shown in Figures 1 to 6 are not intended to limit the scope of embodiments of the present invention. In particular, System 10, Machine 12, Device 20 and Controllers 120, 200, and / or System Controller 16 or Computing System 90 may include fewer or additional components that are consistent with alternative embodiments of the present invention. Indeed, those skilled in the art will recognize that other alternative hardware and / or software environments may be used without departing from the scope of the present invention. Furthermore, those skilled in the art will understand that various devices or controllers and / or System Controllers or Computing Systems may include more or fewer applications configured therein. Therefore, other alternative hardware and software environments may be used without departing from the scope of embodiments of the present invention.

[0066] Routines performed to implement embodiments of the present invention, whether implemented as part of an operating system or as a sequence of instructions performed by a particular application, component, program, object, module, or one or more devices / controllers and / or control systems / computing systems, are referred to herein as “sequences of actions,” “program products,” or more simply “program code.” Program code typically comprises one or more instructions, one or more of which reside at various points in time in various memory and storage devices in the controller and / or computing system, and when read and executed by one or more CPUs and / or their respective controllers and / or computing systems, cause those controllers and / or computing systems to perform the steps necessary to carry out the steps, elements, and / or blocks that embody various aspects of the present invention.

[0067] Figures 5, 5A, 5B, and 6 illustrate an exemplary system 250 using relative addressing according to the present invention in a setting that includes a conveyor machine 251, which includes a plurality of conveyor sections 254, with an upstream end 252 connected to a downstream end 258, reflected by the directional flow 256 of the conveyor. Each conveyor section 254 is connected to its respective controller 260, 262, 264, 266, 268, 270, 272, which, for example, controls the operation of the section and any motorized rollers or other elements within it. In the illustrated examples, the addressing according to the present invention is used to control the flow of items or products on the conveyor 251 and to determine or predict fullness in a particular section to stop the flow of products. Figure 5B shows an exemplary controller 260 and elements to illustrate an example of relative addressing functionality in a conveyor environment.

[0068] Each controller communicates directly with an upstream or downstream controller, as shown in the respective connection tables 261, 263, 265, 267, 269, 271, and 273 shown in Figure 5A for controllers 1-7 shown in Figure 5. Each connection table is associated with each controller using the relative addressing scheme of the present invention. To this end, the connection tables indicate that duplicates may be used to provide a connection between a controller and a particular upstream or downstream element, through instructions for output ports and the number of hops to the destination element.

[0069] As shown in Figure 5B, the controller includes control circuits such as a CPU 280 and motor control and I / O circuits 282. Each controller also includes a network switch such as an Ethernet switch 284 with multiple ports, port 1 288 and port 2 290. Each controller is coupled to other controllers or elements of system 250 via link 286 and to each section of the conveyor via link 292 (see Figure 5).

[0070] For example, in a conveyor system, it is often desirable to be able to exchange status information between conveyor controllers to facilitate the movement of products down the conveyor line. In such cases, all controllers need to establish connections to one or more controllers upstream and one or more controllers downstream. For communication with upstream controllers, each controller passes through output port 1 and one or more hops, as shown in the upstream connections of the connection table in Figure 5A. Similarly, when connecting only to downstream controllers, each controller passes through port 2 and one or more hops, as shown in the downstream connections of the connection table. On the other hand, while the example in Figure 5A shows connections to adjacent controllers via one hop, other communication applications may require one or more controllers to communicate with controllers or elements further along the conveyor 251, and therefore may use multiple hops. The information passed through these connections allows controllers to know what each controller is doing. The examples discussed with respect to Figures 5, 5A, 5B, and 6 represent one such distributed control system in which controllers autonomously transport products into the line. The transport logic that all controllers perform may be identical in each controller, and is usually identical.

[0071] A programmer only needs to create one program and then send it to all controllers. However, in reality, there are hurdles to overcome. Even if the control logic program is identical across all controllers, the connections representing "upstream" and "downstream" must be unique. Relative addressing allows all programs and connection tables to be the same. Using identical programs and connection settings significantly reduces the time required to assemble and operate such a system.

[0072] In the conveyor system shown in Figure 5, there may be specific requirements for product processing by particular controllers. One example of such a requirement is to prevent products from stopping in sections that can be temporarily removed or lifted, such as curved sections or sections involving lift gates. In such cases, it is common for one controller A to require information from a controller B that is not immediately adjacent to or connected to controller A. Therefore, if a controller needs to communicate with another controller further upstream or downstream, the one-hop upstream and downstream connections shown in the connection table may not be sufficient for such tasks. However, relative addressing in the present invention can be advantageously used in such scenarios. In the example shown in Figure 5, there is a requirement that products cannot stop in curved sections of conveyor 251. For example, products cannot stop in section 254 (controllers 264, 266) associated with controllers 3, 4. This is achieved by configuring the "Full Predict" application and functionality on controller 262, shown as controller 2, and their respective connections.

[0073] Again, the programmer does not need to know the actual addresses of various upstream or downstream controllers to set up this connection. The relative addressing of the present invention is convenient and suitable for repeated use in conveyor systems or other systems without changing the program or configuration. As shown in Figure 5A, the “perfectly predictable” connection is configured in controller 262’s connection table 263 to connect to a controller “five hops away at output port 2,” as shown in the controller’s connection table. Output port 2 is downstream, and five hops downstream from there correspond to controller 7 or controller 272. If the conveyor section of controller 7 becomes full of products, for example, because there are too many products in the conveyor section beyond the section associated with controller 7, controller 2 will stop sending products further under the conveyor and around the curve. Products currently moving between controllers 2 and 7 will have room to stop in the sections associated with controllers 5 and 6, and the curved section will remain free of products.

[0074] Figure 6 shows the program flow for such a function according to one embodiment of the present invention. Starting in block 300, the program flow proceeds to determination block 302, where the program determines whether a product is present on the local conveyor section, which in this example is a section associated with controller 262 or controller 2 in Figure 5. For example, a photo eye (not shown) or some other sensor may indicate the presence of a product in section 254. If there is no product as shown, the flow proceeds to determination block 316, where it is determined whether an upstream connection, such as controller 260, is configured to allow the section of controller 262 to receive a product. If not, the flow returns to start block 300 in a loop. However, if there is an upstream connection to section 254 of controller 260 (i.e., controller 1), then in block 318, a determination is made as to whether there is a product on that section 254 of the conveyor. If there is a product, the "yes" or Y path provides that the conveyor section of controller 260 will be executed, for example, by supplying power to the motor of the electric roller associated with conveyor section 254 to execute that section and moving the product to the section associated with controller 262 (controller 2). Thus, the upper loop of the flowchart in Figure 6 is to check whether the product is entering the curved section of conveyor 251.

[0075] Referring again to Figure 6, if block 302 indicates a product, the program flow proceeds to block 304 to determine if there are any further conveyor sections to transfer the product. That is, block 304 determines if there are any downstream connections to controller 264 (controller 3), etc. If there are no further sections 254 to advance the product, controller 262 provides a command to stop the section it controls, such as stopping the motor of the electric roller running section 254 of controller 262, as shown in block 314. However, if there are downstream connections to section 254 of controller 264 (controller 3), a decision is made as to whether there are any products on that conveyor section (block 306). If there are products (yes in block 306), it means that no additional products can be moved downstream, and the flow proceeds to block 314, stopping the movement of conveyor section 254 associated with controller 262 (controller 2), and stopping the flow of products.

[0076] If there is no product in the downstream section 254 of controller 3 ("No" in block 306), the downstream section may be able to receive the product. However, before delivering the product to the curve, the full prediction program of controller 2 (262), represented by blocks 308 and 310, operates to ensure that the product moving from section 254 of controller 262 does not stop at one of the curved sections 254 (controllers 3 and 4) of conveyor 251. Specifically, block 308 determines whether the full prediction program and connection are configured to evaluate the state further downstream. If full prediction is not set up ("No" in block 308) and there is no reason to evaluate the state downstream (for example, if the section of controller 262 is not on the curve), the flow proceeds to block 312 to run the conveyor and move the product. If the answer to block 308 is "Yes", the flow instead proceeds to block 310 to determine whether there is a product on the conveyor section that the full prediction connection is focused on. That is, in order to carry out the full prediction program, it is necessary to establish communication with the conveyor section 254 (controller 7). The conveyor section of controller 7 is 5 hops from the section of controller 262 through output port 2 (downstream). Controller 7 and its section 254 are downstream and are the conveyor sections beyond the curve. The target section coupled to controller 272 (shown as controller 7) is 5 positions or hops from the section of controller 2, as shown in connection table 263 in Figure 5A.

[0077] Therefore, controller 262 communicates with controller 272 using the relative addressing of the present invention to communicate with an element 5 hops downstream through output port 2 of controller 262 in order to determine whether the product is present in the conveyor section of controller 72. Even if the address of controller 272 is not known, the present invention can reach the conveyor section 254 of controller 272 according to the present invention. Controller 2 communicates with controller 7 and if there is no product there, the product ahead of the curve may proceed as shown in the flow of block 312. However, if the product is in the section of controller 7 (controller 272), the “complete” state is met or expected, so the product should not proceed from the conveyor section of controller 2 (controllers 3, 4) to avoid the product stopping on the curve. In that case, the conveyor section 254 controlled by controller 262 is stopped by block 314. In this example, the conveyor sections of controller 5 (controller 268) and controller 6 (controller 270) are too close to the curve, so the section 254 of controller 7 is selected. Therefore, it would be desirable that the full prediction condition be controlled by the conveyor section of controller 272 located further downstream from the two downstream sections adjacent to the curve. Of course, other configurations may be used. For example, the full prediction function could be performed by contacting a section of controller 5 or 6.

[0078] The present invention has been described in relation to a fully functional controller and / or computing system, and is also described below, but those skilled in the art will understand that various embodiments of the present invention are distributable as various forms of program products, and that the present invention applies equally regardless of the specific type of medium holding computer-readable signals used to actually carry out the distribution. Examples of media holding computer-readable signals include, but are not limited to, physical and tangible recordable media such as volatile and non-volatile memory devices, floppy disks and other removable disks, hard disk drives, and optical disks (e.g., CD-ROMs, DVDs, etc.).

[0079] Furthermore, the various program codes described above or below may be identified based on the application or software component in which they are implemented in a particular embodiment of the present invention. However, it should be understood that specific program naming conventions are used merely for convenience, and therefore the present invention should not be limited to use in any particular application identified and / or implied by such naming conventions. Furthermore, since there are usually countless ways to organize computer programs into routines, procedures, methods, modules, objects, etc., and various ways in which program functions can be assigned between various software layers residing within a typical computer (e.g., operating systems, libraries, APIs, applications, applets, etc.), it should be understood that the present invention is not limited to the specific organization and assignment of program functions described herein.

[0080] The present invention is described by the description of its embodiments, and while embodiments are described in considerable detail, it is not the applicant's intention to limit the scope of the appended claims to such detail, or to limit them in any way. Additional advantages and modifications will be readily apparent to those skilled in the art. Thus, the present invention, in its broader embodiments, is not limited to certain detailed representative apparatus and methods, as well as the illustrated and described exemplary embodiments. Accordingly, it may deviate from such details without departing from the spirit or scope of the applicant's general inventive concept. [Explanation of Symbols]

[0081] 1 port, controller 2. Machines, actuators, ports, controllers 3 Controllers 4 controllers 5 Controllers 6 Controllers 7 Controllers 10 Systems 12 Machines 12a machine 12b machine 12c machine 14 Network switches, switch elements, Ethernet switches 15 Communication Links 16 System Controllers 18 Electric Roller 20 Control devices, actuators, nodes 20a Actuator, Master Device 20b Actuators, Master Actuators, Master Devices 20c actuator 30 Port A, Output Port 32 Port B, Output Port 40 flows 80 Communication Links 80a~b Communication Link 82 Networks 90 Computing Systems 92 CPU 94 memory 96 Large-capacity storage devices 98 Network Interfaces 102 Input / Output Device Interfaces 104 User Interface 106 Output Devices 110 Control Applications 120 controllers 122 Central Processing Unit ("CPU") 124 memory 126a Network Interface, Network A Interface 126b Network Interface, Network B Interface 128a Motor Interface, Motor A Interface 128b Motor Interface, Motor B Interface 129a Hardware Interface, Hardware A Interface 129b Hardware Interface, Hardware B Interface 130a Sensor Interface, Sensor A Interface 130b Sensor Interface, Sensor B Interface 132 Power input and adjustment interface 134 Input / Output Device Interfaces 136 User Interface 138 Output Devices 140 firmware 142 Program Code 144 Network Servers 146 Large-capacity storage devices 148 Configuration Data Structure 150 Parameter Data Structures 200 controllers 202 CPU 204 memory 205 Firmware 206 Control Logic 208 Brake output, motor interface 210 Three-phase power inverter bridge, power, motor interface 212 Safety Subsystem 214 Motor Position Interface 218 Large-capacity storage devices 221 Ethernet Switch 222 Controller 224 Ethernet ports, 1 Ethernet port 226 Ethernet ports, 2 Ethernet ports 230 Analog I / O Interfaces 232 Digital I / O Interfaces 234 Interface 236 Power Input Interface 238 Power adjustment circuit 250 Systems 251 Conveyor Machine 252 Upstream end 254 Conveyor Section 256 Flow 258 Downstream end 260 Controllers 261 Connection Table 262 Controllers 263 Connection Table 264 Controllers 265 Connection Tables 266 Controllers 267 Connection Table 268 controllers 269 ​​Connection Table 270 Controllers 271 Connection Table 272 Controllers 273 Connection Table 280 CPU 282 Motor control and I / O circuits 284 Ethernet Switch 286 links 288 Port 1 290 Port 2 292 links 300 starting block 316 Decision Block

Claims

1. A method for communicating between network-connected devices that define a path having multiple device locations, wherein the method is performed by a network-connected device, and the method is A step of specifying a source device for a communication stream, wherein the source device has a first port for communicating in a first direction of the path and a second port for communicating in a second direction of the path with a device networked to the source device; The steps include: selecting a port from one of the first or second ports of the source device in order to define the direction of the communication stream from the source device to the destination device; A step of providing a hop count indicating the relative position of the destination device of the communication stream, wherein the hop count is an integer of the position of a network-connected device from the source device to the destination device along the path in the direction defined by the selected port. The steps include: traversing a single hop in the defined path direction from the selected port of the source device to another network-connected device connected to the selected port, and designating the other network-connected device as a new relative device; The steps include obtaining the network addresses of network-connected devices coupled to the first and second ports of the new relative device, and decrementing the hop count. If the hop count is greater than 1, the steps include iteratively advancing an additional single hop to an additional networked device in the defined direction of the communication stream, thereby iteratively decreasing the hop count. A method comprising the step of designating the next additional network-connected device of the current relative device as the destination device for the communication stream if the hop count is equal to 1.

2. The method according to claim 1, further comprising the step of first obtaining the network addresses of network-connected devices coupled to the first port and the second port of the source device, respectively.

3. The step of performing a single hop from the aforementioned source device to another network-connected device is, The steps include evaluating the network addresses of network-connected devices coupled to each of the first and second ports of the new relative device, A step of excluding the network address of the network-connected device associated with the previous relative device, The steps include using the remaining network address to designate the other network-connected device as the new relative device, and The method according to claim 1, comprising:

4. The method according to claim 1, further comprising the step of designating the current relative device as a previous relative device before designating the other network-connected device as a new relative device.

5. The method according to claim 1, further comprising the step of obtaining the network address of a network-connected device coupled to each of the first and second ports of the new relative device, and recording a fault condition if there are other ports of the new source device in addition to the first and second ports.

6. The method according to claim 2, further comprising the steps of first obtaining the network addresses of network-connected devices coupled to each of the first and second ports of the source device, evaluating the hop count, and if the hop count is equal to 1, determining the network address of a device connected to the selected port that defines the direction of the communication stream, and designating the network address as the address of the destination device.

7. The method according to claim 1, wherein the step of designating the next additional network-connected device as a destination device includes the step of designating the address of the next additional network-connected device from the current relative device as the destination device address for the communication stream.

8. The method according to claim 1, wherein the step of designating the other network-connected device as the new relative device includes the step of designating the address of the other network-connected device as the new relative device address.

9. A network-connected device configured to communicate with other network-connected devices along a path, At least one processor, A first port for communicating in a first direction of the path and a second port for communicating in a second direction of the path for communicating with other network-connected devices, Program code configured to run on at least one processor, which causes the processor of the device to designate the device as a source device for a communication stream to another network-connected device; selects a port from one of the first or second ports to define the direction of the communication stream from the source device to the destination device; provides a hop count indicating the relative position of the communication stream to the destination device as an integer of the position of a network-connected device from the source device to the destination device along the path in the direction defined by the selected port; and from the selected port of the source device, in the defined path direction, the selected The program code causes the following to occur: to advance a single hop to another network-connected device coupled to the port, designate the other network-connected device as the new relative device; to obtain the network addresses of the network-connected devices coupled to the first and second ports of the new relative device, and decrement the hop count; if the hop count is greater than 1, to iteratively advance an additional single hop to an additional network-connected device in the defined direction of the communication stream, and iteratively decrement the hop count; and if the hop count is equal to 1, to designate the next additional network-connected device of the current relative device as the destination device of the communication stream. A network-connected device equipped with [the following features].

10. The network-connected device according to claim 9, wherein the program code is configured to first obtain the network address of a network-connected device coupled to each of the upstream ports and downstream ports in the defined direction of the communication stream of the source device.

11. The network-connected device according to claim 9, wherein the program code is configured to perform the following actions when making a single hop from the source device to another network-connected device: evaluate the network addresses of the network-connected device coupled to each of the first and second ports of the new relative device; exclude the network address of the network-connected device associated with the previous relative device; and use the remaining network addresses to designate the other network-connected device as the new relative device.

12. The network-connected device according to claim 9, wherein the program code is configured to designate the current relative device as a previous relative device before designating the other network-connected device as a new relative device.

13. The network-connected device according to claim 9, wherein the program code is configured to record a fault condition if there are other ports of the new relative device in addition to the first and second ports when obtaining the network address of a network-connected device coupled to each of the first and second ports of the new relative device.

14. The network-connected device according to claim 10, wherein the program code is configured to first obtain the network addresses of network-connected devices coupled to each of the first and second ports of the source device, evaluate the hop count, and if the hop count is equal to 1, determine the network address of a device connected to the selected port that defines the direction of the communication stream, and specify the network address as the address of the destination device.

15. The network-connected device according to claim 9, wherein the program code is configured to further specify the address of the next additional network-connected device from the current source device as the destination device address for the communication stream when specifying the next additional network-connected device as the destination device address for the communication stream.

16. The network-connected device according to claim 9, wherein the program code is configured to designate the other network-connected device as the new relative device, including designating the address of the other network-connected device as the new source device address.

Images