Advanced Search

The 0V, 5V and 12V pins highlighted look like test points to me. I wouldn't expect them to be scattered about the board like that if they were power inputs.

Nope, this one got away ... for now!

I think that this is probably a built-in assumption in the code.

The canned cycles really expect to be used in X and Y with Z as the drill, and that can only ever drill in the negative Z direction.

If you use this a lot then it might be worth looking at building your own "canned cycle" by using G-code remapping.

Or if you really want to distract yourself from getting the job done, you could look at fixing the source code and submitting a fix. (but discuss it first, so there is agreement on what a fix would look like)

github.com/LinuxCNC/linuxcnc/blob/master...nterp_cycles.cc#L110

You restrained yourself from converting it to Plasmac while they weren't looking, then?

Encoder_ratio is coded to count A/B phases (in software) from two encoders and to output a difference to drive a PID.
It would potentially be rather useful for a parallel port based machine, or maybe a Pi using GPIO. I expect it is fast and efficient, as it needs to do very little calculation.
But on systems where the positions are already calculated, you really can do it more simply with HAL maths functions (or the custom comp that my hobber uses)

To be honest, it doesn't really matter where Z home is. You can't rely on limits to avoid mashing the tool into the chuck anyway. (consider long boring bars....)
However, if you fitted a hard-stop for the tailstock, perhaps that would help with repeatability on occasions when you leave work in the machine with it powered down.

Maybe:
"If this message annoys you, add --nocheck to the loadrt hal_parport line"