linking two transporters

Hi everybody,

I have got some boxes which are transported by one transporter and some which are transported by two:

In some way, I need each one of the transporters to know who is its collaborator for delivering a box.

if anyone of them failed and goes in break the other also needs to stop, if one goes in degraded mode when one or more of the wheels fails both operate with lower speed etc.
In fact, my transporter is a new generation of AGVs where two AGVs combine and transport a box and the box is loaded on both of them. When they delivered then the separate again and so on.

There are a lot of issues here but the main questions are the following:
1) how to keep both transporters aware of their partner. I use coordinated task sequence for doing what my an optimization algorithm says. The ideal is that I can add label to each one and introduce its partner and when it arrives to destination then the labels are deleted. This does not work!

2) what is a better way to do this?


Any constructive comment appreciated.

regards,

Hi,

Take a look at the command createcoupling, think that will help you for question 1.

Lars-Olof

Hi,

insert in the standard coordinated tasksequence a sendmessage task with involved 1 and 2 as NULL. So each Taskexecuter send a message to himself.
OnMessage you can querry the active tasksequence to find the node to the whole coordinated tasksequence. In that tasksequence you can look for all tasks with an allocate tasktype and querry for the second involved parameter. That is the allocated task member. If the member is not equal to the owner of the message trigger than that is this a further member of the coordinated tasksequence.

following is the code for the message trigger and the coordinated tassequence example 2 with a sendmessage task

/**mutual member of coordinated task*/
treenode current = ownerobject(c);
treenode ts = gettasksequence(current,0); //Use TE ALLOCATE TASK
treenode task = gettaskinvolved(ts,1,2);// involved path to the task in the coordinated tasksequence
treenode ct = up(task); // node to the whole coordinated tasksequence 
for (int index=1;index <= content(ct);index++) // look for another ALLOCATE task
{    treenode mbr = gettaskinvolved(ct,index,2); // possible member
    if  ((TASKTYPE_CT_ALLOCATE == gettasktype(ct,index)) && !(tonum(current)==tonum(mbr)))
    {
        pr();
        pt(getname(mbr));
    }
}

Jörg

Thanks for the comments.

@Jörg,
let me explain the story further as follows:
when a box is generated and the process is finished then onProcessFinish executes a coordinated task sequence where depending on the size of box it calls one or two transporters bring it to a crane and ask the crane to discharge it (3 task executors involved in the same coordinated task sequence).
Now, there is also another MTTR/MTBF element which injects random faults on every single transporter.

When the fault occurs the the break triggers in MTTR/MTBF is called. Here we need to see if there is another collaborating transporter which must be stopped or not.

here, I have difficulties to understand how to use your idea to identify the collaborating transporter and stop it.

Thanks a lot

Hi Shahin,

I'd like to share my ideas about your modeling problems with coordinated task sequences (cts).

I-Problem with labels
To be sure that the labels on a transporter are not overwritten until the delivery is completed, you have to follow point a) and a) below :
a) Set the label value by the transporters themselves from within the cts. This will initialize the labels only when transporters are newly allocated as oppose to when the cts is created. You can do this with a sendmessage. For example, if I use the dispatcher to handle the messages (call it TrspDisp), then the cts would start like this

...
trsp1key = insertallocatetask(cts, TrspDisp, 0, 0, 0);
trsp2key = insertallocatetask(cts, TrspDisp, 0, 0, 0);
// identify my partner
insertproxytask(cts, trsp1key, TASKTYPE_SENDMESSAGE, TrspDisp, NULL, 1, tonum(cts), trsp2key,0);
insertproxytask(cts, trsp2key, TASKTYPE_SENDMESSAGE, TrspDisp, NULL, 1, tonum(cts), trsp1key,0);
// store my destination
insertproxytask(cts, trsp1key, TASKTYPE_SENDMESSAGE, TrspDisp, NULL, 2, tonum(dest),0,0);
insertproxytask(cts, trsp2key, TASKTYPE_SENDMESSAGE, TrspDisp, NULL, 2, tonum(dest),0,0);
// store the item type of the box
insertproxytask(cts, trsp1key, TASKTYPE_SENDMESSAGE, TrspDisp, NULL, 3, getitemtype(item),0,0);
insertproxytask(cts, trsp2key, TASKTYPE_SENDMESSAGE, TrspDisp, NULL, 3, getitemtype(item),0,0);
// and so on
...

and the message trigger in TrspDisp would look like this

...
treenode trsp = msgsendingobject;
int msgcode = msgparam(1);
if (msgcode==1) // store my partner id
{
    treenode partner = getallocatedfromkey(tonode(msgparam(2)),msgparam(3));
    setlabelnum(trsp, "PartnerID", tonum(partner));
}
else if (msgcode==2) // store my destination
    setlabelnum(trsp, "Destination", msgparam(2));
else if (msgcode==3) // store box information
    setlabelnum(trsp, "BoxType", msgparam(2));
...

also do not delete the labels once at destination. Just reset their values and reuse them over and over.

b) Make sure transporters are not preempted away by the allocate task from another similar cts. To achieve this, the allocate tasks should look like this
trsp1key = insertallocatetask(cts, TrspDisp, 0, must be 0, zero or one); // no preempt
or
trsp1key = insertallocatetask(cts, thistransporter, 0, must be 0, zero or one); // no preempt


II-Dynamic transporter routing
You have to be careful if you externally (outside the cts) make a transporter travel from one networknode to another one while the transporter is allocated in a cts. Without more information, I would suggest to use a tasktype callsubtask in the cts and do all your dynamic routing within the callsubtask so you don't have to preempt the transporter to make it travel or worst, preempt and abort. Preempting the transporter for traveling and for breakdowns will make it difficult to control in the cts.

Normand

Normand, thank you indeed ---very much appreciated.

Normand, Concerning the routing:
In routing transporter arrives at every intersection in the transportation network and upon arrival and based on the current state of traffic etc decides where to go afterwards,
How does one manage this using subtask?
is there any way cleaner/better than doing nested or perhaps recursive calls to subtask?

Thank you

Shahin,

I was thinking of subtasks as a way to travel from point A to point B, to point C up to destination without preempting the transporters (using nested subtasks).

But I'm realizing that you can reroute a transporter within the OnArrival trigger of a Networknode by simply returning the desired edge number. This is managed internally by Flexsim during the travel task and without any preempting. This will do what you want .

Regards,


Normand