Traking Option on Vertical mill retrofit

Has anyone heard of, or thinks it is possible to install traking on a linux cnc retrofit vertical mill?

I am in the planning stage to retrofit my vertical mill and I am looking at possible options to include in my retrofit. I have a Trak1630 cnc lathe and it has an option on it called Traking. In manual mode the X and Z movement is controlled through two hand cranks mounted on the outside of the machine housing. These handles are not physically connected to the X and Z axis, but are probably pulse generators sending signals to the controller and the controller interprets these signals to translation the two axis. If you are running a cnc program on the 1630 you can put the unit into Traking mode which then controls the speed of the programmed machine movement by how fast you turn the Z axis hand crank, i.e. the Z axis pulse generator. At about 30 rpm the machine tops out at whatever feed rate that was programmed, but you can rotate the Z handle just slight and the tool barely moves. You can even crank the Z handle backwards and the tool will backup. This is a great feature for initially running a program to make sure the program is cutting what you want cut and on the lathe, backing the tool up is helpful at times to clear long chips.

Has anyone heard of this type of feature being implemented on a linux cnc mill? Would it be something that is possible or is there some reason that it would be impractical to implement in linux cnc? It works great on the lathe and I see where Southwestern Industries also has it on their mills.

Any thoughts?

I did some testing on my small Sherline mill to see what could be done. As a program is running, I can move the feed override which will speed up or slow down the axis movement; and this is done without having to change the G Code itself. Could not a user defined mode called Traking be defined where if a software key is pressed prior to running the program, movement of the MPG would move the feed override slider? As far as I can tell, input from a MPG is not used while a G Code program is executing. In software one should be able to define a multiplying factor that could be used to adjust the feed override based upon the velocity of the MPG up to a factor of 100%. In traking mode the multiplying factor would equal zero unless the program detects a velocity on the MPG. That would mean that the program would not progress unless the MPG was turning in a positive direction. I am not sure what would happen if the Feed override value was driven negative since the current slider only allows input from 0 to 120%.

Has anyone had any success with this idea? A friend has a ProtoTRAK mill and showed me that feature - I love it and hope to incorporate it into my retrofit if possible. Thanks!

We were able to do this on a vertical mill. We could not get it to go backwards as you can do on a Trak lathe, but we were able to get forward movement controlled by the turning of the handwheel on our pendant. From off the top of my head I think we obtained the rate of the change of tics on the handwheel and then we used that number to adjust the percentage of the feed rate. When the handwheel was not changing at all, the percent of feedrate was zero and the mill did not move. As the handwheel was turned and its rate of change increased, we increased the percent feedrate up to 100%. We had to do a trial and error to determine at what rate of turning the handwheel we wanted to equate to 100% of the feed rate.

If you need it I can probably post the coding that we used.

To be able to make it go backwards you have to have a special experimental branch of Linuxcnc installed.
github.com/LinuxCNC/linuxcnc/tree/feature/reverse-run-master2

Thanks for the replies. As I become more familiar with the OS I will look forward to experimenting with this feature. If successful I'll use it on my retrofit, which I'll be documenting in this thread.

Thank you for the link Todd.

an92626, any code you could drum up would be helpful, and the handwheel velocity scaling factor which you discovered through experimentation will most likely benefit everyone, at least as a starting point, because if we know how many PPR your handwheel produces and its operating mode we should be able to calculate from there. I won't be getting to this stage for a while though - first I have to get the machine running!