touch probe noise

The way I like to look at it is that to have a component work you need to load it, connect it and then set the times it is used.

So in your case you want to take the signal from the probe, filter it and then send the output , but you also need to set the frequency that LinCNC will look at the signal and send an output, that would be the thread.
You would normally have 2 threads a base thread (the fast one often used for step generation) and a servo thread the slower one used for most components.
Each component needs to be individually connected to a thread.

addf debounce.0 base-thread

perhaps try...

addf debounce.0 servo-thread
addf debounce.1 servo-thread
addf debounce.2 servo-thread
addf debounce.3 servo-thread


I have not used debounce but you also need to set how senesitive it is.

setp debounce.0.delay 40

Again you will need a seperate statment for each debounce component you load...
setp debounce.0.delay 40
setp debounce.1.delay 40
setp debounce.2.delay 40
setp debounce.3.delay 40
You can adjust them to see what works best.


Rick G

As a side note you can use
Machine > Show Hal configuration > watch

And select the pins you are using to make sure they are there and change states or values the way you expect.

But after saying all that it would still probably be better to find out where the noise is coming from and fix it there if possible.

Rick G

Hi Rick,

Thanks for the info I understand it a little better they way you described it. The odd thing is the debounce statements I am currently using for the homing/limit switches works and I don't get any odd errors while running any of the steppers. Seems the only problem is when I attached the probe and moved the z-axis the probe was giving false hit I figured it was similar to the homing switches and there was some noise affecting the probe signal. I am really not sure if that is the case but it is similar to what the homing switches were doing. I guess now I am wondering how the homing/limit switches are all working with only one thread statement, more confusion I would say on my part. Maybe I was lucky and it was only one switch causing the problem? My big mental block is the naming conventions for the actual debounce statement not so much the paraport statement but the probe naming. I tried all the probe controller/pin names with no success. I still get a rtapi error or I end up with EMC failing to start saying it can't find the "name used" . I guess I am not following the logic behind how all these commands work, which I attribute to my lack of Linux configuration experience, unfortunately. Some things I can get by looking at other commands and making the adjustments to them others I am completely in the dark on.
OK now having said all of that, should I see anything on the lower screen of EMC stating that the probe was tripped or will it just write to the file and change directions ? I opened a watch window for the probe and it is showing red when I trip it and yellow when it is not tripped. could it be I have been looking for something that will never actually show up on the screen ?? And if so it may be working correctly and I haven't been checking in the correct place. I was expecting the probe to create a message in the lower right on the screen stating it was tripped. I am going to test it to see what happens, I will let you know if the probe works or if the machine implodes.

Thanks for your help,
Joel

Hi all,
It appears I may have found the problem. I didn't have the delsig statement in the hal file ... I added the statement and bingo it appears to be working... this is the current hal file

#load the debounce. One set of three channels.
loadrt debounce cfg=4


#add the debounce to a thread, so that it gets run
#this is running in the fast base-thread
#you could use the servo thread. I am not sure which would be best.
addf debounce.0 base-thread


#Unlink the parport pins and limit inputs for rewiring
delsig max-home-x
delsig max-home-y
delsig max-home-z
delsig probe-in

net x-raw parport.0.pin-10-in => debounce.0.0.in
net y-raw parport.0.pin-11-in => debounce.0.1.in
net z-raw parport.0.pin-12-in => debounce.0.2.in
net probe-in parport.0.pin-13-in => debounce.0.3.in


net x-filt debounce.0.0.out => axis.0.home-sw-in axis.0.pos-lim-sw-in axis.0.neg-lim-sw-in
net y-filt debounce.0.1.out => axis.1.home-sw-in axis.1.pos-lim-sw-in axis.1.neg-lim-sw-in
net z-filt debounce.0.2.out => axis.2.home-sw-in axis.2.pos-lim-sw-in axis.2.neg-lim-sw-in
net probe-filt debounce.0.3.out => motion.probe-input


#It's important to actually activate the debounce
#20 base-threads is about 0.4mS. The typical machine doesn't move far in that time.
setp debounce.0.delay 100

Thanks for all the help, all the suggestion were appreciated and helpful in understand the configuration of EMC a little better than before. Now I just hope I can remember this next time...

I opened a watch window for the probe and it is showing red when I trip it and yellow when it is not tripped. could it be I have been looking for something that will never actually show up on the screen ??

O.K. that shows the probe is working. You will not see a message unless one is stated in the G code.
However it looks like you are still missing the other addf debounce statements you need one for each occurrence of debounce.
Look for the debounce statements in the Hal watch area the debounce for the probe both the input and output should change when you trip the probe.
For the signal to go from the probe to the debounce to the program the debounce needs to be read and that will only happen if it is on a thread.

In your case in the Hal watch area when you trip the probe...

parport.0.pin-13-in should change
debounce.0.3.in should change
debounce.0.3.out should change
motion.probe-input should change

Also if you go to the Hal show area and select pins it will show you what the pins are connected to.

Which file are you editing? Your machine's Hal file or a custom_postgui.hal file?
Perhaps you should post all of your machine's configuration files

Rick G