Basic XY Screw Mapping - Geo Table

[MadTooler]

Tom,

I've been busy here. Hope you have been well.

Attached should be my latest basic screw mapping kinematic class. It seems to work properly. It also now will map between the offset/start point and end of map/table length in either screw + or - direction. The kinematics.txt file allows for a few variables to be set as well.

I need to update my measuring program to handle negative measurements and offsets/startpoints. As soon as that is cleaned up, I should be good to go for my final measurement and mapping.

Some final house cleaning of the class questions:

• what is the value behind the define at start of the class.h and should it be any different than what I copied from other classes?
  AFX_KINEMATICSBASICMAPPING_H__876A0A72_6EC3_48D0_9040_60AE3DA2F3C7__INCLUDED_

• In my initialization, do I need to be setting m_MotionParams.MaxRapidFRO = 1.0; and
  m_MotionParams.UseOnlyLinearSegments = true;

• I don't think I do, but should I do anything regarding soft limits within this kinematic?

After doing some very aggressive tests with mapping, I have a few thoughts on notes you may want to add to your GeoCorrection wiki and manual. It would be good to note the correction table, as with my mapping, is best used for small and gradual corrections from step to step of the table. Large variations in correction from table increment to increment can throw the system into a follow error or violent motion. I found deviation in correction percent of +/-10% at 1" increments to be about as much as my system could handle before it accused me of abuse. For example, at 1" increments, if I said the screw measured 0.9" for this increment, 1.1" for the next, it might be OK, but more would crash. Part of that finding was simple torture testing to see how things would fail, but I also had mistakenly and ignorantly assumed I could cheat and use screw mapping or the correction table to more dramatically distort running gcode to morph to a less linear scenario for special cases (trying to avoid doing it with CAM). The intention was to essentially mash or stretch the gcoded program to fit whatever shape of material I wanted it to machine. Cheating never works out well. For those use cases, it appears I need to either make a program to alter the gcode, or go back to CAM.

It is getting there. Thanks again.

[TomKerekes]

Thanks for posting that

what is the value behind the define at start of the class.h and should it be any different than what I copied from other classes?
AFX_KINEMATICSBASICMAPPING_H__876A0A72_6EC3_48D0_9040_60AE3DA2F3C7__INCLUDED_

That's just any unique symbol used to avoid compiling a header file multiple times. It skips the file if it is already defined or if not defined it defines it and compiles the file. For example:

#ifndef Tom
#define Tom
.
.
.
#endif

In my initialization, do I need to be setting m_MotionParams.MaxRapidFRO = 1.0; and
m_MotionParams.UseOnlyLinearSegments = true;

I don't see any reason for MaxRapidFRO. But UseOnlyLinearSegments probably makes sense so that points along an arc will be corrected rather than just the endpoints.

I don't think I do, but should I do anything regarding soft limits within this kinematic?

I don't think so. Soft limits shouldn't be so critical to matter if they are corrected slightly.

if I said the screw measured 0.9" for this increment, 1.1" for the next, it might be OK, but more would crash.

I think it is not the amount of correction but the amount of change from point to point. If one grid area is 0.9" and the next 1.1" then when crossing the boundary the speed will instantly change by 20%. Maybe that's what you are also saying. But it should be possible to perform major distortion as long as enough grids are used so space is still "smooth" (no large changes in gradient).

[MadTooler]

Thanks for the quick responses, yet again.

what is the value behind the define at start of the class.h and should it be any different than what I copied from other classes?
AFX_KINEMATICSBASICMAPPING_H__876A0A72_6EC3_48D0_9040_60AE3DA2F3C7__INCLUDED_
That's just any unique symbol used to avoid compiling a header file multiple times. It skips the file if it is already defined or if not defined it defines it and compiles the file. For example:

#ifndef Tom
#define Tom

I understand the ifndef, I meant the value after my class header name "876A0A72_6EC3_48D0_9040_60AE3DA2F3C7." I do not know what that is and if it needs to be different than the other kinematic classes that I stole it from.

if I said the screw measured 0.9" for this increment, 1.1" for the next, it might be OK, but more would crash.
I think it is not the amount of correction but the amount of change from point to point. If one grid area is 0.9" and the next 1.1" then when crossing the boundary the speed will instantly change by 20%. Maybe that's what you are also saying. But it should be possible to perform major distortion as long as enough grids are used so space is still "smooth" (no large changes in gradient).

That is what I meant and what I experienced. Enough points with minor enough changes between them is all good. With the values I used as example over a single point, it is a bit too intense.

The other note I meant to suggest adding to the wiki was the potential to create a correction table that pushes the machine past the max feedrates or even the expected cutter speed. Again, that is with a major distortion, but still need to know.

I will post my measurement code when it is working. I think I can get it all without asking for any hand holding

[TomKerekes]

I understand the ifndef, I meant the value after my class header name "876A0A72_6EC3_48D0_9040_60AE3DA2F3C7." I do not know what that is and if it needs to be different than the other kinematic classes that I stole it from.

Ah. That is basically a random number auto generated by some tool like Visual Studio to make the symbol unique from all other classes in the world when asked to create a new class.

[MadTooler]

Tom,

I think I may be at the end of this journey. Don't worry, I have more planned.

Attached should be my hopefully final version of my kinematic class with related files and the couple c programs I run from within KmotionCNC to get the map values and measure the mapped screw after done. I also included a sample screw map data file. The kinematic and programs all now have more checks and message box prompts for better operation.

I hope others may find them of use. My measuring and checking programs have a bit of specific setup to my equipment. Someone could modify them for really basic corrections via a tape measure or 123 blocks or whatever if they were not using as critical of a system. If someone was feeling a bit lazy with their non linear system, they could possibly map their actuator with small enough increments to get away with a relatively accurate system as well.

Thanks again for all the help and in-depth guidance.

[MadTooler]

A final question in my setup with my mapping, regarding look ahead...

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.

Where I will be using 0.1" "grid" or increments on my maps and same for maxLinearLength, and my max system speed would be 250ipm, what would be recommended for a smooth full 3D path look ahead?

I am currently running with 5 seconds. I am a bit unclear what I should be shooting for here for fluid full 3D surfacing motion.

[TomKerekes]

The look ahead time shouldn't normally have any effect on smoothness. The smaller of the MaxLinearLength and the length based on current feedrate and look ahead time is used. Say as an extreme example a segment 0.1" has a specified feed rate of 0.1ipm. If that one segment was downloaded then the motion for the next full minute would be determined and nothing (except hardware FRO) could be changed for a minute. So in this case the segment would be subdivided. In this case the segments per second rate is very low and there isn't any worry about exceeding the max segment rate.

To be most responsive to changes the lookahead time should be set to the minimum time that still allows the motion to be continuous when the PC/Windows/USB freezes for a period of time. Unfortunately its hard to say what is the maximum time it will ever freeze. It is dependent on many things like the Version of Windows, hardware, drivers, apps, memory, Ethernet, etc. But I think 1 ~ 2 seconds is normally sufficient. If the PC freezes for longer than the lookahead time then KFLOP will momentarily and exponentially slow the motion to prevent running out of data. This means that the path should still be maintained but not at the specified feedrate.

Another advantage to a lower lookahead time is faster startup. On Cycle Start KMotionCNC downloads data until lookahead time of data has been downloaded and then KFLOP begins executing the motion. If the segments are numerous and small then this may be something like 1/2 the lookahead time. This also occurs whenever the motion is flushed by something like executing a User Program.

There is another quirk that isn't common but occurs with some extreme configurations. KFLOP determines based on the Axis settings what is the longest time ever needed to make a stop from maximum velocity. If the amount of buffered motion is less than this stopping time then KFLOP slows down. Take for an example an extreme case where a system has high speed and low acceleration and Jerk such that it takes 5 seconds to stop. But then the lookahead time is limited to 2 seconds. In this case KFLOP will always slow down as it never has enough data to be assured it could stop before running out of data. So the lookahead time would need to be increased.

HTH

Thanks again for sharing

[MadTooler]

That was insightful. Thank you.

My dedicated PC/laptop running this machine is a meager i3 running win 10 64b. I do not remember exactly the ram, but it probably only 6g. Nothing to brag about.

I do not remember why I raised the look ahead to 5 seconds except a concern about the basic PC being slowed down by simple tasks and background wifi file transfers while it is running gcode. I typically try not to do anything with the PC while it is running gcode. I am still a bit hesitant to go too low on the look ahead for this reason. Based on the downsides you noted, I am not too concerned with keeping it at 3 or 4 seconds.

I also have some recollection of look ahead having some relation to soft limit performance. I could be wrong. Other than extreme cases that may be affected in related acceleration situations, as your last note mentioned, is there anything between soft limits and look ahead to consider?

FYI, I had a fat finger typo to the ScrewMapAxis.c file I posted yesterday. I fixed it and reposted it in the prior message.

[TomKerekes]

I'm not aware of any interaction between Soft Limits and Lookahead.

[MadTooler]

I have moved my scale to my Y axis and have been doing some mapping. Overall working well, but I do have an annoying hiccup.

With the ScrewMapAxis.c program and the ScrewMap_Check.c, both throw errors in via my serial print and message box for bad total distance not being a whole multiple of my increment distance under certain values that should actually be OK. This is something to do with double math or precision from the values set with #defines. For example, if you set the #define INCREMENT_DIST 0.1 and #define TOTAL_DIST 48.8, the error checking does not come up with a proper division of 48.8/0.1 where the result should be 488. It instead results in 487. This error appears with increment settings of 0.1 and total distance values of XX.3, XX.4, XX.8, and XX.9. As a work around, if I set the value to float, as in #define INCREMENT_DIST 0.1f and #define TOTAL_DIST 48.8f, then it works, but there is some very minor error in some of the calculated outputs (not major enough to matter but it bugs the hell out of me).

So, it works, but it has some issues rooted in type error/precision/rounding and my lack of better math practices with them. I don't think this is a super critical problem for my application, but I thought I should mention it in case anyone else plays with my code.