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
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.
So I should give each cargo duetime on the sorce for it to take effect, right?
So what should I do if I want to implement the (Shortest Processing Time) rule
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.
"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?
"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.
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?
16 People are following this question.
