Decide by label

[simon_s5]

[ FlexSim 21.0.10 ]

Hello,

I have trouble on the last decide step in process flow and would appreciate your help.
After a grey box has stopped and the delay has finished I want to stop a brown box (Label "Type" 0).
For some reason it does not work and a error message appears.

Besides that, could you tell me how to simplify the process flow without "decide"?
How can I add a if-condition to stop a box with a certain label? Mabye with custom code?

Thank you!

decide.fsm

[kavika_faleumu]

Hey @Simon S5, from what I understand, you want gray boxes to stop at the first Station and brown boxes to stop at the second Station? If so, then here's an example of what you could do.

I have an Event Triggered Source that makes a token when a box appears at Station1. I decide whether or not it's a Gray box. If so, then I run a subflow (if you're familiar with programming, it's like a function or method) that stops the box, delays a certain amount of time, and then resumes the box. I then check to see when the box reaches the second station. If that box is brown, then perform the stop, otherwise we're done!

Hope this helps.

decide_1.fsm

[jonah_kendellR47TC]

You can simplify the process by using a variable. If you want to alternate which box you stop on the conveyor, you can use the process flow in the attached model, shown here:

This still uses a decide activity, but in a much more effective way. If token.type==token.variable (i.e. the last token type that was stopped), then it will throw away the token, and the items will keep flowing. Once you get a token.type that doesn't equal the previous token.variable, it will Stop the item, Delay, Resume, then set the variable to equal the current token.type.

AlternatingStopping.fsm

[simon_s5]

Thank you @Jonah K and @Kavika F. Both examples gave me new abilities.

My intention is to stop a grey box (label type 1) at first. Then the station is occupied for a amount of time. That's why I defined the label "state" on the station and gave it a delay. When occupation has finished a brown box (label type 0) has to be stopped. After that the process starts again.

Station 2 should do the same. Later I will just choose different delay times in comparison to Station 1.

[jason_lightfoot_adsk · Accepted solution]

What you're describing doesn't need a process flow - you can set that behaviour on the station process condition:

decide_jl.fsm

If you intend to only process unprocessed boxes then you can record that on the box during the process finish trigger and include that test in the process condition.

You can do the same seem in a very simple object process flow with both stations as members:

decide_jl2.fsm

[andrew_o2]

Hi @Simon S5, was one of Jonah K's or Kavika F's answers helpful? If so, please click the "Accept" button at the bottom of the one that best answers your question. Or if you still have questions, add a comment and we'll continue the conversation.

If we haven't heard back from you within 3 business days we'll auto-accept an answer, but you can always unaccept and comment back to reopen your question.

[simon_s5]

Thank you @Jason Lightfoot ! In comparison to your example I want that the material flow keeps running. It is a loading and unloading process of carriers. In the file attached decide_2 I achieved my latest target for one station.

brown: empty carrier
grey: carrier with unprocessed workpiece
blue: carrier with processed workpiece

My next target is to utilize several similar stations like in the file decide_2. My only idea how to do this is copying the existing process flow and connect it with station 2,3,4,... Do you have another idea how to multiply or how to optimize the process flow?

decide_2.fsm

[jason_lightfoot_adsk]

Don't do that.

We should try to define the generic process for all homogenous stations and model it once - then have all stations use that single process.

You now only have one station in your model. How are your stations connected? Does an item visit each station in series and each performs an operation? How many steps to the process are there and how does each station decide if it is doing something to the arriving items?
From your description so far we cannot glean the actual process definition, so it would be good to know what's being done here (industry and product may help).

Also note that you have a test of the workstation is free on arrival. If the station is not free, you should not be able to reach it, so would not be able to generate an arrival event.

Lastly - instead of representing the carrier condition by color, it would be nicer to have the carrier show what it contains (if anything) and have the process step/state of the part shown as the color. The carrier is passive in my mind.

[simon_s5]

I would prefer to model it only once. For the source I tried to choose as object "group: stations", but that didn't worked...

The stations are in a row like in the picture. Later it will be like a baggage carousel. Gray coloured items should stop only at one station when it's free and not at each station in series. In short, every station does the same:

1. when station free, stop grey item for some seconds (unload carrier)
2. station blocked for a amount of time, conveyor keeps running (processing outside conveyor)
3. after blocking time stop brown item for a some seconds, make it blue and resume (load carrier)

The blue item should not stop at a following station. It's finished.
The only difference between the stations would be the processing time.

The product is a wheel which moves on the carrier in a circular conveyor. It is removed by hand to do an assembly step outside the conveyor. When assembly is finished it comes back on a random empty carrier. Later the finished wheel will leave the circular conveyor.

I agree that it would be nicer to see the wheel lying on the carrier.
But as a flexsim beginner I haven't yet achieved the ability to do that.
For testing different process times or amount of stations the workaround with coloured items would be sufficient for me.

[jason_lightfoot_adsk]

Here's a model with the way I would approach it.

I have a loop with a source to introduce carriers (x12).

There are three sations types Load x1, Unload x1 and Process x8, each with a process flow of which they are an attached object (instance).

I used a group containing the processing stations to populate a list which has to have an entry in order to load a carrier. When a wheel is finished the station pushes a value onto the list again (it doesn't matter what that value is - we just need to know how many are available).

The state of the station is not required to be tracked using this technique since it only waits for a carrier when it has finished a wheel and now needs an empty carrier, or when it is ready to do another and needs a fresh wheel. The decision logic in each process tests for the appropriate carrier state: empty, contains new part, contains finished part. The finished part is identified by testing for the Color.blue. It could also be a label you set on the wheel.

CarrierWorkpieceStationLoop.fsm

Future: you could move the wheels into processors instead of 'parking' them above the station like I do - I'd use a pointer label (e.g. called 'processor') on each station telling the process which object to move to by the expression current.processor for example. You would then also wait for the processor to finish processing instead of using the process delay in the current process flow.

[jason_lightfoot_adsk]

A version with better wheel positions while processing:

CarrierWorkpieceStationLoop2.fsm

I've noticed that the 'opportunistic' approach in the model at the moment doesn't supply some of the stations with wheels after a while. It may be improved with a different configuration or by assigning the wheel to the station when loaded onto the carrier and only allow it to be process there.

[simon_s5]

Thank you Jason for your detailed answer and example! This definetly helps.