Skew correction/perpendicularity correction (millkins or millkins_xyz)

I am trying to use software based skew correction on my 3040 milling machine.  I have tried to adjust it manually and it's just badly made and I would have to modify it by re drilling some holes etc. to get it perpendicular mechanically.  Also there is usually at least a bit of extra adjustment that's hard to do mechanically, especially if all the axis need shimming etc. it really takes forever.  I was hoping I could do it in software.

Worst case scenario I guess I could post process the gcode but that will lead to errors in the parts, pretty minor for my purposes, also it's best to address error sources as close as practical to the root.

This entry had me all hopeful but there are a lot of problems with it, mostly it incredibly ancient and obsolete:http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ContributedComponents#millkins_trivial_kinematics_extended_by_XY_skew_correction

I spend about 6 hours digging through layer after layer of issues.  comp has been replaced by halcompile, emc2-dev sounds like it was a module, linuxcnc-dev is another thing but not clear to me even now if it's a module that appends to the rest of linuxcnc or like a whole forked code base that (hopefully) shares something in common with the main user branch of linuxcnc... 

I am using the .iso file from a usb drive, downloaded about 6 months ago.  I think it's version 2.8.
At first I was miffed that you can't compile stuff using the iso, I thought that sort of thing was part of the open source thing, but now I see how big linuxcnc-dev is so maybe that's why...

Also very unfortunate that millkins is not included, but now I am thinking that's probably because it's not really done.  It is very short, not very much code at all and skew correction is commonly needed on cheap machines so I think it would be good to include it.

Turns out millkins_xyz.c has an issue with the code where probably the guy changed the file name at the last minute before uploading it and didn't test it, after modifying millkins.c  .  The component names etc. in the .c file are wrong.  I just changed the file name back to millkins.c before compilation and install.

So after laboriously installing linux-cnc to get halcompile, I was able to run: sudo halcompile --install /home/anthony/Desktop/3040-1/millkins.c

Said it worked ok. I check in the folder where the hal modules are and looks good.

I modified the beginning of the 3040-1.hal file (the configuration is named 3040-1) to read:# Generated by stepconf 1.1 at Sat Aug 12 17:15:10 2023
# If you make changes to this file, they will be
# overwritten when you run stepconf again
loadrt [KINS]KINEMATICS
setp millkins.skew_y 0.100
setp millkins.skew_xz 0.000
setp millkins.skew_yz 0.100
loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[KINS]JOINTS
.....
Then I modified the 3040-1.ini file to read, in the relevant section:[KINS]
JOINTS = 3
KINEMATICS = millkins


This all took many tries of course, but that's where I ended up.  Sorry if the forum stuff is garbling the hard returns etc.

Now if I double click on the configuration on my desktop, it opens up ok. I can look at the hal configuration and it shows the millkins_y.skew and other variables set the way they are apparently supposed to be.

Ok. So far so good.

But when I move the axis, they all just move in a straight line. Nothing has changed. When the x axis moves the y has to move too in order to do skew correction. It's not moving. Everything is as skewed as it ever is. Ideas?

Here is the component for millkins by the way, it may only work in the exact context of the linuxcnc 2.8 from live install or something who knows but at least you don't have to go through the epic ordeal of trying to compile it: drive.google.com/file/d/1aEv_BwgTv8Liola...dvw/view?usp=sharing 

The wiki is very old and doesn’t get updated that often.
Some of the code on that page is from 2.6 days, I know I add issues with hidcomp mentioned on that page.

So it would that moving the X axis no other axis would move as this is “base” axis.
When moving the y axis there should be some movement of the Y axis.
Have you checked this with an indicator or dial gauge to confirm ?
Depending on the amount of skew the movement may not be noticeable.
The linuxcnc-dev package includes header files and halcomplie and other such stuff needed to build components that are included with the main part of linuxcnc.

I know you probably don’t want to hear it and probably know this yourself, but fixing the hardware issues is the best course of action. It’s a pain but it’s just the nature of beast.

Yeah I guess you are right fixing the hardware is the best, but like I said there is still that last 100 microns or something that is really hard to mop up mechanically on a cheap machine. Better machines have provisions for adjustability so you can tap things into position, but cheap ones you have to use shims which can be pretty finicky and complex as the old ones fall out when you put new ones in, they compress, affect vibration and rigidity etc. etc.

I moved both x y and z and neither of the other axis moves at all over the whole distance of the axis. I just put my finger on the knob that connects to the stepper motor, no motion.

I read up on HAL and I don't quite know how this is possible. The component must not be loaded right or something. I think the information must be being passed through the kinematics module or it would not reach the lower stages and nothing would move at all. However it is not being transformed for some reason. The code in the millkins_xyz(now millkins) module is very simple and I don't see what could be going wrong there.

I dunno mate but for the small distances you are trying to correct you really need to use a dial indicator.

may work for you, i used it some years ago and it worked for me.
look at last post..
forum.linuxcnc.org/10-advanced-configura...y-error-compensation

Yeah that looks like it could work, but I could have the same problem all over again, too. It's not clear why millkins doesn't work and the same problem could arise.

I will have a brief look in there with the hal viewer tools whatever they are called and see if I can figure out why it's not working, it's educational anyway and even if I do adjust things mechanically as I said there is usually some that is hard to mop up.

I know you can *detect* very small errors with a dial indicator but the problem is actually correcting them. doing that mechanically requires shimming for this machine which as I said is very difficult time consuming and is detrimental to the machine structure to some degree.

There are also some things that are not practical to correct mechanically, such as the twist of the y axis, for instance.  Software compensation is very useful, ultimately.

The whole machine design is compromised to begin with.
To be fair it's not a milling machine, at best it's a table top router built to price. Suitable for working with soft materials and maybe thin brass sheet. Not the sort of thing that's suitable for cutting metal. Yeah I know there are plenty of YouTube videos people show doing those things, but I'd take it all with a pinch of salt.
They are probably ok for light duty tasks or having a feel for cnc'ing but other than that.......
And no I don't have access to machines worth 10 - 100 of thousands.
Having a trade background in carpentry does give some insight into what you expect from tools.
Now back to the issue, things maybe working as they should, but the amount being compensated for is too little to notice.
And that compensation will only be applied to the Y & Z axis, as the X is assumed to be straight.
Other things that will affect the outcome is the leadscrew type and backlash between the screw and nut. The coupler, if there isn't a belt and pulley between the motor and leadscrew will throw another variable into the mix. The cheaper helical type couplers are not very good, as they twist due to their construction.
Another thing to consider is racking on the gantry, this can be inconsistent. If things are twisted this is going to be an issue.
Cheap spindle and collets will have run out that will affect things.
There's so many mechanical issues that can add up that software compensation will only get you so far.
All in all getting down to .05 to .02 mm will be quite extraordinary with the way you described the machine's faults.
Yes I know full well shimming isn't easy, it's quite a fun job on my old ML7.
I wish you all the best.

Thanks Aciera! I will totally try this. I know nothing about software .

Cornholio, I set skew to 0.1 mm per mm to test. So that would be observable fairly easily.

I understand the machine is not suitable for more than 0.05 mm in it's current configuration, but if you line up error sources and knock them down it can be surprising how far you can get. I have it slated to get a better spindle, and I will get around to adjusting the mechanics to reduce the error from that source (will require totally dismantling it and drilling 6 holes out bigger), but as I mentioned that last bit is best addressed in software sometimes.

I have already used machines in this class to reliably make small posts and holes to within less than 10 microns, and larger dimensions to within 15 microns, actual accuracy measured with a micrometer. Again, it's about understanding the error sources and (mostly) dealing with them one by one, that requires significant labor but once things are adjusted and procedures established it's the way to go. There are some things you cannot compensate for like lack of perpendicularity of the z motion vs spindle axis (spindle tilt), backlash, and some other things. However if it's *just* the spindle I need to shim, that's manageable. I chose ballscrews because they have very little backlash, for instance, and I chose a machine which has a lot of material in it's structure, not extruded aluminum, and with a replaceable spindle (some are hardly replaceable). It doesn't actually cost that much in the end, in many ways to get into the 10 micron region, except labor, which it does take a lot. If the tools and subsystems are well made it takes a lot less. Although this particular issue has been a rough ride I am still a big fan of LinuxCNC and it is a good subsystem in general. I have also already machined free machining 1215 steel and some tool steel whose alloy designation I forget, with a nearly identical router no problem, there are ways forward. (mild steel was not viable, too gummy, aluminum was fine with adequate lubricant to prevent cold welding which reduces cutting forces by ~5x)

Aciera, it doesn't compile. How did you get it to go?
I go sudo halcompile --install skewkins.comp
and it goes:

Compiling realtime skewkins.c
skewkins.comp: In function ‘skewkins_setup’:
skewkins.comp:43:9: warning: implicit declaration of function ‘hal_set_unready’; did you mean ‘hal_stop_threads’? [-Wimplicit-function-declaration]
skewkins.comp: At top level:
skewkins.comp:63:1: warning: data definition has no type or storage class
skewkins.comp:63:1: warning: type defaults to ‘int’ in declaration of ‘KINS_NOT_SWITCHABLE’ [-Wimplicit-int]
In file included from skewkins.c:2:
/usr/include/linuxcnc/rtapi.h:734:5: error: expected ‘,’ or ‘;’ before ‘char’
char rtapi_exported_##x[] = #x;
^~~~
skewkins.comp:66:1: note: in expansion of macro ‘EXPORT_SYMBOL’
make: *** [/usr/share/linuxcnc/Makefile.modinc:115: skewkins.o] Error 1