## Basic XY Screw Mapping - Geo Table

Moderators: TomKerekes, dynomotion

TomKerekes
Posts: 1854
Joined: Mon Dec 04, 2017 1:49 am

### Re: Basic XY Screw Mapping - Geo Table

Should I be working with version 4.35f?
yes
what will be better, to gather the position of the screw/motor encoder at the increments I have chosen then the true position from the scale, or move the screw/motor until reached the true scale position of the desired increments then gather the current motor position?
I would put in the table the motor positions that would put the axis at the theoretical position based on the scale.
Regards,

Tom Kerekes
Dynomotion, Inc.

Posts: 86
Joined: Thu Nov 08, 2018 11:57 pm

### Re: Basic XY Screw Mapping - Geo Table

I would put in the table the motor positions that would put the axis at the theoretical position based on the scale.
I was thinking the same. For example, if I was looking for mapping every inch, I will move the axis until the scale reads a true inch, then write the current axis position and the inch value from the scale.

TomKerekes
Posts: 1854
Joined: Mon Dec 04, 2017 1:49 am

### Re: Basic XY Screw Mapping - Geo Table

You may not need the position of the scale as those are theoretical and can be calculated.
Regards,

Tom Kerekes
Dynomotion, Inc.

Posts: 86
Joined: Thu Nov 08, 2018 11:57 pm

### Re: Basic XY Screw Mapping - Geo Table

Tom,

I have some results from my X screw mapping (0.2" lead 5/8"dia Roton rolled Ballscrew and nuts). This screw is newer than my Y screw, and is more accurate than it too. Considering the tolerances of the screw are something large, maybe around +/-0.010" per foot from what I think I remember, it measured pretty good for linear accuracy. The oscillation is a bit interesting. That occurs more strongly at areas of travel where I was incurring the large cut quality oscillation.
ScrewMappingResults_X_full_48_700x0_100.pdf
The graph shows error in position of the screw as it moves forward (x+) from 0 per the scales measurement at every 0.1." The return/back data shows positional error as it travels back to the same screw position from where it measured along the forward measurement. This allowed for determining the backlash at those increments. Note some of the backlash would be from the screw, but some is also from the mechanics of the machine since the scale reader head is not immediately next to the ball nuts.

For reference, this took about 2.5 hours to slowly take all the measurements with my program (48.7" with every 0.1" measured). I attached it as well for reference. The program outputs six different files. Three are inch values, three are position values in both screw encoder steps and scale steps (microns). I am thinking the "XscrewData_inchBasic.txt" file would be close to what I would be using for the kinematics (less the returning values).

Based on these results for this screw, I think mapping every inch would be good for this screw except at the end of my travel. Not sure yet about Y that I expect to have significantly larger errors (I expect about 0.04" off over 48" full travel). For the X I made a test geo table with inch only corrections up to 48.0." It worked really well, with errors about 1/10th of prior at 1" increments, until it got beyond 48 where it got off a couple thousands pretty quick for the remaining 0.7." Can a kinematics correction use varying increments so I can map the full travel, unlike the geo correction table?

I need to start digging into the kinematics now. Also want to make any variables that will need updating to match map table increments available for updating without further re-compiling. Maybe a screwMapConfig file or something like that?
Attachments
ScrewMapAxis_bLScrew.c
XscrewData_posError.txt
XscrewData_posDual.txt
XscrewData_posBasic.txt
XscrewData_inchError.txt
XscrewData_inchDual.txt
XscrewData_inchBasic.txt
ScrewMappingResults_X_full_48_700x0_100.xlsx

Posts: 86
Joined: Thu Nov 08, 2018 11:57 pm

### Re: Basic XY Screw Mapping - Geo Table

Tom,

I am digging around in Visual Studio.

Something I see, or think I see, is concerning. My intent is to be able to apply kinematics of individual actuators to provide screw mapping while later, as needed, use the Geo Table for fiduciary type adjustments. Essentially, I assumed the system would blend the two corrections magically with a bit of pixy dust and unicorn farts to give me a smooth and accurate output. Some of what I see gives me concern it is more the situation where it will be either kinematics or geo table. I am hoping I simply am not reading or understanding far enough into the kinematics examples to see where they both do apply together. Can you please confirm do both will work at the same time?

While testing my measured values in a 2x49 geo table, I had screwed up and it tried to move a large distance faster than the servos could run. Is there not any protection built into the geo table correction that considers if it will be running into follow error territory and issue an idiot check to the operator?

Regarding single or multiple screw maps, do all kinematics functions I need to be creating need to apply to 6 axis?

In my 4 axis case (not currently running the 4th but will someday), where I am only currently needing to map X and Y, not Z or A, would it work correctly to have the function look for and import my individual axis map files, then only return corrected values for X and Y (or for only whichever files are existing or valid) while simply returning the original parameters back to z,a,b,and c?

For the adjustment of "m_MotionParams.MaxLinearLength" to match the mapping increments, I am thinking through my options that will allow for updates and recalibration later without rebuilding kmotion files. Right now, I am considering the following options:
• A configuration file to break out some of the params and have them all read in.
• Add the "m_MotionParams.MaxLinearLength" value in the top of the screw map file then compare all found axis screw map files for which has the shortest length and set that as active.
• Have the screw map file import/read process keep track of the increments used then set the shortest active.
Hypothetical, as I consider a flexible config... If I had a 50" screw that needed mapping every 1/2" for the first 10," then is accurate until 30" to 40" where 1" increments min are needed, then good for the remainder of the screw, would the best control approach be to apply increments of 1/2" over the full length or create a variable increment version of kinematic?

Thanks

TomKerekes
Posts: 1854
Joined: Mon Dec 04, 2017 1:49 am

### Re: Basic XY Screw Mapping - Geo Table

Something I see, or think I see, is concerning. My intent is to be able to apply kinematics of individual actuators to provide screw mapping while later, as needed, use the Geo Table for fiduciary type adjustments. Essentially, I assumed the system would blend the two corrections magically with a bit of pixy dust and unicorn farts to give me a smooth and accurate output. Some of what I see gives me concern it is more the situation where it will be either kinematics or geo table. I am hoping I simply am not reading or understanding far enough into the kinematics examples to see where they both do apply together. Can you please confirm do both will work at the same time?
It depends how you write your code. Normally GeoCorrection is performed before kinematics.

While testing my measured values in a 2x49 geo table, I had screwed up and it tried to move a large distance faster than the servos could run. Is there not any protection built into the geo table correction that considers if it will be running into follow error territory and issue an idiot check to the operator?
No checks are performed by the Geo Correction. The outside grid points are extrapolated outward to infinity.

Regarding single or multiple screw maps, do all kinematics functions I need to be creating need to apply to 6 axis?
Not sure what you mean but basically no. Unused axes not in the Coordinated System don't matter

In my 4 axis case (not currently running the 4th but will someday), where I am only currently needing to map X and Y, not Z or A, would it work correctly to have the function look for and import my individual axis map files, then only return corrected values for X and Y (or for only whichever files are existing or valid) while simply returning the original parameters back to z,a,b,and c?In my 4 axis case (not currently running the 4th but will someday), where I am only currently needing to map X and Y, not Z or A, would it work correctly to have the function look for and import my individual axis map files, then only return corrected values for X and Y (or for only whichever files are existing or valid) while simply returning the original parameters back to z,a,b,and c?
Again you could do things however you like. The only disadvantage to that I can see is if a file gets missing or corrupted then no corrections will be made rather than reporting an error.

For the adjustment of "m_MotionParams.MaxLinearLength" to match the mapping increments, I am thinking through my options that will allow for updates and recalibration later without rebuilding kmotion files. Right now, I am considering the following options:

A configuration file to break out some of the params and have them all read in.

Add the "m_MotionParams.MaxLinearLength" value in the top of the screw map file then compare all found axis screw map files for which has the shortest length and set that as active.

Have the screw map file import/read process keep track of the increments used then set the shortest active.
There are existing examples of embedding parameters into the Kinematics.txt file. You might include MaxLinearLength.

Hypothetical, as I consider a flexible config... If I had a 50" screw that needed mapping every 1/2" for the first 10," then is accurate until 30" to 40" where 1" increments min are needed, then good for the remainder of the screw, would the best control approach be to apply increments of 1/2" over the full length or create a variable increment version of kinematic?
I would just use a small constant value. This will simplify the interpolation otherwise some sort of searching may be necessary and the amount of memory you would save would be insignificant.

HTH
Regards,

Tom Kerekes
Dynomotion, Inc.

Posts: 86
Joined: Thu Nov 08, 2018 11:57 pm

### Re: Basic XY Screw Mapping - Geo Table

Tom,

Thanks for the replies.

Did you have any comments about the mapping results I posted prior?

I am unclear what, if anything, I need to do to the "inversion" function "TransformActuatorstoCAD." Do I just re-use the existing as in the 3rod?
There are existing examples of embedding parameters into the Kinematics.txt file. You might include MaxLinearLength.
I had sort of expected to need the extra params in a different file. More than happy to keep with how you have had it done before. I have been looking for format examples of the "Kinematics.txt" file but seem to be overlooking them. Other than a single string of the kinematics name, what else is in there and which example illustrates extra params?

TomKerekes
Posts: 1854
Joined: Mon Dec 04, 2017 1:49 am

### Re: Basic XY Screw Mapping - Geo Table

Did you have any comments about the mapping results I posted prior?
Nothing profound. Looks like max error could be reduced by about half with some slight scaling, but at the expense of making the center sweet area worse.

Not sure what is causing the high frequency "noise". Maybe use a running average or Gaussian filter to smooth it?

Looks quite repeatable going both directions.
I am unclear what, if anything, I need to do to the "inversion" function "TransformActuatorstoCAD." Do I just re-use the existing as in the 3rod?
I believe that should work.
I had sort of expected to need the extra params in a different file. More than happy to keep with how you have had it done before. I have been looking for format examples of the "Kinematics.txt" file but seem to be overlooking them. Other than a single string of the kinematics name, what else is in there and which example illustrates extra params?
See the GetParameter() function and how it is used in CKinematics5AxisTableAB. ie:

The Kinematics.txt file is scanned for a matching name such as:

Regards,

Tom Kerekes
Dynomotion, Inc.

Posts: 86
Joined: Thu Nov 08, 2018 11:57 pm

### Re: Basic XY Screw Mapping - Geo Table

Tom,

Not having fun right now. I know I must be the one shooting myself in the foot. I think subconsciously, I can't stop until I am out of rounds.

I opened the Kinematics3Rod.cpp and .h from within vstudio and saved them as my KinematicsBasicMapping.h and .cpp. Not sure if that is why I am getting errors when I build or rebuild:

Severity Code Description Project File Line Suppression State
Error LNK2019 unresolved external symbol "public: __thiscall CKinematicsBasicMapping::CKinematicsBasicMapping(void)" (??0CKinematicsBasicMapping@@QAE@XZ) referenced in function "public: __thiscall CCoordMotion::CCoordMotion(class CKMotionDLL *)" (??0CCoordMotion@@QAE@PAVCKMotionDLL@@@Z) GCodeInterpreter C:\KMotion435f\GCodeInterpreter\CoordMotion.obj 1

I think I followed through your instructions for adding my .h to StdAfx.h and the check to ccoordmotion.cpp

Was there a more appropriate way to add a class that I bulldozed through?

TomKerekes
Posts: 1854
Joined: Mon Dec 04, 2017 1:49 am

### Re: Basic XY Screw Mapping - Geo Table

It looks like you forgot to add the 2 new files to the project hence calls to the new functions are undefined. Right click in solutions window in GCodeInterpreter - Source Files - Add - Existing Item and select the new .cpp file
GCodeInterpreter - Header Files - Add - Existing Item and select the new .h file

The new files should then be listed under GCodeInterpreter project.

HTH
Regards,

Tom Kerekes
Dynomotion, Inc.