Takt time in an assembly line

[peter_w8]

[ FlexSim 22.1.1 ]

test_takt_time.fsm

I've built a simple model of an assembly line. The line has six stations and the flow items are transported by two AGVs. What I want to do next is to implement a takt so that no station begins work until all stations are ready to do so. In reality the assembly line works on a pulse, each station waits for the others before it releases its work and receives the next, this is what I'm trying to replicate. Is there an easy way to achieve this?

[jason_lightfoot_adsk · Accepted solution]

Here's a solution using a simple process flow and a group for the processors.

test-takt-time_jl.fsm

[peter_w8]

test_takt_time_pw.fsm

Thanks Jason! That was a way more elegant solution than what I came up with. I used a global variable for tracking the state of the stations and then an user event which checks if all stations are ready. It's apparent to me that I need to understand process flow better. I'm having a hard time of understanding what makes the link between a token and an object or flow item, in other words the interplay between processflow and the 3d environment.

[jason_lightfoot_adsk]

I'll share my thoughts on Process Flow in case it helps you.

I think there are a few challenges:

• Defining the process
• How to reference objects in the 3D world
• How to coordinate with or override default 3D object behaviours

To define the process, I consider how it would be documented without considering a simulation - in the real world. This can be a flow chart or a project/pert style diagram with process steps, decisions, predecessors, resources and other constraints along with any data structures needed. Once you have an idea of how that looks you can decide how to represent it in FlexSim.

First of all it's important to remember a token's primary function is just to track of the current step in a process, with information stored on it to use within that process. Sometime we use it to represent something abstract, like an order, that persists across multiple processes so care is taken to preserve that order token until it is fulfilled.

Choosing the technique to connect to the 3D world depends on what behaviour you're trying to achieve and how scalable/generic you try and make it.

In your case it was a system behaviour involving several objects so I put it in a General Process Flow and grouped the processors. This scales because you can add processors to the group and I've used the number in the group when I update the counters on the token. The connection to the model is through the Group and the detection of entry events within that group - the triggering object being added as a label on the token.

An Object Process Flow allows a behaviour to be invoked individually for each member of that flow with the advantage of being able to view the object's tokens in isolation and allowing you to use 'current' to reference the object throughout the flow (slightly cleaner expressions). Here the connection to the 3D world can be primarily through the member object and any information about its environment can be stored as labels on the object and accessed easily in the flow's activities using familiar FlexScript expressions: current.outObjects[1] , current.myLabel.

In both of the above types of process flow you can, in many activities still sample a physical object in the activity's input fields. When you do this it will usually just have one value. I've seen countless cases of people 'hard modelling' duplicated sets of activities that are exactly the same structure, but with different sampled objects. The time taken to do this and subsequently update them if you want to debug or alter the process is large and wasteful. Choosing an Object Process Flow where you can make generic references is critical for having an efficient and well-structured project. Note also that an object can be a member of multiple Object Process Flows.

If people find themselves duplicating the same set of activities and laboriously configuring them - they should consider how to just have that one set of activities and make them generic. We should only have to define a process once and then have many invocations of it (tokens or object instances).

There are tutorials on using process flows with 3D objects which should help with the last challenge of coordinating and overriding the 3D world.