Juddering PVT motion

[rhombusvs]

Hi I am generating a block of PVT motion from the psuedo C# funtion below. angle=0; pCount=0; mystr[pCount]="PVT(20)"; do { pCount++; Apos = Math.Sin(Angle * Math.PI / 180) * 5; Avel = Math.Cos(Angle * Math.PI / 180) * 0.1; mystr[pCount]="A" + Apos + ":" + avel + " B0:0 C0:0 X0:0 Y0:0 Z0:0"; Angle++; }while (angle<360) when I send this to my geobrick via a bin rot buffer on CS1, the motion is very juddery, not the nice smooth motion I was expecting. Have I missed setting some crucial i variables (it would not suprise me if I have)

[Unit101]

Hello, I have not looked closely at what motion profile you are trying to create and I suspect the problem is either in your profile or how your telling the pmac to execute the motion... e.g blending on/off, lookahead... But using simple divide and conquer method.. first lets be sure that the Rot Buf and working with the streaming from you HMI is not the issue.... so I suggest that you simply create the entire profile as hard coded motion program, or enough of the profile to test the section of motion that is Juddering. Then just download this to PMAC, and execute in manually in the PMAC... no HMI or rotary buffers involved... Now see if the motion is still not good... assuming it is we have at least narrowed it down... next we look at the CS setup in the PMAC and the actual commanded profile itself.

[rhombusvs]

[quote='Unit101' pid='685' dateline='1283964269'] Hello, I have not looked closely at what motion profile you are trying to create and I suspect the problem is either in your profile or how your telling the pmac to execute the motion... e.g blending on/off, lookahead... But using simple divide and conquer method.. first lets be sure that the Rot Buf and working with the streaming from you HMI is not the issue.... so I suggest that you simply create the entire profile as hard coded motion program, or enough of the profile to test the section of motion that is Juddering. Then just download this to PMAC, and execute in manually in the PMAC... no HMI or rotary buffers involved... Now see if the motion is still not good... assuming it is we have at least narrowed it down... next we look at the CS setup in the PMAC and the actual commanded profile itself. [/quote] Hi Unit I have attached my brick cfg file as of a few minutes ago. It is pretty complex but basically PLC10 controls the "state" of the tool. I have 3 CS systems, Cs3 used when moving system into fixed locations, CS2 I modify at will to test applications but still basically linear kinematics, then I have a complex IK for CS1 which I know works (I have had to edit the details out for confidentiality). I am actually using your bin rot buffer as defined in your pcomm2 application you sent to me a couple of weeks ago and I have sent regular position commands through this and it works OK, apart from a habit of pausing for long periods of time which I have to resolve. I have also attached a large section of the commands i am sending. In PLC10 I have to put the state machine into (p2000 = 100) state for CS1 to be setup, this then moves the state into p2000=110 where the rot buffer is defined and subsequently started, at this point I can then stream data from pcomm2 (or my equivalent). I think I have done something wrong in the CS setup which is prevent my PVT stuff from working. I do appreciate your input.

[Sina.Sattari]

rhombusvs, I think I know the reason behind the juddering PVT motion that you see and also I have the solution. The PVT move mode in PMAC will completely follow what ever you command it and the only time that I have seen it behaving abnormal is when the commanded velocity is so high that it saturates PMAC's velocity registers (more than 780,000 counts per millisecond if Ix08 is set to default 96). The problem that you are observing is because the points that you are generating are equal distance, but not equal in time which is needed by PVT move mode. See the code below which is similar to your code only in PMAC Script: [code] CLOSE DEL GAT UNDEFINE ALL #3->12800A #DEFINE ANGLE Q50 #DEFINE APOS Q51 #DEFINE AVEL Q52 #DEFINE COUNTER Q53 OPEN PROG 1 CLEAR COUNTER=0 RAPID A 0 DWELL 0 PVT 20 WHILE (COUNTER<10) ANGLE = 0 WHILE (ANGLE < 361) APOS = 5 * SIN(ANGLE) AVEL = 5 * COS(ANGLE) A (APOS):(AVEL) ANGLE = ANGLE +1 ENDWHILE COUNTER = COUNTER + 1 ENDWHILE DWELL 0 RAPID A 0 CLOSE [/code] The result is exactly what you have explained in your post: [attachment=1388:name] But the reason is that the PVT mode move requires equal time distance between the commanded points (if the time is not to be changed and updated through the code). So if the time is the source for generating the points, we have to calculate the position and velocity based upon equal time intervals. See the code below: [code] CLOSE DEL GAT UNDEFINE ALL #3->12800A #DEFINE ANGULAR_VEL Q50 #DEFINE APOS Q51 #DEFINE AVEL Q52 #DEFINE SIN_CNT Q53 #DEFINE dTIME Q54 #DEFINE TIME_CNT Q55 #DEFINE PI 3.141592654 OPEN PROG 1 CLEAR SIN_CNT=100 dTIME = 20 ANGULAR_VEL = 2 * PI // radians per second RAPID A 0 DWELL 0 PVT (dTIME) TIME_CNT = 0 WHILE (TIME_CNT < SIN_CNT *( (2*PI/ANGULAR_VEL) * 1000 /dTIME) ) APOS = 1 * SIN(ANGULAR_VEL * TIME_CNT * dTIME * 0.001 *180/PI) AVEL = 1 * ANGULAR_VEL * COS(ANGULAR_VEL * TIME_CNT * dTIME * 0.001 *180/PI) A (APOS):(AVEL) TIME_CNT = TIME_CNT + 1 ENDWHILE DWELL 0 RAPID A 0 CLOSE [/code] And the result would be a nice and continuous sine wave both on position and velocity. [attachment=1389:name] There is also another difference between the first code and second code which is how I have taken care of multiple sine wave generation. In the first code I have used nested WHILE loops in order to generate multiple sine waves. This approach interrupts the lookahead engine because it will encounter two backward jumps (ENDWHILE) which will result in an abrupt stop in motion as if a DWELL0 was added. The solution for this problem is shown in the second code.