RainG

Cycle Time and Accurate Positioning

15 posts in this topic

Hi All,

I just take over a project which involve accurate positioning and movement up to 0.010mm(around 10 microns) of a servo motor. I found out that my motor always move to an incorrect position. Let's say I want it to move to absolute position of 5.210mm, I found out that it may move more till 5.235 or move less 5.190(something like that). So i start to check if I'm outputting correct pulse. Using CX-Drive, I connect to the driver then i found out that the pulse is correct and consistent(for example i use my pulse per revolution and pitch to determine how many pulses)

Currently I'm using an incremental encoder and servo motor and my PLC cycle time is around 12 ms and my servo move at a speed of 0.66mm/s. So I was wondering if my PLC scan time will affect my accuracy in moving ?? I'm using a CJ2M PLC with CJ1W-NC413 pulse card , incremental encoder and a servo motor. I want to make sure is not software limitation or anything wrong on software side before I bring it to my mechanical team:notworthy:

 

Appreciate all inputs here and thanks!

Share this post


Link to post
Share on other sites

I doubt cycle time has any affect on it.

What drive are you using and does the NC413 have an encoder going to it?

 

 

Share this post


Link to post
Share on other sites
20 minutes ago, photovoltaic said:

I doubt cycle time has any affect on it.

What drive are you using and does the NC413 have an encoder going to it?

 

 

I'm using G5-series Pulse Train Input Type AC Servomotors/Servo Drives R88D-KP15H and an incremental encoder...

Share this post


Link to post
Share on other sites

Based on your given data 0.66mm/s and 12ms Scan Time for Program.  You could see 0.00792 mm variance if off by one scan.

Your readings of 5.235 and 5.190 are 0.0045 apart or off by 5.6 scan times.  So I doubt it's cycle time causing it.

That said, can you move the servo 1 pulse and measure so you know the observed mm/pulse not the calculated.

I'm curious after say 10 trials what the average mm/pulse measurement is.

Working with @photovoltaic and others as to your drive type and circumstance will get you the best answer.

Share this post


Link to post
Share on other sites
19 minutes ago, BobLfoot said:

Based on your given data 0.66mm/s and 12ms Scan Time for Program.  You could see 0.00792 mm variance if off by one scan.

Your readings of 5.235 and 5.190 are 0.0045 apart or off by 5.6 scan times.  So I doubt it's cycle time causing it.

That said, can you move the servo 1 pulse and measure so you know the observed mm/pulse not the calculated.

I'm curious after say 10 trials what the average mm/pulse measurement is.

Working with @photovoltaic and others as to your drive type and circumstance will get you the best answer.

So does that means, part of the accumulated positioning error is caused by the scan time???? based on what you said that there is a 0.00792mm variance, meaning i will still have run off positioning around 8 microns????

Servo is 10000 pulse per revolution so if i move one pulse , then it would be 0.0005 mm which is very hard to measure physically:-(.....

Yea im trying to determine the root cause from my side first before I start argue if the ball screw or the mechanical system something is loose or anything else...

Share this post


Link to post
Share on other sites

A good test for backlash is to approach a position from the same direction multiple times.

ex. Move to 10mm - Move to 50mm (record actual position) - repeat a few times. Then Move to 90mm - Move to 50mm (record actual position) - repeat a few times

If each data set is consistent but there is a difference between the 2 data sets - there's your backlash.

 

I don't see how scan time can effect the system. If the NC card is instructed to output 35,673 pulses it will regardless of CPU scan time. This ultimately controls the position of the motor.

 

 

Share this post


Link to post
Share on other sites
17 minutes ago, photovoltaic said:

A good test for backlash is to approach a position from the same direction multiple times.

ex. Move to 10mm - Move to 50mm (record actual position) - repeat a few times. Then Move to 90mm - Move to 50mm (record actual position) - repeat a few times

If each data set is consistent but there is a difference between the 2 data sets - there's your backlash.

 

I don't see how scan time can effect the system. If the NC card is instructed to output 35,673 pulses it will regardless of CPU scan time. This ultimately controls the position of the motor.

 

 

I had tried to do some testing to determine the servo motor movement behavior, which i think is similar to the one u suggested above?
ex. Move to 10mm - Move to 10.05mm(record actual position) - move back to 10mm, repeat for a few times... i had find out that every time the motor does not stop at 10.05mm but *consistently stop at around 10.06 mm *(i forget the actual value..) I find it stop at consistent position so i worried it might because of scan time issue, since the scan time is always fix and there...

Does that means once my PLC start instructs the NC card to output 35673 pulses...it will output that said amount of pulses immediately and regardless of scan time? once reach the amount of pulses it will stop. is my sentence correct?

Share this post


Link to post
Share on other sites
28 minutes ago, RainG said:



Does that means once my PLC start instructs the NC card to output 35673 pulses...it will output that said amount of pulses immediately and regardless of scan time? once reach the amount of pulses it will stop. is my sentence correct?

Essentially. There are factors effecting how fast they are delivered but that's basically how they work.

 

When you are online with the drive have you done testing using the drive's encoder value?

Share this post


Link to post
Share on other sites
23 minutes ago, photovoltaic said:

Essentially. There are factors effecting how fast they are delivered but that's basically how they work.

 

When you are online with the drive have you done testing using the drive's encoder value?

I got use CX-drive to connect to my drive and monitor the pulse status. Is that what you meant with testing using driver encoder value?

Share this post


Link to post
Share on other sites

Is your encoder on the motor and going directly to the drive?

Share this post


Link to post
Share on other sites
8 hours ago, photovoltaic said:

Is your encoder on the motor and going directly to the drive?

Yes, my motor is the R88M-KE series which comes with an incremental encoder...

Share this post


Link to post
Share on other sites
9 hours ago, RainG said:

So does that means, part of the accumulated positioning error is caused by the scan time???? based on what you said that there is a 0.00792mm variance, meaning i will still have run off positioning around 8 microns????

Servo is 10000 pulse per revolution so if i move one pulse , then it would be 0.0005 mm which is very hard to measure physically:-(.....

Yea im trying to determine the root cause from my side first before I start argue if the ball screw or the mechanical system something is loose or anything else...

so the one pulse  move wont work but moving 10,000 or 5mm each time would. 

Share this post


Link to post
Share on other sites

Will using absolute encoder or incremental encoder affect the accuracy of me reading the live pulse feedback from encoder?

Share this post


Link to post
Share on other sites
7 hours ago, RainG said:

Will using absolute encoder or incremental encoder affect the accuracy of me reading the live pulse feedback from encoder?

Absolute vs incremental will play no difference. Just select the type you have. The accuracy is determined by the encoder's resolution. I'm not a CX-Drive guy but the Drive should have the encoder value available - look at this during your testing. There should be no variation here when you do movements. Please confirm

Edited by photovoltaic

Share this post


Link to post
Share on other sites

I would expect that this issue is mechanical in nature.  0.02 mm variance in a mechanical system is not that much unless you have specialized actuators.  If you observe the command and the feedback from the encoder using CX-Drive and the numbers are repeatable, then you have an issue with your actuators.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now