Basic XY Screw Mapping - Geo Table

[TomKerekes]

The obvious thing would be your table range is 10 inches and there isn’t any test for going outside the table and using garbage data. You might post the code you are testing and files.

[MadTooler]

My table is larger than 10 (48.7) and the control will move either via jog or gcode beyond 10. With jog, the DRO stops at 10 and then it will bring the axis back to 10 as soon as I let off the jog button. With gcode, it will run to the commanded position, again with the DRO stopped at 10, but then the axis will disable after it reaches the commanded position.

For past the table data, I do not have an over table check in place yet. I was going to look into how you did it with the geo table. For less than 0, I am simply returning the incoming axis value. I realized this also makes my current kinematic limited to simple 0 to + mapping.

I am away from my files right now. I will send copies as soon as I get back and try a couple more things. I may also try a fresh kmotion set of files since either I goofed up something or the limit to 10" is elsewhere since I am getting it now even when I completely bypass all of my kinematic calcs.

Is there anything with the inversion or actuator to CAD (I don't remember the correct function) that could cause this? I have no idea how those are suppose to work. For now I am using the same as was in the 3rod example.

Thanks again for all of your help.

[MadTooler]

Alright, I started fresh with an empty kinematics class and a fresh C:\KMotion435f file set. All I did with the TransformCADtoActuators() in my class was to update the Acts[] with the same values that were sent to it *m_MotionParams.CountsPerInch.

I do not have a geo file correction table defined within KmotionCNC tool setup.

It still will only go to 10" on the DRO when the kinematics.txt file is present with my class named.

What else can be causing this?

See attached.

Thanks

[TomKerekes]

Ah, I think I see it. As you guessed I think it has to do with the Actuator to CAD solver - InvertTransformCADtoActuators.

The way the solver works to find the CAD position is it first makes a guess at the CAD position. It then uses TransformCADtoActuators to find that position in Actuator Space and then the error in Actuator Space. It then finds the sensitivity by moving slightly in all possible directions (one at a time) and recording the effect each movement has on all the actuators. With this information a set of simultaneous linear equations is solved to determine how the CAD Position should be adjusted to correspond to the desired actuator positions. If the system was linear then this method would provide an exact result in one shot, but if non-linear would likely result in some error, but hopefully a greatly reduced error. So the process is repeated until the CAD position converges and no longer changes significantly (Tol = 1e-6).

CKinematics makes an initial guess of (0,0,0,0,0,0). There are probably a number of ways to make better guesses but that can get complicated and so far hasn't been necessary. In your case a guess involving no screw mapping might work well if there isn't major GeoCorrection in play.

There is an issue with making a poor initial guess on a highly nonlinear system. If the guess is in a region where Actuators happen to not move the Axis much, then a large correction may be computed. As the actuators move they may move to a region where they move the axis a lot. The result may be an overshoot. If the overshoot is severe the result may be the process diverges or oscillates rather than converges. So to solve this problem and being very conservative CKinematics only attempts to move 0.1 inch (hard coded) toward the target each iteration. The idea is that the movement of 0.1 inches should be fairly accurate as effects should not change drastically within a region of 0.1 inches. So the answer should "walk" ~0.1 inches at a time toward the target and then quickly converge.

CKinematics also has a hard coded limit of 100 iterations. So starting at 0 and making 100 x 0.1 inches places a limit of 10 inches.

So I think the solution it to override InvertTransformCADtoActuators in your class and do it slightly differently. ie just change the d=0.1 to d=1.0 to allow it to walk 100 inches to find the solution.

Sorry for the lengthy explaination.

[MadTooler]

Thank you for digging in and finding the root.

The more I learn, the more aware I am of how little I know. I need to be careful how much more I try to learn

I had seen the 100 iterations and the d=0.1 and wondered if that was related. Even with your explanation, I still am far from understanding the role it plays. I don't think I need to as long as I understand if it will still be accurate with modifying it to d=1.0.?

So I think the solution it to override InvertTransformCADtoActuators in your class and do it slightly differently. ie just change the d=0.1 to d=1.0 to allow it to walk 100 inches to find the solution.

Do you mean to copy the InvertTransformCADtoActuators from CKinematics.cpp and make my own in my class with the same code except changing d=1.0?

Will that still be appropriate if I end up mapping corrections as low as 0.1" in my table (probably 0.5 for my X that you saw results from but expecting Y may be more out of wack)?

[MadTooler]

Well, I made a InvertTransformCADtoActuators in my class that was a copy of the function in Kinematics.cpp with the only change being the declaration of "double d=1.0;"

That did the same 10" issue.

I then changed the d back to d=0.1 and changed the for loop to go to i<1000; That actually ran for the full length, but what did that do? Gives me concern it could be creating some sort of processing issue, more so when doing 3d surfacing?

[TomKerekes]

Oops I'm sorry my mistake. The 'd' variable relates to the amount in CAD space to step in each direction to determine the sensitivity, not the distance to "walk". The code that should be changed would be:

Code: Select all

		if (ex > 0.1) ex = 0.1;
		if (ex < -0.1) ex = -0.1;
		if (ey > 0.1) ey = 0.1;
		if (ey < -0.1) ey = -0.1;

The 0.1 should be changed to 1.0.

I don't think it is a major performance issue as this is only performed occasionally to update the DROs or to determine a final motion and the PC is so blasted fast.

[MadTooler]

Tom, thanks for the clarification.

I don't think it is a major performance issue as this is only performed occasionally to update the DROs or to determine a final motion and the PC is so blasted fast.

To be clear, by performance you are referring to the PC's performance and not the smoothness and accuracy performance of the motor control?
If the potential for error in updates to the DROs is while in motion and not at a rested point, that is not an issue. As long as the final motion determination does not mean a sloppy or rough end of motion or coordinated position of the machine, I guess not an issue either.

All of my current upgrades are an attempt to achieve more accurate results. If the affect of making these changes is going to result in rougher or less accurate path following, then they would undo the potential gains of a more accurate screw position. I am going to be machining full 3D surface molds. With my prior setup, it worked fairly smooth, but I am going to be making much larger mirrored and mating molds that will make any errors in my positional accuracy much more notable. Do you believe making these tweaks will still be an improvement?

Regarding changing the 0.1 variables you last noted, processing performance aside, would there be any difference in machine accuracy changing those to 1.0 vs. increasing the iterations to 1,000? Same question but when considering the size of table increments of the smallest being 0.1" and largest probably 1"?

Curious, is the Geo correction table you already have accessible through KMotionCNC not using the InvertTransformCADtoActuators? If it is, it does not seem to have any issue with the 10" thing. If it doesn't, is whatever method it uses more appropriate here too?

Thanks

[TomKerekes]

Good point. The max 100 of 0.1 inch "steps" was introduced in Version 4.35c. This would cause a problem for anyone using a GeoTable (without a special Kinematics class) with axis positions beyond +/-10 inches. I'm surprised no one has reported a problem.

Regarding performance: I was referring to PC CPU usage. If the PC has tasks to perform that require more than 100% of the CPU then the PC will get sluggish and possibly not be able to compute motion trajectories in time, which would cause motion slow down, and so forth. So I look at what percentage of the CPU a certain task will consume and if the task consumes a significant amount of CPU time then it should be looked at to see if it can be optimized or performed in another way. I just benchmarked the InvertTransformCADtoActuators function doing a 100 step walk and it takes 25us on my i7 processor to complete. Removing the 0.1 inch limit it completes in 1.45us. This task is only required to update the DROs (actually called twice) every 100ms and occasionally after a Jog or Job to sync the GCode Interpreter to the machine position. 50us every 100ms. So it is using 0.05% of the PC's CPU. Not very significant.

Changing the 0.1 inch to 1.0 inches will have no effect on machine accuracy. It will still converge down to a +/- 1 microinch result. The only disadvantage is that a highly nonlinear system may diverge instead of converge and the result would be totally wrong. Your type of system is 99% + linear where the corrections are thousands of an inch over inches so diverging should never be an issue.

I can't remember the GeoTable type that required the "steps" in order to properly converge.

[MadTooler]

Excellent. Your detailed info on performance and accuracy gave me relief.

I added two lines in my kinematics.txt. One for the 0.1 walkDistance value (using 0.5 for now since I don't need more than 50") and for the walkIterations. It doesn't sound like I need the walkIterations, but will leave it for now.

I have my kinematic working for x and y now. I need to consider the logic of z where mine goes in the negative direction.

They are still very much under construction, but you can see where I am at with the attached files. The **** comments are areas I know I need work.

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.

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.