Precision automatic homing using an independent DRO scale index

90% of users seem to struggle with configuring homing as it is. Asking them to provide 9 unmeasurable switch parameters in addition seems unreasonable.

Yes, it's a struggle, I fall in that 90 percent.

The struggle is partly due to LinuxCNC's theoretical model of homing, which is not general, and covers just one special case of hardware. It is reasonable to wish for a rational and complete model that covers the reasonably possible cases, instead of one special case. The vital case that is currently missing is a DRO scale as homing device. Understand that a homing switch is just a poor version of a DRO scale, with no phases and a crude index.

Generalizing the model will make it more complex, and involve defining more parameters. But that will not be any burden on user installation. The current cases will reduce to default values. Pretending theoretical factors don't exist is part of the burden to users currently. Another burden of the current implementation is that it performs homing, limiting, and probing as different theoretical operations with different code and parameters. Those three things are all theoretically identical, and the user predicament should be shrunk into one general implementation of "lunar landing" control, "moving unidirectionally and irreversibly to a sensor's value when that signal is not closed in the real-time motion loop". The signals are transfer functions, and the operation amounts to inverting that function, but the concept of transfer function is not explictly exhibited in LinuxCNC. "Lunar landing" control is stable under hysteresis, which PID cannot be.

But my lathe works that way by using single-turn absolute encoders and the position.txt file.

It works, but it doesn't work on the leadscrew transfer function non-linearity and hysteresis, so it is limited to the precision of that transfer function (0.001in's), not the higher precision of an optical scale (0.0002in's).

If you used your linear scales as part of your feedback loop (Or even just provided the scale remainder counts to Linuxcnc after index-reset) then I think that your objections would also disappear.

That can't work, it's the old two-encoder problem. PID cannot stabilize on hysteric feedback.

By "remainder counts" you must mean a compensation table or other static characterization. But that is open-loop and is limited to the epochal repeatability of the leadscrew characterization table (hence my work to perform automatic characterization in another forum thread "Possible error in logic of LinuxCNC homing with leadscrew compensation" ) (no way you want to write that table by hand), which amounts to a map of the leadscrew transfer function and the inverse by interpolation. Inverting the transfer function in real-time is what homing-probing is about. You want the inversion available dynamically during operations to match the real conditions, not something calibrated long ago and drifting-floating-changing around. Otherwise the drift becomes another weakest link in the final precision. You might imagine that leadscrew error is time-invariant, but it is not. The transfer function is a characteristic of every mechanical element between the motor's rotor and the table: pulleys, belts, bearings, couplers, nut, fasteners, flexure, ..., not just the leadscrew itself. These factors are additional sources of error that change across starts. For example, bearings introduce a periodic runout error which is unpredictable as to frequency and phase, essentially a random error on every move that cannot be corrected by a static compensation file. Belts have a complex non-linearity that is not phase locked to the motor rotor. Until you have an automatic survey capability it is impossible to measure the magnitude of these factors, and the random components only appear as variations revealed between surveys. Assuming the factors are inconsequential will be disproven the first time you apply a compensation file and discover that the LinuxCNC compensation doesn't perform any better than no compensation, and can be worse. Averaging is no help for errors random in magnitude or phase.

It covers at least three hardware cases.
1) Home switch only (with the home position set on either the rising or falling edge of the switch)
2) Home switch + encoder index
3) Absolute encoder.

That's only one case of homing hardware, namely a home switch, where "hardware" is defined as a sensor that founds an absolute physical position of the final business, which is the definition of absolute homing. The absolute encoder is only absolute about the motor rotor angle; this does not found any of the physical business downstream of the motor (leadscrew, bearings, hubs, belts, ...), so it doesn't "count" as absolute homing hardware.

It seems to me that there is little point using the linear scale as a homing device unless you also use it for your positioning feedback.

Yes, the leadscrew transfer function (LTF) must be precisely known, or there is little point. When the LTF is stable and known a priori (because you ran an automatic characterization to sample it and generate a compensation table as I explained in the other thread), then that can provide the feedback inversion. If the LTF is unknown, or it is changing, then it must be inverted in real time with a converging feedback algorithm, which requires establishing a feedback loop on the scale that performs the inversion.

Please correct any misunderstandings I have about your hardware.
You have step/dir servos driven by the parallel port
You also have quadrature + index linear scales with periodic index marks which are identical(?)

These indeed happen to be the case I'm working and running experiments with. But I'm also trying to engineer a solution which covers the theoretically general case of an absolute, precise, unchanging DRO scale being available on a controlled mechanism where the mechanism and controls are much "sloppier" (less resolved, non-linear, hysteric, changing over time, a degree of randomness or noise, compared to the DRO). This is potentially an order of magnitude improvement in practical precision, available for the cost of a DRO scale. I understand LinuxCNC does not have a basic capability to make use of this principle because LinuxCNC motion control is based on non-hysteric PID feedback theory (hence the unsolved two-encoder problem) with a few non-theoretical/incomplete/buggy hacks like COMP_FILE and homing for the hysteric gadgetry pesky users insist on using.

My specimens of DRO scales (Acu-Rite ENC125T and ENC125E) indeed happen to exhibit periodic index marks on a 200mm interval. The phase quadrature signals are 5 micron spacings. Periodic indexes are not a significant problem factor. One simply assumes the unhomed machine is parked to a given side of the relevant index; it's the duty of the operator to wake the machine in that condition, or wrangle it that way manually before engaging the homing action.

You then run a PID component with the commanded position as input and the DRO scale as feedback.

I have imagined doing that, call it "closing the loop on a DRO". In correspondence with Jon Elson, he called it "true servo". But my theoretical workout, and every forum opinion I've researched, finds it not feasible. The first case I found of the general issue is the unsolved "two encoder" problem. Here's my theoretical comprehension of why it can't be solved with the existing LinuxCNC design: The LTF response sits between the motor action and the DRO scale. PID control assumes the loop response is monotonic (OK so far) and non-hysteric (uh-oh, the LTF is hysteric). Under those conditions, PID is necessarily unstable to the magnitude of hysteresis, and consequently imprecise to twice the magnitude of hysteresis. The pat answer to this predicament is "just buy hardware with minimal hysteresis" (preloaded-ground ballscrews, class 7 bearings, etc.). But even if you spend for that, practical hysteresis is still several times DRO scale granularity, so it's spending that still doesn't realize the potential of an optical scale.

The only way (that I know of) to solve the heartbreak of hysteresis is with a "lunar lander" algorithm in the feedback loop, instead of PID. So LinuxCNC would require a HAL motion component that does lunar landing (one-sided, non-reversing, budgeted-time/space, possibly-failing-requiring-retry logic). Curiously, LinuxCNC does have some lunar-landing hacked into the design and source code in several places: (1) homing, (2) probing, and (3) COMP_FILE. These are poorly modeled in theory and implementation. It's even comedic in src/emc/motion/control.c, where there's a Keystone-cop hard-coded approach of sprinting at 150 percent over acceleration limits, to hack the backlash travel with faster bandwidth and magnitude than the outer PID can muster to interfere with it. The code author kindly disclaims in a comment that this "may exceed maximum settings!" and "more testing" may reveal a need for a "more complicate[d] solution".

"The Commanding General is well aware that the forecasts are no good. However, he needs them for planning purposes."
-- Kenneth Arrow

I've been following along quietly but I think we are lost in the forest of accuracy and have forgotten the objective was to drain the CNC swamp.

On many machines controlled by LinuxCNC its simply not possible to "wrangle the machine manually" to the correct side of a homing index. It seems to me the test environment is fairly medicore at best and capable of 0.005mm accuracy defined by the 5 micron scales and limited by parallel port outputs. Whilst 1 micron scales are available and what I use, its long been regarded that the additional accuracy is beyond what can be achieved in the real world. In another thread, PCW observed that a 2.4m long table could change dimensions by up to 1 mm even in our mild climate from winter to summer. So even if the OP could get it right on homing, the machine is probably off by lunchtime in the midday sun.

It seems the OP wants to be able to home his device against any of the index marks spaced at 200 mm intervals along a given axis but to do this, he acknowledges things will come unstuck and require manual wrangling. So what is wrong with just picking one of these index marks to home to as LinuxCNC now does it?

Place a home switch somewhere along the axis that remains enabled from one position to the end of the axis. That way when LinuxCNC wakes up, it knows precisely which side of the home switch it is on (as it either on or off) so it knows which way to go. It finds the home switch and then it seeks out an index mark on the scales and pronounces its home. Then a correctly configured machine will take the feedback from the scale and use it to correct any error in axis moves. The real advantage from using a linear scale is that the feedback is coming from the last link in the motion chain so any back lash or hysteresis has no affect on the feedback signal.

In my view, based on configuring my machine, you can't really bag the LinuxCNC homing algorithm unless you have your axes set up with separate min limit, max limit and home switches but by the time you add 3 encoder inputs and 9 switch inputs (12 on a gantry) to a parallel port, you have well and truly run out of inputs. I suspect therefore a hardware upgrade is in order to continue your experiments.

I would recommend you set the hardware up properly with the required number of switches and do some repeatability tests with a dial indicator to see what variations might exist. But don't forget to correctly calculate all of the tolerances in the system. From my engineering studies some 40 years ago, I think the tolerance on your .005mm scales is +- 0.005mm so there is potentially a 0.01mm error window within the measurement tolerance before adding in the dial indicator tolerances. I have done this. I don't home to an index mark and I'm satisfied the homing variations I observed are immaterial given the accuracy of the plasma cutting process.

Sure the homing procedure is not perfect but I'm sure it will put you within the tolerances that can be held. On a gantry machine you can't jog until that axis is homed and I really don't understand why Linuxcnc won't allow jogging of the gantry motors in unison and allow the limit switches to tell it if things go pear shaped.

sorry duplicate. please delete

My stepper machine will shut off and re home within < .0005 inch with 3 dollar switches. I'm actually impressed.

If you are trying to hold those tolerance you should be indicating or probing the work piece at the time you are qualifying the feature. This is what we do even with premium machine tools.

Sorry, but I can't resist anymore.

The beauty of linuxcnc:
If you don't like a feature, feel free to write a better version.

Mike

Sure the homing procedure is not perfect but I'm sure it will put you within the tolerances that can be held.

Precision is misunderstood. Think of precision inversely, as a limited "budget of imprecision" that you can spend and spread around. Whatever components are in the feedback loop, their imprecision has to be paid for out of the budget. Excessively precise components are not to be dismissed. They free the imprecision budget to be spent on the others, and directly improve the "tolerances that can be held."

This week I have succeeded in implementing the DRO automatic positioning feedback (in G-code, no less). This cuts the leadscrew/bearings/temperatures/etc out of the precision lunar-landing loop, leaving only two basic precision-limiting factors: the DRO scaling and the DRO index-home. These are each +/- 5 micron granularity. Dr Harry Nyquist insists on doubling the prices, but we can cheat him at home by crawling the index leading edge on start-up. Scale non-linearity is perhaps another doubling. So 2 x 2 x 5 microns is 20 microns, or 0.0005in absolute positioning expected, which I've confirmed with dial indicators. A mechanical home switch would overwhelm that entire budget, it is not "within" it as you imagine. I could reset and treat the DRO separately, doing a manual home differential against the rough home, and then count yet another offset, so it would still be feasible, just not fully automatic. The magic is in not depending on anything mechanical, only optical, when closing the loop.

Of course the tools edges are a mechanism, not optical, a cutting granularity of a few 0.0001in's. I anticipate holding final tolerances of 0.001in radial on the lathe cross-feed, repeatable and automatic. When better than that is called out, then you code an automatic-cut-and-manual-try(mic) operation, another lunar-landing function. But an automatic 0.001in would be an achievement, that makes threads automatically in tolerance without cut-and-try.

The project aim is simply to gain automatic CNC mimicking of manual DRO methods. A manual machinist makes cuts by homing and watching on the DROs. He doesn't use his "axis motors" (his hands on the cranks) or "encoders" (scale wheels) for positioning. He's a violinist on a fingerboard listening to the sounds, not a guitar player on discrete frets.