ASagan

This was something I was dealing with quite awhile ago, it is possible with fixed route vehicles, and there are tricks to get it working with other types of routing. I did it with fixed route vehicles with a few steps INSIDE the object the vehicle would go into. I've attached a fairly old example that might help FixedRouteVehicleEnteringSubModel.spfx

That is correct. You have the average, min, max from within a run. And the average of the average, the average of the min, the average of the max... the min of the min/average/max, and the max of the min/average/max. Looking at your results, I see that the average time in station of ScreeningLineL1.Xray.Processing ranged from 12.6974 to 13.3549 seconds, while the min ranged from 0.1229 to 0.8086 seconds, and so on and so forth.

Just enter the state as your link weight. Viola! I've attached a demo model using this for you to check out. sample_StateForLinkWeight.spfx

Dave... Did not know number 3. Excellent

Looks to me like your error is occurring because you have the 'wrong' associated object with your process. Is the press your associated object, or your plant entity? Regarding deadlocks -- What do you mean by transfer deadlocks?

Dariusz, There are many ways of tackling your second question. One way is to increment the monitors threshold state when it fires. I've attached a sample model. sampleMonitorFiringIncrement.spfx

Dariusz, I don't think I've explained myself very well, as if you were 'seizing from a list' the way I described, then the first transporter in the list that is available would be selected, automatically covering your question. 1) Create an object list property in your object. 2) Set the seize step to 'seize from list' and give it the object list. The seize step will automatically select the first free object. I've attached a model demonstrating this. This model has two transporter instances which even have a population of 2. These transporters have been added to the list 'ObjectList1'. I've created an object with an object list property called 'object list name'. This object seizes an object from the list on an event. The running model has four of these seizing objects. Pushing a button in the facility will fire an event, triggering the object to seize a transporter. The transporters will be seized one after another. SampleModelOfSeizingFromList.spfx

You can seize from a list. You'll notice the server has the ability to seize a resource from a list -- therefore we can do it too! All you need to do is create a property to pass in of a list instead of a specific object, and set the seize step properties to seize from a list.

Dariusz, This is the same 'problem' as placing a server in a model and having the server seize a secondary resource for processing. As all the Simio objects are open, you can copy/subclass the server and see how it does this. In short, here's how it can be done: 1. Give a property to your machinery object of 'seize resource' or 'available worker'. 2. Create a process in your machinery object that seizes the resource property. 3. Create a process in your machinery object that will release the resource property when no longer needed.

Interesting discussion. Most programs I've worked with uses the same coordinate system as Simio -- confuses me a bit from my physics days because the z direction is reversed, but the xyz used in Simio is 'correct' otherwise. Unfortunately I don't use these programs enough to say for sure which ones use what...

Did you check if this was a permissions problem? If you're on Win7 you might need to 'unblock' the dll. Right click on the dll and select properties. Then choose to unblock and apply.

Try Model.Entity.Type == String.FromReal(MyTable.ProductType). Total alternative to the current approach -- use an excel table to create 500 different entity types as you originally said was unfeasible. Becomes easy. Look in the 'shared forum' to see the utilities on how to create models straight from excel.

While I stated that both can be constraints, I do find this rare. When I've used the transporter with weight = 100 metric tons and volume = infinity (say, a train wagon), it seems to work just fine. I don't think I understand your problem.

Interesting pick-up on this one Mark. I actually think the tanker is correct and the standard objects are wrong. I have worked on systems before where both volume and weight have been constraints depending on density.

The pipe object appears to have artificial maximum on its rate of transfer. The pipe initially starts with a desired speed state value of 2 m/s has a hidden property input. This means that any entity transferring into the pipe starts at a maximum of that speed. Attempting to transfer entities at mass/volumes that correspond to a linear speed greater than 2m/s doesn't work. Changing this property/state however, does not appear to fix the problem. Entities remain capped at 2m/s.

Would you be able to attach your model?

The easiest way to solve this is to just use two realizations of the same instance of a worker. Set the population of your worker instance to two. The servers will automatically consider the whole population of workers. The other way to do it is to set the servers 'object type' for resources to 'select from list' and give it a list of workers. No process logic required in either instance.

I don't think you can, not in the way you're thinking. However, you could use the search step with a limit of infinity to get separate tokens for every worker of the population. Alternatively, once you are associated with a worker, you can simply use something along the lines of 'Worker.Population....' to get the population functions. You don't even need the search step for this -- if you know the population you are searching, you can directly reference these functions with 'WorkerInstance.Population...'

You can use the search steps 'save number found' state assignment in the advanced properties. Then check the state you saved this too on the original branch to assign 'nothing' to your state. Alternatively, make the search expression 1. This will save, into Token.ReturnValue, (1)*(numberFound). Check your token.returnvalue to see if any were found.

Based only on what you wrote, the picture state wouldn't change... you need an assign step. Assuming you have an assign step later, have you traced the search step and checked which row it is returning? If it is returning the wrong row, try using this for the second part of your match criteria: modelEntity.Population.Name == tabPartsInfo.EntityType.Name

I'm assuming you're using the add-on process 'OnEntered' at the node. Keep in mind that not only do entities enter the node (when they arrive and when they are dropped off), but so do the vehicles when they arrive to pick up an entity. Because of this, it sounds to me like your process is being run whenever an entity enters the node as well when a vehicle. Try using a 'decide' step with something like 'Entity.Is.ModelEntity' or '! Entity.Is.Vehicle' to make sure that only your modelEntities run through the process. Force the process to run through the false branch (with nothing on it) when the associated object is a vehicle.

Joyceamador, from your description both of the above suggestions sound like they should work to me... put the server's queue on the bed, and either use the animated person animation 'prone', or manipulate the queue so the patient looks like they're lying down. If your entity has a symbol of both stretcher/patient, you will have to change the symbol so it is only a patient. However, you could use separate entities for the stretcher and the patient, and using a combiner to place the patient on the stretcher. I've attached a model which uses stretchers and patients and has them 'lying' down as an example. Maybe it would be easier if you posted your model (or a sample of it)... PatientsOnBeds.spfx

Try Worker.Population.Capacity.Utilisation, or Worker.Population.Capacity.ScheduledUtilisation.

Third idea -- position the queue that the patient is in such that the patient is oriented lying down.

I believe the 'arrive' step is used to notify entities in the visit request queue that the transporter has arrived, thereby finishing the visit request. I'm not sure, I haven't tried this... you could give it a go. Alternatively, you could give entities a state of whether they actually want the PRV or not, and use the PRV use a condition or match rule on the PRV to ignore entities in the visit request queue with that state set to false. Of course as I'm sure you're dealing with now, this means your visit request queue will keep building up.