19_AdvancedAGVs

Chapter 13. Advanced AGVs13.1 IntroductionThis is an advanced chapter on AGVs and provides further details on the controller event contexts, AGV commands, and popups that are described in Chapter 12, AGVs.13.2 ObjectivesThis is an advanced chapter on AGVs and provides details on the controller event contexts, AGV commands, and popups that are described in Chapter 12, AGVs.In this chapter it is assumed that you are now familiar with the basics of the QUEST user interface, with the concepts of elements, classes, and parts, and have a good knowledge of SCL. It is also assumes that you have read Chapter 12, AGVs.13.3 Controller Event ContextsThis section explains the different controller event types (or contexts) generated in QUEST. There is a set of pre-defined controller event types generated by the occurrence of simulation events, the execution of some SCL statements, and from the AGV process logic. These pre-defined controller event contexts are represented by constant values, which are specified in the ‘agv.inc’ include file. For each controller event, the related additional information attached to the event and the basic decisions made by the controller are explained below.PART_AT_DECThis controller event type is generated if a part is ready to enter the path system through a decision point. The part is available (logically) at the decision point ready to be picked up by an AGV. When the elements outside the path systemtry to send the part to the decision points using transfer/route SCL statements, this controller event is generated and sent to the controller. The related information for this context is the part handle of the part to be picked and the decision point where it is available.When the controller receives this event, it:•selects an available AGV and•issues a load command to the AGV for the part at the available decision point, and•issues the MOVE command to the AGV to go to the specified decision point.If no AGV is available the controller event is added to the pending list of the controller for later processing. If any special AGV is needed to pick up the part, the decision should be handled in the AGV_SELECTION popup. Popups are discussed in detail in Chapter 14, Advanced SCL — Popups.Using Run | Trace | Current State | Entity to look at the current state of a decision point shows what parts are trying to enter that decision point. These are the parts for which a PART_AT_DEC event has been generated. If an AGV has been selected for the part the current state of the AGV would show the corresponding pending load command. If no AGV had been selected the current state of the controller would show the corresponding pending event.AGV_REQUESTThis controller event is when an element requires an AGV for a process at a connected. The process requirement related statements such as Do_Process, Require AGV, used in the process logics of the connected elements or those set through the user-interface under cycle process requirements requiring AGV generate this event. The AGV_REQUEST eventrepresents the need for an AGV only for processing and not for picking up parts. When an AGV is moving to a decision point in response to this event, it is reserved for the process.. It is released only after the process is completed. In general, in the default logics a reserved AGV is not selected for other load or unload related tasks.The information for this context is the decision point at which the AGV is requested and the AGV class needed.For this context, the controller tries to select an available AGV similar to PART_TO_DEC context.After the AGV is selected, the controller reserves it dDuring simulation, the current state on the AGV (using Run | Trace | Current State | Entity) shows whether the AGV is reserved or not. The current state of the machines shows any pending AGV requirements that need to be fulfilled. If no AGV has been selected the current state of the controller would show the corresponding pending controller event.AGV_REACHING_DECThis controller event occurs when an AGV approaches a decision point. When an AGV moves along path segments and approaches a decision point it needs to know if it has to stop at the decision point. A simulation event is scheduled where the AGV has to start decelerating to stop at the decision point, based on the deceleration speed defined for the AGV. When this simulation event occurs a notification is sent to the controller with this context. The information specified in this event is the decision point and the AGV.In general, for the AGV_REACHING_DEC context, the controller stops the AGV by issuing a STOP_AGV command if required otherwise it issues a CONTINUE_MOVE command to the AGV.• d•If the stop mode is STOP_AT_EACH (stop at each decision point on the AGV's path), the AGV is forced to stop at the decision point.•If the stop mode is NON_STOP (stop only at the destination decision point), the AGV stops only if this decision point is the destination. Otherwise the AGV is allowed to continue moving on its current path.•If the mode is STOP_IF_REQUIRED (stop at decision points where some task is to be performed), the controller checks for any loading or unloading to be done at this decision point (by looking at AGV'spending command list). If any task needs to be done the AGV is stopped, otherwise it continues to move. AGV_AT_DECThis controller event context is generated when an AGV stops at a decision point.For the AGV_AT_DEC context the controller, in general, instructs the AGV to check for any pending tasks to be completed at the specified decision point by issuing a CHECK_PENDING_AGV command.The information attached to this event is the AGV and the decision point where the AGV has stopped.When an AGV is residing at a decision point, the current state on the AGV would show the decision point name in its current element field. Similarly, the current state on the decision point would show the name of the AGV in the residing AGV field.If the AGV passes through a decision point without stopping this controller event is not generated.CMD_COMPLETEDWhen an AGV stops at a decision point, in most cases, it already knows what kind of tasks (such as loading and unloading), need to be performed at that decision point. After a task is completed, the AGV can notify the controller with the CMD_COMPLETED context. This context informs the controller that the AGV has completed a task. It is generated from the AGV process logic.For this context, the controller instructs the AGV to check for any other pending commands that need to be done at this decision point, by issuing a CHECK_PENDING_AGV command.The information attached to this event is the decision point and the AGV.AGV_READY_TO_DEPARTWhen an AGV, at a decision point, has finished all its tasks, such as loading and unloading, it notifies the controller with the AGV_READY_TO_DEPART context. It is generated from the AGV process logic.For this context, the controller executes the AGV_DEPARTURE popup to decide whether the AGV can depart or not. The departure decision can be one of the three values of TRUE, FALSE, or WAIT_AGV.•If the AGV can depart, the controller checks whether the AGV has any other pending commands to be done at different decision points and selects the next destination by executing the AGV_DESTINATION popupfor the AGV. If the AGV has no pending commands, the controller tries to select a new task for the AGVby executing the CTLR_EVT_SELECTION popup and assigns it the AGV. If no task is selected thecontroller instructs the AGV to park by executing the AGV_PARKING popup. By default, the AGVParking popup instructs the AGV to park at the current location. Hence, the AGV will stay at the currentdecision point in IDLE state.•If the AGV cannot depart, the AGV stays at current location until any other part is routed to the decision point and the AGV is selected for it. After loading that part the AGV_DEPARTURE popup is executedagain.•If the AGV has to wait, the controller instructs the AGV to wait by issuing an AGV command WAIT_AGV. The AGV can wait for some known duration or until some user-specified condition occurs.After the AGV's wait is completed, another AGV_READY_TO_DEPART event is generated. Thus theAGV_DEPARTURE popup is executed repeatedly until the AGV can depart.The information attached to this event is the AGV and the decision point.When the AGV is waiting at the decision point for some departure requirement to be met, it is in theDEPART_REQMT_BLOCK state..AGV_LEAVING_DECWhen an AGV is ready to leave a decision point this event is generated with the AGV_LEAVING_DEC context. This controller event is generated only when the AGV is currently residing at a decision point and is about to start moving. The controller does nothing special for this context. This is added to provide some flexibility for you to do any housekeeping tasks when an AGV leaves a decision point.PENDING_PART_AT_DECThis context indicates that there is a part to be picked up at a decision point that has been pending with the controller. A part becomes pending to be picked up at a decision point, when the originally selected AGV for the task has become unavailable due to failure, or when the originally selected AGV had been re-routed to do some other task, or no suitable AGV was available when the corresponding PART_AT_DEC event occurred.This context is the same as the PART_AT_DEC context. The only difference between these two contexts is that, in case of a pending part, it already knows the destination decision point where it has to be unloaded, so the controller does not need to find a destination for the part. For this context the controller makes similar decisions as in PART_AT_DEC. The information attached to this event is the part and the decision point.AGV_UNAVAILABLEThis controller event occurs when an AGV fails or goes into a shift break. For this context the controller executes the AGV_FAILURE popup that may try to submit the pending LOAD commands of the AGV to the controller for some other AGV to take care of them. The information for the event is the AGV.AGV failures are not restricted to occur at decision points, they can happen any time when the AGV is moving, loading, or unloading. If the AGV fails at a decision point the notification to the controller goes through the decision point. If theAGV fails somewhere along a path segment, the notification goes directly to the controller . When an AGV fails, the current state of the AGV shows its state as unavailableAGV_AVAILABLEThis event occurs when an AGV is repaired after a failure or at the end of the shift break.. For this context the controller checks whether the AGV has some pending commands, or incomplete move commands, and lets the AGV complete them. If an AGV has no pending commands and is residing at a decision point, the controller tries to select a task from its pending Ctlr_events list by executing the CTLR_EVT_SELECTION popup and assigns it to the AGV.13.4 AGV CommandsThis section explains the different AGV command that are issued to the AGV. There is a set of pre-defined AGV command types issued from the controller and decision point logics. These pre-defined AGV commands are represented by constant values, which are specified in the ‘agv.inc’ include file. For each AGV command (AGV_cmd), the related additional information attached to the command and the actions taken by the AGV are explained below.MOVE_AGVThis command instructs the AGV to move to its destination decision point. The information attached to this command is the AGV path (AGV_path) through which the AGV has to move to reach the destination.AGV_path is the list of segments and the decision points on them through which the AGV moves. This AGV_path is a data type in SCL, which has several inquiry fields providing all the information related to the given path. For every new move the AGV is provided with a new AGV_path. The AGV path should not be confused with the AGV path system that is an element class that represents the whole layout.When the AGV receives this command it checks whether it already has a current AGV_path to some destination. If current AGV_path exists the AGV is asked to give up the current path and re-route itself with the new AGV_path. To take care of pending tasks to be performed in its current AGV_path the AGV_REROUTE popup is executed.If the AGV has no current AGV_path it starts moving by executing the START_AGV_MOVE ALONG SCL statement. With the default logics provided by the system re-routing is generally avoided. More information on re-routing and how it is avoided is explained under AGV_REROUTE popup. If re-routing is not desired in any user logic, care must be taken before issuing a MOVE_AGV command to the AGV.After executing the MOVE_AGV command, the AGV tries to claim the next or all decision points based on the claim mode of the current AGV_path. If claiming of the decision point(s) is not successful, the AGV cannot move and has to wait until claiming is successful.•When an AGV is moving, its current state (found using Run | Trace | Current State | Entity) will show the details of the current AGV_path under the heading current path. This section shows all the remainingsegments through which the AGV moves and the decision points through which it needs to pass through. Ifthe AGV is not moving the current path field will be none.•When the AGV is moving with no parts in it, its status would be BUSY EMPTY_TRAVEL.•When the AGV is moving with some parts in it, its status would be BUSY LOADED_TRAVEL.When the AGV is unable to move because of claim failure, its status CLAIM_BLOCKED.STOP_AGVThis command instructs the AGV to stop the current move. Upon receiving this command the AGV starts decelerating (stop is not immediate) by executing the STOP_AGV_MOVE SCL statement. There is no additional information attached to this command.When the AGV approaches a decision point a the AGV_REACHING_DEC controller event is generated. If the controller decides to stop the AGV at the decision point, it issues STOP_AGV command to the AGV.CONTINUE_MOVEThis command instructs the AGV to continue along its current AGV_path. The controller issues this command to make the AGV continue in its current AGV_path when the AGV is stopped at decision points, along a segment when failed, or after the specified stop is over.When this command is received the AGV executes the CONTINUE_AGV_MOVE SCL statement and starts moving. The additional information provided for the MOVE_AGV command is also true for the CONTINUE_MOVE command.NEXT_MOVEThis command instructs the AGV about a future move command. The information attached to this command is the decision point and the AGV_path to be used. When the AGV gets this command it first checks whether it currently has an AGV_path. If true the NEXT_MOVE command is added to the AGV's pending commands list. If the AGV is not moving when the command is received and the specified starting decision point (if any) is the same as where the AGV is located, the AGV will do the requested move immediately.If the AGV does not have a current AGV_path, it checks whether it is currently residing at the specified starting decision point. If true it starts the NEXT_MOVE, otherwise it starts moving towards the specified starting decision point.CHECK_PENDINGThis command instructs the AGV to check for any pending commands to be executed at the specified decision point and to complete them. The related information attached to this command is the decision point. If the AGV is not currently residing at the specified decision point it ignores this command. The AGV completes the tasks to be done at the decision point by executing the pending commands in the following order:•Unload commands•Load commands•Next Move commandsThe AGV first gets the unload commands to be completed at the decision point and executes them. After all the unloading is done, it checks for any loading and next move commands. When all the pending commands for the decision point are completed the AGV notifies the controller that it has completed all the tasks with an AGV_READY_TO_DEPART controller event.While the AGV executes the load and unload commands, there are options in the AGV_LOAD and AGV_UNLOAD popups that send a notification back to the controller after the completion of each or all load/unload task(s). In those cases, before completing all the pending commands at the decision point, the AGV notifies the controller with aCMD_COMPLETED controller event.When the controller gets the CMD_COMPLETED event, it asks the AGV to check for further pending commands to be finished with another CHECK_PENDING command. This cycle of AGV and controller communication after completion of each load or unload task continues until the AGV issues the AGV_READY_TO_DEPART event context to the controller.The current state on an AGV shows the pending commands that are to becompleted by the AGV.LOAD_AGVThis command instructs the AGV to load a particular part at the specified decision point. The information attached to the command is the part to be loaded and the decision point where the part is available.When the AGV receives this command it first checks if it is currently residing at the specified decision point. If the AGV is not at the specified decision point, the load command is added to the pending commands list. Otherwise, if the AGV is at the specified decision point, the AGV_LOAD popup is executed. The logic of the AGV_LOAD popup is to execute anyload process attached to AGV or the decision point and require the specified part. With the default options provided for the AGV_LOAD popup the controller can be notified about the completion of either each or all of the loading tasks.In the default AGV_LOAD popup options when a part is loaded into the AGV, and the part's destination decision point is known, the corresponding UNLOAD_AGV command is generated for the part and added to the pending command list of the AGV.While the AGV is doing the load process its state and is BUSY LOADING. Sometimes, if the part's current element has failed, the AGV will need to wait until the part is available to be transferred from its current element. For this duration the AGV's state is LOAD_BLOCK.UNL6OAD_AGVThis command instructs the AGV to unload a particular part at the specified decision point. The information attached to the command is the part to be unloaded and the decision point where the part is to be dropped.When the AGV receives this command it first checks whether it is currently residing at the specified decision point. If the AGV is not at the specified decision point, the unload command is added to the pending commands list. Otherwise, if the AGV is at the specified decision point, the AGV_UNLOAD popup is executed. The logic of the AGV_UNLOAD popup is to execute any unload process attached to AGV or the decision point and transfer the specified part to the element connected to the decision point. With the default options provided for the AGV_UNLOAD popup the controller can be notified after the completion of either each or all the unloading tasks.While the AGV is doing the unload process, its state is BUSY UNLOADING. Sometimes, if the connected element has failed or is under a shift break, the AGV will need to wait till the part is successfully transferred to the connected element. For this duration the AGV's state is UNLOAD_BLOCK.WAIT_AGVThis command instructs the AGV to wait at its current decision point. The duration of the waiting time is not specified in this command. There is no additional information attached to this command.Upon receiving this command the AGV executes the AGV_WAIT popup that makes the AGV wait for a specific duration or until some user-defined condition is satisfied. After the specified wait is over, the AGV informs the controller with the AGV_READY_TO_DEPART event.The controller may issue this WAIT_AGV command in the following situations:•When the AGV has completed all the tasks at a decision point it notifies the controller with an AGV_READY_TO_DEPART event. The controller then executes the AGV_DEPARTURE popup. Thereturn value of the AGV_DEPARTURE popup may be one of the following values:—True : AGV can depart.—False : AGV can't depart and has some departure requirement to be met at the decision point.—Wait_Agv : AGV can't depart and will wait for some duration or until some specific condition occurs.•When the controller gets a WAIT_AGV response from the AGV_DEPARTURE popup it issues the WAIT_AGV command to the AGV.•When the AGV is ready to depart from a decision point, the controller finds a new destination for the AGV by executing the AGV_DESTINATION popup. In general the AGV gets its destination from the parts it iscarrying or the pending commands it has to complete at other decision points. If the AGV is carrying partsand the parts have no destination set, then the AGV does not have a destination to move to. In that case thecontroller issues a WAIT_AGV command to the AGV.If you create logic to make the AGV wait at a decision point until some condition occurs, the user-specific logic has to be done in the AGV_DEPARTURE and AGV_WAIT popups that are attached to the local decision point. TheAGV_DEPARTURE popup checks for the wait condition and based on that it returns either true or wait_agv. The actual waiting of the AGV is done with the AGV_WAIT popup. When the AGV is made to wait with a WAIT_AGV command its state is not changed. When the AGV starts waiting for some departure requirement, the state isDEPART_REQMT_BLOCK. If no departure requirement is specified at the decision point and the AGV is made to wait, its state will be IDLE.13.5 AGV PopupsThis section describes the various popups available for use with the AGV or AGV controllers. For a general description on creating and using popups, refer to Chapter 17, Advanced SCL — Popups.AGV_PART_ROUTEThis popup is used to set a destination decision point for a part that has entered an AGV path system through a decision point. The return data type of this popup is an element handle that represents the destination decision point. The arguments that are sent to the external SCL routine for this popup are:•the_part — The part handle for which a destination is needed.•the_dec — The decision point where the part is available.This popup is executed under the following conditions:•When a new part tries to enter the AGV path system through a decision point with the controller's PART_AT_DEC controller event context.•Before the AGV departs, if there are any parts without a destination, then this popup is called to set their destination. The AGVs destination is found by executing the AGV_DESTINATION popup.•When an AGV is approaching a decision point, which is also the final destination of the AGV, in the controller's AGV_REACHING_DEC context the controller checks for any part carried by the AGV with nodestination and tries to assign a destination for the part. If the part gets the destination to be the same as theapproaching decision point, then the controller stops the AGV at the decision point.Two methods are provided through the user-interface to set the destination decision points for parts entering the path system. The first method is to specify fixed information, which specifies what part class should go to what decision point. The second method is through a set of decision points defined as a group. In general, a group represents a set of elements. When a group is created, a type is assigned to it. The types that are applicable to AGV_PART_ROUTE popup are: •AGV route cyclic•AGV route percent•AGV route priority•AGV route next freeAll the elements that belong to the above specified groups can only be of type AGV decision point. As these groups are created, two of them, AGV route percent and AGV route priority, have the additional information of specifying the percent and priority values for each decision point in the group.Default Options. The various available options are:•Fixed Part Route — This option uses information provided by you at individual decision points for fixed destination for different part classes. Using the Model | MHS | Dec Point | Part Destination button you canprovide the different destination decision points for different part classes or for any part class, which will beused to find the destination for the given part.•Cyclic Route Group — This option calls the AGV route cyclic group attached to the departure decision point and selects a destination decision point in a cyclic fashion from the set of decision points of the group.•Percent Route Group — This option calls the AGV route percent group attached to the departure decision point and selects a destination decision point based on the percentage values provided for each decisionpoint in the group.•Priority Route Group — This option calls the AGV route priority group attached to the departure decision point and selects a destination decision point based on the availability of the connected element from thehighest to the lowest priority values assigned to decision points of the group. The highest priority decisionpoint is found and the connected element's status is checked for accepting the specified part. If theavailability check is successful, the decision point is selected as the part's destination. Otherwise, the nextpriority decision point is checked.•Next Free Route Group — This option calls the AGV route next free group attached to the departure decision point and selects a destination decision point based on the availability of the connected element forthe given part. If the availability check is successful that decision point becomes the part's destination.Otherwise, the next decision point from the group is selected for availability check. If all the connectedelements of the decision points are not available no destination is assigned to the part.•Default Part Route — This is the default option, which looks at the departure decision point for any specified fixed information. If fixed destination information is available, it uses the fixed part route option.Otherwise, it looks for any AGV route group attached to the decision point and uses the correspondingoption to find a destination. Since multiple part route groups can be attached to a decision point, the firstAGV route group is used to set the part destination.•User Func — The user written logic that returns the destination decision point for the specified part.The coordination between assigning routing information at decision point level and the option selected for this popup needs to be understood. If fixed information is specified through the user-interface and the option selected for this popup is cyclic route group, the fixed information will not be used for part destination. The information specified through the user-interface is accessed by the appropriate options and used. Similarly, attaching a AGV route priority group to the decision point and assigning the cyclic route group option for this popup would also result in wrong behavior.Multiple types of routing information that are mutually exclusive can be set for experimentation purposes. The actual data used is decided by popup assignment. So if the AGV route cyclic option is selected, the fixed data will not be considered even if set. In such a case, if no AGV route cyclic is attached to decision point, an error will occur.NOTE: It is not necessary for a part to have a destination before it gets loaded into an AGV. Before leaving a decision point the controller checks the parts of the AGV with no destination assignedand tries to assign a destination. Similarly when the AGV is reaching a decision point if the partshave no destination or the approaching decision point is the finaldestination, and that decision point has no output connection to outside elements the controllertries to find a destination using this popup. Therefore the destination of a part may be decidedsomewhere along the path and not necessarily at the loading decision point.Order of Hierarchy. The hierarchy in which this popup is searched, as specified in the default logics, is decision point and controller. If the popup is attached to the decision point, it is obtained and executed. If the popup is not attached to a decision point, the controller level popup is executed.The SCL file with the default code to implement this popup is: ../QUESTlib/SYSDEF/LOGICS/wgt_r out.scl.src.AGV_SELECTIONThis popup is used to select an AGV to pick up a part or to do a process. The return type for this popup is an element that represents the selected AGV. The arguments to the SCL routine of this popup are:•the_part —the part to be picked up. In case of an AGV that is requested for a process requirement, this handle (the_part) would be NULL.•the_dec —the decision point where the part is available, or the decision point where the AGV is needed fora process.。