To implement cranes in ProModel, the Path Network module allows three types of networks: non-passing, passing, and cranes. From this module, you can lay down and orient a crane envelope, define the bridge separation distance, and define the graphics for rails and bridges in the bay. Additionally, the Resources module allows you to define bridge and hoist speeds, and hoist graphics for one or more cranes operating in the same bay.
Modeling multiple cranes operating in the same bay has never been so easy!
User defined bridge separation distances, extensions to regular dynamic resource usage statements, and a set of new priority rules have been introduced in order to let you manage conflicting movements in the same envelope zone.
Crane Envelope The parallelogram-shaped area represented by a crane type path network, bounded by two rails and the lines connecting the endpoints of those rails. The lines connecting the endpoints of rails are effectively the two extreme positions of the center-lines of any bridges operating within the envelope. ProModel uses the end of one of the rails as the envelope origin to serve as a reference point for all logical distance calculations within the envelope.
Bridge Separation The minimum distance you want to maintain between center-lines of two neighboring bridges. This distance is not related to how close a bridge center-line can get to one of the extreme endpoints of the envelope. Caution: if bridge B tries to move to a node N that lies very close to the left end of the envelope, and bridge A is to the left of bridge B, a run-time error will occur if the space remaining between node N and bridge A is less than the bridge separation distance. To avoid such problems, define the crane envelope wide enough to allow sufficient space beyond any serviceable nodes.
ProModel associates two types of priorities with the operation of crane resources: (1) resource request priority, and (2) crane move priority.
Resource Request Priorities Used to resolve any conflicts that arise between multiple tasks requesting the same resource at the same time. This priority scale follows the rules that regular dynamic resource priorities do (i.e., 10 levels of 100). Use this priority to preempt crane resources from lower priority tasks to serve higher priority tasks.
Crane Move Priorities Used for multiple bridges operating in the same envelope, to decide which crane bridge has priority over another while moving. This priority scale is also in the range [0...999], but does not have any preemption levels. Any higher value has overriding priority over a lower value. You can assign priorities to crane resources temporarily, on a task-by-task basis via extra parameters in the GET, JOINTLY GET, USE, and MOVE WITH statements. Therefore, you can only use priorities for cranes that are either moving to respond to a resource request or moving to deliver a part. Moving to downtime, off-shift or break nodes has the default (0) move priority. Moving to park has the lowest move priority (the same as an idle crane).
You can further sub-divide crane move priorities into three categories:
The operation of cranes in ProModel has been designed to closely resemble the real-life operation of cranes. Under most circumstances, you need not be concerned with how ProModel handles crane movements. The following operational specifications are intended as a reference only and are not essential in order to model cranes using ProModel.
During a simulation run, entities picked up by a crane appear graphically on the entity spot for the hoist. The hoist graphic appears above the entity graphic and the bridge of the crane appears on top of the entity and hoist graphics.
When you define cranes for your model, consider the following:
If a crane is in one of the following states, it will be referred to as “immovable at a node.” No other crane will be able to push this crane away, regardless of its priority.
Extended Movement Zone The net zone that it needs to traverse ± bridge separation distance (± depending on the direction that it will go).
Before starting to move, any <crane A> attempts to claim its extended movement zone (zone A) for the entire movement duration.
ProModel can reject the claim attempt of crane A for zone A for several reasons:
The following cases illustrate specific situations with examples:
Bridge B starts moving first, from [B] to [B'] and claims the zone [B'~B] in the ¨ direction. Bridge A wants to move from [A] to [A'] in the opposite direction. If the move priority of A is less than or equal to the move priority of B, we let bridge A start moving towards [B' - bridge separation] only. If A has a higher move priority, B is stopped immediately and sent back to [A' + bridge separation]. In the latter case, A may queue up behind B.
Bridge B starts moving first, from [B] to [B'], then bridge A wants to move from [A] to [A']. Bridge B claims zone [B~B'] in the Æ direction. Since bridge A wants to move in the same direction and their destinations do not conflict (assuming that B'-A' is greater than the bridge separation), bridge A moves all the way. If B has already cleared the zone [A~(A' + bridge separation)] by the time A wants to start moving, A moves independently. Otherwise, A may queue up behind B. (If the distance B'-A' is less than the given bridge separation and the move priority of A is greater than the move priority of B, bridge A will push away bridge B, and crane B will not respond to the request while passing over [B']).
Bridge B starts moving first, from [B] to [B'], then bridge A wants to move from [A] to [A']. Bridge B claims the zone [B~B'] in the Æ direction. Since bridge A wants to move in the same direction and their destinations do conflict, priorities will be considered. If the move priority of A is not greater3 than the move priority of B, bridge A starts moving towards [A'' = B' - bridge separation] only. Otherwise, A will push B away, and B will not respond to the request while passing over [B']. In both cases, A may queue up behind B.
Bridge B starts moving first from [B] to [B'], claiming zone [B~B'] in the Æ direction. Bridge A wants to move from A to A' and starts moving behind B. Bridge C wants to move in the opposite direction with a higher move priority than both of the other bridges. ProModel interrupts bridges A and B and lays a new course for both bridge B [B'' = C' - bridge separation] and bridge A [A'' = B'' - bridge separation]. In this case, B may queue up behind A, and C behind B.
This is an extension of Case 4. Assume that the move priorities for crane bridges A, B, and C are 3, 1, and 2 respectively. When bridge C tries to claim zone [C'~C] in the ¨ direction, it faces an “effective priority” of 3 and is unsuccessful in its original claim, so it starts moving towards [B' + bridge separation]. Bridge B goes outside the effect of bridge A in the second part of its movement, [(A' + bridge separation) ~ B'] at time t0. However, bridge C does not override bridge B and start moving towards [A' + 2 * bridge separation] until the first “reclaim trigger event4” after time t0.
If ProModel rejects the original claim of crane A, crane A claims the largest available portion of the original zone, and implements the procedure described below to move its bridge through the subset zone. The crane waits until a “reclaim trigger event” occurs, and then repeats the claim attempt to let its bridge traverse the remaining distance. The hoist, on the other hand, moves directly to its relative destination on the bridge, independent of the bridge zone claim results. In case of bridge interruption, the hoist does not stop moving. Therefore, for any particular crane move, the combined trajectory of hoist and bridge may change depending on zone availability at the time of the claim.
If crane A accepts the claim attempt, all cranes inside the claimed extended zone bump away at the time of the claim. This claim also prevents any other cranes with move priority less than or equal to the move priority of A from entering the claimed zone in conflicting directions.
Zone Claim Notes: A crane cannot do a pickup or deposit while another crane pushes it away, even though the request might be on its way. When you interrupt a crane bridge and ask it to make a new claim (or update its claim), its speed is reset to zero and ProModel re-evaluates its mobility characteristics. ProModel recalculates the move time with these new parameters. This rule also applies to bridges that are moving when a bridge behind them with a higher priority and a conflicting destination makes a new claim to go in the same direction. See Case 3 (when priority of A is greater than priority of B) for an example.
For all bridge claims with the potential of having two bridges queue up after one another (mentioned in the example cases above), the following rule applies:
The acceleration rate (a), maximum speed (s) and deceleration rate (d) of the following bridge (F) are compared with the a, s, and d of the leading bridge (L). If all of the following conditions are true, bridge F moves independent of bridge L.
If any one of the above conditions fail, bridge F moves at the same speed as bridge L, maintaining the distance that existed between them at the time F started moving.
Please Note: Condition 3 usually creates a deviation from the typical real life situation, but it is necessary to avoid time consuming computations that can adversely affect the run-time performance of models with crane resources. To avoid unrealistic queue-ups when modeling multiple bridges with different mobility characteristics in the same crane envelope, make either no bridge deceleration entry (infinite deceleration), or use the same overall average deceleration rate for all crane bridges in that envelope.
If bridge A is queued up behind bridge B, bridge A goes through up to two stages of movement. The first stage occurs throughout the movement of bridge B. Bridge A mimics bridge B’s motion, maintaining its original distance from bridge B.
The second stage occurs after bridge B stops. Bridge A continues traveling with the former average speed of bridge B until it reaches its destination.
If bridge B is moving to accomplish its own task (as opposed to just moving out of A’s zone), then bridge A might stop earlier, without going through the second stage. In this case, the total traveling time for bridge A is calculated as if bridge A were traveling with bridge B’s average speed.
When a bridge arrives at its destination, it triggers a chain queue-up re-evaluation that penetrates the crane envelope in the opposite direction that the stopped bridge was moving. This chain re-evaluation handles cases in which there were multiple bridges queued up behind the stopped bridge.
A crane can be idle and moving at the same time (moving to park or being pushed away by another). Independent of its current position and movement direction, the crane still has the capability to respond to resource requests coming from anywhere in the envelope. If allocated to a task with high enough travel-to-pickup move priority, the crane may reverse direction or terminate its move early, bumping other crane bridges on its way.
Whenever a crane bridge changes its claim, it checks to see if there are any bridges behind it that are going in the same direction with overlapping claims. If there are any, the newly claiming crane triggers a chain queue-up re-evaluation towards the following cranes. The following example demonstrates this case.
At time t0, crane A is called for a task and starts moving to [A'] with move priority mpA, pushing idle bridge B to [B' = A' + bridge separation]. At time t1 (bridge A and B are still moving), a request for crane B comes from [B" (1 or 2)] with move priority mpB. Bridge B is allocated to the task immediately since it is available at the time.
If the new destination of bridge B is [B"1], the new claim of bridge B does not conflict with the existing claim of bridge A, so the move priorities are not significant. ProModel re-evaluates all motion values for crane B (acceleration, deceleration, empty and full speeds for both the hoist and the bridge) and crane B starts moving to its new destination. If the bridge motion expressions for crane B have changed their values between t0 and t1, the queue-up status between bridges B and A (and any others behind A) may change, so ProModel performs a chain queue-up re-evaluation.
If the new destination of bridge B is [B"2], the new claim of bridge B conflicts with the existing claim of bridge A, so ProModel considers the move priorities:
Unsuccessful claims of all crane bridges in an envelope are re-attempted when a reclaim trigger event occurs in that envelope. The following events are considered to be triggers for claim re-evaluations in the related envelope:
In the first six cases, a crane changes state from “immovable” to a finite move priority. The seventh case may change the “effective move priorities” of other cranes. ProModel requires the eighth case for envelopes with three or more bridges with overlapping operation zones: It ensures that two or more unsatisfied, opposing claims with the same move priority will resolve their conflict based on earlier task assignment time instead of locking up the crane system. Hence, all of the above cases create a potential to realize previously unsuccessful claims.
The reclaim trigger events for each envelope echo in the trace together with the triggering reason for model debugging purposes. The results of reclaim attempts for each crane resource and its effects on other crane resources in the same envelope are also displayed.
- Picking up or depositing an entity.
- Being used at a location.
- Experiencing a downtime, off-shift time, or break time.
ProModel allows definition of resource points for crane resources on envelope nodes to achieve the three dimensional look for “lowering the hoist” upon arriving at a node. Since cranes can only have one unit, only the first resource point for any crane at any node is meaningful. Also, ProModel only uses the resource points if the crane resource arrives at the node to perform a task. In other words, the hoist does not lower if the crane arrives at a node to park or just ends up there after a bump.
In general, once ProModel makes a match between a resource request and a resource of the requested type, the resource is allocated for that job and the simulation engine does not go on looking for other matches that can actually reach to the requester sooner. Since cranes blocking other crane resources is a common phenomenon in multi-bridge envelopes, extra care should be used while designing the active operation zones and resource request logic in such models.
ProModel “registers” all cranes to their home nodes at the beginning of a simulation run. When a crane starts to move, ProModel erases registration, and re-establishes it when the crane stops, according to the following rules:
Please Note: Only users can instruct cranes to park on nodes. However, as a result of bump-aways, a crane can end up standing still at positions that do not necessarily correspond to nodes. In any case, ProModel registers an idle stationary crane to a node and places it under the control of work and park searches of that node.
Cranes follow the same rules as regular dynamic resources while searching for assignments (returning to preempted jobs, exclusive & non-exclusive work searches, requests coming from nodes not included in the work search, etc.). There are some additional steps to handle interactions with other cranes operating in the same envelope. Upon completion of its task, a crane goes through these extra steps:
Please Note: A crane bridge moving to park cannot bump other idle bridges out of its way. In such a case, the bridge goes as far as it can towards its destination and registers itself to the closest node upon stopping (using the rules discussed above).
The statistics reported for cranes are very similar to regular dynamic resource statistics. The following definitions highlight the differences in the interpretations.
In Use Includes the following states:
Travel To Use Is the gross move time to start being used — traveling to respond to a request for either stationary use or use to pickup and deliver an entity to another location.
Gross Move Time May include the following times:
Blocked Time Tally blocked time by subtracting the internally computed, hypothetical net traveling time from the actual incurred gross move time. ProModel defines the net time as the time a crane would have taken to get to its destination if it were the only bridge in its envelope.
Please Note: The first component of gross travel time (moving towards the actual destination) may be greater than the net travel time, since it may include going back towards the destination after another crane bumps it away. It may also involve deviations from the bridge’s original motion values when queued-up behind slower bridges.
Remember that an idle crane registers itself to the closest node whenever its bridge stops. If the hoist is still moving, ProModel uses the destination of the hoist to break any ties between nodes that are equidistant to the bridge position.
In case of an unsuccessful claim attempt to move to park, the crane bridge needs to stop before reaching the instructed park node, and ProModel ignores the hoist travel for statistics purposes. The “travel to park” statistic terminates at the time the bridge stops, not when bridge or hoist stop time reaches its maximum value. In this case, the net moving time to park computes as the bridge move time from current position to the endpoint of the claim, using original bridge motion values for the crane resource. Blocked time can accrue if this bridge queues up after a slower bridge that is already moving (remember that a crane moving to park cannot bump another crane).
|
© 2012 ProModel Corporation • 556 East Technology Avenue • Orem, UT 84097 • Support: 888-776-6633 • www.promodel.com |