Transporter Movement

Question

question

rhorn2 asked Jan 17, '23 rhorn2 commented Jan 18, '23

Transporter Movement

I have a 3D flow model showing movement of items from source to transporter.

The source creates an item (sheet of glass) every 68 seconds to go to first queue. In the first queue, I've asked it to perform batching of 14 items (14 sheets of glass) with a max wait time of 940 seconds (15m40s). Each batched item should proceed to the first processor which will take 45 seconds (accounting for placement of styrene by an operator on the front of each pack of glass with 14 sheets inside said pack). The processed, batched item then goes to the second queue to be batched into 6 with a max wait time of 5640 seconds (6 packs at 14 sheets each onto a moveable frame/stand, which should finish at around 94 minutes). Said item should then go through the second processer at 60 seconds (turnaround time of the stacker cell). In theory, the transporter should then pick up the stand of finished packs to deliver to a put away location/area.

So here are my questions:

1) Is batching the correct function when wanting to put items together via queue or should a combiner be involved somewhere in the process?

2) Should a queue be created for staging/pick up by the transporter or can it pick from the processor itself?

3) From my initial training, I did not do much with transporter 3D models & I am unsure if I have set up all parameters correctly so that said transporter A. knows to pick up from the processor or queue; and B. go to the correct location for drop off/unload after pickup. Currently I have load & unload times set up for how long a pickup & drop off should roughly take. Do I need a task executor or dispatcher to get the transporter to follow directions?

Attached is my model currently.
Any help with my questions would be appreciated. Thank you.

Model 1 v1 Carleton.fsm

Software Version:

FlexSim 23.0.0

batching order batching batching grouping transporter movement

model-1-v1-carleton.fsm (42.7 KiB)

Answer 1 · 2023-01-18T08:19:14Z

Joerg Vogel answered Jan 18, '23 rhorn2 commented Jan 18, '23

General remarks:

If you batch items and such a batch is not split up again later, then you are better of with a combiner in join mode. You have only item then. You can keep data in labels. Then you are still able to build statistics just from those values.
if you need items later as single items then you use pack mode. It results in container structure. A container with subnodes of items. The container is your reference that gets a reference of item in triggers or events in process flow.
If you want to collect items and process them in a batch mode, then this is completely collectIng them in combiner. The processed items are processed together and ready ready to exit simultaneously, but they are still single items then.

In 3D Model a Transport of items is a supporting Process. It moves items by spending time on travel to different objects. Primarily it is a transport of one item at a time. An involved object is called in general a taskexecuter. A taskexecuter can transport more items at once. BUT each loaded item has got its own transport job called a tasksequence.
If you combine items in join mode this makes it simpler to transport such a batch because it is just one item. A packed item behaves equally.
A batch of 12 single items gets complicated, because of 12 individual transport jobs executed simultaneously in a taskexecuter. Loading and Unloading is LIFO mode by default.

Please repeat tutorials of transports for basic 3D modeling. You will see that you build a material flow by object connections. Then you add an operator to your model, which gets a center port connection to an 3D object. This is just a simple reference connection. You activate in properties of the sending object the option Use Transport in Output pane. There is set by default a reference to first center port connected object to do this transport job. If you let run your model, the transport is done. FlexSim creates in background automatically tasksequences to transfer each item. FlexSim dispatches those tasksequences to referenced objects. The referenced object executes the tasksequences. All this is done by setting an option of Use Transport and a center port connection to a Taskexecuter which can be an operator, a transporter, an agv, or any other member of Taskexecuter class.

You can do the same in Process Flow. You do this by telling a referenced Taskexecuter every single step of an involved transport job:

travel to load station,
load item at load station,
travel to unload station,
unload at destination the transported item.

An automatically created tasksequence has got an additional task between point 2 and 3. It is an interrupt, which gets executed if the Taskexecuter has got capacity to load more than currently loaded items left. Then the default function “Break To” gets executed in the Taskexecuter, which normally searches for additional available transport jobs to execute as a next one simultaneously.

A taskexecuter can load more items, if there is enough capacity. And by default a taskexecuter loads as much as possible even from different load stations. This can be a wanted behavior, but if you want to restrict load stations then this can get complicated. And if this happens, then a process flow logic is a better choice.

Runtime and Sequence of executing tasksequences can result in strange behaviors. There is not an intelligence inside of FlexSim. Everything works with the paradigm of FIFO. If something is happening in a model and there is a sequence is involved, then this sequence of action is done to the end and then starts a next sequence. This means even if everything happens at the same time point there are many sequences of actions happening after another, and if inside of a sequence changes a value or a state, then this won’t changes an already waiting sequence nor push waiting sequences back to a later rank in the list of waiting sequences. This changed value or state is pushed to the last rank of waiting sequences. This seems complicated but it follows strict basic rules. And then it seems for a watching person that a model behaves strange.
In such a Case a Process Flow logic might be a better choice, too.

· 2

rhorn2 commented · Jan 18, 2023 at 04:07 PM

Thank you, Joerg.

I'm coming back to the transporter with your advice, but, for now, I am attempting to batch & join my items together. I cannot verify that the boxes in the final queue are anything but individual boxes.

I have taken the 68s on average from source (FL1) & split it in half with a processor. Indicating source as run of material to the line stopping & transferring the sheet of glass to a stacker/auto packer.

In Queue 4, I have set batching at 14 indicating 14 sheets indicate 1 batch/pack. I'm wondering if A) is batching necessary when the combiner would be joining the 14 sheets onto a container (in this case represented by a pallet); B) if batching is necessary for join option on the combiner, is the box on the pallet (or sometimes no pallet at all for some reason) meant to represent 14 sheets/1 pack of glass? If so, what is the point of batching & joining when the final container for movement needs to be 6 packs at 14 sheets each on 1 container?

Basically, I'm stuck on batching then joining being the best option or if I should switch the combiner to packing & have 14 sheets (shown as boxes) onto 1 pallet, and then having a 2nd combiner create a new container of with 6 pallets (packs).

I'm also, as you can see below the main model, starting to play with no queues till the very end. In other words, there is no staging or holding type area (queue) on the production line until the final container of 6 packs at 14 sheets each pack is complete and ready to move into the WH.Model 1 v1 Carleton.fsm

0 ·

model-1-v1-carleton.fsm (41.1 KiB)

rhorn2 rhorn2 commented · Jan 18, 2023 at 04:29 PM

Model 1 v1 Carleton.fsm

I think the 3rd example option (most bottom flow line from center screen) I've created in this model works best. I set the combiner to batch with no queue until after the combiner. That queue shows 14 boxes on a pallet.

0 ·

model-1-v1-carleton.fsm (42.7 KiB)

Answer 2 · 2023-01-18T08:27:41Z

Felix Möhlmann answered Jan 18, '23 rhorn2 commented Jan 18, '23

1) The Batching function of the queue only makes it so that the queue waits until the given number of items is present before it starts to release them to the next station. The item stay as individual objects. For your purpose it sounds like the "FL1Styrene" and "TransporterCell "processor should be replaced by combiners.

You would have to decide whether the "Pack" mode (keeps all items and places them into the first item) or the "Join" mode (deletes all but the first item) is better suited.

For more information about the combiner, see its reference page in the manual.

2) A queue is not needed, though be aware that the processor can not work on the next item until the previous one has left.

3) The processor does not know where to send the item next. You can either use an a-connection to the storage, like you have between the queues and processors. Or you can push the finished items to a list from which the storage pulls items.

The s-connection between the processor and transporter is actually redundant currently, since you specifically refer to the transporter in the "Use Transport" field.

The connection is only needed for the default option of using the first centerport-connection.

Another note: You wrote that the source should create an item every 68s. But in the model you are using a statistical distribution that has the queue create an item every 68s on average. Is this correct? Since this could lead to the batch not being full after the max. wait time.

model-1-v1-carleton_fm.fsm

1674030074918.png (2.4 KiB)

1674030093114.png (3.7 KiB)

model-1-v1-carleton-fm.fsm (43.4 KiB)

· 1

rhorn2 commented · Jan 18, 2023 at 04:08 PM

Thank you for your help.

0 ·

question