Dynamically adjust the number of cars in the circle

[a9080109]

@FelixMoehlmann 

I have several logics I want to implement now!!

1 For example, I need to keep a fixed number of vehicles in the loop. When the car enters the loop to load and unload, the newly entered car will squeeze out one of the cars in the loop (the new one will become a part of the loop). The squeezed car may enter someone else's loop or be pulled away to do tasks, etc.

2 There are some red CP points in my model. When a car enters, it will need to wait for 5S
Actually, I want to make a switch (SWITCH) but I can't think of any way to do it
3. It's a bit similar to the first point, so what should I do if I need to keep the upper and lower limits of the empty loop (to avoid a circle full of cars or no cars)

For example, the maximum number of cars in the picture cannot be less than two and cannot be greater than 4. How can I control it?

[a9080109]

@moehlmann_fe 

HI 

I would like to ask if you have further thoughts on this question? I have made a similar concept but it seems not good to do it this way for every point?
Is there a better way?

[FelixMoehlmann]

Here's something I came up with.

I added a new CP-connection called "NextLoopPoint". (I could have also used an existing connection type, but I don't want to interfere with those, in case you choose to use the AGV Process Flow template for something.) The connection is really just a convenient way to define a loop of destination CPs.

Each AGV-token is assigned a CP in one of the loops as their default destination. It then creates a child-token that is responsible for having the AGV drive around. This tokens checks if the CP the AGV is currently at has a "NextLoopPoint" connection. If so, the AGV is send to the next CP via that connection. If not, the AGV is send to the default destination.

Each loop is enclosed by a Control Area with a maximum allocation count of 4. One of the loop-CPs has two "NextLoopPoint" connections. If an AGV arrives there, a check is made if there is a pending request for the Control Area. If so, the AGV uses the second connections to determine the next CP to travel to, which sends it to the other loop, freeing up a space in its current loop in the process.

Pulling an AGV from the list is also different. The list is divided into partitions, depending on which loop the AGV is currently in ("10" or "20"). The 'main' AGV-Token actually waits in the Push To List activity until the AGV is pulled. When this happens, it releases its child token to a sink, stopping the loop logic. When the task is finished, the AGV is not directly pushed back to one of the "active" partitions, but instead is pushed to partitioned defined by the pulling token. This lets the AGV-token now that the task is completed. It then loops back up, creates a new Loop-Token and pushes the AGV back to either the "10" or "20" partition, depending on what the CP the AGV is currently at (the Loop-CPs all have labels that denote what partition they belong to).

[a9080109]

I have some ideas about split switch. But my question is that if I have many CP points that are split switch, my method will be useless. Is there a better way?

[FelixMoehlmann]

What is the purpose of the logic in your latest model? To send AGVs to the different paths in a "Round Robin" distribution?

[a9080109]

The purpose of this model is that when it reaches a certain point, it will be a bit like a switch in a train system in real life. It will turn my car to the left or right, just like the function I posted in the link below. I don't need to simulate the turning, but I need to take the turning time into consideration! There is no need to turn in the same direction, so there will be no delay.

https://youtube.com/shorts/CRgejv_hd2Y?si=Yh-H86s09KxArJwq

[FelixMoehlmann]

I would use a label on the switch-CP to keep track of which direction was last used. You can then listen for allocations of the next CPs after the switch. In the attached model I use a cp-connection to refer to these control points. If the allocated CP is the same as the last one,  the AGV can continue as normal. If it's different, the AGV is stopped for some time.

[a9080109]

I want to know how I can use it? I added a point and connected it? But it won't have any effect.

[FelixMoehlmann]

The AGVs do need to actually travel through the intersection to an effect. One of them currently just stops ahead of it and blocks the second one.

[a9080109]

@FelixMoehlmann

What I want to do now is as follows:
When the car performs a task, it will go around a maximum route (maybe a preset circular main route?).

On this large route, the car may be pulled away by certain loops, which means that they may be led into some branch lines or small areas for branch detours (there will be a limit on the number)

Even if the car detours in these loops, they can still take on new tasks and be considered detours.

Let me explain with a picture. My current model has five cars circling. When it passes the blue dot, it will ask if the number of cars in the circle meets the requirement (for example: two cars). If there is no car in the circle, it will circle back!

[a9080109]

The difference is that the judgment is based on the total number of cars on a few sections of road!! Because sometimes the road may be winding, the control area may not be universal

[a9080109]

Start at "Have Task" Decision

• If there is a task (T) → go to "GO TO Destination"

• If no task (N) → go to "Go to loop" (AGV enters the standby area)

---

GO TO Destination

• Execute dispatch or move to the target location

Then proceed to the decision point → "Decide Max Context" (check for overload)

---

Decide Max Context (Determine max capacity)

• If the number of AGVs in the target segment or area is less than the capacity (less) → continue executing "GO TO Destination"

• If overloaded (over) → execute "Go to Retry" to reattempt entry

---

Go to Retry

• the agv will go around to try to again enter

• Then return to "GO TO Destination"

---

After completing the task → "Finish Task"

---

Finish Task → "Check Small Loop Have Space"

• If there is space (T) → execute "GO TO Small Loop" to return AGV to the standby loop

• If no space (F) → return to "Go to loop" to wait

---

Go to Loop → "Ask Small Loop Have Space"

• If there is space (T) → "Go to Small Loop"

• If no space (F) → return to "Go to Loop" and continue waiting

---

Go to Small Loop → finally return to the initial state and wait for a new task

[a9080109]

@moehlmann_fe

I updated my model. The problem I'm having is that I seem to encounter an unknown error. I can take on tasks but the token doesn't disappear from my small loop, which causes my model to go wrong!

[FelixMoehlmann]

I would still use cp-connection as I initially suggested. The CPs with two connections at the entrance to the small loops could have labels that denote the current and maximum count of AGVs in the small loop. Based on those an arriving AGV either enters the small loop or continues along the main one.

[a9080109]

Could you please teach me how to make good use of these models? I think it can be a template. I have a similar problem and I just put it into the problem, but my problem now is that I can't make good use of it. Could you give a more detailed introduction and instructions for use?

[a9080109]

I also want to ask how to adjust the number of circles. I don't see any relevant settings here. by the way (The CPs with two connections at the entrance to the small loops could have labels that denote the current and maximum count of AGVs in the small loop. Based on those an arriving AGV either enters the small loop or continues along the main one.) I don't know where in the model this sentence is implemented

[FelixMoehlmann]

The connection is really just a way to get a reference from one CP to another. Most of the CPs with a connection only have one and they form a loop. This allows the AGV to follow the loop defined the CP connections.

Some CPs (the ones in front of entry points to a smaller loop) have two such connections and two labels. If the "LoopCurrent" label value is smaller than the "LoopLimit" label, the second connection will be used to determine the next destination, so the that the AGV enters the small loop. Otherwise the first one and the AGV continues along the main loop.

The Process Flow works like this:

At the start of the model, a token is created for each AGV. These then create a sub-flow token that is responsible for having the AGV travel along the loop. Afterwards the AGV is pushed to a list (made available to be pulled for tasks).

The first thing the sub-flow token does is to search for the next "Loop-CP". If the CP the AGV is currently at ("AGV(token.OHT).recentCP") has at least one loop-connection, it can follow the connection (blue). If there are two connections, the aforementioned labels are checked. If the AGV is then diverted to the smaller loop, the "LoopCurrent" label on the CP is incremented and a reference to the CP is written to the label "CurrentLoopCP" on the AGV (green).

If the current CP does not have a loop-connection (either at the start of the model or after finishing a task) the code loops through all CPs belonging to the main loop. They are identified by being part of the "MainLoopCPs" group. It then chooses the one closest to the AGV as the next destination (pink).

This gets repeated after the AGV arrives at the next destination. The travel task uses the "TaskExecuter.MaxEndSpeed" expression for the end speed field. This means that the travel task will finish when the AGV would start to decelerate in order to come to a stop at the destination CP. If a new travel task is given to it immediately afterwards, they don't have to decelerate at all and keep travelling in the loop at full speed.

Now let's go back to the "main" token. When the AGV is pulled from the list, the token checks if the AGV has entered a small loop in the meantime, meaning the "CurrentLoopCP" label would be set. If that is the case, the label on that CP gets decremented again, since the AGV is now assigned to a task and as such does not count as "in the loop" anymore (at least that is what I assumed). It then releases the sub-flow token to a sink activity. Then it waits until the token that pulled the AGV is put onto a list to denote that the task is completed and the AGV should resume the idle travel. 

So overall this logic assumes that there is one big main loop with smaller loops around it. To add more small loops, just draw the necessary connections and add the labels as shown in the first screenshot to the CP where an AGV would get diverted to the small loop.

[a9080109]

In addition, I have added s

ome functions to the same model, but the area in the picture cannot be executed smoothly. I want to know what happened.

[a9080109]

In addition, I adjusted the location of the goods, but many more problems came out. How can I solve them?

[FelixMoehlmann]

Frankly, I don't know why you would expect that model to function. 

- The connections don't form proper loops, there are some deadends.

- There is only one CP with two outgoing loop connections and it does not have the necessary labels.

- You did not remove or deactivate your previous logic for idle AGVs.

- At the intersection you show in the screenshot, AGVs can't even drive straight on.

In the other model (0709test), you get an error telling you that the label "Type" does not exits on the items. The custom control area logic you copied to the "Basic Processor" flow needs that label because in the model it was developed for the priority of AGVs was determined by what they have loaded.