Applying Dispatching rules

[a9080109]

[ FlexSim 22.0.0 ]

I would like to know if I want to use the dispatch law of edd spt st etc. to be applied in this model, what should I do0816排程模擬.fsm

[moehlmann_fe · Accepted solution]

Ordering a processing order by a label, such as a due time, can be done by using a list to distribute the items and use the ORDER BY clause to sort the available items by the respective label.

I modified your model, so that all of the queues push the items to "ItemList1". This list duplicates the "DueTime" label on the item as a label field and has two more expression fields. The first checks whether the items current position is in one of the "inObjects" of the puller. The puller will be a processor, so we use this to only allow them to pull items from either their respective "wip" queue or from Queue1. The second expression returns 1 if the item's type matches the action parameter for that processor. Otherwise it is 0.

These fields are used in the Pull Strategy of the processors.

"WHERE" filters the available items by the "canPull" value. So the processor is only allowed to pull an item if the queue it is in is connected to the processor. The remaning items are then first sorted by the "matchesRLParam" value, so pulling a type mandated by the action parameter has priority. Then again, they are sorted by the "DueTime" label in ascending order, so items with an earlier due time will get picked first.

0816 (1).fsm

[a9080109]

So I should give each cargo duetime on the sorce for it to take effect, right?

[a9080109]

So what should I do if I want to implement the (Shortest Processing Time) rule

[a9080109]

"WHERE" filters the available items by the "canPull" value. So the processor is only allowed to pull an item if the queue it is in is connected to the processor. The remaning items are then first sorted by the "matchesRLParam" value, so pulling a type mandated by the action parameter has priority. Then again, they are sorted by the "DueTime" label in ascending order, so items with an earlier due time will get picked first.

The above paragraph may need you to explain again!!

value.up == puller.inObjects[1] || value.up == puller.inObjects[2]

What I don't understand is the meaning of value.up?

Puller.inObjects[1] You said that the puller represents the machine, so the reason why inobject[1] has two is because I have two ports?

[moehlmann_fe]

Instead of having a fixed label value like the due time, you would add a new expression field to the list that calculates the processing time if the value (item) were to be pulled.

The code is copied from the setup time setting of the processor. The only difference is adding the variable "current" (= puller = processor), because that is the reference used in the setup time code. As well as adding the 10 seconds of actual processing time. If the process time was different per item, you would calculate both it and the setup time and return the sum of the two.

Then use this new field to order the items when pulling.

[moehlmann_fe]

"value" is a reference to the object on the list that might be pulled. In this case, this would be the item. ".up" returns the container object of something. Because the items on the list are always in one of the queues "value.up" thus gives a reference to queue that currently holds the item.

We then compare this to the two "inObjects" of the processor, which you correctly identified as the objects connected to the input ports. A comparison will either return "true" (1) or "false" (0). These are then linked with a logical OR operator ( || ). So if either of the comparisons is true (the item is inside a queue connected to the processor), the value of "canPull" will be 1. If both are false, the value will be 0. By filtering for values of 1 in the query, we make sure that the processor only pulls items from queues connected to it. So processor1 can't pull items from wip3 for example.

Which of the remaining, eligible items is pulled is then further determined by the ORDER BY statement. This sorts the items by the chosen value in either ascending or descending order. First they are sorted by "matchesRLParam". Again, this is a binary value stemming from a comparison like above. If the item type matches the type mandated by the action parameter the value is 1, otherwise 0. So we order this in descending order, to put items with a matching type at the top. If there is more than one entry for either value (0 or 1) these are then further sorted by the next value "due time"/"process time" to pull the item best suited for the current policy.

[a9080109]

Can you give me the file?

[a9080109]

So do I give the source a duetime?

[moehlmann_fe]

0816-2.fsm

If you want to see the pull logic work without the action parameter interfering, you can change the order of "matchesRLParam DESC" and "processTime ASC" in the pull query.

[moehlmann_fe]

Sorry, I missed a minor mistake. The second to last line in the code of the "processTime" expression has to be removed.

0816-3.fsm

[a9080109]

Thanks for that. Back to the question about duetime. Did I join in production?

[moehlmann_fe]

I don't know what you mean by "Did I join in production?".

In regards to your question about the due time: Yes, you would have to add a label with this value when creating the items (or when they enter the first queue but always before they are pulled).

Doing this directly in the schedule of the source is a good way.

[a9080109]

TIs the purpose of creating the labels to execute the following line of code?

[moehlmann_fe]

Yes, I use that label to have a reference to the correct parameter for the processor.

[a9080109]

value.Type == Model.parameters[puller.RLParamName].evaluate()

Can you explain this sentence? What is the relationship between this sentence and parameters. What does evaluate() mean?

And what is his ordering method?

[moehlmann_fe]

There are three ways to read a model parameter.

Model.parameters.Parameter1;
Model.parameters["Parameter1"].value;
Model.parameters["Parameter1"].evaluate();

The first is the simplest. To use it, the name of the parameter must the use directly and it cannot contain any free space.

The second allows to pass in a variable as the parameter name. It also works if the name contains spaces.

Model.parameters["Name with spaces"].value;

Lastly, the third allows to pass in parameters. This can be used when the parameter is of the "Expression" type. For example the parameter could define a statistical distribution and this would allow to pass in the lower and upper bound.

Model.parameters["Distribution"].evaluate(0, 5);

For the "matchesRLParam" expression the second way would have sufficed. I guess I just used the third out of habit.

value.Type == Model.parameters[puller.RLParamName].evaluate()

This compares the "Type" label of the value/item with the action parameter that corresponds to the processor. Like explain above, it either returns true/1 or false/0.

If the action parameter "ItemType" of processor1 was set to 3 for example, the expression would return 1 for all items of type 3.

[a9080109]

So take this picture as an example, what action will he take when ITEMTYPE=2 and return 1

[moehlmann_fe]

If "ItemType" is 2, the processor will pull an item of type 2, if available. All items of type 2 have the same processing time, so the second ORDER BY value doesn't make a difference in that case. If no item with type 2 is available it will pull the item with the lowest setup/processing time.

[a9080109]

Thank you for your reply. I would like to ask if you are free tomorrow. I am sorting out some questions to ask you.