Work with probe

Ouch is right. I shattered the steel shaft on a small probe once and almost crashed my big probe (Hallmark ITTP Probe).

This is the code I added:
ACTION.CALL_MDI("#[4000 + [#5220]] = [#5063 + #[5203 + [20 * #5220]]]")

What is odd is that when I include the probe length I was getting an odd value in #4001. It seems that this probe code is somehow already accounted for in the probe length. I still need to go back and check the numbers but at least it is updating the parameter.

I made this change in probe_routines.py

Thanks. I'll take a look.

Just got back from a social visit to a machine shop with 3 HAAS. He's done commercial work for me before but is now retired and just sits and visits with people.
Showed him the broken probe photos. We all laughed. He said that's why he didn't have a probe because an apprentice would likely toast it and he'd be out $4K for the real one.

None of the folders for my AXIS linuxCNC has probe_routines.py.

Really didn't like not having a Z probe and having to wait up to 4 weeks before a new one arrives.  I'd like to solve my problem before I forget what I was doing and have to start again.

So first.  I made a probe. 
 

Then I took a look at the "probe_z_minus_wco.ngc" file and started thinking about how the parameters were set up or for that matter if they aren't provided what is used?

So I changed "_psng_probe_z.ngc",  which calls  "probe_z_minus_wco.ngc", to provide all 15 parameters and added additional diagnostic print statements in "probe_z_minus_wco.ngc".

Now it behaves... almost. 

Here's the output.
Current coordinate system is 1.000000 identified as 540.000000
 Workspace_Z is -6.326753
 Probe Tool Safety Check
 Current Z Position 3.158367 -- Fast Probe starting
 Probe Position = 2.886978
 Probe Error check, 5070 will be 0 if failed
 Move to z_clearance height for slow probe
 analog aio output to gui DRO "Z PROBED POSITION"
 5220=1.000000
 z_minus_probed=2.960507
 5063=2.960507
 workspace_z=-6.326753
 _ini[PROBE]LENGTH=4.784000
 Executing G10 with Z[2.960507 + -6.326753]
ERROR: index out of range, 7 not in [0..4] (increase num_aio/EMCMOT_MAX_AIO=64)

ERROR: index out of range, 7 not in [0..4] (increase num_aio/EMCMOT_MAX_AIO=64)
('error', 'See notification popup')

I have no idea where the ERROR: index out of range comes from.Any suggestions?

I don't use the analog-in pin. I'm not sure I even need that. I'll check the link you posted and see why it's there.

Thank you for your reply.
John

jcdammeyer wrote:

None of the folders for my AXIS linuxCNC has probe_routines.py.

Keep in mind I found that file on my LinuxCNC 2.9 with QTDragon_HD on Debian 12 (Bookworm) machine that I am in the process of migrating to.  I believe that the probe code is from basicprobe.  I never went looking for that file on my current LinuxCNC 2.8.4 QTDragon machine which is the one where the probe_z_minus_wco.ngc came from.

phillc54 wrote:

This line is referencing analog-in pin 7, there are only 4 analog pins by default (0~3).

  M68 E7 Q[#<z_minus_probed_position>]

That can be changed when loading the motion module as the error message indicates:

[code](increase num_aio/EMCMOT_MAX_AIO=64)

http://linuxcnc.org/docs/devel/html/man/man9/motion.9.html

[/code]

Ooh, that error sounds familiar.  I think I faced that years ago and did what was described above.

Alright!  Found one of the problems.  The one that destroyed my probe and also snapped apart one of the micro-switches in my intermediate probe after I thought I'd fixed the issue.

The issue lies in the psng_probe_table.ngc and surfaced when I started using the probe_z_minus_wco.ngc.  I added diagnostics in the form of (PRINT, ) statements.

Here's a piece of it.

Notice the save current Z position.  This is the sort of documentation that is so typical in a lot of software.   I can see they are saving the Z position.  Not why.  It's like a Pascal Statement like Pi := 3.14;  And the comment reads Assigning PI into the variable Pi.  Duh!

Now once the probing is complete which called _psng_probe_z.ngc  which in turn called probe_z_minus_wco.ngc where the #4000 new G54 (or whatever co-ordinate system was active) was updated since we now have a new zero position.

Come back to psng_probe_table.ngc and here's the fault.  I added a test and message to prevent future switch damage.
So why is it happening?
Well when the <z> value is saved it may well be say -2.0
While probing the knee moves up slowly, switch opens and then knee moves down again until switch closes again.  Now the G38.2 is done and it's moved down just far enough for that clearance parameter.

The probe touched the top of the 1-2-3 block and that becomes our new 0.0000 since G54.Z has now been changed.  The probe is above the work by the #<z_clearance>]

And then for some undocumented reason the code, at full G0 speed heads to that saved <z> location in the psng_probe_table.ngc G-Code.
A negative move, by convention is towards the tool.  So our tool (the probe) is still 0.2" above the test point and then the knee is told to move to -2.0 at full 150 IPM.  

After crushing the tool and switch assembly pressing hard now against whatever was probed (1-2-3 block on table) the servo drive faults with a following error since it's telling the motor to go to -2.0 but the knee can't go any higher since the probe can't crush any thinner.

 

So I added num_aio=8 and un-commented M68 E7 Q[#<z_minus_probed_position>]
The error is gone but I don't see any difference in program operation. so I'm not sure where the psng probe software is using that.