Basic XY Screw Mapping - Geo Table

[MadTooler]

I am planning to fixture a glass linear scale to my 3 axis gantry router to map my rolled ball screws in X and Y. The goal is to shoot for +/-0.001" positional accuracy (not under load), but realistically would be super happy with +/- 0.002 or even 0.003. My Z is already pretty good via slight encoder count adjustment after a process with a dial indicator.

My machine has brushed DC servos via SnapAmp with max rapids of 240ipm on all axes. 28,000 encoder counts/inch X, 30,000 Y, and 20,000 Z. It is sometimes run at the full speed for full 3D surface machining.

Looking at the Geo Table documentation in the manual, wiki, and anything I could find here and on cnczone, I am a bit short of fully understanding the ideal grid size, best approach in table format, if there is already an example code for screw mapping, and if/when/where the "m_MotionParams.MaxLinearLength" value should be tweaked.

1) Grid size. I have 49" travel in both X and Y. I noted max geo table size is 4,000 x 4,000. I was considering 0.1" grid size since I have standard precision rolled screws and not that long of travel. Maybe 1" grid would be OK, but I would error on tighter if there is not a processor or speed issue. Is there a recommended size for this application or any downside to 0.1?"

2) Table format. If I am only measuring and correcting the screw travel without trying to fix skew, square, straight, or other issues at this time, would I still need a table with columns and rows of the entire table? For example, if I was using a 1"x1" grid for my 49" x 49" travel, would I have to fill in all 50 x 50 entries for 2,500 total coordinates, or is there a shortcut 2 column x 50 or something else like that?

3) Example code. I expect to be reading a Heidenhain linear glass scale with TTL output. The scale will be temporarily fixed to the table with the reader mounted to the spindle. This would allow one axis to be measured, then remounted for the other axis. My ideal plan will be to write a C program to step through the grid sizes and write the linear measured values to a file. For now, I expect this would generate two files that I would then run through excel to format into a single table. Maybe I would create a separate C program to do the consolidation, but I would have to learn how to read/write within C first. Is this all something that has been done in the examples or features I have overlooked or were you considering adding it?

4) "m_MotionParams.MaxLinearLength" adjustment. Per the various forum threads I have read on nonlinear kinematics and for fast full 3D surfacing, I believe it may be necessary to adjust this parameter for the geo table to work as desired. I think it should be changed from the default infinite value to match my grid size. Assuming that is correct, is there any access to this parameter from my custom C programs called and run from KmotionCNC, or will I have to go to "Kinematics.cpp" in the "GCodeInterpreter" directory, make that change, then recompile the entire project in VS2015?

Thanks and stay healthy.

[TomKerekes]

Hi MadTooler,

I think you should collect the correction data then decide based on the magnitude of the correction and the shape. If it is a smooth shape like a parabola over 49 inches with only a few thousands of an inch in magnitude then a table with only several points would be adequate.

1) Grid size. I have 49" travel in both X and Y. I noted max geo table size is 4,000 x 4,000. I was considering 0.1" grid size since I have standard precision rolled screws and not that long of travel. Maybe 1" grid would be OK, but I would error on tighter if there is not a processor or speed issue. Is there a recommended size for this application or any downside to 0.1?"

The downside is memory usage. Each table entry is 4 doubles (32 bytes). PCs have lots of memory these days.

2) Table format. If I am only measuring and correcting the screw travel without trying to fix skew, square, straight, or other issues at this time, would I still need a table with columns and rows of the entire table? For example, if I was using a 1"x1" grid for my 49" x 49" travel, would I have to fill in all 50 x 50 entries for 2,500 total coordinates, or is there a shortcut 2 column x 50 or something else like that?

There is currently no shortcut.

3) Example code. I expect to be reading a Heidenhain linear glass scale with TTL output. The scale will be temporarily fixed to the table with the reader mounted to the spindle. This would allow one axis to be measured, then remounted for the other axis. My ideal plan will be to write a C program to step through the grid sizes and write the linear measured values to a file. For now, I expect this would generate two files that I would then run through excel to format into a single table. Maybe I would create a separate C program to do the consolidation, but I would have to learn how to read/write within C first. Is this all something that has been done in the examples or features I have overlooked or were you considering adding it?

See the example DiskWriteRead.c

Code: Select all

#include "KMotionDef.h"

main()
{
	FILE *f;
	char s[256];
	double a=123.456,b=999.999,c=0.001;
	double x=0,y=0,z=0;
	int result;
	
	// write 3 comma separated values to a disk file
	f=fopen("c:\\Temp\\KFlopData.txt","wt");
	fprintf(f,"%f,%f,%f\n",a,b,c);
	fclose(f);
	
	// read them back in
	f=fopen("c:\\Temp\\KFlopData.txt","rt");
	if (!f)
	{
		printf("Unable to open file\n");
		return;
	}
	
	// read a line and convert 3 doubles
	result=fscanf(f,"%lf,%lf,%lf",&x,&y,&z);
	fclose(f);
	
	printf("# values converted = %d, x=%f, y=%f, z=%f\n",result,x,y,z);
}

4) "m_MotionParams.MaxLinearLength" adjustment. Per the various forum threads I have read on nonlinear kinematics and for fast full 3D surfacing, I believe it may be necessary to adjust this parameter for the geo table to work as desired. I think it should be changed from the default infinite value to match my grid size

It doesn't necessarily have to match your grid size, but yes it makes sense to have them both smaller than some amount to limit "cord errors" caused by approximating a curve with linear segments.

is there any access to this parameter from my custom C programs called and run from KmotionCNC

no

or will I have to go to "Kinematics.cpp" in the "GCodeInterpreter" directory, make that change, then recompile the entire project in VS2015?

yes

However the linear length is also limited by the feed rate x 1/2 the Lookahead time. So for example if the feed rate is 120ipm and lookahead time is 2 seconds then the segments will be limited to: 120/60 x 1/2 x 2 = 2 inches.

Thanks and stay healthy.

You too

[MadTooler]

Tom,

It's been a while. Hope all is well.

I am curious if a basic screw mapping feature, not through a geo correction table, is anywhere in the future?

I was thinking some of my future applications that would require a simple geo table for correcting to registration marks or fiducials may not be possible if I want to keep the screw mapping values as well.

[TomKerekes]

Hi MadTooler,

Nothing currently planned. I suppose it could be added to the Kinematics class. You could also just apply any transformation to the geo table values.

[MadTooler]

Tom,

I like the idea of using the Kinematics. That seems to me like a better place to handle this. I would hope it easier on RAM as well.

I scanned over the Kinematics pages in the wiki. Without reading in full, I am wondering if a new kinematic for screw mapping would be dealing in steps or lengths or both?

Which example kinematic would be the best starting point?

Thanks

[TomKerekes]

Hi MadTooler,

Like the Geo Correction the units would be inches.

Something like that would be added to the base class CKinematics so it would be applied to all Kinematics.

[MadTooler]

Tom,

If I do take the road of screw mapping, I will definitely need some hand holding to get through the full kinematics process. I saw some of the threads where you helped others. Maybe those will be enough when I fully read through them.

First, I have to figure out if my machine and process will benefit enough to justify the significant amount of labor. I already have a scale on hand that will be suitable, but the best I can do for mounting the scale will be on the machine's table, not directly next to the screws.

If I decide to do it, I hope to begin scale integration in the next few weeks.

Thanks again,
MadTooler

[MadTooler]

Tom,

Alright, I am going to begin my path down the rabbit hole, at least in theory. I am sure I should and could improve my gantry router with glass scale measurement corrections applied with screw mapping. What I am not yet sure of is if I will be able to fully set aside the time and interrupt production for long enough to implement the changes now. Regardless of whether I will be able to apply the mapping in the immediate future or not, it very much seems like a useful and essential core feature for an industrial CNC control, so I will move forward describing my current wish list features and questions regarding how to best apply them.

Screw mapping wish list:
From within KmotionCNC setup pages, a check box for each axis to have screw mapping applied individually and an external file name/location field next to it for that axis data only (independent of but similar to external file of the geo table, but prefer individual axis instead of all per file). It would be ideal if this was a base feature that does not require re-compiling and can have the file easily updated after maintenance and periodic machine re-calibration.

From what you have detailed here and other areas I have read, I think I understand the current closest solution is to create a new Kinematic class with the screw data packed into the code at compile time without any ability to change it from KmotionCNC after compiling. Is that very basically the case?

Regarding the screw mapping measurements, I would like to, at a minimum, have measurements at corrected inch intervals for the length of my XY 49" travels, no need for my Z to have any corrections right now. More would be nice, maybe per rotation of the screw (.2" or 4000 counts), but I am not sure what is wise when approaching the Kinematics processing.

Your thoughts?

[TomKerekes]

Hi MadTooler,

I am sure I should and could improve my gantry router with glass scale measurement corrections applied with screw mapping.

Well if you add glass scales to a system it is usually better to make the system closed loop on the glass scales which makes screw mapping somewhat uneccesary.

What I am not yet sure of is if I will be able to fully set aside the time and interrupt production for long enough to implement the changes now.

You should copy your KMotion folder and make sure you can run out of either folder before making any changes. You should then be able to switch back and forth between the experimental version and the version you have been using if you need to run production in the previous mode.

From what you have detailed here and other areas I have read, I think I understand the current closest solution is to create a new Kinematic class with the screw data packed into the code at compile time without any ability to change it from KmotionCNC after compiling. Is that very basically the case?

Probably not. To make some sort of change to make some sort of correction because you have to change the code and re-compile anyways it may be simpler to hard code any parameters that are need to make the correction. But if some sort of a table of data is needed it may be as easy to read in a table of data rather than hard coding it. Once you have done this changes in the data will not require a re-compile.

Regarding the screw mapping measurements, I would like to, at a minimum, have measurements at corrected inch intervals for the length of my XY 49" travels, no need for my Z to have any corrections right now. More would be nice, maybe per rotation of the screw (.2" or 4000 counts), but I am not sure what is wise when approaching the Kinematics processing.

so that works out to be a 49 / 0.2 = 245 x 245 point table. Which the current Geo Correction table could handle easily. You might write a KFLOP C program to read the two screw mapping files 1 x 245 each and create a 245 x 245 Geo Table so no changes would be required.

[MadTooler]

Tom, Thanks for the replies.

Well if you add glass scales to a system it is usually better to make the system closed loop on the glass scales which makes screw mapping somewhat uneccesary.

I am not adding scales to the machine. I will temporarily mount a single scale on the table to get measurements in X then Y. In other applications, one may use a laser system to acquire these measurements.

so that works out to be a 49 / 0.2 = 245 x 245 point table. Which the current Geo Correction table could handle easily. You might write a KFLOP C program to read the two screw mapping files 1 x 245 each and create a 245 x 245 Geo Table so no changes would be required.

I know I could use the current Geo Correction for now, but in the future I will not be able to also use the Geo Correction for work and part correction/alignments. It is also forcing me to burden the system with 245 x 245 instead of 245 x 2 (one for x and one for y). I need to look back, but I think I would also need to change "m_MotionParams.MaxLinearLength" to match the 0.2" and recompile anyway.

If I were to use the Geo Correction for now, should I expect any limitations or down sides in performance/precision/repeatability vs. kinematics, aside from memory usage?