Work with probe

Solution to the 2.1" issue.
The problem is that the distance to move has to be 2x 2.1"+0.2". There doesn't seem to be any definition that disallows a 4.4" motion.

But, inside the INI file is
# Maximum search distance and direction (sign)
MAXPROBE = -2.0

Change that to be larger than the ps_edge_length and now both circular and linear X length works.

The fault really lies here:
Range checking should be done when the data is entered, not when it's used unless it can be modified indirectly somewhere else.

Also the ps_edge length is the max distance to move so why doe sit work for the first distance which is larger than MAXPROBE but not for the other side which is more than 2x MAXPROBE.

This is very screwy.

John

 

Hi
Some problems occurred during my use.
I want "probe_screen_v2" to work in "gmoccapy GUI", I followed the guide, but did not succeed. I used the same operation in "Axis GUI" but succeeded, I don't know why.

I use a parallel port board to control my machine. I use the P11 pin to receive the probe signal, but I don't know how to set up my ".hal" file.
I am a newbie, can anyone help me, thank you very much.

For my MESA based system which started out as a PP type I had:
# net min-home-x <= parport.0.pin-11-in
Now it's which is the same pin on the DB25.
net min-home-x <= hm2_7i92.0.gpio.014.in

I have my probe on the second PP documented like this:
#IO Connections for P1
#Pin# I/O Pri. func Sec. func Chan Pin func Pin Dir
# 15 20 IOPort Probe 1 Probe (In) Probe Input

# ---probe signal---
# begin Touch Probe
# DB25-2_15 is Touch Probe Input.
net probe-in <= hm2_7i92.0.gpio.020.in_not => motion.probe-input
# end Touch Probe

I believe you'd have to do this:
net probe-in <= parport.0.pin-11-in => motion.probe-input

you might need parport.0.pin-11-in_not if the polarity is backwards.

Hope that helps a bit.
John

OK,Thank you ヾ(≧▽≦*)o

Have you tried using "probe_screen_v2" in "gmoccapy GUI"

I have a problem using "probe_screen_v2" in "gmoccapy GUI". I followed the guide, I opened "gmoccapy GUI" and found that there was no interface about "probe_screen" 

tuzki wrote:

I have a problem using "probe_screen_v2" in "gmoccapy GUI". I followed the guide, I opened "gmoccapy GUI" and found that there was no interface about "probe_screen" 

 

I do not mean to hijack this thread but why don't you switch to qtDragon? Chris has been busy the last few months to make it a very good and stable screen (and it look great too). You can use the gmoccapy probing routines if you want to remap M6. The probe-basic and VersaProbe screens are already built in and work fine. All you need is a properluy setup probe and the probe screens will work. For the M6 remap you have to do a little more work, but there is some progress in automating stuff and making things more user friendly.

I have been using the screen for months now, most errors are fixed, the develloppers are very responsive and nice in case of a bug or question.
As I understand it Norbert is working on a new version of gmoccapy, you can wait for that too.

Thank you for your recommendation, I will try qtDragon.
I just started learning LinuxCNC and always use "gmoccapy GUI". Compared with gmoccapy GUI, I don't know much about qtDragon

tuzki wrote:

Thank you for your recommendation, I will try qtDragon.
I just started learning LinuxCNC and always use "gmoccapy GUI". Compared with gmoccapy GUI, I don't know much about qtDragon
 

There is proper documentation at linuxcnc.org/docs/devel/html/gui/qtdragon.html it's updated on an almost weekly basis.
You can always ask questions at the qtvcp forum.

 

Hi,
All probe masterminds.
I am using qtdragon and love it but I have another stupid question.
I have touch probe connected to probe-in that is all good.

What pin do I connect the tool sensor?

I believe that I have my 3D probe and Tool Setter connected to the same hal pin through an "or" component.. The 3D Probe and TS are connected to different physical pins on the Mesa card.