Transport links (vcTransportLink) are between transport nodes (vcTransportNode) and are defined in vcTransportSystem.
Each transport link has an associated transport controller (vcTransportController) and any number of custom properties added by that transport controller.
Process executor behaviour (vcProcessExecutor) is associated to a transport node via property.
Multiple valid paths of transport links (transport solutions, vcTransportSolution) can exist between transport nodes, so in general case you can’t know how the product will get from process to process. The transport solution is decided by the sending side (usually TransportOut statement) and assigned into the product (vcProduct). Then the product is given to the starting transport node to send out, which gets the first transport link from the solution and calls the corresponding transport controller to come get the product and move it to the next node in the solution.
Along the way, the transport solution can be altered if necessary as long as it reaches the original destination node eventually. In practice layouts are not really modeled this way, instead preferring simple single-link solutions between processes.
First you would need to know the product instance(s) (vcProduct) and from there you can get the current transport solution (vcTransportSolution) which contains transport links. From the transport links you can get the transport controller.
Then you would need to assume it is a PythonTransportController and that the robot transport controller is modeled such that it is a base component onto which the controlled robot is attached. The processes are not meant to know or care about any of these things, as these are internals of the transport system.
However, using those process handler statements with PM is a very hacky way of doing things and especially if you going to mess with the transport system too. You would need to somehow communicate about the products to your script, and there aren’t really any good ways to do that. Assigning value to a “known” component property before calling the process handler could work.
Well, you can’t just override the robot’s movements at random point in its program, all users of the robot must collaborate so everybody gets a turn to control the robot. The only really generic way to achieve this is to let the robot go idle (leave main program), and then the next user can do something with it.
There is Python API (idle event) for this kind of collaborative use of a robot between Python scripts and PM run robot routine calls.
I don’t know what you are trying to achieve exactly, but sounds like it would be easier if you just copy the robot transport controller component and add some features to its scripts. You could then give it custom commands from processes by e.g. sending string signals.
it’s not possible to let the robot go idle with a grabbed product but I have to make a custom (generic) producthandling during the transportation! → Do you know what I mean?
I have to make a custom (generic) producthandling during the transportation!
If you want the robot to do something special while handling transport requests, then I think you will need to either:
Use the existing functionality in the robot transport controller to record and modify the robot programs used for transport.
If that is not enough, modify the transport controller’s code to include your custom stuff when it commands the robot to pick, move, place etc.
The robot transport controller could probably also be modified such that it will let the robot executor idle (clear the executor stack) at certain points of transport and then continues (jump the executor to next statement before idle), which would allow injecting some routine calls with the run robot routine statement.
I want that when the robot have picked the product over the PM-Magic after TransportOut do some custom movements over pythonScript (with the picked product) and when I’m finished the transport should be finished over PM-Magic!