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?
Related
Is there a way for a PLC program to know its own cycle time?
As a workaround, I can just add a persistent variable or a constant to tell it manually, but that's obviously error prone.
To add to Jakob's answer - you can also use GETCURTASKINDEXEX function (Infosys) instead of GETCURTASKINDEX FB. This way you don't have to instantiate it.
_TaskInfo[GETCURTASKINDEXEX()].CycleTime
Will return cycle time as multiples of 100ns (UDINT)
UDINT_TO_LREAL(_TaskInfo[GETCURTASKINDEXEX()].CycleTime) / 10_000_000
Will return cycle time as seconds (LREAL)
For TwinCAT3 this is available in PlcTaskSystemInfo (variable CycleTime).
Combine it with the FB GETCURTASKINDEX to get the data you want.
See one example (though not cycle-time, but still same FB) here at AllTwinCAT.
This is not directly an answer to your question, but can be used to determine the Cycle time.
I like to use the Time() function. It returns a value of data type TIME. It does not represent an absolute time, but can be used to calculate the time between two calls to Time(). In this way you can calculate the Cycle time.
I use it in function blocks (FB) where timing is critical. In this way the FB knows when it was lastly called instead of assuming that it is being run each scan. Even if I or another user of my FB "forgets" to call the FB each scan, the FB still delivers correct outputs.
You can find info on Time() using this link. There is also a function called LTime() which returns a value of data type LTIME, but it seems that Beckhoff did not bother to document this function.
the basic idea behind the modeling issue is a breakdown of a production machine.
I would like to model this by setting the arrival rate (simply arrivals per second) to zero (Source.rate = 0). After the machine is repaired, the arrival rate is set to its actual value again (e.g., Source.rate = 5). While the first command does the job, the second does not seem to have any effect, i.e. new agents are not created.
The segment of the model is rather simple: Source --> Select Output (decision about breakdown) --> true: go on in production; false: delay (repair machine) --> go on in production.
Source.rate = 0 is called at the out port (false) of "breakdown" and Source.rate = 5 at the out port of "repair".
https://i.stack.imgur.com/hqGoI.png
Of cause, this issue might be modeled differently (e.g., using hold with disabled "forced pushing"), however, it is not clear for me why my approach does not work.
Thanks in advance!
Instead of using source.rate=5; use source.set_rate(5);
To expand on Felipe's answer with an explanation:
Instead of using source.rate=5; use source.set_rate(5);
rate is effectively a Parameter (in the AnyLogic sense) of the Source block. (All AnyLogic's Process Modeling blocks are actually themselves Agents developed by AnyLogic, and thus with Parameters, Variables, etc.)
You can set an AnyLogic Parameter directly (via just assigning a value as you did), but they also all have a set_<parameter name> method (function) which should really always be used instead because this triggers any internal on-change logic for this Parameter. It is only this triggered logic (internal to the Source block) which causes the Source to 're-evaluate' the rate properly.
(You can use on-change logic for Parameters in your own models, and need to do so when altering a parameter requires some 'adjustments' to the rest of the model; i.e., in situations where the change doesn't 'just work' due to other bits of the model reading the new value after the change point.)
I don't know why your model doesn't work (maybe more details of your model is needed), but a simple solution which I tested and worked, is as below:
You can set the source's "Type of arrival" to "calls of inject() function", add an event to your model and set its "Trigger type" to "Rate" and set its rate value to 5. Then in action code of the event use below code:
if(yourCondition)
{
source.inject(1);
}
I hope it helps you.
I have read the Mathworks documentation carefully and tried to find a solution on forums as well. However, I have not been able to find a solution to my problem yet.
I am using Matlab/Simulink to simulate the dynamics of a vehicle, which picks up an object during operation. The way I am planning to do this is to:
Simulate the motions of the vehicle by itself at the start of the simulation;
Stop the simulation, save the final state, update the model parameters (so that they now represent the vehicle and the object)
Initialize the simulation again starting from the end time of the previous run and using the previous final state as input state to the new simulation.
To do this, I have been using the options FastRestart, SaveFinalState, SaveCompleteFinalSimState and update. Unluckily, the simulation runs seamlessly, but the model parameters are not updated.
The dynamics of the vehicle and vehicle+body are modelled by the same C-coded S-function. This function receives the parameters of the dynamic equations (e.g. inertia, damping, etc.) as parameters to the S-function block. I think this is the main problem with my approach: even though I run the update command, the S-function does not recognize the update of the parameters in the workspace. Do I need to recompile it? I guess that is not feasible under Fast Restart mode, is it?
Any advise is really appreciated! Thank you!
I have a similar issue to this in a different situation. Trying to update the initial state target of a revolute joint, the fast restart option does not change the property.
I have had some luck updating the model in fastrestart with other parameters, however, using:
set_param('Model_Name','TunableVars','Variable Name')
Not sure if this will help in your situation, perhaps saving the final state as a variable and having the respective variables as initial parameters.
I wish to measure the time it takes for some of my Actor methods to execute. I plan to use OnPreActorMethodAsync and OnPostActorMethodAsync to log when these methods have begun and finished execution.
However I also wish to measure the time it takes for these methods to execute. My original plan was to use an instance of StopWatch to begin timing in the OnPreActorMethodAsync class and stop in the OnPostActorMethodAsync class. However I'm unsure how I can accessthe same StopWatch instance in the second method. If there is a better way of doing this I would be very interested.
If anyone could point me in the right direction on this matter that would be great.
Many Thanks
By using some dirty reflection tricks you can access the Actors' call context.
More about it here: https://stackoverflow.com/a/39526751/5946937
(Disclaimer: Actor internals may have changed since then)
I'm implementing an FRP framework in Scala and I seem to have run into a problem. Motivated by some thinking, this question I decided to restrict the public interface of my framework so Behaviours could only be evaluated in the 'present' i.e.:
behaviour.at(now)
This also falls in line with Conal's assumption in the Fran paper that Behaviours are only ever evaluated/sampled at increasing times. It does restrict transformations on Behaviours but otherwise we find ourselves in huge problems with Behaviours that represent some input:
val slider = Stepper(0, sliderChangeEvent)
With this Behaviour, evaluating future values would be incorrect and evaluating past values would require an unbounded amount of memory (all occurrences used in the 'slider' event would have to be stored).
I am having trouble with the specification for the 'snapshot' operation on Behaviours given this restriction. My problem is best explained with an example (using the slider mentioned above):
val event = mouseB // an event that occurs when the mouse is pressed
val sampler = slider.snapshot(event)
val stepper = Stepper(0, sampler)
My problem here is that if the 'mouseB' Event has occurred when this code is executed then the current value of 'stepper' will be the last 'sample' of 'slider' (the value at the time the last occurrence occurred). If the time of the last occurrence is in the past then we will consequently end up evaluating 'slider' using a past time which breaks the rule set above (and your original assumption). I can see a couple of ways to solve this:
We 'record' the past (keep hold of all past occurrences in an Event) allowing evaluation of Behaviours with past times (using an unbounded amount of memory)
We modify 'snapshot' to take a time argument ("sample after this time") and enforce that that time >= now
In a more wacky move, we could restrict creation of FRP objects to the initial setup of a program somehow and only start processing events/input after this setup is complete
I could also simply not implement 'sample' or remove 'stepper'/'switcher' (but I don't really want to do either of these things). Has anyone any thoughts on this? Have I misunderstood anything here?
Oh I see what you mean now.
Your "you can only sample at 'now'" restriction isn't tight enough, I think. It needs to be a bit stronger to avoid looking into the past. Since you are using an environmental conception of now, I would define the behavior construction functions in terms of it (so long as now cannot advance by the mere execution of definitions, which, per my last answer, would get messy). For example:
Stepper(i,e) is a behavior with the value i in the interval [now,e1] (where e1 is the
time of first occurrence of e after now), and the value of the most recent occurrence of e afterward.
With this semantics, your prediction about the value of stepper that got you into this conundrum is dismantled, and the stepper will now have the value 0. I don't know whether this semantics is desirable to you, but it seems natural enough to me.
From what I can tell, you are worried about a race condition: what happens if an event occurs while the code is executing.
Purely functional code does not like to have to know that it gets executed. Functional techniques are at their finest in the pure setting, such that it does not matter in what order code is executed. A way out of this dilemma is to pretend that every change happened in one sensitive (internal, probably) piece of imperative code; pretend that any functional declarations in the FRP framework happen in 0 time so it is impossible for something to change during their declaration.
Nobody should ever sleep, or really do anything time sensitive, in a section of code that is declaring behaviors and things. Essentially, code that works with FRP objects ought to be pure, then you don't have any problems.
This does not necessarily preclude running it on multiple threads, but to support that you might need to reorganize your internal representations. Welcome to the world of FRP library implementation -- I suspect your internal representation will fluctuate many times during this process. :-)
I'm confused about your confusion. The way I see is that Stepper will "set" the behavior to a new value whenever the event occurs. So, what happens is the following:
The instant in which the event mouseB occurs, the value of the slider behavior will be read (snapshot). This value will be "set" into the behavior stepper.
So, it is true that the Stepper will "remember" values from the past; the point is that it only remembers the latest value from the past, not everything.
Semantically, it is best to model Stepper as a function like luqui proposes.