Search the Community

You can create a customized server, where you can store the entities in the processing station, with processing time as zero and at the output node of the server make the ride on capacity as true. Also in add on process trigger for transport request you can choose the waiting for vehicle by stacking number. Stacking_RideRequest.spfx

********************* FOR VERSION 191 AND LATER ******************************* In Sprint 191, a change was made to the Seize step's On Seized Process and the Release step's On Released Process which impacted the Token Associated and Context Objects. This change effects the logic in VehicleX. For use in Simio versions 190 and earlier, please use the files at the top of this thread. Attached is an updated VehicleX (now VehicleX3) for use in Simio 191 and later, as well as the updated examples using VehicleX3. VehicleX3 now will reject an Entity's Transport Request if an operator is not available for that vehicle. This prevents entities from seizing and waiting for an unmanned vehicle. *************************************************************************************** VehicleX3.spfx VehicleWithDriver_VehicleX3_Examples.spfx

Within each of the Source objects, you would specify (within the output node of the Source) that a worker is required to transport the entity(s) to the next node. The decision making of the worker is then handled by the worker itself. The worker has several decision making options - first of all, for transporting, the worker has Transport Logic properties, one of which is the Task Selection Strategy property, which can be set to First In Queue, Largest/Smallest Distance or Largest/Smallest Priority. In addition to that, under the Worker's Add-On Process Triggers properties, you have the Evaluating Transport Request process that can be used to accept or reject any transport request. You can add custom logic, a distribution, etc. within a Decide step in that called process and simply then accept (Token.ReturnValue == True) or reject (Token.ReturnValue == False) a request (which is the first in the allocation queue, as ranked as noted above). You can use the requesting entity location within the decision logic as well.

you can do that on the worker's On evaluating transport request addon, use process logic to check those conditions, can you attach a model that we can look at.

Here are my issues broken down: 1. After dropping passengers off, busses usually travel one more segment without any passengers. This should only happen if the station they dropped off at has zero passengers in queue. How do I make sure the bus does not travel empty unless there is no one to pick up? 2. The middle station has two types of passengers, but a bus coming in to the middle should only pick up one type. If the bus is empty, it should pick up the passenger type with the highest in system. If the bus dropped some passengers off, but has more bound for stations A or C, the bus should only allow passengers bound for that station to board. I don't know Add-On Process Triggers very well. I tried finding some information to use Evaluating Transport Request, but no luck so far figuring it out. I've also tried using state variables to fix my 2nd issue, but I'm missing something.

Hi oma110, If I understand your problem correctly, I think your issue here is with your entities' Initial Priorities and the Vehicle's Task Selection Strategy. If you do the two following things I think it should do what you want: 1) Set the LowPriority entity's Initial Priority to 2 (in the Routing Logic) 2) Set Vehicle1's Task Selection Strategy to "Smallest Priority" The problem with your current model is that since Vehicle1's Task selection strategy was set to First in Queue, it will do the first 30 entities that were created in Location 1 and then pick whichever entity came first in the transport request queue. Hope it helped!

Hi, I am trying to model this situation: One vehicle picks up entities "On Demand" from two locations (TransferNodes) and send them to Sink1. Entities with high priority arrives at TransferNode1, while entities with low priority arrives at TransferNode2. When I choose the Ranking Rule to be Smallest Value First and the Ranking Expression is ModelEntity.Priority in the Resource Logic of the Vehicle, the Vehicle picks up entities probabilistically from the locations. How can I make the Vehicle picks up the entities with the highest priority first and once it is started picking at one location (say TransferNode1), I want it to keep picking up the entities from that location until the RidePickupQueue of that location is empty. Then the vehicle can move to the next location, finish it up, and so on. I think I need to add a logic on the Evaluating Transport Request Add-On Process Trigger on the Vehicle but I do not know how. Any help is appreciated. Thanks, Omar

Here's a follow-on question I can't quite figure out ... I have a worker who is required as a resource to setup and teardown two different workstations. The worker is also a transporter to move entities from the source to the workstation, and from the workstation to the sink. The workstations are set to seize the worker for All But Specific, Processing, Move to Node, Input@Workstation#. The workstations have identical setup, processing, and teardown times (fixed at 5, 30, and 5 seconds respectively). The source initially starts with 2 entities, and then creates additional entities each time one of the workstations begins its Setting Up process. Once both workstations are processing, the worker goes back and gets the next two entities to place one into each workstation's input buffer. No matter what I attempt, I cannot make the worker stay at the workstation to complete the next entity's setup before taking the previous entity to the sink. Each time the worker takes the completed part to the sink and then returns to setup the workstation. Even though they happen at the same time, it appears that the previous entity enters the outbound node of the workstation and then makes a visit request to the worker, all before the next entity initiates the Setting Up process and attempts to seize the worker. To be more precise, the outbound part is placed on the outbound node, triggers the RiderWaiting event, requests and has accepted a transport request from the worker before the Teardown process has actually ended. I've read through multiple SimBits and other files from the forums. I can't get the next entity or workstation to seize the worker since the visit request has already been accepted or the workstation still has the worker seized to complete the teardown. I can't figure out how to use the Worker Used For Multiple Tasks SimBit since it only shows the worker going to and waiting at a node, and I need to model a workstation at this location instead of a node. I can't force a Delay math.epsilon on an Evaluating Seize/Transport process to force it to the end of the "same time", and putting in conditions (to reject transport requests if the allocation queue is not empty) appears to be moot since the Worker.AllocationQueue is technically empty when the RideVisitRequest is made (the next entity hasn't made the request yet). I also read in one of the posts that there is no way to reneg a ride/visit request once it is made, although seize requests can still be manipulated. I've attached an example file. It's definitely a work in process, so some of the custom processes aren't used or have been manipulated. I need to be able to model a real world process ... the worker would take out the previous part (teardown), set it down on a table (the output buffer), pick up the next part (from the input buffer), place it in the machine (setting up), and then press Cycle. Once complete, the previous part would be transported to the sink, and the worker would move to the next machine waiting. Thanks! Worker Seize vs Transport Test.spfx

I believe that the behavior you are asking for is the default behavior for an on-demand vehicle. It will accept reservations only for entities moving from the same location to the same destination. But regardless, you can add some process logic to the Evaluating Transport Request add-on process to only allow the pickups that you desire (e.g. if it's empty take any entity, if its not empty only accept entities that have the same destination as the first entity).

Just take a look somehere in help or documentation about Evaluating Transport Request, if token used in this process (so you have to search for tokens as well) is assigned value 0 or less, the entity trying to reserve transport on this vehicle is rejected and have to wait for another try. This is just a simple model, for production use (models with multiple locks) it make a good sense to use object approach as David showed in Elevator Simbit. That way you would be able to have logic in one place.

I would think about the lock as like it is a vehicle. Basically lock is nothing but an elevator. Use two nodes (one for top level of lock and one for bottom). Then use vehicle to transfer entities from one node to another. You can use Evaluating transport request add-on process to check if your ship that is about to enter the lock (be picked up by vehicle) is not bigger than remaining capacity of lock. There is a simbit dealing with this, I bet. For this you would probably need to subclass vehicle definition and add some state to vehicle and update it each time you load or unload a ship into the lock.

Hi Martin, I think this isn't possible because of the routing of the vehicles: I don't want that the containers reserve a Vehicle object (reserve best/closest), but I want that custom made vehicles pick up containers (batching) based on the properties of the vehicles which are ready for transport). Because the containers don't ride on a transporter the containers must be batched to the custom made vehicle. So I don't know what you mean exactly with the evaluating transport request. How does this work? Can you only use it for a transporter? Kind regards, Marloes

One approach that comes to mind would be a custom vehicle serving as transporter instead of the batching approach. Then utilize the evaluating transport request to check if TEU capacity on the vehicle is available or not. Sincerely, Martin

If the vehicle Routing Type is On Demand, then it works by reservation only. Reservations are made based on the node's Reservation Method and Selection Goal. In general each vehicle can only accept a single reservation at a time, with the exception that it will accept up to (Vehicle Capacity) reservations all originating at the same node and with destinations at the same node. You can customize the above behavior customizing the Evaluating Transport Request Add-on Process as illustrated in the attached Librarian model.Workshop08c-Librarian.spfx Another choice which may better address your problem is to make your vehicle Routing Type be Fixed Path. With this, the vehicle will cycle through any nodes you want and pick up as many at each node as possible. You can see an example of this in the VehicleFixedRoute SimBit.

Hi Glen, I feel your pain...hahaha....and please whatever you do stay away from Math.Epsilon for this... Lets have a look at this based on the impact that this problem will have on a Tanker object (Transportation Requests) for I think the ultimate generic solution for all FlowContainer elements should be based on this logic... 1. There can always be a positive or negative residual around a specified level (0.0001 + 16000 MT - 0.0001) in a tank (cap of 25 000 MT)... 2. If there is a positive residual, there will be an entity in the output regulator's flow request queue...Thus an erroneous transport request will be logged.... 3. If there is a negative residual, there will be no entity in the output regulator's flow request queue...Thus transporter will be stuck as it would not have reached its load level of say 16 000 MT.... Based on these assumptions we have discarded the problem with the residual in the tank, which kinda really can be disregarded...and redirected the problem to the Flow regulators where the actual residual problem becomes more evident... What I typically do is set the variables on the monitors watching the transfer, to the specified level WITH plus or minus 0.0000000001 depending on the transfer performed. The monitor will thus trigger the end transfer process just before the specified level, and then I simply adjust variables back up by means of rounding up to a higher decimal. (0.0000001 instead of 0.0000000001 ) ALTHOUGH, you HAVE to clear your regulators' flow request queue before and after ANY transfer if you use the above option. This brings another catch 22 for each time you do this, a new entity instance is created. To be quite honest, I would program in hard code a function that executes after every transfer to round the value up to a higher decimal. i.e. perform the transfer in the code with the monitor to a level of variable - 0.00000001 (HARD CODE) and then have a function call after transfer to cut some decimals and round up back to the specified level which is at a higher order i.e. 0.000001. Truly think the solution to this conundrum lies close to this logic and its difficult to explain the on the blog...Perhaps we can set up a skype conference call and I can demonstrate as well as enlighten you to ALL potential pitfalls and workarounds we have discovered pertaining to these transfers...

Thank you very much Glenn. I did what you said. However, when the 'Evaluating Transport Request' add-on process trigger reject a rider, how I can assign the current vehicle to continue the task? Im my model, the rider is being rejected and the current vehicle is freezed. One more doubt. In the 'Unloaded' add-on process trigger I only need that the vehicle continue the task until the next machine and not until the whole sequence be completed. How can I evaluate that? My model is attached. Thanks a lot! Breno. FMS v0.0.1.0.spfx

Breno: Go to the 'Add-On Process Triggers' property category of the Vehicle object. Perhaps use the 'Loaded' add-on process trigger to execute a process that assigns an entity state variable reference variable equal to the entity just loaded (e.g., Assign: CurrentEntityReservingVehicle1=Entity). Perhaps use the 'Unloaded' add-on process trigger to execute a process that clears the entity state variable reference if the vehicle has unloaded the entity into the last destination in its sequence (e.g., Decide: Entity.Sequence.CurrentJobStep==Entity.Sequence.NumberJobSteps...if True then Assign: CurrentEntityReservingVehicle1=Nothing). Perhaps use the 'Evaluating Transport Request' add-on process trigger to execute a decision process that only allows the vehicle to pickup a new rider unless the rider is its reserving entity or there is no reserving entity (e.g., Assign: Token.ReturnValue = CurrentEntityReservingVehicle1==Nothing || CurrentEntityReservingVehicle1==Entity)

Possible approach is to: 1) Define an entity reference state variable storing a pointer to a reserved entity for a vehicle. 2) For the 'Evaluating Transport Request' add-on process of the vehicle, only accept a transport request if the entity reference state variable is 'Nothing' or is the currently active entity assigned to the vehicle. Thus, the vehicle can only pickup that assigned entity until that reference variable is cleared. 3) When you pick up a new entity, assign the vehicle's entity reference pointer to that entity. 4) When you drop of an entity at the last destination in its sequence, clear the vehicle's entity reference pointer.

lhu123, Your model is working -- transport requests are rejected. However, pickup requests (at the node itself) are not, so the vehicle picks entities up. This is because you have not modified the vehicles 'OnEvaluatingRiderAtPickup' process. The standard library vehicle calls the 'Evaluating Transport Request' add on from both the OnEvaluatingTransportRequest and OnEvaluatingRiderAtPickup processes. To bring this logic into the vehicle, you will need to subclass both processes.