Homing on Linear Scale Index

I have linear scales on the X,Y, and Z axes. There is a reference mark in the center of the scale, I want to use this mark as my home position.

I currently have homing set up with HOME_LATCH_VEL and USE_INDEX = YES. The marks are being detected properly, but there are two problems:

1. Since the mark is in the center of travel, you have to start on the correct side of the table.

2. The movement is quite slow, so if it is not positioned close, there can be quite a long wait.

What i would like to do is move to a limit switch at a reasonable speed, back off nearly half the table travel, and then go into a slow crawl as I search for the index mark.

Wondering what the best way to do this may be, or if I am overlooking a simpler method.

1. The search for home switch should get you there (assuming you have a home switch) you need to set the HOME_SEARCH_VELOCITY

2. Assuming you have a hardware encoder counter, You can set the index search velocity to anything you like (no danger of over running into hard stop if index is in the middle)

A faster way would be to have a flag for the home switch that was 1/2 of the travel so you have a 1 bit abs encoder so LinuxCNC always knows which way to go to get to the center

So the precision of the home position is not dependent of the index search speed? Using 7i85+7i76e.

No, if you are using "home to index", the raw scale count is latched at the physical index
in hardware (so independent of speed) and used by LinuxCNC to offset the position

andypugh wrote:

dswanson wrote:

1. Since the mark is in the center of travel, you have to start on the correct side of the table..

If you can arrange for a home switch sensor to be off in one half of the table and on in the other (for example a proximity sensor and a long target) then homing will either do a search and latch or go straight to latch. If those are in opposite directions than it will work on either side.

This is absolutely the way to go. A strip of metal half the length of the table and a prox sensor might be an easy solution. The metal strip just needs to be thicker than the maximum sensing distance of the proximity sensor so it can't see any metal the strip is attached to. 5mm works on my machine...

Please see my post Precision automatic homing using an independent DRO scale index .

You likely don't need any hardware as the others are suggesting, just HAL magic.

The reason for the unreasonably slow crawl working is that LinuxCNC is peculiar, not recognizing anything but a step function switch, not an impulse function with a falling edge like a scale index. By crawling at an some agonizingly slow speed, the peculiarity happens to stop before crossing the falling edge of the impulse, as if it were a step function. But given a typical 5 micron pulse width in an optical scale, "slow speed" is going to result in poor performance, or be impossible if your motor steps are more than 5 microns.

But with HAL you can turn the impulse function into a step function, and then the peculiar LinuxCNC logic works at reasonable speeds. Details are in my post referenced above. This is a workaround that works at base-thread or servo-thread rates, so it can only find and stretch in index pulse that is traversed in 2 or more {base,servo}-thread cycles per Nyquist. But that gets you higher traversing speeds, limited only by the thread rate Nyquist limit.

Software cannot solve the predicament of motor step size (servo resolution) exceeding the half the pulse width. In that case you would have to add hardware logic (D flipflop connected as a divider) between the scale index signal and the PC input. It's a case of resolution limits and detection. If your mechanism resolves D, you can reliably detect impulses only that are 2D wide or larger. If your mechanical step size is, say, 0.001in, you can't possibly detect a 5 micron (0.0002in) index reliably, or both edges at all. If you process the impulse into a step function, then you will always detect it, but at best to an accuracy of twice the mechanical step size. Step and detection rates also apply, so the speed has to also honor those limits.

I consider this peculiarity a deficiency-bug in LinuxCNC due to its non-theory of adaptive positioning, but others dispute my conclusion. The post discussion turned into my elaborate critique versus defenders of, and apologists for, the peculiarity. If you happen to have a machine with switches that's been working all along, then you might also deny the peculiarity of it, which I suppose is reasonable. I don't understand why using a linear scale index for homing provokes hostility, as if switches were ideal.

I have to agree with Andy to some extent. We are not attacking you. But if you follow the Homing configuration docs
You can still home to an index but you don't need to crawl to find it. You can sprint or jog even.
This would work particularly well for the OP as he only has one index mark.
Please take the time to review this diagram taken from the link above


Have you actually tried this? How can this differ in finding the index mark then your method (other than being faster and not needing to "wrangle" the axis manually)?. Its the final move to the index that counts.

I did manage to get homing working by traveling to a limit switch and then proceeding to the index mark. I am using a 6i25 and 7i85s, so it is good to know that it is a hardware reset.

I did some testing to verify how good the hardware counter reset for homing works. It is quite good. I tested velocities from 1mm/s to 16.6mm/s by zeroing a length gauge at home on the Y axis, and checking the repeatability. Placed the raw data below for anyone interested. Encoder pulses occur over .0001mm, so there are 10 to 166 encoder counts per 1ms servo period. Was interesting that higher velocities homed more consistently, so I am willing to attribute the variation to dynamics of the table itself and not the homing count. (not sure why all the measurements were biased after the original setting of zero)

1 mm/s -.0026 -.0023 -.0022
3 mm/s -.0020 -.0019 -.0020
5 mm/s -.0019 -.0019 -.0020
10 mm/s -.0016 -.0017 -.0017
16.6 mm/s -.0017 -.0016 -.0016

I like the idea of a home switch that is on for half of the table travel, but won't be doing that (at least for now), since space is constrained and this works well.

Thank you all for your help.