Process Flow label assignment errors

Question

question

Aidan W asked May 18, '21 Eric M commented May 20, '21

Process Flow label assignment errors

Attached is a very early version of a model that I am creating that is intended to replicate an assembly floor where many different types of parts are made and each has different assembly, test, process, and inspection times (as seen in the PartStandards Global Table). For the sake of baby steps since I am pretty new to Process Flow, only a few part numbers are being created in the source at the moment. What I intended to happen was each item that is created at the source goes into the first queue, where the process flow assigns a TaskSequence to it that is meant to 1). claim a processor, 2). assign necessary labels, 3). move part to station, work part (using delay), then move to next queue, and 4). free up processor and rinse and repeat sequence.

The source currently assigns labels on the parts that come in based on their ItemNum (what I'm having errors with) and their Test Rig assignment (problem for down the road). What I wanted to accomplish was through the use of Assign Labels, I wanted to take the ItemNum that was assigned to each part and in turn assign it to the token of concern, then by using that ItemNum use a Global Table Lookup to find the associated AssemblyTime with that ItemNum. That way in the delay step I could simply reference the token's AssemblyTime and it would know how long the part should be taking and therefore how long the operator must wait. However, upon running the simulation, the console is swamped with Invalid Row Identifier errors for the label assignments so I must've implemented my idea incorrectly.

How can I go about accomplishing my idea? Am I misusing the label assignments or is there a different approach I could take to reach the same goal?

Also one final note, I have no way of currently telling if it happens, but I would like that if an operator does not finish their part before their shift ends, the next shift workers will pick up where they left off. Any tips on accomplishing that (or just letting me know if my current system should accomplish that) would be appreciated as well.

AssemblyFloorUsingProcessFlowV2.fsm

Software Version:

FlexSim 20.2.3

process flow flexsim 20.2.3 assign labels

assemblyfloorusingprocessflowv2.fsm (103.5 KiB)

5 |100000

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

Answer 1 · 2021-05-18T20:28:18Z

Eric M answered May 18, '21 Eric M commented May 20, '21

Hi @Aidan W, here's what we were able to come up with based on the model you had uploaded previously. Let me know if you have any questions about how it's working. This model uses the ItemNum label created on the items to assign the processing time (however, I did notice some discrepancies between the PartNum and ItemNum between the global table and the source that you may want to double check).

I'm still trying to find solutions to stop the processors between shifts and assign a new operator to help process. The way it is now, the old operators leave and the processor keeps going. The new operators don't walk over until the items are done processing. This shouldn't change the results for the weekday shift changes (other than visually) since the processing shouldn't stop between those changes anyway. The problem is on the weekends since the items shouldn't be processed continually then. To get around this for now, I added a time table for the processors to make sure they stop when it's the weekend, but I'll keep thinking about it and see if I can come up with something better for both the weekday and weekend shift changes.

assemblyfloorusingprocessflow-em.fsm

assemblyfloorusingprocessflow-em.fsm (108.0 KiB)

· 8

5 |100000

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

Eric M commented · May 18, 2021 at 10:21 PM

Here's an update where I followed this post to get the shift changes to be handled correctly. An acquire resource was added to the process flow to make sure the operators finished their current box before getting the next box (since the subflow is being initiated by Queue1 there were issues without it). The processors use the "Multiple Teams" to select the operator which I believe is why the operators need to be connected to the dispatcher in two directions. This essentially allows them to hand off their old task to the dispatcher to be reassigned.

assemblyfloorusingprocessflow-em1.fsm

0 ·

assemblyfloorusingprocessflow-em1.fsm (109.6 KiB)

Aidan W Eric M commented · May 19, 2021 at 01:04 PM

Could you explain the difference between what is going on in the General Process Flow and the Sub Flow in the example model you created? Are both in use and if so what triggers the Sub Flow to be initiated?

0 ·

Eric M Aidan W commented · May 19, 2021 at 02:39 PM

The general process flow is just what you had uploaded previously with the sources disconnected. It's not doing anything since it's not connected, but that way you still have access to what you had done before.

The sub flow is created at Queue1 under the Use Transport section. When a port becomes available (since send to port is set to first available), it will create a token in the sub flow. Using a wait for event activity would work as well, but the sub flow comes with a lot of default labels which is convenient.

0 ·

Show more comments

question