Idea

Chris,

Sorry, you're not going to get many non-process flow solutions on this from the FlexSim employees. Most of us are pretty sold on the advantages of process flow. It's visual, it's easier to communicate what logic is happening when, and it doesn't pigeon-hole people into only using the canned (hidden) logic that we would provide if we were to make an actual module for it.

To your point on speed, there is certainly some overhead with executing process flow logic. However, first off, it does depend on how you build your process flow, whether you're creating new tokens every 10 milliseconds vs finding options for not having process flow logic fire all the time. Second, right now there is a lot of low-hanging fruit for us to optimize it on our side, and even make it faster in some cases than would be possible if you were to implement logic in FlexScript. Label access is an example. There are ways that we can make label access in some cases an order-1 operation, even faster than a hash table lookup. So yes, speed is something to think about, but I don't think it necessarily has to be a show-stopper.

Secondly, on the object-oriented point, process flow can be implemented from an object-oriented perspective, specifically using the instanced (fixed resource and task executer) process flows. Using this methodology, you can implement a process flow from the perspective of the object. If done properly, the process flow will then scale to as many objects as you like; you just attach the objects as instances to the process flow, and each will start performing the desired functionality.

Thirdly, I guess I'm a bit flummoxed that you want to implement the replenishment mechanism using a "patient track"-style UI, but not using process flow. Process flow gives you the capability you would get from a patient track, and you get an extra dimension (patient tracks are a one-dimensional list of activities, while process flow gives you full flowchart style 2D UI).

I'm attaching an example model I put together that contains a fixed resource process flow that I believe is pretty flexible for implementing material consumption and replenishment. The cool thing, as I said before, is that you can just define the set of objects that use this logic by adding them as instances of the process flow (and you can drag new ones from the library as well). To define parameters, click on an attached object and in its quick properties you should see process flow input variables. These are inputs specific to that object associated with the process flow logic, as follows:

1. StartLevel - This is the amount of material that the object will start with at the beginning of the simulation
2. ReorderLevel - This is the level at which the object will make a new order to replenish the material
3. ReorderUnitQty - This is the amount of material that is replenished with a single unit delivered to the station. So if it's bolts, and there are 500 bolts per box that's delivered to the station, this value is 500.
4. NumReorderUnits - This is the number of discrete units to reorder at a time. So if you have boxes of 500 bolts each, and you reorder 4 boxes at a time, ReorderUnitQty would be 500, and NumReorderUnits would be 4.
5. ItemDependentDepletion - This is a 1 or 0 value that tells whether the amount to deplete the material by is dependent on the item that is being processed. Usually this will be 0, but in some cases it might be 1. For example, if every part that is being assembled at a station uses up 2 bolts, no matter what the part type is, then ItemDependentDepletion should be 0. However, if some parts use 2 bolts, and others use 4, etc. then ItemDependentDepletion should be 1. When 0, the process flow can optimize for speed, which I'll talk about further down, so if you can make it 0, make it 0.
6. DepletionUnit - What you enter for this value is dependent on ItemDependentDepletion. If ItemDependentDepletion is 0, then you should enter the constant amount of material that is used for each part. For example, if you use 2 bolts for each part, then this should be 2. If ItemDependentDepletion is 1, then this value should be some expression that contains token.Item. For example, if items moving through the station have a label called Volume that represents the amount of material that is consumed at that station, then you should enter for DepletionUnit: token.Item.Volume.
7. Storage Location - This is the location from which to replenish the material. The default replenishment process uses this to create an item and place it there for pickup.

On the speed optimization: When the depletion amount is not dependent on each item, the process flow can simply listen for when the object's total input reaches a certain amount calculated from the various parameters. It is essentially saying: notify me when the object's input reaches 300. In between that time, nothing is happening in the process flow, so it is actually potentially faster than if you were to track things on the object using entry/exit triggers. It should be noted that in building this, I came across a bug in the wait for event, and unfortunately you can't get/set the proper values in the GUI. But when it does work, you will see that I'm listening for a tracked variable's OnChange event (the object's input statistic usually) and I'm setting it so it waits until the object input increases "to or through" a given value, namely the point at which I need to reorder.

If depletion amount is item-dependent, then the process flow does need to listen for each entry of the object, although I don't think that would bog down the system that much.

In the example model, I've implemented the two types of depletion/replenishment. Processor1 has standard fixed depletion, while Processor2 has item-dependent depletion based on a Volume label on the item.

Regarding your resource capacity suggestions, I believe that how and what resources pick up is a completely different problem than material consumption and replenishment, and thus I don't see those two as really needing to be paired together, since the problem of how, when, and what to pick up is a problem that happens in almost every model, not just in material consumption/replenishment. In the example model, I use the AGV template process flow to direct the AGV motion. If you want to constrain what an AGV can pick up given its current state, you can customize this in the AGV template process flow by changing a list pull query. You might push back on this as the AGV template process flow can be somewhat complex. I would respond that the AGV template process flow is exactly the result of people pushing for more flexibility in controlling transportation, which is exactly what you are wanting. It consolidates many of the complex decisions and prioritizations into a set of list pulls, where you can customize what you want to do next by simply adding/changing an ORDER BY or a WHERE clause in a pull. You just need to take some time to understand how everything is working (and I am open to feedback on how we can make it more easily learnable).

Going forward on this, my thought is that we should implement these types of functionalities via more template process flows, like the AGV template process flow, instead of as separate modules. Perhaps if many people find this one useful (and I'm open for feedback as to how it can be improved), then we will put this into the standard software as an available template. I also would like to make tweaks to the AGV template process flow so that it enables more automatic functionality, such as polling at intervals as you suggested.

materialconsumptionreplenishment.fsm

I don't know if this is exactly what you're looking for, but instead of creating a new module, if you use process flow to handle the logic of your facility. You could use the preemption activities to simulate replenishment.

We've created a sample "bottling" facility to demonstrate how this could work. The preemption activities here simulate an MTBF/MTTR functionality for the Filling and Capping areas. But it also uses preemption for the label restocking, which sounds like it could be something similar to what you're trying to simulate.

bottlestationexample.fsm

Thanks, Sam. This process flow does accomplish the logic of much of this request (specifically, the material replenishment mechanism). However, it also seems to prove the scalability issue. If you try to run 8 replications of 3 scenarios of this model for a months (or even a weeks) worth of production it takes a surprisingly long time. Now imagine that there are 50 stations with 500 parts... I think that an object oriented module would be superior for the following reasons:

1. Object-oriented models seem to require less processing power. Maybe I am using Process Flow incorrectly, but it seems when I use process flow the models seem to slow down dramatically compared to a custom coded solution. I would be interested in having a discussion about this to see if there is a way to minimize this performance impact.

2. Object- oriented modeling is more familiar to a broader set of people. Process flow, while incredibly useful, is not common to people who have used other software. It is much easier to help people create models if the 3D objects have the default capability to accomplish the modeling task.

I mostly just want to present this as a module idea to judge how much community interest there is in this type of module. Thanks again for your comment.