Best Practices to exchange conditions to and from the plc with the robot

Ask Questions Mechatronics & Motion
5

Hello,

You descripe the typical issue of a synchronisation of the Robot to the plc.
You have a condition which will lead to a different behaviour. As we can not delete information in the motion-packet-queue jet, you need to wait until the descition is made, to start filling the motion-packet-queue. Meanwhile the rest movement is to short and the robot comes to a stop.

If you want to prevent the stops on the path you must know how the path continues earlier. To fill up the path bevor a stop is nessesary due to lack of rest path.

WaitALAP does not lead to a stop, but it releases often very erly as the robots are really fast. Once the Decceleration has startet we must stop (there are ideas to improve this).

WaitUntilSync does at every time introduce a stop on the path and has to be avoided as long as possible. That was why we introduced WaitALAP, to have a possibility to skip WaitUntilSync or similar in situations where the decition was made early enouth.

There is a abort, and replaning Feature in development, which can create some new Use-Case in considertation to lose Parts and don’t move ahead , instead replan and repic a new part faster.

Reading Variables is almost at any time interpreter-synchronous. And in consideration to decide path planing it must be interpreter-synchronous. To select the packets you like to put into the motion queue. (Motion Commands ST/G-Code)

Only the Write part of a Variable is influenced by its poperty “Path-Synchronous” “Interpreter-Synchronous”
If you want to use a Variable to Programm Coordinates for the next G-Code , it is important to use it “Interpreter-Synchronous” it is interpreted in the context of the interpreter and at the moment the G-Code line is processed by the Interpreter it has its new Value.
If you want to use a Variable to Programm a Valve-Command it has to be used as “Path-Synchronous”. The Valve must be operated in the Context of the Path-Generator. With the Setting “Path-Synchronous” the Variable gets processed by the interpeter, there is a motion-packet created and moved throught the motion-packet-queue. The Path Generator accesses this packet at the right time on the path and writes the Variable in the context of the PathGenerator.

If you want to prevent stops on you path this is i think the best approach to achive it right now (MappMotion6.5.0), to only hole in this aproach is that your decission has to be available early enought.

Wait as long as possible and decide

VAR {AT PLC} 
    Left : BOOL; 
    DecisionAvailable : BOOL; 
END_VAR 
 
VAR CONSTANT 
    P0 : McPointType := (Pos:=(X:=0, Y:=100)); 
    PLeft : McPointType := (Pos:=(X:=-100, Y:=100)); 
    PRight : McPointType := (Pos:=(X:=100, Y:=100)); 
END_VAR 
 
PROGRAM _MAIN 
    RoundingEdges(25); 
    Feedrate(1000); 
    MoveL(P0); 
    WaitALAP(); 
    IF NOT DecisionAvailable THEN 
        // optionaly move to a waiting position 
        WaitUntilFlush(DecisionAvailable); 
    END_IF   
    IF Left THEN 
        MoveL(PLeft); 
    ELSE 
        MoveL(PRight); 
    END_IF     
END_PROGRAM

And then there comes the discussion in which syntax you will program this or present this to a coustommer. There are options to use sub-Programs or the internal AIL to adapt the Code-Style. But i think this is not the scope of your discussion?

I am also interessted in others ideas to this topic, as it is a very interessting one.

Greetings
Michael

3 Likes