topic Re: An operator doesn´t work in FlexSim Forum

An operator doesn´t work

oscar_manuel_cmn — Thu, 14 May 2020 11:19:40 GMT

[ FlexSim 19.0.9 ]

Hi!

The objective of the model is for operators to take an item from a queue and take it to the next machine and then process it. Also, operators have to stay on that workstation (queue+machine) until the queue is empty, only then can they decide whether to go to another queue. Also, the queue they go to has to be the one with the fewest items.

In zone1, I have 3 operators, but only two of them work at the same time. I suppose it will be because a queue can only be acquired by an operator, and I don´t know how to solve this.
Thanks!
FIFO-WHN2-SQ.fsm

19.0.0 Version

Re: An operator doesn´t work

regan_blackett — Thu, 14 May 2020 17:24:03 GMT

I did a sample model that I think handles the rules that you want. It works on a two-list system rather than one which it looks like you were going for.

I have one list for the queues, and another for the items. At the start of the model, the operators will first try to pull the queue with the least number of flowitems, with at least one flowitem in it, and then sorts by the queue with the lowest queue size, and in case there is more than one queue that meets that criteria, I do a second sort on distance to the operator.

Once a queue has been chosen from that list, the operator will only pull flowitems that are in that queue until it is empty. To do this I partitioned the list by queue during the send to port event of the queues. When the queue is empty the queue is pushed back onto its list and the operator searches frot he next available queue.

Shortest queue until empty.fsm

Re: An operator doesn´t work

oscar_manuel_cmn — Thu, 14 May 2020 20:11:10 GMT

But, if you have two parallel machines attached to the same queue, you woul still have the same problem, right? The problem is that two operators can access the same queue simultaneously. If an operator removes a queue from the list, it is no longer available so that another operator can collect items from it.

Re: An operator doesn´t work

regan_blackett — Thu, 14 May 2020 23:29:08 GMT

@Óscar Manuel CMN

Here's an updated version to accommodate some queues that have multiple processors as potential destinations. I created a Field on the Queues List called "AllowedPullers" that gets a value equal to the number of center ports on the Queue.

Then in the Pull from List to find a Queue, I added a SELECT statement to the query which decrements the AllowedPullers Field. This will keep Queues on the list until all of its puller slots have been consumed. So more than one operator can "use" a queue if there are parallel machines downstream.

I also changed the way queueSize is handled so rather than looking at how many things are phsycially in the queue, I'm looking at the number of items that haven't been pulled from a queue's assigned partition on the item list. With travel time on the operators looking at the phsycial things in the queuse alone wasn't enough.

at time 288 you can see the operator at Queue 1 transition to Queue 2 to help the queue with two parallel processes available.

Shortest queue until empty_3.fsm

Re: An operator doesn´t work

oscar_manuel_cmn — Sun, 17 May 2020 15:05:28 GMT

Thanks!!

Could you clarify a few points for me please?

1. What is the ID tag for?

2. What does trueQueuesize do and what does it expression mean?

getstat(List("ItemList1").as(treenode), "PartitionContent", STAT_CURRENT, value)

3. Are "customode" tabs necessary?

4. I know that in the Condition tab inside "DECIDE" you look if there are more objetcs in the queue but how does the expression you write there work?

getstat(getactivity(processFlow, "List: Items"), "PartitionContent", STAT_CURRENT, current, token.PulledQueue) == 0

Re: An operator doesn´t work

oscar_manuel_cmn — Sun, 17 May 2020 16:40:23 GMT

I implemented your logic in my model but it doesn´t work properly. I will have written something wrong but I cannot find the fault.

Oscar.fsm

Re: An operator doesn´t work

regan_blackett — Mon, 18 May 2020 14:31:57 GMT

@Óscar Manuel CMN

1. What is the ID tag for?

This was just so I could easily color-code the tokens that represent the operators, using the "Visualization" properties of the Process Flow. A red token for the red operator, a green token for the green operator.

2. What does trueQueuesize do and what does it expression mean?

getstat(List("ItemList1").as(treenode), "PartitionContent", STAT_CURRENT, value)

I found the queueSize field that comes with an Item List was insufficient for checking if there was something in the queue in your case. So the getstat() command is looking at the contents of the Item List partition that I assigned to each of the queues. So the trueQueueSize is taking into account that something could still be in the queue even though it has been pulled from the List, which means it won't be in the queue for much longer because an operator is traveling to retrieve it.

3. Are "customode" tabs necessary?

I'm not sure what you mean by this. Do you mean the Custom Code activities that set the operators state? I put those in so that the operator's states don't show as "idle" while they are waiting for the process times to end. IF you don't care about the operator's state reports you can remove those.

4. I know that in the Condition tab inside "DECIDE" you look if there are more objects in the queue but how does the expression you write there work?

getstat(getactivity(processFlow, "List: Items"), "PartitionContent", STAT_CURRENT, current, token.PulledQueue) == 0

Same as trueQueueSize explanation. Needed to know if there was an available item in the queue, more than if there was one just present, because it might have been pulled already.

In your attached model, you didn't include the decide to see if the queue was empty, which means you also don't have the connector that the max wait timer is looking for on the pull from the item list, or the connector needed to continue pulling items from the List.