Work with probe

I'm using the 2.8 version with the changes from Alkabal and others.  Some of the changes are incorrect and resulted in my probe destroying itself at 150ipm into a 1-2-3 block.

Part of the problem is I believe the design philosophy was to place the tool setter on top of the work (perhaps a sheet of MDF on a CNC router) and be able to probe various configuration edges etc.  The PSNG screen is an amazing bit of work but it keeps changing appearance on each iteration and likely the code keeps changing too.

So for now I'm staying with 2.8 and I've now got several processes in place.

1. Probe the tool setter to determine the length of the tool tip to the quill and put that into the tool table.
2. For tools like R8 collets that hold various cutters with different shanks the length in the tool table for that tool # is 0.
3. Same with Drill Chucks unless you have several for one project and the drill bits stay in them for the entire project in which case measure them.
4. On a tool change if there is a valid length then use that to set the new work space Z zero position.
5. If there isn't a length go probe the tool setter.
6. Finally , normally, the M06 macro does not perform a tool change if the requested tool is the same as the currently mounted tool. What I've done is forced a re-probe at the tool setter if the length in the tool table is 0.  This avoids doing a T00 M06 G9 and then a T5 M06 G43.  Instead a T5 M06 G43 will result in a tool measurement after I put a new drill bit in the drill chuck (TTS Tool #5).

I still need to do more testing before I post the modified code.
 

JPL wrote:

lrak wrote:

OK - I just upgraded to 2.9.0

 
Then NONE of the current verser version will work for you because of python incompatibility.image missing /media/kunena/emoticons/sad.png

Then install QTDRAGON_HD on V 2.9 and use it's version inspired by verser.

Serg425, Thanks for the good questions.

Serg452 wrote:
What is the value of the buttons (1) if the enable measurement is still pressed with an offset?
What does the ERR check mean (2)?
  

      

First question. These buttons only set to 0 the current coordinate system for arm or spindle, but do not physically move the axes.
Second question. I made edits to the 'ERR pin proccessing' code yesterday (     Probe Screen v2.8.3     ) and am preparing the information for the User Guide. This checkbox will be useful for users of wireless probes, such as Vers WLR v7, in which radio signal delay is critical. The ERR pin is physically connected to the CNC controller and signals an abnormal delay in radio. Probe Screen will repeat the measurement if an ERR signal occurs.
Probe Screen can also handle any delay. Not only from wireless probes. For example, Connection Module Vers CM  in anti-vibration mode generates a fixed delay of 5 ms, which must be taken into account.

Serg452 wrote:     
Another question. The remap enable button has disappeared. I use a tool in a cone BT40 and every time there is no need to measure. What should I do?

This is an important question. And it looks like simple advice is not enough. I'll try to make an appropriate update.

Ok - so I looked at what changed in python - doesn't look like that much?  They changed print into a function and assume float for integer math.  There is even code available that will edit the old 2.x print code into 3.x code (I'm sure it will still take a fix or two)..
I've written in a bunch of languages, but not python - (I'm thinking I'm too old to learn yet another language.. )

Perhaps something else  changed in the latest version of LinuxCNC?

Hello,
I've also wanted to run probe_screen on a recent system - here is modified version from:
github.com/verser-git/probe_screen_v2.8
that runs on Gtk 3, and Linuxcnc 2.10. In fact only 2 files ("psng/python/probe_screen.py" and "python/stdglue.py") had to be modified. While I've tested it on my system, I can not guarantee that all places are modified correctly - please tell me if there are any troubles. 

We have a real meas with all the versions of "probe screen" floating around and I just added one more..... Anybody has any solution for this? My changes will not run on older systems, so I don't think that asking original author to push it to git is an option.
Michael W.
PS. there are only python files in attachment, the rest You need to take from git.

GrumbleMode := ON;
There is no solution to this and it's one of the problems with the whole GIT thing. Original author is happy with what he did and updates occasionally and then finally moves on. After all the source is on GIT so support isn't needed.
Various forks show up again, with minimal support since no one 'owns' the the source so each branch peters out and dies as the authors who made the changes also move on to new projects.
Add to that the fact that the milling machine might be 60 years old with updated servos the basic operations that it performs hasn't changed yet LinuxCNC constantly changes to enhance one's user experience. So that old GIT supported stuff isn't updated but doesn't run on the new systems.
As I get older I must admit I'm getting tired of the constant change for hardware that hasn't changed.
I'm still working with the original screen. About 1/3 of the way through a user manual for probing and setting tool lengths. I may modify the original code to select enter probed tool into table or just use probed length. Likely it won't go to the GIT branch since I've not bothered to learn how to use that nor do I really want to.
GrumbleMode := OFF;