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