A* custom code problem

A* custom code problem

a9080109
Observer Observer
19 Views
9 Replies
Message 1 of 10

A* custom code problem

a9080109
Observer
Observer

[ FlexSim 20.0.10 ]

我之前有在另一個問題詢問過了,但因為檔案的問題無法解決,目前的問題是我不知道報錯發生的問題是甚麼。1659934941759.png

0 Likes
Accepted solutions (1)
20 Views
9 Replies
Replies (9)
Message 2 of 10

kavika_faleumu
Autodesk
Autodesk
Accepted solution

Hey @mark zhen, I found one of your problems.

In your AGV Process Flow, the "Custom 1Code" activity tries to call ".first" on a variable that is null.

1660085959851.png

The "paths" variable comes out null, meaning that there is no "travelPath" subnode coming from the agvNavNode variable. When I go to the "agvNavNode" location, this is what I get (it's referencing TaskExecuter2 in the error at 18 seconds).

1660086203936.png

You'll have to get the paths of the agv another way.

0 Likes
Message 3 of 10

moehlmann_fe
Observer
Observer
This looks like the code I provided in another question that was asking for prioritization on an AGV network. I thought it would be obvious that the same code won't work when using A*.
0 Likes
Message 4 of 10

a9080109
Observer
Observer

沒錯這是您之前回覆的問題,但我想要嘗試將兩者進行結合,這樣也方便在很窄的路上利用a*來進行路徑的計算可以不會有邏輯死結的情況。

0 Likes
Message 5 of 10

moehlmann_fe
Observer
Observer

I had a look at the model you uploaded to google drive in your other post.

The collision logic will work without the 'Custom 1Code' activity. It was used to determine which TaskExecuter would wait and which one could continue immediately (simulating the waiting one stepping out of the way).

The 'Ignore Inactive Members' setting is currently active in the A* navigator. So when a TaskExecuter gets stopped, it will deallocate its node which allows the other to continue.

1660199391557.png

If you still want to use the logic where only one has to wait, you could read the destination from the currently active task and make a decision based on that.

In the example below, the TaskExecuter that is travelling towards Queue1 does not have to wait.
Important: The destination is determined before the TaskExecuter is stopped (yellow)! The activity marked in orange then later checks if the destination is Queue1. If so, a delay time of 0s is returned.

1660199693008.png

I noticed two errors in the ProcessFlow:

- The order of the Push the List activities should be switched; the parking is only made available once the AGV is pulled by another task.

1660200022415.png

- The push values in both activities are not set properly. Those should be the respective objects (AGV, ParkPoint).

1660199988397.png

0 Likes
Message 6 of 10

a9080109
Observer
Observer

This is a bit too complicated. Could you please let me refer to your file?

0 Likes
Message 7 of 10

a9080109
Observer
Observer
@Felix Möhlmann !你能讓我參考一下嗎?
0 Likes
Message 8 of 10

moehlmann_fe
Observer
Observer

You can download the modified file here.

https://drive.google.com/file/d/1i94UTAguwRbFk0kJ1L3i-QKTbYYjTQGI/view?usp=sharing

Though there really aren't many changes compared to your version.

- Removed the previous custom code that used the AGV system
- Added the yellow Assign labels activity with the respective code (see last comment)
- Modified the orange activity by adding the marked code (see last comment)
- Switched the order of the mentioned Push to List activities

0 Likes
Message 9 of 10

a9080109
Observer
Observer
@Felix Möhlmann 我還有新增一個問題!再麻煩您有空幫我解答一下
0 Likes
Message 10 of 10

Jeanette_Fullmer
Community Manager
Community Manager

Hi @mark zhen , In reference to the original question, was Kavika F's answer helpful? If so, please click the "Accept" button at the bottom of their answer. 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.

0 Likes