Homing with probe input

Lol what? Did LinuxCNC turn into the penny CNC conversion alternative? Most people are working with a manual machine costing about $2500 and adding another $2k-5k in conversion parts. $100 for some prox switches are too much? Just did a quick check on Ebay and brand new Turcks are going for $35ea.....is that really too much for a quality part?

So if you made the statement "cheap, improperly spec'd inductive proximity sensors work like shit" I'd certainly agree. You just said inductive switches in general, which is not true at all.

Just so ya know I'm not trolling, these are all of my axes limits and the spindle index installed on the head. I paid $70 for 10 of these switches brand new a couple years ago on Ebay and I still have 4 left, so there's nothing too crazy about any of it.

 
 
 
 
 
 

@mecanix That Ini configuration is what I already use. Regarding the signal filtering, I realize that with the hal debounce. Works flawless.

But what I want is more a custom home cycle. Like I described above. A limit switch which, as soon as activated reduces the speed for the final approach which is then connected to a different input. I  wonder if that would work with the mux in the hal.

Regarding the rest of the discussion which sensor to use or not. Why would I spend money for a sensor which at the end is never as good and simple as the probe input? I simply make the machine a mechanical switch which is connected on touch. It's just a question if that can be realized in the software.

Well that discussion was about clearing up a generalization that was made. People see this stuff on the forum and they run with it.

I think nobody really understood what you're asking.

But what I want is more a custom home cycle. Like I described above. A limit switch which, as soon as activated reduces the speed for the final approach which is then connected to a different input. I  wonder if that would work with the mux in the hal. 

Yeah you can do that......you're going to do that for multiple axes within a standard homing sequence? That's where you'll run into problems.

If you want to write a "custom homing sequence" then just do that. Write a Gcode file with a subroutine that alters the inihal home pins on inputs from the touchprobe. You can have it do whatever you want but you'll be responsible for the entire sequence, there's nothing canned about it. You run a standard LinuxCNC homing sequence to normal home/limit switches just like normal to get the machine in some reasonable coordinates, then run the sub file to do whatever you want with the probe. You can set NO_FORCE_HOMING = 1 in the ini file so you'll never have to run standard homing in LinuxCNC, so as long as the machine is somewhere near the correct position you'll only have to run the sub to use the probe to alter home.

Honestly I wouldn't do any of it, if accuracy is that important to you buy better home switches. LinuxCNC is meant to use home/limit switches, not a touch probe.

mBender wrote:

Why would I spend money for a sensor which at the end is never as good and simple as the probe input? 

Because it means that you are not fighting the paradigm. Life is always simpler if you follow the paradigm with any computer it stuff.
You can still use the probe and set the G5X offsets before running any code.

mBender wrote:

But what I want is more a custom home cycle. Like I described above. A limit switch which, as soon as activated reduces the speed for the final approach which is then connected to a different input. I  wonder if that would work with the mux in the hal.
 

True. Using unleashed creativity and extra time, a whole lot can be done with hal. Alternatively you could create your own cycle & logic using remap and subroutines for instance. At the end of the day it's all about whether it really worth the effort tolerance-wise. In my case; I sneeze on the machine and an offset of 0.01mm is automated!! (rigidity issue), let alone the afternoon sun (thermal expansion) sending my entire machine-tool out of whack, to name a few. Lastly I don't know anyone who needs to pay for sub-atomic size tolerances anyway, less myself. My manufacturing & drawings tol are twice more than what a dumb mechanical switch throws. 

Unrelated (but related) I've moved on to On-Machine and In-Process probing "in CAM". Currently writing automated subroutines that does all that where & what coordinates and tool offsets work at the start of each program. Therefore Home Pos[n] becomes pretty redundant at this stage. Consider this remapping idea I've given you, worth looking into custom cycles. gl 

Why would I spend money for a sensor which at the end is never as good and simple as the probe input? 

Because it means that you are not fighting the paradigm. Life is always simpler if you follow the paradigm with any computer it stuff.
You can still use the probe and set the G5X offsets before running any code.

 


Amen to that! As I was thinking about how you could actually do it and yeah, it is possible.......I'm thinking "why the hell wouldn't you just buy better switches than go through all this"
 

Ok, thank you for all the input! Like I said in my first post, I was wondering if there is a simple way of a custome home cycle ( The answer is NO) or touching off at a fixed point somewhere in the machine work space.

I think I will proceed with a regular homing cycle and then write a small subroutine which touches off at a fixed point in the machine workspace and set the G53 coordinates for X Y and Z to a fixed offset once the probe input is triggered.

Would that work with G10 L2 P0 x<coordinate> set the G53 X position? The manual says P1 is G54 and P0 is active. Since I never executed any coordinate system change, is the machine still in G53?