Jump to content
OMRON Forums

precision loss


hibitor
 Share

Recommended Posts

hi, there is a Gordian knot here for me. Is there a good idea to perfectly avoid the wrong effect caused by the round data when transfering the data among the 'target position register' and 'P1...P32' and 'Q1...Q9' when I develop kinematics program? thanks
Link to comment
Share on other sites

  • Replies 6
  • Created
  • Last Reply

Top Posters In This Topic

The P and Q variables in PMAC are 48 bit floating-point values with a 36-bit mantissa and 12-bit exponent. The motor target position (and other position) registers are 48-bit fixed-point values, and with typical scale factors, have about 36 bits of whole-count resolution and 12 bits of fractional resolution.

 

The 36-bit mantissa in the P and Q variables can represent count values up to 64 trillion with no loss of whole-count resolution. Very few kinematic applications have position values that get anywhere near this size. (Typically, the only types of motors that may get to this type of range are spindles or webs that run continuously, and they usually are not involved in kinematic calculations.)

 

The conversion between the floating-point Pn motor position value you work with in your kinematics routine and the fixed-point motor target position register is done automatically by PMAC. Other than using the best possible math in your kinematics routines, there is nothing special to be done for optimal numeric resolution. Any errors from the finite resolution of these variables will be trivial (and very far below other sources of error in your application) in virtually all applications.

Link to comment
Share on other sites

The P and Q variables in PMAC are 48 bit floating-point values with a 36-bit mantissa and 12-bit exponent. The motor target position (and other position) registers are 48-bit fixed-point values, and with typical scale factors, have about 36 bits of whole-count resolution and 12 bits of fractional resolution.

 

The 36-bit mantissa in the P and Q variables can represent count values up to 64 trillion with no loss of whole-count resolution. Very few kinematic applications have position values that get anywhere near this size. (Typically, the only types of motors that may get to this type of range are spindles or webs that run continuously, and they usually are not involved in kinematic calculations.)

 

The conversion between the floating-point Pn motor position value you work with in your kinematics routine and the fixed-point motor target position register is done automatically by PMAC. Other than using the best possible math in your kinematics routines, there is nothing special to be done for optimal numeric resolution. Any errors from the finite resolution of these variables will be trivial (and very far below other sources of error in your application) in virtually all applications.

 

Thanks for your kindly response,curtwilson. in face,I come across this problem just when I use the Kinematic program to control the third axis Tangent relative to the path described by two other axis.

first I move the three axis to the specified position under the RAPID mode described by axis definition. this time, the rotary axis is toward the direction of the comming movement. then I download another program control by kinematic program that keep the third axis tangent to others into PMAC. but when execute it, there is a jump occur on the rotary motor at once sometimes(and it doesn't occur every time). I have checked the data in Mxx61,Pxx,and Qxx in the forward kinematics, it same(but a very little tolerance for example,0.000007) with the value I give it when I did in the RAPID mode movement in advance.

So I think that maybe the tolerance in the modulo operation cause the big jump on rotary motor. If not.Is there any other factor can cause this problem? Thank you for taking the time to answer my questions.

Link to comment
Share on other sites

As I understand your process, you execute a RAPID move to the XY position and C-angle orientation for your starting point and tangent angle on the path. For this move, the C-angle is directly programmed, and not calculated as an arctangent.

 

Then, with the kinematics algorithms for calculating the C-angle to be tangent to the path enabled, you start a motion program to command the XY path. The first thing that happens is that the forward kinematic algorithm is executed to calculate the starting axis positions (X, Y, and C) from the motor positions. Then, as it calculates the first programmed move, it computes the axis positions for the first segment (Isx13 time) for this move, and passes these axis positions to the inverse kinematic algorithm.

 

It is quite common early in the development of a project for the user's forward and inverse kinematic algorithms not to be perfect inverses of each other everywhere in the workspace. If they do not match each other exactly, there will be a sudden jump at the beginning of the first move. The kinematics for tangent control of a rotary axis are especially tricky to start right, because the inverse kinematics derive three motor positions from two axis positions, which cannot be a directly invertible calculation.

 

Our modulo operation on the PMAC has been stable for over 20 years now, without any record of complaint for accuracy, especially not one big enough to cause a noticeable jump. I would be much more concerned as to whether to the commanded end angle of the RAPID move really matches the starting tangent angle of the first path move in all cases. If it does not, you will get the jump.

Link to comment
Share on other sites

As I understand your process, you execute a RAPID move to the XY position and C-angle orientation for your starting point and tangent angle on the path. For this move, the C-angle is directly programmed, and not calculated as an arctangent.

 

Then, with the kinematics algorithms for calculating the C-angle to be tangent to the path enabled, you start a motion program to command the XY path. The first thing that happens is that the forward kinematic algorithm is executed to calculate the starting axis positions (X, Y, and C) from the motor positions. Then, as it calculates the first programmed move, it computes the axis positions for the first segment (Isx13 time) for this move, and passes these axis positions to the inverse kinematic algorithm.

 

It is quite common early in the development of a project for the user's forward and inverse kinematic algorithms not to be perfect inverses of each other everywhere in the workspace. If they do not match each other exactly, there will be a sudden jump at the beginning of the first move. The kinematics for tangent control of a rotary axis are especially tricky to start right, because the inverse kinematics derive three motor positions from two axis positions, which cannot be a directly invertible calculation.

 

Our modulo operation on the PMAC has been stable for over 20 years now, without any record of complaint for accuracy, especially not one big enough to cause a noticeable jump. I would be much more concerned as to whether to the commanded end angle of the RAPID move really matches the starting tangent angle of the first path move in all cases. If it does not, you will get the jump.

 

Yes,Curt.that's the process I did, I always feared that using the RAPID under the Axis definiation first and then change it into the control of kinematics is not a legal usage before. now by your patient reply, I'm not afraid it any more.

I agree with you definiatly, tangent control of a rotary axis are tricky. After several days study, refer to a lot of materials such as URM and SRM etc,which relate to kinematics I can find.unfortunatly, I still don't think that I really understand it completely.I have made a lot of tests on the machine. because the movement will stop at once when the jump occured,I get the chance to check the value of the variable used in the kinematics at that time. mainly I check the variable "Mxx61","Pxx",and "Q3"(for Axis C), after the RAPID movement, I can see the data in the RAPID command, so I think I can get the angle in RAPID X(data1),Y(data2),C(data3). because I test a simple case that straight line vertically movement, the angle is 90 degree cearly same with data I found in RAPID command. As you said,this data is computed by myself through the host program. but the third motor positions at start point from two axis positions is derived from the inverse kinematics and calculated internally, so I can just look it indirectly by query the value in variable,for example Q3, and it is 90 degree too in this cases(vertical line move from bottom to top). so I have no idea about it. maybe I misunderstand some point in kinematics.could you give some tips. please permit me to append the code snippet to help explain the case.

// first download the RAPID mode movement code

A

CLOSE

UNDEFINE ALL

&1

#1->200.0X

#2->200.000000Y

#3->50.000000C

I5150=0

...

OPEN PROG 102 CLEAR

...

ABS

ABS LINEAR X430.000000 Y2399.000000 F2000.000000

...

 

// second download the movement controled by kinematics

A

CLOSE

UNDEFINE ALL

&1

#1->I

#2->I

#3->I

...

I5113=10

I5150=1

OPEN PROG 102 CLEAR

NORMAL K-1

TA666

TS166

ABS LINEAR X430.000000 Y2399.000000 F2000.000000

...

 

 

// forward kinematic

&1 OPEN FORWARD

CLEAR

...

Q3=P3/Q49

Q7=P1/Q47

Q8=P2/Q48

Q43=Q7

Q44=Q8

Q45=Q3

Q50=Q45%(-180)

...

CLOSE

 

// inverse kinematic

&1

#1->I

#2->I

#3->I

Q51=0.01

&1 OPEN INVERSE

CLEAR

Q0=Q7-Q43

Q41=Q8-Q44

IF(ABS(Q0)>Q51 OR ABS(Q41)>Q51)

Q52=ATAN2(Q41)

ENDIF

Q53=(Q52-Q50)%(-180)

Q3=Q52+Q53/2

Q3=Q52

Q42=(Q3-Q45)%(-180)

Q3=Q45+Q42

P1=Q7*Q47

P2=Q8*Q48

P3=Q3*Q49

Q43=Q7

Q44=Q8

Q45=Q3

CLOSE

Link to comment
Share on other sites

The thing I am most concerned about in your inverse kinematic routine is your IF branch. You are checking to see if either DeltaX or DeltaY is greater than a threshold distance before you compute the arctangent angle. I am worried both that your threshold may be too large (0.01 seems small, but that is 5 counts in your system, and I could easily see the first 10-msec segment at the start of S-curve acceleration being shorter than that) and that you have no ELSE branch to decide what to do if the threshold is not met. In the first move of a program, the angle command if the threshold is not met is effectively random.

 

On a separate subject, if I were doing this application, I would always process the axis data through the kinematic routines, but with a logic flag that would let me choose between direct programming of the C axis (which you would use in RAPID mode) and arctangent calculation of the C axis (which you would use in LINEAR and CIRCLE modes). I think this would simplify your application greatly.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share


×
×
  • Create New...