Oblong pockets, odd geometry. Root cause ideas?

Hi ya'll, new to the forum and LinuxCNC world. I have a Lagunmatic 310 mill running LinuxCNC (AXIS) through a Mesa card, with CAM handled by BodCad. Things seem "pretty well" set up, and I've cut several odds and ends from wood. Starting a large project from aluminum, and have been doing some test cuts in MDF to verify all is good. I realized that my machine is doing a few things wrong. Included are images of my subsequent controlled test cuts to illustrate the issue.

The first image is aligned vertically. The pockets are concentric, and both are identical and 2" apart. Large ID=1.75", small ID=1" The second image is just turned 90deg CW.

If you focus on the larger ID pocket of the bottom set, you might notice it is slightly "egged" on the left-most side. This is about .012" when measured on the diameter. The top pocket sets have a similar error on the right hand side of the pocket. The 1" holes have a less exaggerated error that is practically immeasurable. They are perfectly 2" apart. My CAM simulation does not show this. I then zoomed in on my AXIS screen and can see the egging in the purple tool path lines! So the machine "knows" that is is moving exactly how I measure it-but of course I programmed it to be a perfect 1.75" circle. The error with my real test cuts previous to this are even more dramatic-4" circles were coming out .090" and one entire operation seemed shifted in the Y direction by ~ .125" but only on one side of the part??

I have done linear tests and the machine is very repeatable in linear moves. (EA Backlash gross encoder errors not at the top of my list). Since I've only cut decorative parts up to now, I hadn't even caught the error yet.

My more qualified and zealous friend (who has moved) did 95% of the setup-So I am backpedalling now that I'm on my own.

I am thinking our cursory PID tuning wasn't good enough, and the feedrate in that larger circle is causing the issue?
My latency test today (following PnCConfig walkthrough) was around 200000ns. Fishy? When I try to put this number in, it is automatically changed to 500000 (as if I am below some software limit?)

I am still battling the halscope to tune my axis' further- but am learning. Any thoughts or advice in general are greatly appreciated.

Travis

Thanks John. I have read over and over your tutorial-just need to put into practice and get halscope figured out. Not going to ask questions until I hit the wall some more!

I have attached INI file. I actually hadn't ever opened this yet. It appears many parameters are unit-less, like max_linear_velocity is 1.66 in the Display section, while it is 5.83 in the TRAJ section.

See my attached test_circles.nc for the question of lines vs arc. Most of the code is just the spiral lead in (if I'm interpreting correctly) . I think it could benefit from the G64 if I understand. There doesn't appear to be much of a preamble-just 643, g90, H1 (if that all counts as a preamble.) I am using a post processor from BobCad that was designed for and EMC run Sherline mill. So it is very stripped down from the other post processors, but they had code that was causing Linux CNC to not start. We couldn't figure it out.

Thanks for all the info-I need to read up.

Andy, thanks as well. The preview comment makes sense-it is as if the speed was too much for the planned trajectory. I will dry run @ very small speed and see what happens.

When you say "look at path-following mode" are you saying for me to change some setting to path finding mode, as if it is in another mode now?

Travis

PS. The large part I first milled (which clued us into this problem) involved a large concentric cylinder above another with spline like cuts. I programmed the top one with very shallow DOC, so I took the Feed Override to 200% since this was MDF, not the planned aluminum. When it went into the second operation with splines, DOC almost tripled (again, purposeful programming). The em was humming, so turned down Feed Override to ~60% programmed. It was between these two cylinders the "shift" in the -Y axis is noticed. Measuring, the error is only in the top portion-feedrate override section-while the slower cut portion is within .001 of my print. Agreement again with the feedrate being the issue.

a couple of things:

Since you have "LINEAR_UNITS = inch", distances are in inches,
velocities are in inches per second(I/S), and accelerations are in inches per second per second (I/S^2)

Your accelerations are very low (2 I/S^2) so would take almost 3 seconds to get to a rapid speed.
this is a likely cause of your lumpy circle. A value of say 6 to 30 (from 1 downto 0.2 seconds to full speed)
is probably more reasonable. The machine specs might come in handy if you are using the original drives
as they are likely to specify the allowable acceleration.

Your FERROR and MIN_FERROR limits are huge (1 inch!) so if you had a tuning issue or mechanical problem,
you would not know.

Its fine to make these limits large when tuning but they should be set quite small on a tuned machine so that any
deviation greater that the limits is detected quickly.

A typical machine of your type might use values of .003" for MIN_FERROR and say 0.010" for FERROR
These are large enough that you avoid nuisance faults but small enough that a real issue (like a crash)
is detected in milliseconds.

Thanks all.

Loaded new ini file and have been playing around with the F_ERROR and MIN_ERROR, while increasing acceleration to a healthy 20 in/sec*sec. My test circle cut looks much smoother-only small amounts of the error in circularity. (see attached) I turned down feedrate by~25% and things are even smoother. Looks like things are pretty well in sync.

Travis