BACKGROUND OF THE INVENTION In a conveyor system a conveyor control system is implemented. Due to the complexity of a typical conveyor system layout, conveyor resources must be shared and allocated in an organized manner in order to assure efficient utilization of resources and to avoid traffic jams in the system.

Currently, specialized conveyor system programs are written in order to manage carrier traffic load in the conveyor system. These programs need to be updated whenever the conveyor system is altered in any way including the addition or subtraction of a resource. This is expensive and inefficient.

It remains desirable to have a way of managing carrier traffic in a conveyor system without specialized programs.

It is an object of the present invention to provide a method and apparatus to handle traffic in a conveyor system in order to avoid traffic jams.

It is another object of the present invention to provide a method and apparatus to handle traffic in a conveyor system that adapts to alterations in the conveyor system.

SUMMARY OF THE INVENTION The problems of managing traffic in a conveyor system are solved by the present invention through a system of software

modules which are connected according to the conveyor layout.

These software modules each contain an identical, simple program, such that when the modules are connected according to the physical conveyor layout, their aggregate can control the conveyor system without traffic jams or lockups.

In the present invention these modular programs use a process referred to herein as"the method of deferred decisions"in order to coordinate their activities as required. With this method, conveyor zones that have more than one input (such as intersections or bi-directional elements) are only allowed to act as"pass-thru"elements, rather than storage elements. The logic is as follows: 1) A conveyor zone that wishes to send a carrier to the next zone, must first send a message to this zone requesting permission to transfer a carrier into that zone.

2) If the receiving zone is a single input zone, then the zone will respond'OK'if the zone is empty. If the zone is not empty, the carrier is put on a queue, and then once the zone is empty, the carrier is taken off the queue, thereby indicating it is all right for the sending zone to release the carrier into the receiving zone.

3) If the receiving zone is a multiple input zone, e. g., an intersection or bi-directional element, then the zone cannot be reserved, and the request is forwarded or deferred to the next zone.

4) This process continues until a single input zone is reached, which responds'OK'once the zone is empty and has been reserved for that particular requesting carrier.

Therefore, no carrier is allowed to enter an intersection in the conveyor system operating under the present invention until it is confirmed that the carrier will be allowed to leave the intersection. As each resource in a path is queried for availability, that resource is allocated to the querying carrier. Once a carrier moves through an allocated resource, that resource is deallocated.

Through the method of deferred decisions, it is possible for each autonomous conveyor zone to communicate with only its direct neighbors and accomplish resource allocation in the conveyor system.

The present invention together with the above and other advantages may best be understood from the following detailed description of the embodiments of the invention illustrated in the drawings, wherein: BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a diagram of an intersection in a conveyor system operating according to principles of the invention; Figure 2 is a section of a conveyor system having a plurality of intersections and linear sections operating according to principles of the invention; Figure 3 is a detailed diagram of an intersection such as the intersection of Figure 1 operating according to principles of the invention; Figure 4 is a chart of a typical message flow in the conveyor system according to principles of the present invention; Figure 5 is a flow chart diagram showing the logic used when a"request to transfer in"message is received; Figure 6 is a flow chart diagram showing the logic used when an"OK to transfer in"message is received, or when a conveyor zone becomes available and queued requests are outstanding;

Figure 7 is block diagram of a distributed computing architecture according to principles of the invention; and, Figure 8 is a block diagram of a centralized computing architecture according to principles of the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS Figure 1 is an intersection 100 connecting four linear sections AB 105, CD 110, EF 115, and GH 120 in a conveyor system operating according to principles of the present invention. The intersection 100 in Figure 1, also referred to as a"QS"or a"corner", is a multiple input zone meaning that it has more than one input. Other examples of multiple input zones are multiple port shuttles, elevators and bidirectional linear sections. The linear sections 105,110,115,120 are all single input zones meaning that they each accept carriers from only one input. Each carrier in the system has a unique identification which is included in an abbreviated data packet used in messaging between zones in the conveyor system.

Before a carrier is allowed to enter the intersection 100, the conveyor system first establishes that the carrier will be able to leave the intersection 100. This prevents the carrier from blocking the intersection to cross traffic. In this case, it must be established that the"resource"of the linear section following the intersection 100 is available.

The resource is then allocated to the particular carrier before the carrier travels into the intersection 100 in order to prevent another carrier from using that location.

In Figure 1, suppose that linear section C-D is full of carriers, and another carrier approaches from interface B to travel through the intersection 100 to interface C. If the carrier from interface B were allowed to enter the intersection 100 before linear section CD 110 is available to receive it, then the intersection 100 would be blocked, preventing any cross traffic from interface F to interface G.

For this reason no carrier is allowed to enter an intersection in the conveyor system operating under the present invention until it is confirmed that the carrier will be allowed to leave the intersection.

Figure 2 shows a section of a conveyor system having a plurality of intersections and linear sections. Linear sections 201,202,203,207,210A and 210B are unidirectional sections and are therefore single input zones under the definition given above. Linear sections 204,208,211,213 and 214 are bidirectional sections, and therefore are multiple input zones as are all the intersections 205,206,209 and 212. Each intersection 205,206,209,212 has a unique routing map. This routing map indicates the exit port (direction) for each destination in the entire conveyor system. The routing map is automatically generated by the conveyor system by each element querying its neighbors at configuration time in order to determine how the elements are connected. Once this is known, the connection information from all of the elements is gathered and translated into a unique routing map for each decision node (a node with more than one output).

In Figure 2, if a first carrier originating from location (D) 226 is travelling to location (B) 222, and a second carrier originating from location (A) 220 is travelling to location (C) 224, these two carriers may collide in linear section 208 if resources are not allocated effectively.

In the present invention, a zone having a carrier initiates a query to the next zone in order to request the transfer of that carrier. If the receiving zone is a multiple input zone, then the request is deferred to each zone in the carrier's path toward the destination zone until a single input zone is reached. In this case the decision is made, and the request is granted, allowing the carrier to move ahead in the conveyor system. In other words, the decision to move

ahead in the conveyor is deferred until a storage location in a single input zone can be reserved. As each resource (conveyor zone) in a path is granted as available, that resource is allocated (reserved) to the querying carrier.

Once a carrier moves through an allocated resource (conveyor zone), that resource is deallocated.

In this case, either the first carrier must wait before entering intersection 206 until the second carrier enters linear section 207, or the second carrier must wait before entering intersection 209 until the first carrier enters linear section 210A. In the present invention, the first carrier asking for an available resource receives that resource regardless of the carrier's priority in relation to other querying carriers. If, however, a resource is not available, requests made by carriers are queued and once the resource is available, these requests are granted based on carrier priority or some other selection logic. Through the method of deferred decisions, it is possible for each autonomous conveyor zone to communicate with only its direct neighbors and accomplish the resource allocation issues discussed above. Each zone with more than one output contains a unique lookup table indicating which output port should be used to send the carrier for each possible destination in the system. In a preferred embodiment of the invention, the lookup table is automatically generated from a data base or data file describing the layout of the conveyor system at system initialization. In alternative embodiments, it may be precalculated and then uploaded to the conveyor system.

In order to implement this control concept, two architectures are possible. Figure 7 shows a distributed computing architecture. Figure 8 shows a centralized computing architecture.

The distributed computing architecture in Figure 7 may be used such that an independent controller 701 is used for each

conveyor zone, and these controllers communicate via a communications channel 702. This communications channel 702 need only connect adjacent zones, so it may be a simple 2- party communications channel, such as a serial connection, because all communications occur between adjacent nodes only.

If the hardware permits it, the communications channel may occur also across a common network.

In the centralized architecture in Figure 8, a central computer (or a network of several centralized computers) may implement the same logic by establishing asynchronous, independent software modules 801 that communicate to each other through software channels 802 mimicking the serial channels described above. This would require a multi-tasking operating system to simultaneously execute the many copies of identical programs. These programs would be"connected" together via connections 802 according to the conveyor layout, just as the distributed computers would be connected together via serial cables. The conveyor hardware (motors and sensors) would then be controlled via a Factory Floor I/O bus 803 as is common in factory control systems.

In order to accomplish querying, the zones have messaging capability among themselves. First, the data package passed with the initial request includes an abbreviated carrier data packet (ACDP). The full carrier data packet definition is provided below along with a specification for the ACDP. This ACDP contains enough information to handle allocation and routing issues. An abbreviated data package is used in the distributed computing implementation in order to limit communications requirements. In the centralized computing architecture, a pointer to the full data package could be passed, avoiding the need to have two types of data carrier packets.

The ACDP will include at a minimum the following: FINAL ZEST: Final destination for carrier.

PRIORITY: Priority to be used in resource arbitration.

TIMEOUT: Timeout to be used when waiting for resources to become available also referred to as"resource limits".

REQUEST ID: A unique ID for the request, used to deallocate.

Usually set to the CARRIER-ID.

The ACDP may also contain a current carrier destination and batch data.

The process for a simple carrier routing case is as follows: 1) When a zone would like to transfer a carrier to the next zone a XFERREQUEST (transfer request) message is sent to the next zone. Included in this XFERREQUEST message is the FINAL destination of the carrier, the priority code for the carrier (if any) and the timeout value to use for attempting to secure resources.

2) If the zone receiving the request is a single input zone, it must only determine only if there is a storage place in the zone for the carrier. If there is space in the zone for the carrier, the space is allocated and a XFERACCEPT message is returned, indicating a storage place has been reserved and the requesting zone may now send the carrier.

3) If the zone receiving the request is a multiple input zone, then it must defer the decision to the next zone on the path to the final destination. Based on the destination, the request message is forwarded to the appropriate next zone in the path. This zone then evaluates the request, and if that zone is a multiple input zone, then the request may yet again be forwarded to the next zone until finally a single input element is reached.

In order to handle all cases of errors, unavailable resources, timeouts, priorities a few additional rules must be imposed. The process to handle priorities and timeouts is as follows:

1) When a request for transfer is received, then the direction of the zone making the request is allocated to be INPUT, if the zone was not previously allocated.

2) When a request is sent out of a zone, then the direction of that zone is allocated to be OUTPUT, if the zone was not previously allocated.

3) When a zone was previously allocated to be in the opposite direction, then the request for this change is queued in a list along with the passed PRIORITY and TIMEOUT.

4) When the zone becomes available to change direction then the requestor with the highest PRIORITY (and then with the shortest TIMEOUT time left if the priorities are the same) is granted the request.

5) If the timeout expires before the zone becomes available, then a DENY (w/TIMEOUT response code) is returned to the requestor.

Figure 3 shows an intersection 300 with a carrier 305 having a destination of location <F> 310. The carrier 305 is located in location <B>. There are ten locations shown, <A>, <B>, <C>, <D>, <E>, <F>, <G>, <H>, <I>, <J>.

Figure 4 shows a typical message flow associated with moving the carrier 305 through the intersection 300 of Figure 3 to destination <F> 310. The list at the left of the figure has the messages in the order they are sent. The horizontal bars at the top and the bottom of the chart are the locations in the intersection 300. The rectangles in the chart show carrier location and movement from step to step and the lines and arrows show messages propagating through the locations. A messaging specification for an implementation using a distributed computing architecture is provided below.

At the start of the message flow, step (1) 400, the carrier is in location <B>. At step (2A) 402, a query is sent out to location <C> in movement toward location <F>. Location <C> is available but is a multiple input element and so defers

to location <D> 406. Location <D> is also available but is also a multiple input element and so defers to location <E> 408, and similarly location <E> defers to location <F> 410.

Location <F> 410 is a single input zone, so it reserves the location and responds with a"GRANT"message. The resources, as the decision is deferred along the path to location <F>, are allocated to the carrier and are added to the propagated message as it returns from location <F> to location <B>, steps (3A)- (3D), 412,414,416,418. At step (4) 420, the carrier is moved to the next location, location <C>, along with the full carrier data packet (CDP), and location <B> is deallocated. In the following step 422, the carrier is moved again (along with the full CDP), this time to location <D>, and location <C> is deallocated. In the steps following the move to location <C>, space around location <D> is allocated and then the carrier is rotated. At step (8) 428, a transfer request is received to transfer the carrier to location <E>.

In steps (9) and (10), the space around location <E> is allocated so that <E> may rotate to accept the carrier from <D>. In step (11) the carrier is transferred (along with the full CDP) to location <E>. In steps (12), (13) and (14) element <D> is rotated back to its original position. In step (15) the carrier is transferred to <F>, along with the full CDP, and in steps (16), (17) and (18) element <E> is rotated back to its original position.

CARRIER DATA PACKET SPECIFICATION Carrier Data Packet Requirement In order for the conveyor system to intelligently track and transport carriers a package of information should be carried around with the carrier. This packet of information, called the Carrier Data Packet (CDP) includes such things as the carrier ID, the destination for the carrier, reader information (bar code ID or RF Tag ID), carrier priority,

batch information, and higher level routing logic. Depending on the requirements of different systems, portions of this carrier data packet may or may not be required. The functions associated with each piece of information are identified in this section in order to facilitate the process of determining exactly what needs to be contained in the carrier data packet.

Additionally, in order to limit overall communications overhead, there are 2 types of CDPs used: the Abbreviated Carrier Data Packet (ACDP) and the Full Carrier Data Packet (FCDP). Whenever CDP is referred to it is to be understood that the FCDP is meant.

Detailed Requirements: Full Carrier Data Packet: The Full Carrier Data Packet (FCDP) carriers all of the information required by the conveyor system in order to deliver the carrier. In systems containing a host Transport System Controller (TSC) the FCDP is additionally stored on the host for backup and recovery purposes. In order to avoid continuous network traffic to the host however, the FCDP is stored locally within each controller board responsible for that carrier, and then transferred from controller board to controller board as the carrier navigates its way through the system.

The following data is stored in the carrier data packet: Final Destination: This is the ID of the final destination of the carrier.

It may be the ID of a physical location, a buffer or a group.

Current Destination: This is the ID of the current destination of the carrier. It may be the ID of a physical location or a buffer.

This differs from the final destination when a carrier's final destination is a group, or when the carriers planned path to the final destination includes intermediate stops.

When the final destination of a carrier is a group, the group has an associated distribution location where the distribution algorithm for the group must determine which group member should receive the carrier. The final destination would be the group ID, and the current destination would be the physical ID of the distribution node. The current destination is the destination used in the routing logic and is passed in the ACDPs.

Additionally, a carrier may enter the system with a planned path of intermediate destinations. The final destination indicates the final stop on this path, the entire path is stored in the path array, and the current destination on that path is stored in the current destination field. A planned path may also develop for a carrier that has overflowed several previous buffers. For example, suppose a carrier was originally destined for a particular tool buffer, and this tool buffer was found to be full when the carrier arrived near the buffer. The carrier may have overflowed to another buffer, for example, a nearby loop. The planned path for the carrier would be updated to indicate the path of two destinations (final buffer destination and overflow buffer) and the current destination would indicate the overflow location. This process may recurse itself if the overflow is full, then the path would be updated to indicate three destinations, etc.

Carrier Path: As described above under Current Destination, this represents the planned path of a carrier on the way to its final destination. This list may be used to enforce a particular path through intermediate buffers in the system.

Group Definition: The definition of the group, if the destination is a group. This data structure defines the group for carriers that are destined to a group. It includes the decision tree,

and the distribution node and distribution algorithm associated with each decision branch in the tree.

List of allocated resources: This list identifies all of the resources currently allocated by the carrier. It is used to release resources as they are no longer needed. It is also used in error recovery to determine which resources may need to be released when a carrier is incorrectly moved or removed from the system.

Error log: This data structure stores error logging information.

If a particular carrier causes too many errors, for example, then an error threshold may be set in order to route this carrier to an error destination and record a problem in the error log. Errors may be in the form of expired resource limits (timed out waiting for traffic), bad reads from the reader, etc.

Priority: This defines the priority for the carrier. It is used for resource allocation and for distribution from buffers.

Batch data: This is a data structure that includes the batch ID, batch element number and size of batch when batch integrity is used during routing and resource allocation.

Resource limits Modifications to resource limits are possible for an individual carrier if desired. For example, timeout for a resource to become available may be short for low priority carriers and longer for high priority carriers.

This data structure carries a list of resource limit modifications.

Carrier ID A unique ID for each carrier is required. This ID is used during resource allocation and deallocation (in order to associate the resource with the correct carrier). It is also

used in host communications to uniquely identify a carrier.

This may occur when the host is looking for a carrier, for example.

Reader ID1 The string expected from the reader for this carrier.

This must be unique to all the carriers currently in the system. READERID1 indicates the string received from readers of type 1. More than one type of reader may be used in the same system.

Reader ID2 The string expected from the reader for this carrier.

This must be unique to all the carriers currently in the system. READER ID2 indicates the string received from readers of type 2. More than one type of reader may be used in the same system.

Search field 1 The string is optional. It provides a search mechanism for locating carriers or updating carrier information. For example, product type may be recorded here, and all products of a certain type may be changed to a low priority.

Search field 2 The string is optional. It provides a search mechanism for locating carriers or updating carrier information. For example, product type may be recorded here, and all products of a certain type may be changed to a low priority.

Search field 3 The string is optional. It provides a search mechanism for locating carriers or updating carrier information. For example, product type may be recorded here, and all products of a certain type may be changed to a low priority.

Reader ID2 The string expected from the reader for this carrier.

This must be unique to all the carriers currently in the system. READERID2 indicates the string received from readers

of type 2. More than one type of reader may be used in the same system.

Abbreviated Carrier Data Packet: The Abbreviate Carrier Data Packet (FCDP) carriers only the information required for the resource allocation performed by the differed decisions logic. Most of the information comes from the FCDP, but some of the information is determined locally by the controller board sending the packet.

The following data is stored in the abbreviated carrier data packet: Current Destination: This is the ID of the current destination of the carrier. See Current Destination description above for details.

Priority: This defines the priority for the carrier. It is used for resource allocation and for distribution from buffers.

Batch data: This is a data structure that includes the batch ID, batch element number and size of batch when batch integrity is used during routing and resource allocation.

Resource limits This defines the resource limits for the deferred decisions allocation logic. It does not necessarily come directly from the FCDP, but may come additionally from the resource limits of the local hardware.

Carrier ID A unique ID for each carrier is required. This ID is used during resource allocation and deallocation (in order to associate the resource with the correct carrier). It is also be used in host communications to uniquely identify a carrier.

This may occur when the host is looking for a carrier for example.

MESSAGING SPECIFICATION Introduction: The conveyor control system is implemented through the use of distributed controller boards. Each controller board is responsible for controlling a small area of the conveyor.

When one controller board must communicate with a neighboring controller board (for example to hand off a carrier) it is done through the secondary interface described herein.

The secondary interface is a serial interface. It is a 3-wire connection consisting of Receive Data, Transmit Data and Ground. Data is transmitted in packets and an error detection protocol is used to determine lost or incomplete packages.

If the conveyor area controlled by a particular controller board is viewed as a block box, it will have a defined number of physical locations where carriers may be transferred on or off of the conveyor. For a simple left travelling linear section for example, there will be an input on the right and an output on the left. A QS element may have 4 such I/O ports, some may be input, some may be output and some may be bi-directional, for example. At each of these physical I/O ports a separate secondary interface connection will be made to the neighboring conveyor section (or potentially external device).

The secondary interface will be used primarily for the following purposes: 1) Carrier handoff: Are you able to accept a certain carrier?....

YES.

Here comes the carrier...

.... I received the carrier.

2) Transmission of Carrier Data Packet (CDP).

Along with each carrier a CDP will be carrier which holds information about the carrier, such as the final destination, priority, batch membership, etc.

3) Configuration: Through the action of each controller interrogating its neighbors it is possible for each controller to determine "who"is connected through each physical I/O port, and by pulling all of this information together the overall system layout may be determined. This makes reconfiguration after conveyor layout changes simpler.

4) Communication with external devices: Since a secondary interface port will exist at each physical I/O point of the conveyor, it is possible to use this interface to handoff carriers to external devices as well (either to send delivered carriers, or to receive new carriers).

Hardware Interface: The Secondary interface is based on an RS-232 serial I/O connection. It is a 3-wire connection, from a 4-pin connector as follows: Pin 1 of connector (power)-Do not connect for secondary interface.

Pin 2 of connector-Transmit Data (TD), connect to RD of other connector.

Pin 3 of connector-Receive Data (RD), connect to TD of other connector.

Pin 4 of connector-Signal Ground (GND); connect to GND of other connector.

The protocol is as follows: Baud rate: 19,200 bits per second.

Data bits: 8 Stop bits: 1 Parity: None.

Flow control: XON/XOFF

Message packet format: The format of the packets of data sent over the secondary interface is as follows: Byte 1: STX character (start of message).

Byte 2: MSG ID (ASCII): HEX 41-5A (A-Z) = Originating message.

HEX 61-7A (a-z) = Response message.

Byte 3: Length in 7 byte blocks (shifted by hex 30 for ASCII) Message length = ( (BYTE3)-30hex) *7 bytes TOTAL, including all chars (STX, etc.) Byte 4: Data byte 1.

Data may take any form, except it must not include any message control chars.

Byte LEN-2: Last data byte Byte LEN-1: (CRC%OxDO) +Ox30.

Byte LEN: ETX character (end of message).

Therefore the smallest message will have a total length of 7 bytes, with 2 data bytes. All message lengths will be in multiples of 7.

CRC computation and error recovery: The CRC code is computed by adding the individual bytes of data, MOD OxDO, and then adding 0x30 to the final value.

This keeps the value above 0x30 to avoid any conflicts with ASCII control characters.

On the receiving side: 1) At the reception of the STX character the internal CRC value is set to STX.

2) Each additional byte is added to the CRC MOD OxDO.

3) At the reception of an ETX character, it too is added to the CRC MOD OxDO, and then this value is compared to the character received just before the ETX.

4) If this is correct, a single ACK character is returned to the sender.

5) If it is incorrect then a single NACK character is returned to the sender.

6) If another STX character is received before an ETX is received, then no character is sent in return, and the CRC count starts over at step 1.

On the sending side: 1) If a NACK is received during a transmission, then transmission is immediately aborted, and the message started new again with an STX character. The MSG_ID counter is NOT incremented in this case because the message has not been sent through yet.

2) If a NACK is received following transmission, then the message is sent again in its entirety. (Same MSG_ID counter).

3) If no response is received after a timeout, then the message is resent from the beginning (same MSG-ID counter).

4) If an ACK is received, then the message is considered sent, and the MSGID counter is incremented.

Message contention: Message contention is not an issue, but a few requirements are placed on the communicating parties.

1) Both parties should be capable of receiving messages while sending messages.

2) A message block can not be interrupted, so if a message transmission is in process and it is determined that an ACK should be sent for a received message, then the ACK must be added on to the END of the transmit buffer, not in the middle.

3) Timeouts must be long enough to allow for a message being received to complete before a timeout will occur waiting for an ACK of a sent message. Either that or the sending side must not start the timeout until the receipt of the incoming message is complete.

Message responses: In order to track which message is being responded to, the response message should have the same MSG ID as the query message plus 0x20.

Otherwise message responses are message specific (depending on message type) in fact a single message may solicit several responses as long as they all have the same MSG-ID.

Message content: The first 2 bytes of data represent the OPCODE of the message, and the following bytes (if any) include the data.

Total message length depends on the OPCODE.

The OPCODES their data, and their possible responses are as follows: OPCODE'02'-PING OPCODE: PING ('02') Data length: 0 bytes Data: None.

FUNCTION: This OPCODE checks to see if the receiving party is alive and reads the UNIQUE ID of the controller.

RETURN Messages: OPCODE:'82'.

Data length: 14 Data: Bytes 1-8: ASCII representation of 32 bit unique ID.

Bytes 9-14: ASCII representation of status.

Status options: '000000'-OK, board functioning.

'FFFFFF'-Board exists, but in error state.

No message after timeout indicates nothing is connected, or controller is dead.

OPCODE'10'-XFER REQUEST OPCODE: XFER REQUEST ('10') Data length: n bytes * Data: Abbreviated CDP (ADCP). * The abbreviated carrier data packet (ACDP), holds only the information needed for the receiving party to make an accept decision. In the limited case, this may include only the destination ID, but the form of the actual ACDP is system specific and may include other information. All controllers must be compiled and linked with the correct ACDP and CDP header files for compatibility.

At a minimum the ACDP must include the following: Destination ID.

Request timeout. (secs., 0 indicates immediate response) Priority (0=low, 9 = high) *-Attachment of the ACDP is optional. If DATA length is 0, then no ACDP is attached. See the description of return codes for when this must be attached.

FUNCTION: This OPCODE issues a request to transfer a carrier to the receiving party.

RETURN Messages: If the requested transfer is accepted, then the receiving party returns: OPCODE: XFER ACCEPT ('90').

Data length: 2 Data: Return code: IS SUC-No errors or special return code needed.

IE_ERROR-General Error processing request (should be reported).

ISNOADCP-In the future the ADCP is not needed by this zone for making this decision.

If the requested transfer can not be accepted within the timeout specified, then at the end of the timeout the receiving party returns: OPCODE: XFER DENY ('91').

Data length: 2 Data: Return Code.

IS SUC-No errors or special return code needed.

Returned only if request would never be granted even if you waited forever.

IE ERROR-General Error processing request (should be reported). IS TMO-Request timed out waiting for a conveyor area or resource to clear. If requested timeout was zero (meaning do not wait), then this is returned if the request may have been accepted after some waiting period (if allowed), IS SUC is returned if the request would never have been accepted for some reason.

IE NEEDACDP-ADCP is required in order to process this request, please resend request with ADCP and include ADCP on all future requests (until NOADCP is returned).

OPCODE'12'-XFER CDP OPCODE: XFER CDP ('12') Data length: n bytes Data: Full CDP.

FUNCTION: This message is used to transfer the complete contents of the CDP for a carrier that is about to be transferred. This would only occur after a XF'R REQUEST was made and the receiving party returned a XFERACCEPT. Only after the CDP has been transferred and CRC checked is the physical transfer started. During this time (before the carrier actually is confirmed arrived, the CDP is marked as being the transfer state for error recovery in case of transfer errors.

RETURN Messages: If the requested transfer is accepted, then the receiving party returns: OPCODE: XFER CDP OK ('92').

Data length: 2 Data: Error code. 0 =OK, otherwise re-send CDP.

OPCODE'13'-XFER START OPCODE: XFER START ('13') Data length: 0 Data: none.

FUNCTION: This message is used to signal the start of the physical transfer. It only occurs after a XFER REQUEST has been answered with a XFER ACCEPT, and the CDP has been successfully transferred with the XFERCDP command. Once the CDP has been successfully transferred, and the XFER START command is sent, then the CDP on the sending rail is also marked as"in XFER"for error recovery purposes. After this message is sent the carrier must arrive on the receiving element within XFERTIMEOUT time or a timeout error will occur.

RETURN Messages: OPCODE: XFER END ('93').

Data length: 2 Data: Error code. 0 =OK, otherwise error code.

After a successful transfer, then the CDP on the sending rail is deleted, and the last zone is cleared to accept a new carrier.

OPCODE'20'-RE LALL OPCODE: RE LALL ('20').-Allocate local resource Data length: 3 or 11 Data: Byte 1,2: ID of resource to allocate.

Byte 3,4: TMO: Timeout for request in secs.

0 = Return immediately (no wait).

Byte 5-14 (if present): Priority code for request, in case of simultaneous requests.

All Data in Hex ASCII format.

Requests the allocation of a local resource. A local resource is allocated between 2 adjacent elements only, and the ID is unique only to this particular secondary interface communications channel. The same ID may be used among

different secondary interface channels of the same controller to mean different physical resources.

An example of such a resource may be the'space'between 2 adjacent QS elements. The elements are not allowed to rotate simultaneously because they must each occupy the rotating space between them in order to rotate. If the both rotated simultaneously they would collide. Therefore they may use this OPCODE between themselves to allocated a resource called ROTATESPACE.

The sequence for allocation is to call RELALL, and wait for a response indicating allocation, then to use the resource, and then when finished call RELDEA.

If TMO = 0, then a response is sent immediately (see response codes below). If TMO>0, and the resource is not available, then the request for the resource is queued on the receiving side until the timeout (TMO secs) expires or until the resource becomes available, whichever occurs first. In either case, a response will occur within TMO secs.

The priority code is a 10 byte priority code for the request. The priority code is optional, and if not sent, then a code of 0 (lowest priority) is used. The priority code is used only in the case of simultaneous requests as described below.

Simultaneous allocation requests: It is possible that two devices will simultaneously request the same resource. In this case, the controller will first evaluate the request, if ISSUC is determined to be the appropriate response, then the priority resolution logic below will be executed. Otherwise ISTMO, ISALL, ISNOALL, ISSTOPASK or IEERROR may be returned as appropriate.

If IS SUC is the intended response, then the controller board will compare the priority code of his sent request with the priority code of the received request. If the received

priority code is less than the sent priority code, then ISNOPRIO is returned. If the received priority code is greater than the sent priority code, then the resource is considered allocated to the requesting party and ISPRIO is returned. Otherwise if the two priorities are equal, then IS TIE is returned. In any case this priority resolution response is sent immediately regardless of timeout.

Then, in the response handling logic, if an IS NOPRIO is received, it is handled as an ISNOALL. If an ISPRIO is received it is handled as an ISSUC. If an IS TIE is received then a new message is sent with a different priority code.

The priority code can be any 10 byte string, however some care must be taken to avoid perpetual lockups due to identical priority codes from two parties. In the first case, since the priority code is only used in the case of simultaneous messages, it is optional and may not be sent on nearly all messages in order to reduce overall message length. If it is not sent from either party, then the priority code is interpreted as 0, and an ISTIE response will occur from both parties. This will cause 2 new requests to be sent with new (real) priority codes.

The form of the priority code can be of the unique ID (32 bits, expressed in ASCII hex is 8 bytes). This leaves two additional bytes free. In the case where the"unique"IDs are for some reason not unique then it is possible to add a random number in this last byte until the priority is resolved.

RETURN Messages: OPCODE: RE LALL RESP ('AO').

Data length: 2 Data: Return code.

ISSUC = Resource allocated successfully.

IS NOALL = Resource not available.

IS TMO = Timeout expired before resource could be allocated.

ISPRIO =Simultaneous LALL requests occurred, and sending party has priority over responding party, so resource IS granted.

IS NOPRIO = Simultaneous LALL requests occurred, and responding party has priority over sending party, so resource is NOT granted.

ISTIE = Simultaneous LALL requests occurred, and the two priority codes were identical.

ISALL = Resource was already and still is allocated to requesting party.

ISSTOPASK = Resource not used by this device, you may stop asking for it.

Note: If resource becomes needed in the future by responding party, then a RELALL by that device will cause the sending party to start asking again in the future.

IEERROR-Error occurred.

OPCODE'21'-RE LDEA OPCODE: RE LALL ('21').-Deallocate local resource Data length: 2 Data: Byte 1,2: ID of resource to deallocate.

All data in Hex ASCII format.

Requests the deallocation of a local resource. A local resource is allocated between 2 adjacent elements only, and the ID is unique only to this particular secondary interface communications channel. The same ID may be used among different secondary interface channels of the same controller to mean different physical resources.

See RELALL for further details.

RETURN Messages: OPCODE: RE LDEA RESP ('A1').

Data length: 2 Data: Return code.

IS SUC = Resource deallocated successfully.

ISNOALL = Resource not available, (ie. allocated by responding party).

IEERROR-Error occurred.

OPCODE'22'-RE GALL OPCODE: RELALL ('20').-Allocate global resource Data length: 32 Data: Byte 1,2: ID of resource to allocate.

Byte 3,4: TMO: Timeout for request in secs.

0 = Return immediately (no wait).

Byte 5-6: Priority code.

Byte 7-14: Unique ID of requesting party.

Byte 15-22: Location ID of resource arbitrator.

Byte 23-32: Unique request ID All data required for every request.

All data in Hex ASCII format.

Requests the allocation of a global resource. A global resource is a single unique resource in the entire system.

The ID must be unique to the system.

An example of such a resource may be a buffer location being reserved remotely, a space in a loop, a communications channel to an external device, etc.

The sequence for allocation is to call REGALL, and wait for a response indicating allocation, then to use the resource, and then when finished call RE GDEA.

If TMO = 0, then a response is sent immediately (see response codes below). If TMO>0, and the resource is not available, then the request for the resource is queued on the receiving side until the timeout (TMO secs) expires or until the resource becomes available, whichever occurs first. In either case, a response will occur within TMO secs.

The priority code is a 2 byte priority code for the request where'FF'is highest priority and'00'is the lowest.

The priority code is used to determine which queued request will receive the resource when it becomes available.

The unique ID of the requesting party indicates where the response message should be sent.

The location ID of the arbitrator indicates the location ID of the controller board responsible for arbitrating the resources (required in order to rout the message).

The unique request ID is used to free the resource by request ID. Therefore it may be possible for one controller board to allocate the resource, and another one to free it based on this unique request ID. This may happen for example when a carrier will allocate a resource before a certain move, and then free the resource upon arrival.

RETURN Messages: OPCODE: RE GALL RESP ('A2').

Data length: 2 Data: Return code.

ISSUC = Resource allocated successfully.

ISNOALL = Resource not available.

IS TMO = Timeout expired before resource could be allocated.

IS ALL = Resource was already and still is allocated to requesting party, with identical request ID.

IEERROR-Error occurred.

OPCODE'21'-RE GDEA OPCODE: RE LALL ('23').-Deallocate global resource Data length: 28 Data: Byte 1,2: ID of resource to deallocate.

Byte 3-10: Unique ID of requesting party.

Byte 11-18: Location ID of resource arbitrator.

Byte 19-28: Unique request ID All data required for every request.

All data in Hex ASCII format.

Requests the deallocation of a global resource.

Unique ID of requesting party, indicates where to send the return message.

Location ID of resource arbitrator is used to route the message to the correct arbitrator.

Unique request ID indicates the ID of the request to deallocate. A different controller board than the one that allocated it may deallocate the resource. Only the unique request ID is required.

See REGALL for further details.

RETURN Messages: OPCODE: RE GDEA RESP ('A3').

Data length: 2 Data: Return code.

IS SUC = Resource deallocated successfully.

IS NOALL = Resource was not allocated to REQUESTID, but REQUEST ID was removed from the queue.

IS NOREQUEST = Request ID not found, no change in allocation status of resource.

IEERROR-Error occurred.

It is to be understood that the above-described embodiments are simply illustrative of the principles of the invention. Various and other modifications and changes may be made by those skilled in the art which will embody the principles of the invention and fall within the spirit and scope thereof.