Jump to content
OMRON Forums

tread reporting target position incorrectly


paddax

Recommended Posts

The functions tread, pread and dread calculate values based on programmed positions but appear to have an error when cutter compensation is active.

 

Given the following program

 

normal I0 J0 K-1

ccr 1

ccmode1

X10

Y10 ; Read value here

X-10

Y-10

 

on line command T reports an X value of 10:-1

tread reports an X value of 9

 

The manual states these command are equivalent.

 

Our MMI is using tread, pread and dread values and these are not actually reporting the programmed target, position and desired position which is confusing.

Link to comment
Share on other sites

  • Replies 9
  • Created
  • Last Reply

Top Posters In This Topic

Hi,

 

Have you enabled segmentation time by setting Coord[x].SegMoveTime > 0? Typical values for this are about 2 msec.

 

Have you set up Coord[x].TpSize? It should be set to at least 3 for using the tread feature.

 

Coord[x].Tpcoords must also be configured based on the axes you want to report.

 

Also make sure you have defined the plane of interpolation with the normal command.

Link to comment
Share on other sites

Hi,

 

Have you enabled segmentation time by setting Coord[x].SegMoveTime > 0? Typical values for this are about 2 msec.

 

Have you set up Coord[x].TpSize? It should be set to at least 3 for using the tread feature.

 

Coord[x].Tpcoords must also be configured based on the axes you want to report.

 

Also make sure you have defined the plane of interpolation with the normal command.

 

Please reread the question, tread is working but reporting different result to the online command T. The difference is the cutter compensation value.

 

Put another way, if cutter compensation is not used the system works perfectly. T and tread report the same correct values. When cutter compensation is applied the following occurs

 

1. The program moves through the correct path

2. T reports the programmed target positions

3. tread reports the actual target positions not the programmed target positions

 

 

From my configuration

 

Coord[0].SegMoveTime=5; // ms
#define MaxStoppingTime0 Motor[1].MaxSpeed * Motor[1].InvAmax
#define LHSegsNeeded0 MaxStoppingTime0/(2.0 * Coord[0].SegMoveTime)
Coord[0].LHDistance=4.0/3.0*LHSegsNeeded0;

Coord[0].TPSize=3 + Coord[0].LHDistance; // at least 3, plus the number of lookahead segments
Coord[0].TPCoords=$1E6; // Axes X, Y, Z, B, C, W 

 

normal is set to 0,0,-1

Link to comment
Share on other sites

CCDistance and CCSize make no difference as Cutter compensation is working!

 

My problem is tread reports the actual position not the programmed position e.g.

 

T reports the programmed position and the currently active cutter compensation T -> X10:-1

tread reports D6 -> 9

 

Is there a way to determine the actual programmed position via an equivalent to tread or is the only way to do this issuing a "T" command and interpreting the string

Link to comment
Share on other sites

Ah OK, now I understand what you are asking.

 

What you are seeing occurs by design.

 

See the descriptions of t and tread from the Power PMAC SRM.

 

From the tread description on page 1139:

 

If cutter radius compensation is enabled for the move, the positions returned for the X, Y, and Z

axes in D6, D7, and D8, respectively, include the offsets from compensation for those axes at the

end of the move. If 2D compensation has added an arc move around an outside corner to blend

into the next move, the reported compensated target positions for these axes are at the end of the

arc if bit 0 (value 1) of Coord[x].CCCtrl is set to the default value of 0; they are at the beginning

of the move if this bit is set to 1.

 

From the t description on 1024:

 

If cutter radius compensation is active for the move, and there is a non-zero offset from compensation for

the axis, the position for the X, Y, or Z axis will be reported with two values – the programmed value for

the axis immediately following the axis letter name, then a colon, and finally the automatically computed

axis offset for cutter compensation. If the compensation adds an arc move around an outside corner at the

blend to the next move, the offsets at the end of the arc will be reported if bit 0 (value 1) of

Coord[x].CCCtrl is set to the default value of 0; the offsets at the beginning of the arc will be reported if

this bit is set to 1.

 

So basically, t will have the colon and the compensation specified, whereas tread just adds them together before putting them into a D-Variable.

 

Note also that if you want desired position, not target position (which is the end of the move, not the reference position being fed into the servo loop), use dread in a program and d on-line.

Link to comment
Share on other sites

So the answer to the actual question

 

Is there a way to determine the actual programmed position via an equivalent to tread or is the only way to do this issuing a "T" command and interpreting the string?

 

is....

Link to comment
Share on other sites

Coord[x].CdPos[j] contains the most recently calculated commanded move target position for the specified axis. If the coordinate system is currently executing a continuous move sequence, the move for which this contains data may be one or more moves ahead of the presently executing move. (The axis target position for the presently executing move can be found in Coord[x].TPExec.Pos[j] if a target position buffer has been set up.
Link to comment
Share on other sites

To go into a little more detail, the on-line "t" and buffered "tread" commands use the data in the Coord[x].TPExec structure to obtain their results.

 

Coord[x].TPExec.Pos[j] (j=6,7,8 for X,Y,Z) contains that commanded position for the axis for the presently executing move. Coord[x].TPExec.XYZPos[j] (j=0,1,2 for X,Y,Z) contains the commanded position with offset from cutter comp for the presently executing move. (Earlier versions of the manual said that it was the offset, but it is the position with offset.)

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...