I haven't configured spindle orientation on my mill, mainly because I don't have a toolchanger and I probably won't be fitting one. (I do have a pneumatic pull-stud, though, which is far more fun than a drawbar)
But, here are some thoughts on orientation, at a slightly higher level than the specific HAL implementation.
The first thing to consider is that the orient process needs to take control of the spindle motor. In some cases is it only necessary to make the spindle turn slowly (and with low torque) until a pin drops in to engagement. That is a fairly simple modification to the more general situation.
To orient a spindle using only the motor you need to temporarily make the spindle into a position-controlled axis just like X, Y and Z. And to do that you need the same sort of software control, which tends to mean a PID controller component in HAL. That will look at the difference between the current spindle position and the required spindle position, and will output clockwise/anticlockise / faster/slower commands for the motor.
The spindle position, after a period of running, will generally be many thousands of turns. Simply telling the spindle to return to (for example) 45 degrees, will try to unwind all those thousands of turns. So, something needs to be done to prevent that.
One approach would be to set the spindle index-enable (which will zero the spindle position at the next index marker). This would probably work, but would involve interfering with the normal index-enable net used for rigid tapping or lathe threading.
An alternative is to use the "orient" HAL component, which does a few useful things, but the main thing it does is take the many-thousand-of-turns spindle position and pass out only the partial-turns from the last full turn. This makes a good basis for the input to the orient PID controller.
www.linuxcnc.org/docs/html/man/man9/orient.9.html
The spindle will never be "on" in the normal sense when orienting (so the orientation HAL needs to somehow send an enable to the spindle motor drive). An advantage of this is that there is no need to choose between the orient-pid output and the normal spindle control signal, they can just be added together.
The HAL logic needs some flag to tell it that it is time to orient. If the orient is using the M19 G-code (
www.linuxcnc.org/docs/html/gcode/m-code.html#sec:M19
) then the motion.spindle.orient bit can be used. If the tool-change is handled by a G-code subroutine then an M19 can be part of that sequence. Otherwise, it probably makes sense to use the iocontrol.0.tool-change output bit to start the orient.
So, the logic is that the orient flag enables the orient PID and the orient component .enable bits. The orient component calculates a valid input to the orient PID controller, (many thousands of whole turns, plus the required angle) and the PID controller uses that number in conjunction with the actual spindle position (many thousands of turns, plus a random partial turn) to output a spindle motor command that controls the spindle to move to a particular position.
The _exact_ implementation will depend on your current spindle control, whether you have a closed-loop control on spindle speed, whether there is a gearbox, etc etc. But basically it comes down to an extra PID component (that will need to be tuned), an orient component, and a sum2 to combine the normal + orient command sources to the motor.
