Sine Wave TCP movement Ext. Axis Speed

Teodoro1998

Hi , 
we use  an IRC5 to lay tape using a tool and an external axis that rotates while the robot does its linear move. 
We normally perform a MoveL of approx. 2m and that works fine. 

Now, I need the TCP to move as a sine Wave instead of linearly, I tried to create it by performing 2000 movements , i.e applying a y'' offset every 1mm as per code below : 

FOR i FROM 1 TO nLength DO 

        nRotSegmentPos{i}:=0; ( Initialise segment array)

     ENDFOR

  FOR i FROM 1 TO nLength DO

       nRotSegment{i} := (nNumberRotation/nLength)*i (Defines position of Ext. Axis)

  ENDFOR

vMoveSpeed.v_reax:=aRotationSpeed{nLayerCounter}; (Desired speed of Ext. Axis)

FOR i FROM 1 TO nLength STEP 1 DO

         pStart.extax.eax_a:=nRotSegmentPos{i}; (move ext. axis to next position)

         y:= A*sin (x*i);                                                (Define y'' offset during move)

        MoveJ RelTool(pStart,0,-i,(nPipeDiameter+y),vMoveSpeed,zSine,tTH2\WObj:=wobjPipe;
ENDFOR.

now, the movement works Ok but the external axis isn't achieving the desired speed, any idea why ?

Could it be because the axis doesn't have time to ramp up to the correct speed before executing the next movement ?

Or maybe anyone knows a better way to achieve this without using independent axes moves ?   

any feedback will be appreciated, thanks in advance.  

matti

Hallo, you should have a coordinated movement between robot and manipulator.

In the lag_control_master_0 settings of your external axis, the FFW-mode should be at least 1 (speed).

If so, the controller will take ramp up/down into account.

lemster68

At which speed are you moving the robot?  1mm is a small distance and the standard servo lag time for the robot alone is like 90ms.

Teodoro1998

Thanks for the feedback guys,  I did get it working  this morning by increasing the step to 3mm and using moveL instead.

@lemster68 the external axis rotates at approx. 65 deg/s .. the robot I didn't work it out and I dont really know , as I normally always use moveL with speed data with the ext. axis having the lower speed .. so they synchronise and finished at the same time.

For this job the accuracy doesn't really matter much, so the increase from 1-3 does the job, but could anyone point me to some documentation that can explains the behaviour mentioned by @lemster68 and the fact it works with 3mm ? 
Could be useful reading for future jobs.
Thanks

lemster68

So far I am only going by memory on the servo lag time.  I have not found the printed reference yet.  While searching though, I came across the motion process modes which made me think that it might be helpful to you to try different modes.

Teodoro1998

Thanks, just to see if my mind can get it .. each step is a new move even if it is define as a zone (example , z2 ) ,conc and not defined as "fine"  it needs some time "lag" to ramp up to the correct speed ?
Is that correct ? 
 

lemster68

Briefly looking at your posted code, yes, each move is new.  Another thing I just thought about that you might not have considered is that zone sizes are automatically reduced when they overlap.  Since you had 1mm steps and z2, you would never see z2 but it would be reduced to one half mm or less.  Speed changes are begun when it enters the motion zone.
Here is a suggestion:  Instead of doing the math on the fly with where to move to next, do the math before the FOR NEXT and populate a robtarget array with the points.  Then you MoveL pArray{i}, spedd, zone, tool, etc.

Teodoro1998

Thanks for the suggestion, that makes sense. And yes, I didn't fully understood the zone side of it .I did it more kind of try and error ..
Thanks for the support and if by any chance you find the literature related to the comments above  
Please add it to the trend 😀
Thanks again. 

nicolahinssen

The RAPID Technical Reference Manual explains a bit about this lag at the TriggEquip chapter. Also lookup the Event Preset Time parameter in the System Parameters manual.

I/O events with distance is intended for flying points (corner path). Using stop points will result in worse accuracy than specified below. Regarding the accuracy for I/O events with distance and using flying points, the following is applicable when setting a digital output at a specified distance from the start point or end point in the instruction TriggL or TriggC:

• The accuracy specified below is valid when using a positive EquipLag that is less than 40 ms, which is equivalent to the lag in the robot servo without changing the system parameter Event Preset Time. The lag can vary between different robot types.

• The accuracy specified below is valid when using a positive EquipLag that is less than the configured Event Preset Time in the system parameters.

• The accuracy specified below is not valid when using a positive EquipLag that is larger than the configured Event Preset Time in the system parameters. In this case, an approximate method is used in which the dynamic limitations of the robot are not taken into consideration. Then SingArea \Wrist must be used to achieve an acceptable accuracy.

• The accuracy specified below is valid when using a negative EquipLag.
The typical absolute accuracy values for setting digital outputs is: ±5 ms.
The typical repeat accuracy values for setting digital outputs is: ±2 ms.
TriggEquip cannot be executed in an UNDO handler or RAPID routine connected to any of the following special system events: PowerOn, Stop, QStop, Restart, Reset or Step.