Overview The Resource Group is a command center for a group of Gantry Cranes and/or Top Loaders. When multiple yard resources operate on the same block or area, the Resource Group is used to assign tasks to the resources. The yard resources can still function without the Resource Group, but using it helps to distribute tasks more evenly and prevents RTGs from crossing over each other, so it is more realistic. Note: To use the Resource Group, you must assign it in the [Resource Assignments tab](Resource_Assignments.html) of the Yard Planner by assigning the block's or area's resource to be the Resource Group. Note: To associate a RTG/Top Loader with a Resource Group, make an "A" connection from the Resource Group to the RTG/Top Loader. Also, the order in which you connect the Resource Group to its member resources has an effect on the way that the Resource Group's dispatch strategy assigns tasks to those resources. The resource connected to output port 1 of the Resource Group will be seen as the first resource of that group. If the assignment strategy is to assign lower logical bay numbers to the "lower numbered" resources (which the default pick list options do), you should connect resources such that they are initially in the appropriate areas. The Resource Group object is assigned an area, defined in the Yard Planner's Areas tab, to which it will distribute its assigned resources evenly. The object creates a mapping from the different blocks in the area to a linear range of logical bay numbers. For example, Resource Group A is assigned to Area1, which consists of Block1 and Block2. Block1 contains 50 bays, while Block2 has 30 bays. The Resource Group creates a mapping where its logical bays 1-50 are associated with Block1's bays 1-50, and its logical bays 51-80 are associated with Block2's bays 1-30. Once this mapping is created, all assignments made through the Resource Group are made according to this new logical bay ordering. For example, if the Resource Group receives a task to stack a container at Block2, bay 10, it will make an association for that task to its logical bay 60, and all subsequent dispatching logic is made based on bay 60. The Resource Group can also manage, if needed, a range of logical bays for each of the resources assigned to the Resource Group. So a dispatching strategy can assign one RTG to logical bays 1-40, and another RTG to bays 41-80, and then dispatch tasks to the RTG whose range encompasses the task's logical bay. Note: The Resource Group should only be used for pooling resources in a side-loaded operation. The Resource Group is hard-coded to tell trucks to travel along the block to the bay location of the container, and are not implemented to work with transfer areas. Dispatching for end-loaded blocks with multiple RMGs managing the block should be done using some other mechanism. Properties  Resource Group Area - This is the assigned area that the Resource Group uses to create the logical bay mapping, as described above. Note: All tasks dispatched to the Resource Group should be within this Area, or else the Resource will not be able to create a proper logical bay association for the task. Dispatch Strategy- This pick list defines how the Resource Group should dispatch tasks to its individual resources. The function is fired at several points in the decision making process. The trigger variable will be one of the following values: - RG\_DISPATCH\_ON\_RESET - fired when the model is reset. This may be used to reset the resource ranges to initial values. - RG\_DISPATCH\_ON\_TRUCK\_ARRIVAL - fired when a truck arrives at a block to stack/unstack a container. Additional access variables for this trigger are: - parval(2) - yardop - this will be one of two values: It will be YARD\_OP\_STACKING if the truck has arrived to stack a container or YARD\_OP\_UNSTACKING if the truck has arrived to unstack a container. - parval(3) - id - the id of the container to stack/unstack. - parnode(4) - a reference to the arriving truck. - parnode(5) - a reference to the block. - parnode(6) - a reference to the container object. - You may also use getresourcegroupstat(current, RG\_STAT\_TASK...) to get more information on the task, such as the logical bay associated with that task. The return value for this trigger should be: - Greater than 0 : the resource number (or output port number) to assign the truck to. The truck will be assigned to the designated resource regardless of whether the resource is available, and you cannot change the decision later on. - 0 : the Resource Group will search its group of resources, and if it finds an available resource, it will send the task immediately to that resource. Otherwise, it will queue the task. - -1 : the Resource Group will queue the task聽without looking for an available resource. - RG\_DISPATCH\_ON\_RESOURCE\_AVAILABLE - fired when a resource finishes a task and requests the Resource Group for another task. Additional access variables for this trigger are: - parval(2) - the output port, or resource number, of the available resource. - parnode(3) - a direct reference to the resource object. The return value for this trigger should be: - Greater than 0 : the task number to assign to the resource. This is the rank of the task, as retrieved using various stats from the getresourcegroupstat() command. - 0 : the Resource Group will assign the task 1 to the resource if the task exists. - -1 : the Resource Group will not assign any tasks to the resource. - RG\_DISPATCH\_ON\_CUSTOM\_ACTION - fired when the user calls a custom action using the resourcegroupop(current, RG\_OP\_CUSTOM\_ACTION,...)command. This allows the strategy to execute code at defined times that are not necessarily associated with a truck arrival or resource availability. Any given dispatch strategy will make significant use of the getresourcegroupstat() and resourcegroupop() commands, so you should also refer to the documentation on those commands to understand how a Resource Group's dispatching strategy works.