[m_c]

I know all about having too many things on the go!
I'm currently in the middle of retrofitting a mill, so my time is a bit limited just now, but I'm certainly willing to put some time into probing routines.

Having re-read the tapping thread, my understanding was Tom was wanting you to test it via a M-code, to make sure it would work as you expected with the necessary parameters, and then if it worked as planned he'd add it to the main interpreter as a G-code. I suspect Tom's reluctance to just add it, is he doesn't have any machinery to test it on, so is wanting somebody to physically test it first. I would test it, but I'm not sure if my spindle would be up to it. It's rated 1HP at 4000rpm (1.3lbft/1.7Nm), but it's actually a 4.5Nm/4000RPM DC servo motor, so it may be able to provide a bit extra power for testing with a small tap.


I'd be interested in seeing the Hass probing routines, but all those routines you've shown are what I'd class as basic probing. They're basically probing certain features for location purposes, and not like perimeter probing where you need to rough guess where the next touch is going to be, and how to react if it's not.
The actual routines for them are reasonably simple, it's just getting suitable graphics in KMotionCNC that might be a problem.
I think the graphics might be possible with the new screen editor, but I've only had a quick play with the new screen editor, as I'm trying to avoid distractions and concentrate on getting the mill retrofitted first.

Tool probing is probably one of the easier things to implement. I've already got a couple tool setting C programs for my lathe, which involve a taking test cut, entering the measured value, at which point the program calculates the offset and updates the tool table. It would be easy to alter them to make use of a tool probe (which has just reminded I need to add an input for on my retro!)

[engnerdan]

I know all about having too many things on the go!
I'm currently in the middle of retrofitting a mill, so my time is a bit limited just now, but I'm certainly willing to put some time into probing routines.

Having re-read the tapping thread, my understanding was Tom was wanting you to test it via a M-code, to make sure it would work as you expected with the necessary parameters, and then if it worked as planned he'd add it to the main interpreter as a G-code. I suspect Tom's reluctance to just add it, is he doesn't have any machinery to test it on, so is wanting somebody to physically test it first. I would test it, but I'm not sure if my spindle would be up to it. It's rated 1HP at 4000rpm (1.3lbft/1.7Nm), but it's actually a 4.5Nm/4000RPM DC servo motor, so it may be able to provide a bit extra power for testing with a small tap.


I'd be interested in seeing the Hass probing routines, but all those routines you've shown are what I'd class as basic probing. They're basically probing certain features for location purposes, and not like perimeter probing where you need to rough guess where the next touch is going to be, and how to react if it's not.
The actual routines for them are reasonably simple, it's just getting suitable graphics in KMotionCNC that might be a problem.
I think the graphics might be possible with the new screen editor, but I've only had a quick play with the new screen editor, as I'm trying to avoid distractions and concentrate on getting the mill retrofitted first.

Tool probing is probably one of the easier things to implement. I've already got a couple tool setting C programs for my lathe, which involve a taking test cut, entering the measured value, at which point the program calculates the offset and updates the tool table. It would be easy to alter them to make use of a tool probe (which has just reminded I need to add an input for on my retro!)

You are right that Tom wanted me to test the code out using an M code and passing some variables like a sub-routine. Part of the problem is laziness on my part and part is I don't wish to hand write code for every test part. I may get motivated soon to give it another try. Now that I have the control panel in place and mostly functional I am finding my mill much easier and more enjoyable to use.

Attached are the probing routines I have. There are from 2 different machines, the one titles Haas #5 has a spreadsheet in it with some variables listed I didn't make this so I am assuming it was a record of the variables on the machine the macros were copied from. I think these would be great to use, being they are g-code based, already written and easy to add to or modify instead of c based code that has to have a thread to run in. But to make them work KMotion would need to call the correct macro and them there would need to be a variables file in the background that these files could reference and write to. For instance when you do a calibration the probe tip diameter offset is stored in the variables.

-Dan