Basic XY Screw Mapping - Geo Table

[TomKerekes]

BTW, I tested the GetParameter() calls while I still had a pretty much bare install of kmotion files and it still did not look the "c:\KMotion435f\KMotion\Data" directory. I had to modify the start of the function same as before with "FILE *f = fopen(".\\KMotion\\Data\\Kinematics.txt", "rt");" Unless there is something I could have tweaked with my machine config files in the data folder, I don't think the default is working as intended.

idk. I tested it and it works for me. When you have something that simply fails it should be very easy to debug by working backwards.

Regarding the GeoTable potential problem as I ran across with my 10" fun, earlier I had made a double column test table from my initial 1" increment x 48" measurements and it ran properly. Not sure why it worked if it should have been plagued too.

Did you have a GeoTable selected? If not, that would explain it.

[MadTooler]

Did you have a GeoTable selected? If not, that would explain it.

Yes. I know for sure it was using it because it corrected my positions accurately for the full length of travel.

[MadTooler]

While I have some msg boxes popping up during the start of my kinematic class for debugging, I have noticed them pop up as I open Kmotion and again when I open KmotionCNC. Does this mean, roughly, that Kmotion and KmotionCNC both create instances that then communicate with Kflop?

I didn't expect this. Is this normal, or do I need to have some check if already loaded?

[TomKerekes]

Yes they both create their own instances of the GCodeInterpreter/CoordMotion/Kinematic Classes. KMotion would not normally use them.

[MadTooler]

Some results to check out. See the pdfs. The "ScrewMappingResults_X_full_48_700x0_100" is the same as you saw before. The "check" versions are measured based on the scale at gcode commanded positions. I also added the check version of the excel file.

One check file is for only 25" of my travel at 0.05" increments. In order to calc the backlash, I cannot create a double array to track the previous positions large enough not to crash Kflop (array size somewhere between 500 and 1000 kills it).

The other is full 48.7" of travel at 0.1" increments. That is the same as was measured in the error mapping before.

It looks pretty good, but I am not sure why there is such a linear gain in error. Even though it is less than 0.001", it still bothers me since it looks like it could be corrected. Seems like maybe 10" of measured error before applying the map.

Something else weird, the screw inch values have some error at the 6th decimal after a while. Those are the result of the row number * the float increment. How it gets some deviation is beyond me.

[TomKerekes]

One check file is for only 25" of my travel at 0.05" increments. In order to calc the backlash, I cannot create a double array to track the previous positions large enough not to crash Kflop (array size somewhere between 500 and 1000 kills it).

I looked through a previous C program and found this declaration inside the main function:

int screwIncrementStepPos[NUMBEROFSTEPS] = { 0 }; // MAKE SURE NUMBEROFSTEPS IS LARGER THAN NEEDED OR MACHINE WILL ACT POORLY

Variables declared inside functions (not declared static) are placed on the stack. KFLOP User programs only have 2KByes of stack (500 ints).

Add 'static' or move outside of functions to place in global memory where there is 64KBytes.

Or use a pointer to the gather_buffer where there is 8MBytes.

It looks pretty good, but I am not sure why there is such a linear gain in error. Even though it is less than 0.001", it still bothers me since it looks like it could be corrected. Seems like maybe 10" of measured error before applying the map.

It's not entirely clear what you are doing or expecting. Did you apply any smoothing? Do you think the high frequency stuff is real?

Something else weird, the screw inch values have some error at the 6th decimal after a while. Those are the result of the row number * the float increment. How it gets some deviation is beyond me.

I see the Increment is defined as a float. It turns out 0.1 in binary is a repeating decimal so can not be represented exactly. As a float It will have an error after 6-7 decimal digits. If you remove the 'f' then it will be treated as a double and have 16 digits or precision.

#define INCREMENT_DIST 0.1f // float distance in inches of test measurements MAKE SURE THIS WILL RESULT IN FULL SCALE COUNTS PER INCREMENT

[MadTooler]

Tom, as usual, very helpful and enlightening.

It's not entirely clear what you are doing or expecting. Did you apply any smoothing? Do you think the high frequency stuff is real?

My goal is to improve positional accuracy. I would say it is within +/-0.001" now, if I sort of ignore the backlash. Overall, I am happy with it.

Regarding the "high frequency" stuff, yes, I think it is real. The data is the actual physical measurements from a 1 micron scale while stopped at various points. The noise is a cumulation of the rolled, not ground, ballscrew that has some warbles in it, the mechanical stiction and slop, and the scale reader head a bit farther from the ball nut than desirable. It is interesting to see, but not entirely surprising considering all that.

Smoothing? I don't know how I would smooth physical measurements without a grinder My increments of my correction table could be larger than the 0.1" I have been playing with, but would that have a smoothing affect? Not really sure.

With the seemingly linear growth in error I saw when measuring to see if the mapping worked, I had a thought (mostly pay attention to the green line). It is so linear, at least to my eye, I was wondering if it could be thermal. We are in winter here in Missouri. I let the machine run the axis back a fourth a couple dozen times and re-ran the check pattern. From my thermal camera, I think the screw warmed up about 2deg C. And shazam, the error was positive instead of negative. Exactly what I would expect if the screw was warmer when I had taken the measurements that are in the screw map correction table vs. the cooler temperature the screw was when I did the mapping check earlier today. The error amount and the variability of it is more similar to the path of the mapping as well. Sorry, I realize I may be poorly describing all of this.

I have been wondering about temperature and when would be best to take the mapping measurements. My shop is climate controlled, but really cold or hot days keep my HVAC struggling to keep up. Summer is worse than winter. Realistic that I could operate as low as 55F in the winter down low near the floor and pushing 90F in the summer on the over 100F days outside.

[TomKerekes]

Regarding the high frequency stuff: I suspect it is noise. Either in the measurement or the mechanics. ie on one move it over shoots a bit into the backlash and on the next it doesn't. If you make a run one day and another on a different day does the high frequency stuff overlay well? if not then you are probably worse off trying to make corrections for it than not. If not I would smooth the data with something like a running average. ie replace each point with the average of the +/- 5 points. After smoothing you could probably get by with fewer points in the table, but then there is really no benefit in having fewer points.

Thermal expansion is probably significant. With a 10F change over 48 inches I get an expansion of:

0.00000645 x 10 x 48 = 0.003 inches

I wonder if it would make sense to incorporate a thermometer and make a correction?

[MadTooler]

The "check" results were generated by using gcode inches to get into position while running the screw mapped kinematic. That means the motor very likely had a little bit of reversing as it closed in and finalized position. With backlash and mechanical issues, that means all that extra was fed into the resulting scale value. That is why some of the results on that run are "sloppy." That run took under 10 minutes for 0.1" increments forward and back along my 48.7" travel. Yes, multiple runs do have some variation due to the mechanical slop.

The runs where I try to pull the most accurate positional data from the screw vs. scale that I then use by the kinematics to map the screw were achieved differently. With that program, the screw is commanded short of the target scale position in screw positions. Then even slower and closer to the scale position, to within 5 or 10 screw/motor encoder steps. Then a single stepping of the screw/motor steps until it hits the desired scale position. That process, at 0.1" increments forward and backward over 48.7", took about 2.5 hours. Looking at multiple runs, the results are pretty consistent.

If I were to run a check in a similar manner to my initial measurement method (biggest difference being I would have to go to inch instead of position), I would expect rather consistent results, aside from thermal affects.

Regarding thermal expansion, a 0.001"ish difference in my earlier assumed cooler run vs the warmer last run fits very closely to the expansion calculation. My screw material is 1050. That is closer to a CTE of 6.39.

I wonder if it would make sense to incorporate a thermometer and make a correction?

Well, I could, but is it enough to matter, even over twice that temperature for 0.006"? I don't know. On my machine, realistically probably not. On the other hand, I love control Air temp vs screw temp might be pretty far off. Even if I did add it, that would be about 3.5 encoder steps per inch total variance (count of 28,000/inch on my X). Why do I feel like the rabbit hole just got deeper?

[MadTooler]

http://www.matweb.com/search/datasheet_ ... 351cf8072d
Oops, that math and spec are off. 6.39 is per deg F. That would mean over a HUGE 50 deg F range, I could see 0.015" total variance. That would be extreme, but possible if I run at the beginning of a cold day vs. Stupid hot summer. I think I want to check me some temperature