Geo correction not always working

I have created a Geo correction file similar to what I have done in the past. I lined a precision straight edge up in x. It was at zero on the test indicator mounted in the spindle and touching each end of the rail. Along the travel from one end to the other I recorded the deviation at each inch. This revealed a bow in the x that basically created a arc of about .03 inches along its span. I made measurements at each inch of the deviation and created points in cad space. I then mounted a linear scale to a frame and squared it to my straight edge. I took measurements of the travel also every inch and created a offset that was equal but opposite the deviation. This was mapped to my previous map. I squared another precision straight edge to the one already mounted. I the took my y measurements same as x. This went quickly since it was straight and square to x by less then .001 over the whole travel and the screw held less then .002 deviation at any inch move. I decided y was close enough to leave out of my mapping needs. I adjusted the measurements file to create a grid of 2 rows and 49 columns. The spacing was set to 1 and 32. That's to cover the whole travels 0-48 in x and 0 and 32 in y. The origin was set at 0,0.

I took my measurements by running a g-code program that single stepped through the mapped coordinates and using the measure button. The file I created works but has some issues. When I redid my previous tests in x to check my results I found mixed results. The scale measurements of travel distance were reduced from as much as .029 inches down to .0015 or less at any position. That's great and better then expected. It's also repeatable every time. The issue I'm having is with the correction of the bow in x. When I jog or make step moves along the straight edge the indicator shows the bow being corrected and deviation over 48inches is now within .004 of the straight edge. I think I could make this better with a more careful map of the bow. When I make a move along the straight edge in mdi or through a g-code program the error increases drastically. The move now has a error of as much as .015 which is better then .029 but still not good. Oddly it seems the x movement correction is still correct but the y tracking is off whenever I run g-code which is where it really counts.

I'm wondering if the configuration of my map could be causing this even though it works while manual jogging and stepping. The error goes back up to about .015 during rapid as well.

If anyone has any suggestions of where to look please help.

Thanks
Ben

Sent from my E6810 using Tapatalk

Hi Ben,

I'm not sure I follow that exactly, but I'm thinking it might have to do with only the endpoints being Geocorrected and things assumed to be linear in between. That's the only difference I can think of between Jogging and GCode Motions. When you move with GCode/MDI are you looking for errors during the motion or at the endpoints of motion? See diagram below:

Attachment 410546

Motions will be automatically sub-divided into segments less than an allowed maximum length of:

MaxLength = FeedRateToUse * MP->TPLookahead/2.0;

What is your Trajectory Planner Lookahead time set at? What Feedrate are you running?

Rapids will not be subdivided unless the "Rapids as Feeds" option is selected.

Yes your graph shows what I am describing. My look ahead is set at 10 seconds. The feed rates for the tests in both jogging and g-code/mdi were at 50 and 150ipm. Yes I observed the actual error during a move by watching a dti as it traversed a 48" precision straight edge. The straight edge was clamped to the table and aligned perfectly parallel with the travel. I took my measurements on the same straight edge and never moved it between then and the tests after I created the Geo map. The error drives very close to zero during a traverse using jogging. It stays within .002 for most of the traverse but there are a few spot as high as .004. I did these move in both forward and reverse maybe a Dozen times through the whole travel. The errors were consistent and repeatable but acceptable for my needs. When I tried making moves in mdi to give myself a break from holding the jog buttons I noticed the large increase in error. I then tried g-code with the same moves and got the same amount of error as during mdi. It was tracking the straight edge at 10-15 thou error instead of .002-.004. The original error is as much as .029 so it's always working but in varying degrees depending on move type. The error was always zero at each end during all move types. That is because the map has zero correction at the first and last points of the travel. Those points define the ideal straight movement with the ones in between defining the deviation. I know this is probably hard to visualize from a post. I'll try and get a copy of the map posted if needed. The header looks like this.

2,49
1,32
0,0

As you can see I left out all the points in between in y0 and y32. So only the extents were defined for Y but all 49 were defined for X to fix the travel distance errors.

Ben

Sent from my E6810 using Tapatalk

Hi Ben,

It seems like the segment lengths might be the problem.

150ipm / 60 * 10sec / 2 = 12.5 inch segments.

Please try reducing the Look Ahead time to 1 second to see if it makes a big improvement.

I tried lowering the look ahead to 1 second. Yes it made a drastic improvement. The error during moves running from g-code are now on par with those during jogging. The error seems to be the same at 50 and 150ipm. I am unsure if having such a short look ahead will be a issue during complex 3d tool paths which is most of my work. Do you see that as becoming a issue or something I shouldn't worry about? Also I'm curious how you came up with 12.5 inch segments. I understand the math and the conclusion just not the parameters. The Geo map has both a x and y correction every inch with the only zero points in y being at x0 and x48. The rest are somewhere along the curve and a different value at every inch. How do the 1 inch segments get combined to make 12.5 inch segments? I guess I'm just curious how moves get computed in relation to the map. Thank you for your always having such good insight into the problems I run into from time to time.

Ben

Sent from my E6810 using Tapatalk

Quote:

---

I tried lowering the look ahead to 1 second. Yes it made a drastic improvement. The error during moves running from g-code are now on par with those during jogging.

---

Good. That makes sense.

Quote:

---

The error seems to be the same at 50 and 150ipm

---

That seems strange. Is the feedrate really 3X faster at 150ipm? Or is the feedrate limited by something else such as the Trajectory Planner settings?

Quote:

---

I am unsure if having such a short look ahead will be a issue during complex 3d tool paths which is most of my work. Do you see that as becoming a issue or something I shouldn't worry about?

---

Normally a couple of seconds is sufficient. Otherwise there is a parameter in the CKinematics.cpp for limiting the segment lengths. However you will need to recompile the libraries to change it. Change:

m_MotionParams.MaxLinearLength = 1e30; //Infinity for default case

to

m_MotionParams.MaxLinearLength = 1.0; //Set to 1 inch

I suppose we should make that a configuration parameter. Normally it is only an issue with highly non-linear systems. In those cases the length can be specified in the Kinematics code. Your case is somewhat extreme because of the combination of an abnormally large amount of Geocorrection, large lookahead time, and relatively high feed rates.

Errors should decrease as the inverse square of the length. ie 1 inch vs 12.5 inch should be 156X better.

Quote:

---

Also I'm curious how you came up with 12.5 inch segments. I understand the math and the conclusion just not the parameters. The Geo map has both a x and y correction every inch with the only zero points in y being at x0 and x48. The rest are somewhere along the curve and a different value at every inch. How do the 1 inch segments get combined to make 12.5 inch segments? I guess I'm just curious how moves get computed in relation to the map

---

The Geocorrection table is a separate issue. The number of grids and such have an effect as to how well the transformation from CAD space to Actuator Space is represented. Assume for the sake of discussion the Geocorrection is perfect. Still only the endpoints of each segment are perfectly Geocorrected and all the points in between are assumed to have a linear relationship causing your error. The CCoordMotion Library checks the length of each segment and recursively divides it in half until it is less that the max allowed length. So actually your 48 inch long GCode segment will be divided int two 24 inch segments that will each be divided into two 12 inch segments which are then less than the 12.5 inch limit.

Quote:

---

Thank you for your always having such good insight into the problems I run into from time to time.

---

Thanks for your patience and great communication skills.

Tom
Thank you for your reply. I will be doing some careful testing the next few days. When I'm through I will be able to answer your questions with regards to speed vs accuracy more precisely. I can say for sure that the speeds are in no way limited and are real speeds. This can be confirmed by making a move and timing how long it takes. From that the actual speed can be determined very closely. The trajectory planner is limited to 300ipm for X and y and 180 for z or 5,5 and 3 IPS respectively. Rapids are about x330ipm y600ipm and z280ipm.

As for the recommended changes to the kinematics program I would like to try making the change you suggested. The problem is I do not know how to recompile the library. Is there a tutorial or description available that can point me in the right direction so I can learn how to do so?

Thanks
Ben

Sent from my E6810 using Tapatalk

Hi Ben,

Quote:

---

As for the recommended changes to the kinematics program I would like to try making the change you suggested. The problem is I do not know how to recompile the library. Is there a tutorial or description available that can point me in the right direction so I can learn how to do so?

---

Please see this wiki article. Let us know if you have problems.

I am assuming the library has to be rebuilt on the PC that kmotion is installed to? And once I get to that point what do I choose debug or release? Also do I make the changes to the kinematics file in visual studio or just use notepad then compile in visual studio? Thank you for making the help file since my searches were getting me nowhere. Awesome support.

Thank you
Ben

Sent from my E6810 using Tapatalk

Ok I think I answered my own questions for the most part. I got vs2015 installed and the library rebuilt late last night. Your help article worked great. Thank you very much.

Ben

Sent from my E6810 using Tapatalk

The results are in. I put the look ahead back at 10. The change you suggested is working great. I now have a max error of .005 total deviation. That is on all moves at all speeds tested jog and code. Ill do a better map of the bow today and see if I can do even better. I also changed to fanuc style compensation and that works amazingly well. Thank you for pushing me to learn something new and useful. Now I need to tackle a program for auto tool change. I'll get to that once I get the drawbar sensors wired back to snapamp opto's and showing correct state changes. I'm thinking of starting with the linear tool changer code but I would have to add more tools. I may try starting from scratch and see if I can get anywhere. I even thought of doing a rotary tool changer and using the fourth motor from snapamp through a gear box. We'll see.

Thanks
Ben

Sent from my E6810 using Tapatalk

Hi Ben,

Quote:

---

I am assuming the library has to be rebuilt on the PC that kmotion is installed to?

---

Yes, or the Libraries copied to the target machine.

Quote:

---

what do I choose debug or release?

---

Debug configuration adds debug information and keeps the code in the way you wrote it that allows you to debug the code by setting breakpoints, step through the code, watch variables, etc. Release configuration does not include debug information and optimizes the code for small size and faster execution speed. If you wish to debug the application using the libraries you would need the debug libraries, otherwise you can use the release libraries.

Quote:

---

Also do I make the changes to the kinematics file in visual studio or just use notepad then compile in visual studio?

---

You can change the source code any way you wish, then re-build the code with VS. But normally you would use VS to edit the code.

Quote:

---

The results are in. I put the look ahead back at 10. The change you suggested is working great. I now have a max error of .005 total deviation. That is on all moves at all speeds tested jog and code.

---

Great thanks for posting back.

Quote:

---

Now I need to tackle a program for auto tool change. I'll get to that once I get the drawbar sensors wired back to snapamp opto's and showing correct state changes. I'm thinking of starting with the linear tool changer code but I would have to add more tools. I may try starting from scratch and see if I can get anywhere. I even thought of doing a rotary tool changer and using the fourth motor from snapamp through a gear box. We'll see.

---

Sounds good. Don't hesitate to ask further questions

Tom,

I may have some similar needs for screw mapping or leadscrew comp on my machine as what bhurts encountered where I run full 3D and several or more seconds of look ahead. A couple of follow ups on your comments in this thread while I figure out if I need to start one of my own...

Quote:

---

Originally Posted by TomKerekes

Normally a couple of seconds is sufficient. Otherwise there is a parameter in the CKinematics.cpp for limiting the segment lengths. However you will need to recompile the libraries to change it. Change:

m_MotionParams.MaxLinearLength = 1e30; //Infinity for default case

to

m_MotionParams.MaxLinearLength = 1.0; //Set to 1 inch

I suppose we should make that a configuration parameter. Normally it is only an issue with highly non-linear systems. In those cases the length can be specified in the Kinematics code. Your case is somewhat extreme because of the combination of an abnormally large amount of Geocorrection, large lookahead time, and relatively high feed rates.

---

Was there a configuration parameter added in later releases for "m_MotionParams.MaxLinearLength" for changing without full recompile? If so, where would I find it?

Is "CKinematics.cpp" file now "Kinematics.cpp" in the "GCodeInterpreter" directory (KMotion434 and later)?

Thanks

Hi MadTooler,

Quote:

---

Was there a configuration parameter added in later releases for "m_MotionParams.MaxLinearLength" for changing without full recompile?

---

No

Quote:

---

Is "CKinematics.cpp" file now "Kinematics.cpp" in the "GCodeInterpreter" directory (KMotion434 and later)?

---

No sorry that was a typo. It has always been the file Kinematics.cpp that contains the class CKinematics.