question

Raashid Mohammed avatar image
0 Likes"
Raashid Mohammed asked Adrian Haws edited

Only Two Operators loading and unloading

In my model I'm creating boxes in two separate queues (a1 and b1). Then I'm acquiring operators from a group, who load from the beginning queue and unload to either queue a11 or b11. As the tokens loop through, a label called "pick" is incremented. Once the value for "pick" is the same as the number of boxes assigned I'm releasing the operator out of the loop.

The problem is that I want only two Operators loading and unloading at each pair of queues. There are a total of six operators. I want the other two operators to wait if there are already two operators working on each pair of queues. What's currently happening is that one of the pairs of queues has four operators loading and unloading, and all six operators are being utilized.

What I'm trying to model is that I have an empty trailer in a dock with flex conveyor. Only two operators at a time can load from flex conveyor and unload on trailer. Each trailer has a certain number of boxes

Choose One
process flowresourcescheduletask sequencespick
model5.fsm (25.7 KiB)
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Adrian Haws avatar image
2 Likes"
Adrian Haws answered Raashid Mohammed commented

Raashid,

You mentioned a few specific things that need to happen in your model:

  • Up to two operators work on each pair of queues
  • The number of total operators available varies
  • If there are more boxes to unload, more operators are needed

I created an example model to accomplish this, so I'll explain how it works:

  1. I added a couple MTBFMTTR tables to demonstrate operators going on and off shift. Each operator has a label called "opAvail" that is originally set to 1. When an operator goes off then back on shift, that value is changed to 0 and 1 in the breakdown table (with custom code).
  2. Boxes are initially created with a schedule source, assigned to a queue, then pushed to an item list. An event-triggered source then pulls from that list and is directed in the flow depending on which queue the item was created in.
  3. The maximum amount of operators at each pair of queues is defined by the max content of zones.
  4. The operators in use are determined by a series of lists. The token first tries to pull from a smaller list for that pair of queues. If there aren't any operators available there yet, it will pull from the global Task Executer list called "Operators", which has an initial content of the group of operators and acts like a "Resource". Once the task sequence is done, a "Decide" will see if the operator is still available (by looking at the label "opAvail". If it is, the operator will be pushed onto the specific list for the pair of queues. If not, the operator will be pushed back onto the "Operators" list. The way the lists are set up ensures that the operators aren't constantly switching between different queues.

There are several small details that are necessary to make to model logic perform correctly (mostly just in the Process Flow) but overall it's fairly simple. Take a look at the model and let me know if you need clarification on anything. It shouldn't be too difficult to expand this model to fit your needs.


· 12
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Adrian Haws avatar image
1 Like"
Adrian Haws answered Jeff Nordgren edited

Hi Raashid,

There are multiple ways to accomplish what you're describing. I chose to make three different resources connected to separate groups of two operators each. Then I placed a "Decide" activity after the "Assign Labels" to go to a different "Acquire" activity based on the Queue assigned to the label. Let me know if I misunderstood what you're trying to do.

See attached updated model.


1851-model5-1.fsm (27.7 KiB)
· 7
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.