The rules of the continuous kinematics movement command?

[KangZhihao]

I know that the kinematics can achieve continous motion by this command(ML_KinContMotionP).

The PLC program sequence is ① Wait for signal command ,ID=99; ② activate the continuous motion(ML_KinContMotionP); ③ move to position 100(ML_KinMoveLinAbs); ④ move to position 200(ML_KinMoveLinAbs); ⑤ set signal command ,ID=99,start the motion movement;

The PLC program is below:

And in this program, I can not get the continuous motion movement,the graph is below:

And I have found that if I write the ML_KinMoveLinAbs(D1) and ML_KinMoveLinAbs(D2) in the same step, I will get the continuous movement without speed down to 0;Like below:

I want to know if there are too many buffer ML_KinMoveLinABS commands to send, that I have to send them in several PLC cycle or steps, I can not get the whole continuous movement even if I have block the motion by wait for signal command( ML_WaitForSignalCmd)?

Or is there other solution to achieve what I want? By the requirement, the continuous motion commands are about 50 to 100, there is no way to send them in one PLC cycle.

[CodeShepherd]

At least the movement commands need to be in the buffer at the same time so a blending movement can be calculated by the motion. So first of all it does nod need to be in the PLC cycle but I would suggest you to do it for your case Otherwise the first command could already be prepared before you add the second one and so blending could not work.

In our template for handling applications we do this also via the MotionInterface.

[KangZhihao]

So I have understood that when the command is prepared,the blending movement between this command and next command is not available.  

I wanted to use wait for signal command to block the first movement command into prepared state, but I have found that didn't work. Even the kinematics is blocked, the first movement command still goes into prepared state.

Is there any other solution to block the command from 'CREATED' & 'INBUFFER' state into 'PREPARED'?  In the real case, there are over 50 to 100 buffer commands to send, and every buffer command needs different logical check program to decide if to be sent or not. So we can not write the whole buffer commands in just one step(in one case).  

[CodeShepherd · Accepted solution]

"WaitforSignal", like you experienced, only stops the execution of commands.

You will need additionally to your "KinContMotion" the "KinContourCmd" before beginning  and after adding all commands. See description.

If you are blending in an corner and you want to stay in contious movement you also will need "PolyTrans". See description.

[KangZhihao]

It sounds like a good idea.

I have two quesiton:

1. this function already released in V1.16?

2. The sequence is this:① I first use "KinContourCmd" command, then I send several buffer movement commands, no matter how long it takes. ②Then I use "KinContourCmd" command again at the end of the buffer commands. ③ At last , I start the motion movement. Is this sequence correct?

[CodeShepherd · Accepted solution]

1.  Yes.
2. Order is:
   1.  KinContourCm(IsStart:=true)
   2. PosLinAbs, PosLinAbs ...
   3. KinContourCm(IsStart:=false)
   4. Working on sent kommands will start

[KangZhihao]

Thank you very much, this really helps a lot!