Rack Pick in a custom flowchart with a dynamic event - anylogic

I would like to use my custom flowchart for different process flows and my target is to pick my pallets from the racks to the certain times from my dbase. So with a delay block it doesn't work so I replaced it by a wait block where I will release the pallets which should get picked by the time of my dbase. The function doesn't work and I'm not sure if it is the right way to solve my problem. I would like to release the number of pallets (n) to the picktime of my dbase.
Thank you for your help!

Your DE looks good but you are calling it from a wrong location, that is what the error is telling you. Make sure you access that location first before calling create_DE....
(depends on where you call it from and where it lives, see https://help.anylogic.com/index.jsp?topic=%2Fcom.anylogic.help%2Fhtml%2Fcode%2FAccess.html&resultof=%22%77%68%65%72%65%22%20%22%61%6d%22%20%22%69%22%20

Related

Limit the number of Pedestrian in service 'queue'?

I have a simple model which has two Pedestrian Service blocks after one another. Is there a way to limit the queue for a service so it has a 'knock-back effect' on the queue/path area before?
I assume you can add a wait block before every ped-service that frees an agent if the ped-service queue is below a certain length. But, that seems a little messy (maybe a limitation of the pedestrian library) - would be keen to hear what best practices are from the experts (cough Ben & Felipe) :)
You can add a simple wait or queue block before the service block and only let them exit the queue if the pedestrians in the service blocks are below a threshold.
You need to implement the release logic in the on enter for the queue
as well as for the exit at the service block
But, in order to make your snake path act as a queue you will need to add walls around it, else as per your example the pedestrians will group around the end of the path in a bunch. You will also need to set your pedestrain width to just more than half your path width to ensure they don't bunch inside the path

Is possible to induce a maintenance or break with java code?

How can I send all resource units from a resource pool to maintenance or break whenever another event in another block occurs?
I'm looking for something like: resourcePool.startMainteinance()
and write it inside a "On start" box in some other block of the flowchart. Of course then I would need to end the maintenance with something like resourcePool.stopMainteinance() and resume all the tasks the resource units were executing.
Any idea? or some idea to pause manually all resources from executing their task and then resume them?
Note: suspending the agent that seized in the size block with the code SizeBlock.suspend() and SizeBlock.resume() is not an option because the resources have preparation tasks and those tasks also need to be paused.
Thank you!
You should use the Downtime block that is designed for this setup.
You can control it any way you like. In your case, myDowntimeblock.startTask(someAgent) and stopTask(sameAgent) work.
Also check the example model named "Maintenance of a Coffee machine": It shows all the other ways of using the block.

Sequence of blocks

I have an agent which needs to seize two different equipment units, one excavator, and one truck. It seizes excavator first, release it and then it seizes truck. I added some functions to the release excavator block but interestingly the agent goes to seize truck block without going to release excavator block! so thus functions do not work. How this is possible?
Please see the attached file. How can I solve this? Thank you.
That's weird. Have you tried adding any other block in between seize and release exc? In some cases it happens that some code isn't executed (i.e. in the options on a selectOutput) because you defined the conditions in the block inmediately before that. But in your case the counters remain in 0 and the next ones have the same value as the previous ones (you're sure the blocks are properly connected, right? they seem to be connected at first sight).

Usage of timeInState function in Anylogic

So for my project in area of Industrial Engineering, I am making a warehouse simulation and optimization model in software Anylogic. I want to know the time my picker spends in being busy( that is moving) and so I came across this built-in function 'timeInState'. This helps me to determine the total time by picker has spent being 'busy'.
The issue I am facing is that upon calling this function, I am getting no value (0), but my pickers are clearly moving in the model. Maybe the parameters I am giving is not the right way to do it. I was thinking if anyone familiar with this can help me out? . To clarify the function, its meaning and parameter initialization is as below:
double timeInState(ResourceUsageState state) -Returns the time the unit has spent in the given "usage state" so far.
Parameter: state - the state (ResourceUsageState.USAGE_IDLE or ResourceUsageState.USAGE_BUSY)
Thanks for your help !
The timeInState function has nothing to do with state charts but records durations for resources. It is named rather unfortunately...
There is no build-in way to measure state durations (for good reasons ;-) ).
Easiest solution:
create a double variable timer and another timeInStateX
on-enter of your state X, set timer=time()
on-exit of your state X, add the duration as timeInStateX += (time()-timer
Make sure to not accidentally overwrite the timer from elsewhere, though
The timeInState function does work to capture time busy so you must have another problem. You should be calling it similarly to <resource reference>.timeInState(ResourceUsageState.USAGE_BUSY) or (specifying time units) <resource reference>.timeInState(ResourceUsageState.USAGE_BUSY, TimeUnits.MINUTE).
You'll need to give more context to understand why it's not working for you.
You are also seizing and releasing these agents as resources in a ResourcePool right?

How to get around using Enter and Exit blocks in "Prepare" flowchart (Execution error "0 isn't supported for building resource behavior flowcharts")

I have an airlock (small room called AL_2216) between 2 areas. The airlock has many different agent types passing through it (cart, product, operator, etc). There are queuing areas on either side of the airlock.
Because the space is small, I built a short flowchart that has a queue and restricted area blocks that all agents must pass through when going through this space. If the restricted area's capacity is full, the agents wait in either the InsideQueueArea or OutsideQueueArea depending on the direction they're going.
I send agents via Exit and Enter blocks to this flowchart and it works great on the top portion of the flowchart.
BUT if I try to use an Enter or Exit block in the prepare flowchart, I get this error:
I tried using a custom block instead of Enter and Exit blocks, but that creates a new instance of the code each time and the restrictions don't work together across the multiple custom blocks.
This airlock is just one of many in my model. Without referring to the same code, I'll have multiple copies that need to refer to each other's restricted areas and the flowcharts become huge and complicated. Is there a way to get around this?
EDIT:
I'm not sure what to do with these ports. They have no properties that do anything:
EDIT2:
Here's a file to see the behavior - Model2.zip
The Prepared flowchart portion is set to "ignore" so the code will run. You can see the operators and the carts passing through AL_2216 with only 2 being allowed at a time. If you uncheck "ignore" for the prepare flowchart, the error will trigger.
AnyLogic sent the right answer!!
So I was asking Anylogic a different question and they recognized my name from this post! They sent a fix to me and it works exactly the way it should! The exception error message I was getting "out: 0 isn't supported for..." made me think the exit/enter blocks were not supported in perparation flowcharts.
But actually, the seizeCart block didn't know where to start the prep flowchart because it wasn't directly connected to the resource task start block. A quick setting change under the Advanced section of the seizeCart block defining which resource task start block to start at did the trick! Here's the email from AnyLogic:
-The error text and documentation are not sufficient for understanding this (the error text is confusing), I suppose it is obsolete error text. We will rectify the description;
-Under the question there is a more generic discussion which seems to be unrelated to the initial problem. Please let me know if I miss something or if your model does not work as you expect even after adjustment of seizeCart block property.
I think you should replace the Enter and Exit blocks that lead to the bottom input of your seizeCart Seize block with simple Port objects (from the Agent palette).
As per the help for Seize:
So it wants a direct link to a ResourceTaskStart flow and your Enter/Exit combinations might be ... not "direct" enough... Try it.
So here's what I ended up doing. It's the best I could come up with that could be easily replicated for lots of airlocks.
I've added a wait block (dummyThruAL_2216) to my Product flowchart prior to seizing the cart. This wait block injects a new Agent into sourceDummy at the cartHome node. The dummy then seizes a cart and moves through the airlock and it's restriction. Upon exiting the restriction, I check what type of agent and direct the agent to the correct exit block. The dummy agent and cart move to the Product where the dummy agent releases the cart and sinks. The sink frees the wait block and the Product seizes the cart that is right next to it and continues on it's journey.
It's an easy copy/paste to add more airlocks. Not as nice as my original, but what are you going to do... Thanks for everyone's help and suggestions.
As others have said, there are (not really documented) restrictions on what blocks you can use in preparation and wrap-up flowcharts, which mean what you're attempting won't work.
As you say, it's important to keep a single 'instance' of the airlock flow so that the restrictions (queue and restricted area) are 'global' when this represents the same physical airlock. (Otherwise a repeated custom block is precisely what you should use for each different physical airlock.)
Your best option (and assuming you needed to attach the Cart resource to the Product) is probably to
Add dummy agents (via Source block inject calls) to a separate mini-process that represents your resource preparation requirement (but now not attached to the Seize block).
Replace the Seize in your main process with a Seize-Wait-Release-Seize combination:
The Seize block seizes the cart as normal (without moving or attaching it; no 'Send seized resources' or 'Attach seized resources' options) and then injects an agent into your mini-process (which can use Exit and Enter blocks to use the airlock sub-process). This agent represents the seized resource agent (Cart) and thus should start where it starts and be animated so it looks like it. (You can make the actual Cart temporarily non-visible during this mini-process.)
When the agent reaches the end of the mini-process (at a Sink block), instantly move the related Cart to your node (use jumpTo), make it visible again and free the Product agent from the Wait block
Release the seized Cart and then immediately re-Seize it, but now attaching it (so the animation looks correct). If you use the Resource selection 'Nearest to the agent' option you should be guaranteed to seize the correct cart. (You can also use the 'Customise resource choice' option with some code to ensure that you absolutely always choose the same Cart.)
(It is simpler than the above if you don't care about having a correct animation, and you can use custom blocks to make this block combination reusable and thus not too clunky.)
Edit: A very similar alternative which also works (and is the basis for your own answer) is to have a dummy agent representing your Product in the sub-flow which seizes (and attaches) the actual Cart agent, leaving it at the Product's location to be immediately seized as above. This is slightly better since you don't have to worry about the visibility and 'jumping' of the real resource agent, plus you can move a Seize and a Release from the main flow (which now just has Wait-Seize) to the sub-flow (thus 'hiding them away').