Attaching/Detaching appearances based on state

Recently we are seeing issues with the classic material flow. In particular the attach event is not working although it is properly defined. After spending quite a lot of time debugging it became clear that the problem is not with the attach event itself but with the material flow links. There are cases where the link is there but due to the specific ordering of the operations the appearances are passed around using a wrong instance of the link and this leads to a situation where appearances cannot be found and the attach event fails ... how on earth is this possible?

I think this has something to do with the material flow operations running concurrently instead of sequentially. In this case the results are undefined. We see customers using logic blocks that control the operation start signals but they hardly take care of operation sequencing. Then they open a PR.

Leaving aside this issue, my personal opinion is that the attaching/detaching action should not be based on time (like it is today). It should be based on state.

For example:

1. If you set the attach event at time zero of the operation, isn't it better to say that the attach should happen when the operation starts?

2. If you have a sensor, isn't it better to do the attach when the sensor detects a part?

3. If you work with complex conditions (expressions), isn't it better to have the part attached when the conditions are met?

There are endless use cases for attach/detach that will be much better done if based on state. After all the simulation is a state machine. The states can be related to time. Time is relative. Why use time at all?

With the script this is even more evident. The script can easily work with states. The only issue is: How to identify the part appearances that have to be attached/detached?

This is a big problem actually since appearances might be created by a script or by the classic material flow. They can appear/disappear based on logic. So if I want to make a script attach/detach appearances I need a way to discover the live ones first and this involves some heuristics.

Which ones should I choose? The nearest ones probably? Still I cannot be sure that these are the appearances that I need.

It seems like this would only be possible if the use case ensures that either there is a single appearance to be attached/detached or there is a well known number of appearances to be attached/detached. In cases where there are many random appearances to be attached/detached we cannot rely on a script to choose the right ones.

With this presumption in mind I've introduced two new SCL functions under a feature toggle (SCL_ATTACH_DETACH) in version 2509:

1. ATTACH_PART_APPEARANCE(PART:STRING, MAXPARTS:DINT):DINT

   when called the function attaches the nearest N appearances to the resource that has the script. returns the number of appearances actually attached.

2. DETACH_PART_APPEARANCE(PART:STRING, MAXPARTS:DINT):DINT

   when called the function detaches the nearest N appearances from the resource that has the script. returns the number of appearances actually detached.

   
   

   To show the usage I will present a possible solution to one of the PRs related to

   material flow links. The issue was: A lift cannot attach a set of part appearances for no obvious reason. To solve the case I just put a script on the lift's end effector. The script is triggered by the start signal of the operation dedicated to the lift.

   

   Now it works. Who cares of non working material flow links :)

   
   

   Imagine if the lift had to pick a number of stacked (one over another) part appearances.

   How would you do it? Just set MAXPARTS = to the number of stacked parts.

   We can also add a parameters to override the resource location and the detection range.

I believe these functions will make our life easier in cases like this.

Try them!